A GEO Audit Checklist: Can AI Search Read Your Website?

Choose pages that represent the customer journey

A homepage-only check can miss the page that actually explains the service. Start with the homepage, one priority service page, the pricing or quotation page, the contact page, and a recently published article. Add a deliberately nonexistent URL to check how the site handles mistakes.

Write down the expected result before testing. The service page should return the service description; the contact page should explain a working contact method; the missing URL should return a genuine not-found response. This turns an audit into a comparison against a clear expectation.

Profound's Pages announcement connects page-level content, crawler activity, and citations in one view. The useful lesson for this checklist is to examine the actual page behind an observation. A broad visibility number cannot tell you whether one important URL is serving an empty response.

Inspect the response before the visual design

Ask your developer to save the HTTP status, relevant headers, and initial HTML for each selected URL. You do not need to interpret every line of code. Search the saved response for the page's service name, a distinctive paragraph, its main heading, and the contact link.

Compare that response with the page a person sees. If the browser shows detailed services while the first response contains only a loading indicator, document the gap. Rendering capabilities vary between consumers. Serving essential information directly makes the site easier to inspect and reduces dependence on a successful chain of scripts.

Also inspect the response body when the status is 200. A security challenge, generic error, or homepage fallback is not the intended service page. Conversely, a visually attractive error page should not pretend to be a successful resource. Keep a screenshot and the response evidence together so the finding is reproducible.

Check discovery and indexing controls together

Review the public robots policy, page-level indexing directives, canonical URL, sitemap, and incoming internal links as a set. They answer different questions and should express a consistent publishing decision.

Google's robots.txt documentation distinguishes control of crawling from removal from search results. Do not treat a robots rule as a reliable privacy boundary. Public content and private systems need different access arrangements.

A sitemap should not be the only route to useful content. Link a service article from its hub and connect it to the service it explains. Use descriptive link text so people can decide whether following the link will help.

Check what happens at the network edge

A page can work locally while a CDN or firewall changes the production response. Test the live domain and a deep URL from a normal unauthenticated request. Record redirects and any challenge page. Ask the person managing the edge configuration to inspect the corresponding event rather than disabling protection broadly.

Document the intended policy for search bots, training crawlers, and user-triggered retrieval separately. A synthetic request using a bot's User-Agent can reveal a rule, but it is not proof that a verified bot will receive the same treatment. For that, correlate verified traffic or use the search platform's inspection workflow.

When an audit tool receives a 403, retain the timestamp, URL, request conditions, and response information. The failure could involve a policy, a network path, or the tool itself. Avoid labelling the whole site inaccessible from a single unexplained result.

A real diagnosis: why our local sitemap returned 404

On September 28, 2026, FoundUp's local /sitemap.xml returned 404 while the production file returned 200 and listed nine pages. The cause was a build-mode difference: the local preview deliberately omitted discovery files and added noindex, while the production build generated them.

The useful repair was to select the intended build, not create a second hand-maintained URL list. The local SEO inspection build can generate a registry of 25 pages: nine core pages, ten articles and six comparison guides. It must be running to serve those pages. Do not infer production publication or search indexing from the build registry. That local count does not mean all 25 were deployed or indexed at the time of the observation.

For your site, compare the live file, local output directory and build command. Also inspect response headers: a sitemap can exist while a preview-wide noindex header remains active. A file's presence, a page's indexability and confirmed search indexing are three different checks.

Use a normal GET request when inspecting the body:

curl -sS -D - https://getfoundup.ai/robots.txt
curl -sS -D - https://getfoundup.ai/sitemap.xml
curl -sS -D - http://localhost:8787/sitemap.xml

These commands inspect public responses. They do not impersonate a verified crawler or query a search engine's index.

Historical check: September 29, 2026, 04:58 UTC

At 04:58 UTC on September 29, 2026, a fresh production check found nine working core pages and nine sitemap entries. All ten article routes and six comparison routes returned 404. The local source generated 25 pages in an in-memory check, while the local preview server was not running. These are different release states, not proof that search engines have indexed the drafts.

The later production Pricing and FAQ checks at 05:57 UTC showed new page layouts. That is another reason to retain the time of a review and recheck before publishing a local copy. These observations describe the reviewed release; they do not claim a search engine fetched it.

Turn findings into small, testable repairs

Give each issue a URL, observed behavior, expected behavior, owner, and retest method. “Improve SEO” is too broad. “The pricing page returns a challenge to the test request; inspect the matching edge event and verify the intended public response” is something a developer can investigate.

After a repair, repeat the same request and check another representative page for unintended effects. For routing changes, also retest legacy URLs and the missing-page response. For content changes, inspect the initial HTML and check that the visible facts agree with metadata and structured data.

Finish with two lists: technical checks that passed and external outcomes that remain unproven. A clean response does not establish indexing, rankings, citations, or real-user speed. Pair this audit with a maintenance process and keep the publishing format simple using the HTML and Markdown guide.

Post-launch verification: September 29, 2026

At 07:42 UTC on September 29, 2026, all 25 canonical pages returned HTTP 200. The sitemap included all ten article URLs and six comparison URLs. The full-text reference contained 25 page sections, and the RSS feed contained ten entries. These checks confirm publication and access; they do not establish search indexing or AI citations.

The earlier failures remain part of the record. The later check closes the publication issue at that time, without claiming that an independent search or AI platform had refreshed its copy. Read the dated change record and the reference-file check for the related follow-up.