← Back to GEO LibraryAUDIT / SEARCH AND ANSWER SYSTEMS

AI search audit: what to check first

An AI search audit should locate the first broken link in the evidence chain. Publishing more content before that diagnosis can add cost without improving eligibility, accuracy or demand.

Updated
02/09/2026
Publisher
NobleJackal
Version
1.1
Source review
Primary sources reviewed
01

Freeze the question before collecting evidence

An audit begins with scope, not a crawler. Record the domain, canonical host, markets, languages, priority services and the commercial questions the business needs answered. Decide whether the review concerns technical eligibility, non-branded search discovery, brand accuracy, source citations, referrals or qualified enquiries. If those outcomes are mixed together, the final report will make activity look like progress.

Record the date and the available access as well. A public-site review can inspect rendered pages and HTTP behaviour. Search Console adds indexing and query evidence. Analytics can connect visits to actions. Server logs can show verified crawler requests. A model response is useful only as a dated sample. Each source answers a different question.

02

Test the eligibility layer first

Confirm that important URLs return the intended status, are not blocked, contain indexable text and declare a coherent canonical. Follow redirects to their final destination. Compare internal links, sitemap entries and canonical URLs rather than reviewing each file in isolation. A page included in a sitemap but canonicalised elsewhere is not a clean signal.

For multilingual sites, check every equivalent set as a unit. Each page needs the correct language, a same-language self-canonical and reciprocal alternates. Forced IP redirection can hide language versions from people and crawlers; stable URLs and visible language controls are easier to audit. Arabic also needs a genuine right-to-left reading experience, not only a translated string inside a left-to-right layout.

03

Reconcile the entity before optimising the wording

Collect the organisation name, legal operator, founder, services, markets, contact routes and other material facts from controlled sources. Then compare the homepage, company profile, service pages, author pages, structured data, public profiles and machine-readable files. Record contradictions instead of selecting the version that sounds most impressive.

Answer systems often have to resolve relationships between a brand, its legal entity, an individual, a sister company and a delivery partner. If the website blurs those relationships, more copy can amplify the error. The audit should identify the canonical fact, its owner, its evidence and the surfaces that require correction.

04

Evaluate whether the content deserves retrieval

A technically available page may still add little. Review whether it answers a recognisable question, defines the terms it uses, gives the reader enough context to act and shows where material claims come from. Pages that repeat category language without experience, method or evidence are easy to replace with another result.

Map existing pages before proposing new ones. Two articles competing for the same purpose can weaken internal clarity, while a missing comparison or buyer guide can leave a valuable decision unanswered. The recommendation may be to expand, merge, redirect or retire a page. An audit that always concludes ‘publish more’ has not examined the cost of duplication.

05

Separate crawler policy by purpose

Search retrieval, user-requested fetching and model training are different choices. For OpenAI, OAI-SearchBot concerns ChatGPT Search discovery, GPTBot concerns potential training use, and ChatGPT-User can be triggered by a person. Similar distinctions exist across platforms and may change, so the audit should use current publisher documentation rather than a copied robots template.

Check the CDN and firewall as well as robots.txt. A permissive file does not help if the hosting layer returns a challenge, rate limit or error to the crawler. Conversely, a successful request proves access on that occasion, not indexing or citation. The report should retain that boundary.

06

Sample AI answers without manufacturing a ranking

Build the query set before running it. Include branded, category, problem, comparison and method questions that a real buyer might ask. Fix the language, market, product surface, account state and collection date. Store the full answer and every cited URL, including unfavourable and absent results.

Score observations by type: mention, linked citation, accurate description, inclusion in a comparison, recommendation and referral. Do not compress them into one unexplained GEO score. Repeatability matters more than a dramatic screenshot, and a small sample should remain labelled as a small sample.

07

End with an action register, not a scorecard

Every material finding needs an affected URL, evidence, owner, priority, proposed change and verification method. Technical defects can be tested after release. Editorial claims require source and approval. Platform outcomes require time for recrawl and a dated observation window. Unknowns should stay unknown until the necessary access or evidence exists.

The final sequence should follow dependency, not excitement: remove hard eligibility barriers, correct entity facts, repair internal architecture, improve priority decision pages, then expand content where a distinct need remains. Measurement continues after publication. A launch is an intervention date, not proof of an outcome.

DIRECT ANSWER / AUDIT STANDARD

An AI search audit should produce evidence and decisions, not a mysterious score.

A useful audit establishes what can be verified now: which canonical pages are publicly reachable, which search and retrieval agents can receive them, whether the important language versions are internally consistent, what the search platforms report, and how a fixed sample of answer systems mentions, cites or describes the organisation. Every finding should point to its source, collection time, confidence and next decision.

The audit must keep several layers apart. A public preflight can test delivery, rendered content, metadata, structured data, internal paths and crawler policy. Search Console or Bing Webmaster Tools can add index, query and citation reporting available to the verified property. A prompt benchmark can observe selected products at a stated time. Analytics and enquiry records are needed before any visibility observation can be connected to qualified demand.

The output is therefore not one universal GEO percentage. It is an evidence ledger, an issue register and a prioritised release plan. A high-severity block affecting every commercial page deserves action before another article is commissioned. A single missing citation in one volatile answer sample may justify observation, not an emergency rebuild.

THREE AUDIT DEPTHS

State the access level before stating the conclusion.

Different evidence becomes available at each depth. A credible report names what it could inspect and leaves unavailable evidence marked as unknown.
  1. 01

    Public preflight

    Tests the same public surface available to users and named crawlers: status, redirects, canonical, robots directives, sitemap and hreflang parity, rendered content, internal discovery, structured-data agreement, mobile layout and security challenges.

    Produces: route inventory, reproducible requests, rendered captures and externally checkable findings.
  2. 02

    Access-enabled audit

    Adds verified-property and first-party evidence such as URL inspection, index coverage, query and page performance, Bing AI citations where available, analytics, consented referrals, server logs and release history.

    Produces: platform exports, date ranges, filters, aggregation notes and finding-to-record links.
  3. 03

    Observed answer benchmark

    Runs a fixed, versioned set of branded and non-branded questions across agreed products, languages and markets. It records the full answer, cited URLs, description accuracy and recommendation context without treating the sample as a platform census.

    Produces: prompt register, raw observations, coding rules, denominators and comparison limits.

EVIDENCE LEDGER

Every layer needs its own proof and its own decision.

The table prevents an activity receipt from being promoted into an outcome and makes disagreement reviewable.
Audit layerMinimum evidenceDecision it supportsWhat it does not prove
Release truthPublic HTTPS body, headers, checksum and rendered capture for the intended canonical URL.Whether the approved version is actually live and usable.That a crawler has discovered or indexed it.
Crawler deliveryBot-specific response, final URL, content type, body parity, robots state, rate-limit and challenge detection.Whether a named agent can technically receive the page.That the platform used the page in an answer.
Canonical ownershipRedirect, canonical, hreflang, internal-link and sitemap agreement for each locale.Which URL should consolidate and represent the intent.That the platform selected the same canonical.
Search discoveryVerified platform records for crawl, index status, impressions, clicks, queries, pages and countries.Where discovery or search demand is absent, weak or growing.Complete query coverage or AI citation share.
Answer observationExact prompt, product, surface, language, market context, timestamp, full answer and source URLs.Whether the sampled system mentioned, cited or described the entity accurately.Stable behaviour across all users, prompts or future model versions.
External corroborationIndependent records that support material identity, expertise, publication and service claims.Which claims are well supported and which need stronger public evidence.That a platform must trust, rank or recommend the organisation.
Commercial actionConsented referral, landing path, qualified brief, call, proposal and won-work records with attribution limits.Whether discovery contributes to useful demand and where the journey fails.Causation from one ranking, citation or content change on its own.

REPRODUCIBLE METHOD

Run the audit as five controlled passes.

01 / FREEZE SCOPE

Define the market, decision and canonical set before collecting data.

Name the business question first: technical eligibility, non-brand discovery, source citation, provider recommendation or conversion. Record the countries, cities, languages, devices and products that matter. A worldwide claim cannot be tested by one English prompt from one account.

Freeze the route list and capture the approved version. Separate core commercial pages, evidence publications, entity records and supporting articles. This makes later additions visible instead of allowing the denominator to change whenever the result looks weak.

02 / PROVE DELIVERY

Inspect the public response before interpreting platform reports.

Follow every redirect and compare the final page with its canonical, language declaration, hreflang set, sitemap membership and internal links. Render the page at representative desktop and mobile widths. Test the user agents relevant to search discovery and user-requested retrieval, including the CDN and security layer rather than robots.txt alone.

Record exact failures: a 403 for OAI-SearchBot, a soft 404, an English canonical on a German page, main content absent from initial HTML, or a mobile overlay covering navigation. Vague labels such as ‘AI not ready’ cannot be verified after the report is delivered.

03 / READ PLATFORM EVIDENCE

Use each console for the questions it can answer.

Search Console is the source of truth for Google Search performance; analyse clicks, impressions, CTR and position by query, page, country, device and date range while respecting aggregation and omitted-query limits. Use URL and index reports for discovery questions. Do not infer an index state from an HTTP response or a site: search alone.

Where Bing AI Performance is available, preserve citation counts, cited pages and sampled grounding queries separately from conventional search metrics. Microsoft states that these figures are not a measure of rank, page importance, authority or answer placement. The report should keep that limitation beside the chart, not bury it in a footnote.

04 / SAMPLE ANSWERS

Build a question set that represents real decisions.

Include branded verification questions, non-branded category questions, comparison questions and buyer-stage questions. Stratify them by language and market. Keep one versioned core set for trend comparison and a smaller exploratory set for emerging wording; never replace losing prompts mid-period to improve the score.

Code unlinked mention, linked citation, cited URL, factual accuracy, recommendation and refusal as separate fields. Preserve the complete response. A brand can be cited but described wrongly, mentioned without using its site, or listed without being recommended. Those outcomes require different remedies.

05 / PRIORITISE AND HAND OFF

Rank work by consequence, reach, confidence and effort.

Prioritise a finding when the evidence is strong, the affected route set is broad and the commercial consequence is material. First remove access and canonical blockers; then repair source quality, entity ambiguity and intent gaps; then test incremental presentation changes. Keep speculative ideas in an experiment queue rather than presenting them as defects.

Every action needs an owner, affected URLs, acceptance test, rollback path and measurement date. Close the audit only when implemented findings have been rechecked on the public site. Publication is not the final outcome: indexing, visibility, citation and qualified demand each run on a different clock.

USEFUL DELIVERABLES

A buyer should be able to act on the report without decoding it.

The exact scope may vary, but these records make the work portable, reviewable and measurable.
01

Canonical inventory

The agreed page set by role, locale and market, including redirects, preferred URLs and ownership conflicts.

02

Evidence ledger

A source-linked record of each test, timestamp, access level, result, confidence and limitation.

03

Issue register

Reproducible findings with affected routes, severity, commercial exposure and an explicit acceptance test.

04

Answer benchmark

A versioned prompt set, raw responses, citations and coding rules with the denominator left visible.

05

Prioritised release plan

Work ordered by consequence and evidence, with owners, dependencies, rollback and verification.

06

Measurement plan

Baseline dates, review windows and separate metrics for crawl, index, search, citation and qualified action.

AUDIT RED FLAGS

Eight signs that the report is selling certainty it did not earn.

A polished dashboard does not repair an undefined sample or an unsupported causal claim.
01

One unexplained GEO score

The inputs, weights, products, dates and denominator are hidden, so the number cannot be reproduced.

02

Crawler allow equals visibility

Permission is reported as if it proved crawl, indexing, retrieval or citation.

03

A favourable screenshot as baseline

The exact prompt, product, locale, account context and failed observations are absent.

04

Branded and non-branded prompts mixed

Known-entity recall is blended with discovery by people who have not named the brand.

05

Rank, citation and recommendation merged

Distinct outcomes are compressed into one visibility label, hiding where the journey stopped.

06

No public-site verification

Recommendations are based on a crawler export or local build without checking the actual HTTPS response and rendered page.

07

Generic fixes with no acceptance test

‘Improve authority’ and ‘add schema’ are listed without affected URLs, expected state or verification method.

08

Outcome promised before observation

Future ranking, citation, recommendation or revenue is guaranteed despite platform volatility and missing first-party evidence.

CONNECTED RECORDS

Use the audit to move from evidence to the next controlled action.

These NobleJackal records cover public preflight, discovery stages, measurement, crawler policy, source quality and implementation.

QUESTIONS / PRECISE ANSWERS

Questions buyers should ask about an AI search audit

01What is the difference between an AI search audit and a technical SEO audit?

A technical SEO audit focuses on crawling, rendering, canonicalisation, indexability, architecture and performance. An AI search audit includes that eligibility layer but also examines crawler purpose, source quality, entity consistency, answer observations, citations and measurement boundaries. Neither should replace the other.

02Can an AI search audit be completed without Search Console or analytics access?

A public preflight can verify many technical and editorial conditions without account access. It cannot confirm private index coverage, complete query performance, verified crawler logs, referrals or qualified demand. A responsible report labels those fields unavailable rather than estimating them.

03How many prompts should an AI visibility benchmark use?

There is no universal valid number. The set should be large and diverse enough to represent the agreed decisions, languages and markets, yet stable enough to repeat. Publish the denominator, sampling method and raw observations; do not choose a count because it produces a favourable percentage.

04Does an IndexNow or sitemap submission close an audit finding?

It closes only the notification action when the endpoint accepts it. Discovery, recrawl, canonical selection, indexing, ranking and citation remain open until their own evidence appears after a reasonable processing window.

05What should happen after the audit?

Approve a bounded release plan, implement the highest-confidence blockers first, verify the public result, then observe indexing, search performance, answer citations and qualified actions on separate dates. Keep unresolved hypotheses in an experiment register instead of presenting them as completed fixes.

Practical checklist

  • Record scope, markets, languages and available evidence
  • Verify status, crawl, index, canonical and hreflang conditions
  • Reconcile organisation, person, service and partner facts
  • Map content purpose before adding URLs
  • Test search, retrieval and training policies separately
  • Preserve exact AI-answer samples and cited URLs
  • Assign every action an owner and verification state

Official sources

  1. Google Search CentralOptimizing your website for generative AI features on Google Search
  2. Google Search CentralAI features and your website
  3. Google Search CentralTell Google about localized versions of your page
  4. Google Search Console HelpPerformance report: search results
  5. Google Search CentralUsing Search Console and Google Analytics data for SEO
  6. OpenAIOverview of OpenAI crawlers
  7. IndexNowIndexNow protocol documentation
  8. Microsoft Bing Webmaster BlogIntroducing AI Performance in Bing Webmaster Tools