AI readiness audit: our method before any results

Publish the method before the success story

A credible audit article begins with what was inspected and what was not. For our own live site, that means saying plainly that this article has no completed dated run. There are no scores to celebrate, failures to dramatize or repaired pages to claim. The method is the useful deliverable today.

When a run exists, its record should identify the domain, date, page set, check versions and reviewer. A static source review should be called exactly that. A production browser check and a real assistant observation should have their own evidence, rather than being implied by the same word “audit.”

This distinction also protects your team. If an owner approves work because they believe a citation problem was measured, a static heading suggestion is the wrong basis for the decision. Naming the evidence type keeps the next step proportionate to what you actually know.

Choose a small, purposeful page set

Start with pages that answer important reader questions: what the organization does, who operates it, how to use its offering, what it costs where applicable and how to contact it. The selection should follow the site, rather than a universal checklist copied without context.

For an eventual advisorseo.ai run, a reasonable proposed sample would include the home page, capability reference, connection docs, pricing availability and operator identity. That is a proposed sample, not confirmation that those live pages were fetched or passed any test.

Record the canonical URL you intend to inspect and any redirects. Note language, country or account variants. If a public visitor and a signed-in user receive different content, say which response your check reads. A single static fetch cannot stand in for every variant.

Write down exclusions too. Private account pages should not become public merely to make an audit look complete. Keep the reader's legitimate access needs and the site's privacy obligations ahead of a heuristic completeness score.

Check what the static response actually contains

Ask for the page title, primary heading, relevant body passages and any structured-data types present in the fetched HTML. Compare them with the question a reader needs answered. A technically present heading may still be vague; a clear heading may be absent from the static response but visible after rendering.

Inspect the authorized page's static HTML only.
Show the title, main heading and the passage answering its purpose.
For each observation quote the supporting text or markup.
Separate missing evidence from a confirmed absence.
Do not claim that an answer engine fetched or cited this page.

A helpful response gives the source evidence before its interpretation. If the page says “help for your next step” but never identifies who provides the help, an editor may need a clearer operator statement. That is a page-clarity decision, not a measured AI ranking factor.

Check the browser version separately. Hidden text, collapsed sections and script-inserted content can change what a person sees. Do not fix a static warning by adding text that misleads the reader or duplicates an existing visible answer.

Inspect access rules without predicting retrieval

Read the relevant robots rules and identify which agent and path each rule concerns. A rule can express permission or restriction; it does not show whether a request happened. Confirming actual crawler activity requires a different source, such as appropriate server records, with its own limitations.

Do not treat every restriction as an error. An organization may intentionally restrict private, licensed or low-value material. The audit should ask whether the rule matches the owner's intent. Removing controls simply to improve a readiness score can create a worse site.

Also distinguish robots instructions from authentication, response status and indexing controls. They are different mechanisms. Ask a technical reviewer to inspect an apparent conflict rather than relying on one summarized “blocked” label.

A useful action record names the intended audience and the access decision. If public help content is accidentally unavailable, propose a narrow correction and a recheck. If a restriction is deliberate, record the rationale and leave it in place.

Review passages for clarity and evidence

A page passage should answer a real question with enough context to stand on its own. Identify the subject, the condition and the limitation. “It works everywhere” is weak because the reader cannot tell what “it” means or which environments were tested.

For AdvisorSEO, a factual passage should keep planned answer tracking close to its planned status. It should distinguish static readiness from actual citations and source-supported publication paths from verified customer workflows. Clarity comes from preserving those boundaries, not deleting them for a more dramatic promise.

Ask the assistant to identify ambiguous passages and propose alternatives using only supplied facts. Review each alternative against the product reference. A rewrite can be easier to read while quietly broadening the claim, especially when it replaces a qualified verb with an absolute one.

Use short sections and descriptive headings because they help people find answers. Do not claim that a particular sentence length, format or heading automatically earns inclusion in an assistant answer. That would need evidence beyond an editorial preference.

Check structured data against the visible page

Read the structured-data fields and compare them with what a visitor can see. A named operator, publication date or FAQ answer should not contradict the page. Markup can make facts explicit, but it cannot turn an invented author or unsupported review into reliable evidence.

Google's public AI-feature guidance says there are no additional requirements or special optimizations needed for those features. Google guidance, read 21 October 2026. This guide therefore does not prescribe an “AI schema” as a route to guaranteed inclusion. The practical job is accurate public information and consistent markup.

If you draft a site guide such as llms.txt, keep it as a reviewed navigation aid. Check every destination and avoid exposing private paths. Its presence is not evidence that an engine uses it, and a validator passing is not a citation result.

Do not publish generated markup without review. Ask the assistant to list each field, its factual source and any uncertainty. If a field needs a fact you do not have, omit or correct it rather than filling it with an attractive guess.

Work through an illustrative finding

Imagine fictional Peak Plumbing has supplied a draft service page that says “covering the local area” without naming it. That is an invented review scenario, not an observation from a real website. It shows how a readiness suggestion can remain grounded in a business fact.

Illustrative observation: service-area wording is ambiguous
Evidence: supplied draft says "the local area"
Unknown: exact coverage has not been provided
Proposed action: ask the owner for the supported coverage statement
Acceptance: the approved statement appears consistently on the page
Citation effect: not measured

What should the reviewer do next? Obtain the actual service-area fact, check whether it belongs on this page and approve the wording. Then inspect the updated source and browser view. Do not write “AI visibility improved” simply because the ambiguity was corrected.

A second illustrative scenario might involve an FAQ answer that names a service the owner has stopped offering. The correction would be to verify the current service and update both visible answer and markup. Again, the outcome you can check is factual consistency, not an assistant's future recommendation.

Recheck changes and preserve what remains unknown

For each approved change, rerun the same relevant check. Capture the new passage or markup and compare it with the acceptance condition. If a check fails to fetch the page, keep the result unknown. Do not convert an incomplete recheck into a pass because the editor believes the upload succeeded.

Keep a change ledger with the original observation, reviewer, approved text, publication state and verification date. Include intentional non-changes. Some suggestions should remain unresolved because the fact is missing, the access restriction is deliberate or the proposed rewrite would overstate the product.

If you later collect real answer-engine observations, link them as a separate study with exact prompts and collection conditions. Keep readiness changes and observed citations in separate records. A temporal association may suggest a hypothesis, but it does not establish that one caused the other.

The eventual own-site article should publish failures and limits as clearly as successful corrections. Until those receipts exist, this method remains the honest starting point: inspect what can be checked, improve what the evidence supports and leave the unmeasured outcome unclaimed.