Skip to main content
Site Audit crawls your own website and answers one question: can AI engines get in, read your pages, and pull facts out of them? It sits in the sidebar under Content as Site Audit, with the description “Audit your site for issues that affect AI engine access, trust, and citation.”
Site Audit measures readiness only. It does not measure how often AI actually mentions or cites you — that lives in Visibility and Citation.
Site Audit screen with the GEO readiness score, recommendation panels and the checks card
  1. GEO readiness — the score and its four lanes: Access, Discovery, Technical health, Structured data.
  2. Site-wide fixes — one-time changes. Beside it, Page-level fixes for page-by-page work.
  3. Why we recommend these fixes — the evidence each recommendation came from.

What the audit checks

In plain terms, three things:
  • Can AI crawlers get in? Your site and robots.txt load normally, and robots.txt isn’t blocking AI crawlers.
  • Can they find your pages? Your sitemap and internal links lead somewhere.
  • Can they read and extract? Pages aren’t broken, titles and summaries are clear, and product facts are marked up so a machine can read them.
It does not look at Core Web Vitals, mobile layout, backlinks, or keyword rankings.

Running an audit

You don’t have to run the first one. When a workspace finishes onboarding an audit starts automatically, so most people already have a completed result the first time they open this screen. To run it again, press Re-run audit at the top right. If nothing has ever run you’ll see No audit yet with a Run audit button instead. There is no automatic re-run schedule — run it yourself after you change the site. While it runs, the Audit in progress card walks through three stages.
1

Discovering pages

Crawls your sitemap and internal links. It finishes as “[count] pages found”.
2

Measuring pages

Runs technical checks page by page. Sites over 500 pages get a representative sample per URL pattern instead of every page, and the card says so.
3

Analyzing issues

Groups the findings into action-ready recommendations.
Large sites take a few minutes. You can leave the page and come back — it keeps running. Only one audit runs per workspace at a time.

Reading the score

The score adds up four lanes, each drawn as a tile. Green means healthy, yellow needs a look, orange is weak.
The realistic maximum is 85. A fifth lane covering measurement isn’t wired into this screen, so it always scores 0. Don’t chase 100.
Beside the score you’ll see “[confidence] confidence · [lane]”. Confidence is low or medium, and medium is the best the rules produce — it means at least 10 pages were measured. The lane named after it is where to work first. If a previous audit exists you also get a comparison strip: the readiness change, the Technical health change, and counts for Fixed, New and Regressed. Fixed means that issue type disappeared entirely, not that fewer pages have it. Regressed means the same issue type now affects more pages than last time. Under that, three columns give you the conclusion:
  • What’s working — the lanes in good shape
  • Biggest blocker — what’s holding you back right now
  • Do this first — the single next action

Reading the recommendations

Recommendations split into two cards, up to six per run. Site-wide fixes are one-time changes, usually a single edit in your theme or site config: making important pages reachable, exposing critical facts before JavaScript runs, making page facts machine-readable, helping AI and search find priority pages, and fixing broken page experience issues. Page-level fixes are page-by-page work, sorted by how many pages they reach: adding missing facts to a page group, clarifying page titles and summaries, and consolidating duplicate or competing pages. Each row carries:

Who does what

  • Developer — robots.txt and firewall or security-service rules, how pages are served, structured markup, HTTPS, resources and speed
  • SEO — titles, descriptions, H1 patterns, canonicals and redirects, sitemap and internal links
  • Content — adding the missing facts to thin pages
  • Analytics — setting up the validation loop
Every fix happens on your own site. Site Audit changes nothing for you.

The recommendation detail page

Click a recommendation row to open it.
Recommendation detail page with Why it matters, Primary action, How to validate and the affected pages list
The top card gives you Why it matters, Primary action and How to validate. That’s the part you hand to whoever does the work. Below is the affected page list. By issue groups pages into a card per issue type, each with the evidence (an empty title, a word count, a duplicated description). By page puts one row per page with everything wrong on it. Export CSV downloads the page list to pass along, and Load more pulls in more rows. Site-level recommendations have no page list. They say the recommendation is measured at the site level, with the actions listed instead. If a re-run cleared the issue, you’ll see Nothing to fix here.

Checking the evidence

Expand Why we recommend these fixes to see the actual check results. Collapsed, it summarises as “[n] needs attention · [n] unverified · [n] passed”. Each check has a status: The checks are Public access (your homepage and robots.txt load normally), AI crawler access (AI crawlers aren’t blocked), Canonical and sitemap discovery (your sitemap leads to pages), Technical health (the share of clean pages), and Product/Offer schema or Entity schema coverage. Commerce sites also get Merchant facts machine-readability and Raw HTML commerce visibility. Expand a row for How this was checked, Issues, Affected pages and Evidence. Passing checks collapse into “[n] checks passed”. The Sitemap button on the right opens the URLs this run discovered, grouped into sample sets. Click a path to open the live page in a new tab.

Exporting

Once a run completes, an Export button appears in the header. Pressing it downloads a PDF report; the caret next to it offers PDF, CSV, Markdown and Copy Markdown. The PDF is written out in full sentences — summary, priority actions, diagnosis, lane breakdown, evidence — so it works as-is for a leadership update or a developer handoff.

FAQ

Not the first time — onboarding starts one for you. Re-runs are manual via Re-run audit, and there’s no schedule.
The measurement lane (15 points) isn’t wired into this screen and always scores 0. The practical ceiling is 85.
The rules never award high. Medium is the top grade and means at least 10 pages were measured.
No. It’s recorded as evidence if present and treated as optional. Missing it is not a blocker.
Sites over 500 URLs are sampled, up to 30 pages per URL pattern. Counts are extrapolated from that sample, marked with a ”~”, and can be larger than the number of rows you see.
Once the deeper markup check runs, it replaces the generic per-page finding. It’s a more precise check, not a sign the issue vanished.
Separately from robots.txt, the homepage was fetched using real AI crawler identities and came back blocked. That’s usually a rule in the firewall or security service in front of your site that blocks AI bots. A developer needs to adjust it.
The same issue type now affects more pages than in the previous run.
Not directly. The audit clears technical and access blockers. Check the outcome in Visibility.
There’s no button for that on this screen today. Fix it, press Re-run audit, and confirm it in the Fixed count on the comparison strip.
If you see Couldn’t complete the audit, press Re-run audit to retry. If it keeps failing, your site may be blocking crawlers — talk to your contact at Anymorph. A run stuck for over 30 minutes is stopped automatically.

Visibility

Check the outcome after your fixes land.

Citation

See which sources AI actually pulls from.

On-site

Create pages built to be cited.

Search Console indexing

Get new pages indexed.