An audit can prove that a page returns an error or that important service information is missing. It cannot prove that every assistant will recommend a moving company once those defects are fixed. Define the audit’s evidence standards before accepting a score that blends technical readiness with unobserved recommendation behavior.
View full-size graphic ↗Write two audit questions instead of one broad promise
The technical question is whether intended public information can be accessed and understood under the systems being examined. The observational question is whether the business appears in a defined sample of actual answers. Both matter, but they require different collection methods.
Scroll the table horizontally to compare all columns.
| Workstream | Evidence | Conclusion it can support |
|---|---|---|
| Technical access | Responses, directives and rendered content | A specific access or interpretation issue |
| Business facts | Verified operating records and public pages | An inconsistency or missing explanation |
| Answer observation | Saved responses with prompts and context | Presence or absence in that sample |
| Commercial measurement | Referrals and qualified-opportunity records | Observed demand under an attribution rule |
Agree on the pages, platforms and markets included. A review of five public pages should not be sold as a complete audit of every branch, crawler and assistant. Record exclusions so the next reviewer knows what remains untested.
Create a reproducible technical evidence sheet
For each important page, record the requested URL, final URL, response status, robots directives, canonical destination and whether the main answer is present in accessible content. Check the real deployment rather than only the CMS preview.
Google’s technical requirements distinguish accessible, successful and indexable pages from guaranteed indexing. Its noindex guidance also requires a crawler to access the page to see the directive. A robots block and a noindex instruction are different controls. [1] [2]
Scroll the table horizontally to compare all columns.
| Field | Example of the required detail |
|---|---|
| Observed fact | A public service URL returns an error |
| Reproduction | URL, method, date and response evidence |
| Business impact | Customers and crawlers cannot read the service explanation |
| Proposed repair | Restore the page or intentionally redirect it |
| Retest | Confirm response and content after the change |
For other platforms, inspect their documented controls separately. OpenAI’s search crawler and training crawler have independent roles; a single ‘AI bots allowed’ checkbox can conceal materially different choices. [3]
Check whether the available answer is worth retrieving
An accessible page can still fail to explain the business. Review service fit, geography, estimate process and credible evidence. Mark unsupported statements separately from missing detail. A company should not solve an evidence gap by adding an invented review or a fictional office address.
Use a real customer task as the content test
For an office relocation inquiry, can the reader determine whether the mover handles that work, what information is needed and how to reach the appropriate team? If the page only says ‘we move everything,’ the audit should specify the unresolved decision rather than calling for more keywords.
A question-to-page map helps turn this review into a focused content repair plan.
Keep answer observations in a separate record
Record exact prompts, product surface, visible mode, location context, date, conversation state, mentions and linked sources. Preserve the complete answer where permitted, not just a cropped favorable sentence. Include failed or unavailable observations in the collection log.
A citation should be checked against the statement it accompanies. If the answer names a similarly branded company, record an identity mismatch. If no source is shown, mark that limitation instead of inventing the page the assistant supposedly used.
Prioritize repairs by confidence and customer value
Rank findings by the strength of the evidence, practical impact and effort to fix. A broken estimate path is a confirmed customer problem; a theory about an assistant’s preference may be an untested hypothesis. Both can appear in the report if the distinction is explicit.
Give each accepted action an owner and retest condition. Close technical findings when the repair is verified, while leaving answer observations as dated observations. Do not mark ‘AI visibility fixed’ solely because a schema validator passes.
A useful final report includes completed checks, unresolved access limits, factual corrections, sampled answers and commercial evidence. It should help the operator choose the next improvement without promising control over a third-party recommendation system.
Common questions
Can a crawler audit prove that assistants recommend us?
No. It can identify access and content issues. Recommendation evidence requires actual observations with a documented sampling method.
Should technical and visibility scores be combined?
Keep the underlying results separate even if a summary score is used. Otherwise a technical pass can be mistaken for demonstrated discovery or customer demand.
Your next step
Require two evidence sheets: one for reproducible site findings and one for observed answers. Use each to support only the conclusions it can establish.
Sources & editorial notes
Platform claims cite the documents below. Operating frameworks and labeled examples are MoverFuel editorial analysis, not client results or industry benchmarks.
- Google: Search technical requirementsTechnical eligibility does not guarantee indexing. Reviewed .
- Google: block indexing with noindexCrawler access is needed to observe noindex; robots blocking differs. Reviewed .
- OpenAI: overview of crawlersIndependent OpenAI crawler controls. Audit sheets and prioritization are original recommendations. Reviewed .
