Skip to content

The site audit: how a run works

The poll measures what the engines say. The site audit measures your own pages: whether each AI crawler can read them, what they say, and whether they answer your questions. It runs as runs: a full run each month where the plan has one, and change runs in between. Its findings become evidence on Fix a page plays, and site-wide hygiene becomes Foundations; see Plays.

A run is a pipeline. Each stage does one thing, writes what it found, and hands it to the next. The run’s page shows the stage in progress as a sentence, its Log panel shows it by name, and the API returns the same names in a run’s steps. This page is the key to those names.

Nothing here is a setting. The only choices are the ones in the run dialog: how many pages, whether pages are rendered in a browser, and whether the analysis agents run.

Stage What it does Where its work shows
discover Reads robots.txt, the sitemaps it names and every child sitemap, and builds the run’s picture of the site’s URLs. A site with no sitemap is read from its home page and the pages the home page links to, and the run says so; a sitemap is recommended. The run’s page
sample Chooses the pages to read: a spread across URL patterns and languages, within the page budget. Pages, Templates
fetch Requests each sampled page as several different machines and records what each one was given. Crawlers & access, Pages
extract Reads what each page actually says, and how much of it exists only after JavaScript runs. Pages
signals Adds the site’s real search queries and positions, when Search Console is connected. Pages
deterministic Runs the checks every page gets: access, technical, performance, search. Plays (Fix a page, Foundations)
graph Names the things the site talks about and the factual statements it makes, and scores each statement for how verifiable it is. The run report
index Indexes the site’s own passages so questions can be asked of them. (behind the simulation)
intents Writes the questions the site’s pages should answer, from its own subject matter and its search queries. The run report
simulate Asks the site those questions through a retrieval engine over its own passages, and judges each answer complete, partial or missing. Plays (Write the missing page)
cite Asks the configured engines the run’s most important questions, once, for the run report. The run report
learn Adds the run’s pages and answers to what Vercatus Intelligence observes. Intelligence
analyze Specialist analysis of what the measurements mean for this site in particular. Plays
critic An adversarial review that discards anything the evidence does not support and downgrades what it overstates. Plays
synthesize Writes the run in the words of the person who has to act: the position, the risks, the order of work. The run report
change Compares this run with the previous one: what is new, what is resolved, what regressed. The run’s page

Read in one line: find the pages, read them as several machines, understand what they say, ask the site the questions its pages should answer, decide what matters, and say what changed since last time.

The cite stage is the run’s own dated snapshot. Your Answer Share does not come from it: it comes from the continuous poll over your topics.

  • Analysis agents off (the switch in the run dialog) skips the four stages that call a language model: graph, analyze, critic and synthesize. You still get the access matrix, the technical and performance findings and the retrieval simulation, which is a useful check but not the full audit.
  • Search Console is what signals needs. Without it the run uses the site’s own subject matter alone and the stage is skipped; see Google Search Console.
  • Answer engines are what cite needs. Where an engine is unavailable, or answers with an error, the run records that engine as not asked rather than as not citing you.
  • A previous run is what change compares against. On a site’s first run there is nothing to compare, and the stage says so.

A change run re-reads exactly the pages the last full run read and reports what moved. It runs discover, sample, fetch, extract, signals, deterministic, cite, learn and change, and skips the rest: the site’s questions, the simulation and the written analysis belong to the full run and are carried forward, so the picture stays complete without paying for them again. That is why a change run is quick, and why it can be scheduled weekly. A Fix a page play whose finding a change run no longer finds passes its check.

A stage that fails stops the run at that point and leaves everything before it intact. The run can be resumed: finished stages are not repeated, the run continues from where it stopped, and it does not spend a second allowance. A stage that was skipped says why in the log, in one line.

Stages that read the network are patient rather than fast: the crawler keeps to a polite rate per host and backs off when a site asks it to, which is why the run dialog quotes crawling time in minutes. See the crawler.

Each stage has a concept behind it, and those pages go deeper than this one: