The order to fix a failed AI visibility audit

The failures cluster, and they have a dependency order. Doing them in the wrong order means redoing work: rendering pages that a firewall blocks, or writing structured data for content a crawler already cannot read.

Here is the order we recommend, with the reasoning at each step.

1. Access first (A1)

Nothing else matters if the crawler is refused. Check robots.txt for the AI user agents and test the page with their user agent:

curl -sS -A "GPTBot/1.0 (+https://openai.com/gptbot)" -o /dev/null -w "%{http_code}\n" https://example.com/

A 403 here is the whole problem. Fix the firewall or bot rule before touching anything else.

2. Content in the HTML (A2)

Then make sure the text is in the response. Test without a browser:

curl -sS https://example.com/ | python3 -c "import sys,re;h=sys.stdin.read();print(len(re.sub(r'<[^>]+>',' ',h).split()),'words')"

A shell with fifty words means the rendering work comes before the schema work. Pages that answer questions come first — not the homepage.

3. Structure the page states (B1, B3)

Title, description, and a heading tree that says what the page is about. This is cheap, and it is what an assistant reads to decide whether the page is even about the question.

4. Structured data (B2)

Now that the content is real and the page says what it is, mark it up: the entity for the site, the type for the page, and the connection between them. Marking up a shell would just describe an empty page accurately.

5. Make it quotable (C3, C5)

Lead with the answer, break the detail into short paragraphs, lists and tables, and keep one sentence per section that can be quoted without context. Add the update date and the author (C4) — a claim with a date is easier to trust than a claim without one.

6. Then the plumbing (A3, A4, A5)

Sitemap accuracy, dead links, response time and HTTPS. These are not glamorous, but they decide whether the crawler comes back: a site that 404s a third of its sitemap gets crawled less often, which slows everything above.

After the fix, re-scan

A fix you did not re-measure is a hope. Re-run the same check and compare item by item — the report keeps the before and after for identical checks, so "we improved it" is a diff rather than a memory. If an item still fails after a change, the evidence next to it usually says why: a different URL, a cached response, or a second firewall rule nobody remembered.