Review Technical GEO Health Before Your Next Site Deploy

Two lists describe your site and they are rarely the same: the pages you chose to monitor, and the URLs engines actually quote. Diff them, then read the technical snapshot, because the diff decides which half of it matters. Nothing here needs a log or analytics integration, so once your crawler logs and GA4 are wired up, the observability playbook decides whose problem each fetched but uncited page is.

The GEO problem it solves

Merging the two lists is what the product already does. get_page_presence labels every page WORKING at three or more citations, NEEDS_ATTENTION at one or two, NOT_CITED at zero, and DISCOVERED for a cited path never in the monitored set. Read DISCOVERED first: engines quoted something nobody registered, so nobody is maintaining it either.

The join is where this goes wrong. get_page_presence groups by a normalised path; get_source_urls groups by the raw exact URL, and its domain filter is exact string equality, so an apex domain and its www host are unrelated values to it. Diff carelessly and you manufacture gaps that are only casing and hostnames.

Technical status arrives afterwards and answers one question: is anything blocked. A robots.txt tuned for Google can still be wrong for retrieval, since OpenAI separates OAI-SearchBot, which governs inclusion in ChatGPT search results, from GPTBot, which governs training use.

How the workflow breaks down

1. Build the two inventories. get_page_presence returns the merged page view with citation counts, distinct-question counts, average position and providers. get_source_urls, filtered to your domain string, ranks the exact cited URLs. Neither returns prompt text.

2. Diff them on a normalised key. Lowercase the host, drop www, strip query and fragment, trim the trailing slash. Keep the raw URL beside every key, so a hostname split stays visible instead of reading as a gap.

3. Read the technical snapshot once. get_technical_status returns the stored robots.txt, llms.txt and sitemap statuses, an AI-readiness score, the crawler tokens marked Disallowed, issue counts by severity, and open page issues each carrying its URL. Stored analysis, not a live crawl.

4. Order the backlog by the rule below, not by effort tier.

What a run actually returns

A 263-page site came back with 13 pages cited, 250 not, and 4 DISCOVERED, paths engines had quoted that were never in the monitored set. Those four carried 1, 5, 5 and 6 citations.

That distribution is the normal one, and it is why the backlog rule matters more than the scan. Three of the four DISCOVERED rows clear the three-citation bar and open the queue. The 250 NOT_CITED rows are not 250 tasks: most are policy pages, keyword indexes and release notes nobody would ever quote, so only those also carrying a returned technical issue earn a place this cycle. The single DISCOVERED page at one citation goes in the log.

What to do with the output

Three empty states look alike and are not. A null technical block means the brand was never analysed, while an empty blockedCrawlers array means it was analysed and nothing is disallowed. And a brand with no domain set returns zero pages with zero stats, which is not a clean site. Resolve those before ordering anything.

Then work the list top down and resist reshuffling it.

Blocked tokens come first: a non-empty blockedCrawlers is a site-wide access defect outranking every page-level item, because no amount of content work routes around it. Then every DISCOVERED page with three or more citations joins the monitored set this cycle, since it is already earning citations unmanaged. Then NOT_CITED monitored pages that also appear in the returned open-issue list, the only subset with technical evidence attached. Then the remaining NOT_CITED pages, an editorial question that should not reach engineering. Leave NEEDS_ATTENTION alone: one or two citations is a single answer moving, and it will move again without you.

The Complete Prompt

I want to diff my monitored pages against the URLs AI engines actually cite. List the brands I monitor, and ask which one to use if there is more than one.

1. Run get_page_presence. Return every page with its status, one of WORKING, NEEDS_ATTENTION, NOT_CITED or DISCOVERED, plus citation count, distinct-question count, average position and providers. Do not claim the tool returns prompt text.
2. Run get_source_urls with my domain. Its domain filter is an exact string match, so if it comes back empty, retry with the other host before concluding I am never cited.
3. Diff the two on a normalised key: host lowercased with www removed, path lowercased, query and fragment stripped, trailing slash trimmed. Keep the raw URL beside each key. Report monitored pages with no citation, and cited URLs with no monitored page. Flag any pair differing only by host or casing as a join artefact, not a gap.
4. Run get_technical_status. Report the stored robots.txt, llms.txt and sitemap statuses, the AI-readiness score, the Disallowed tokens, issue counts by severity, and the open page issues returned. Call it stored analysis, not a live crawl. If the technical block is null, say the brand was never analysed rather than reporting a clean result.
5. Produce one ordered backlog: Disallowed tokens first as a single site-wide item; then DISCOVERED pages with three or more citations; then NOT_CITED pages appearing in the returned issue list; then remaining NOT_CITED pages as editorial work; then NEEDS_ATTENTION as no action this cycle. Give each item its evidence row and one validation step. Where a tier is empty, say so and move on.