Site Audit Pro goes deeper than the standard audit — adding page speed scoring, structured data validation, cross-page duplicate detection and detailed link analysis across your entire site.
📊 Run Site Audit Pro All Audit Tools →Use the standard Site Audit for regular monthly health checks on sites up to 50 pages. Use Site Audit Pro when you need a comprehensive analysis of a larger site, when preparing for a site migration, or when you suspect duplicate content issues across multiple pages.
Unlike the standard audit which checks speed at the domain level, Pro scores LCP, CLS and INP for every individual page — so you can identify which specific pages are dragging down your overall Core Web Vitals score.
Pro compares title tags, meta descriptions and content across all crawled pages to identify duplicates. Duplicate titles confuse Google about which page to rank. Duplicate content dilutes your topical authority.
Every JSON-LD block on every page is validated against the schema.org specification. Invalid structured data cannot earn rich results in Google search, regardless of how well formed it appears visually.
The 500-page limit is not really a limit — it is a prompt to do the thing you should be doing anyway. A single undifferentiated crawl of a large site produces a report where a broken product template and a broken blog template are jumbled together in one list of four thousand rows, and nobody can see either.
Crawl by template, not by site. Run one audit per section — products, categories, blog, location pages, help centre — and read each in isolation. The reason is that on a large site, issues are properties of templates, not of pages. One product template with a missing canonical produces two thousand identical rows. It is one fix. Segmenting the crawl makes that obvious; a flat crawl buries it.
/products/, /blog/, /locations/. Usually maps cleanly to templates.Of everything a deeper audit surfaces, internal linking is the one most often skimmed and most likely to be the reason a large site underperforms. Two numbers matter, and neither is "number of links".
How many clicks from the homepage to reach a page. Pages buried at depth 5, 6 or 7 are crawled less often, and Google infers — reasonably — that a site does not consider them important. On large sites, valuable pages routinely end up deep purely as an accident of pagination: product 400 in a category is thirty pages of pagination away from anything.
Anything you care about should be within about three clicks of the homepage. If it is not, you have a navigation and internal linking problem, not a content problem — and adding words to the page will not fix it.
A site where every page is linked from a mega-menu on every page has a flat internal link graph: it has told Google that all pages are equally important, which is the same as telling it nothing. Authority arriving from outside then spreads evenly across five thousand pages instead of concentrating on the twenty that matter.
The pattern to look for in the report:
hreflang is unusually unforgiving. The rules are simple, absolute, and broken on the majority of sites that implement it — and a broken implementation is silently ignored, so nothing tells you.
en-UK is not a valid code — the region code for the United Kingdom is GB, so it is en-GB. This one appears constantly, and it invalidates every tag it appears in.x-default declares the fallback for users whose language you do not serve. It is optional, and it is what a country-selector or global landing page should be.Scoring speed page by page is the right approach — the domain-level number hides everything. But the numbers need interpreting, and there is one distinction that determines whether you act on them at all.
A per-page score generated by a crawler is lab data: one synthetic load, on a simulated device, on a simulated network, with no cookie banner interaction and no third-party script that only fires for logged-in users. It is invaluable for finding problems and it is not the number Google assesses you on.
Google's page experience signals come from the Chrome User Experience Report — real users, real devices, real networks — assessed at the 75th percentile over a 28-day rolling window. Three consequences:
| Metric | Good | Poor |
|---|---|---|
| LCP — Largest Contentful Paint | ≤ 2.5s | > 4.0s |
| INP — Interaction to Next Paint | ≤ 200ms | > 500ms |
| CLS — Cumulative Layout Shift | ≤ 0.1 | > 0.25 |
INP replaced FID in March 2024, and it is a considerably harder test: FID measured only the delay before the first interaction was processed, whereas INP measures the full latency until the interface actually updates, across all interactions. Sites that comfortably passed FID routinely fail INP, and the cause is almost always long JavaScript tasks blocking the main thread.
A cross-page duplicate report will produce a lot of rows on any large site, and they are not all the same problem.
The report cannot tell these four apart. You can, and the response to each is completely different.
Crawl budget is invoked constantly and matters rarely. Google's own guidance is that sites below a few thousand URLs generally do not need to think about it at all. If you have four hundred pages, crawl budget is not your problem and any consultant telling you otherwise is selling something.
Where it becomes real — large ecommerce, large publishers, anything generating URLs combinatorially — the symptom is specific and unmistakable: new pages take weeks to be indexed, while Search Console reports enormous numbers of low-value URLs being crawled. Faceted navigation is the usual culprit: six filters with five values each generates tens of thousands of crawlable URLs, and Googlebot dutifully fetches them all.
And the fix is not the one people reach for. Neither a canonical tag nor a noindex saves any crawl budget — both live inside the page, so Googlebot has to fetch the page to read them. Only robots.txt, and not generating the crawlable links in the first place, prevent the crawl. This is why large stores can have noindex on a hundred thousand filter URLs and still find new products taking a fortnight to appear.
Site Audit Pro adds Core Web Vitals scoring for every page, structured data validation against schema.org specifications, cross-page duplicate title and content detection, detailed internal link analysis showing which pages are most and least linked, and hreflang validation for multilingual sites.
Site Audit Pro supports crawls of up to 500 pages in a single audit. For sites larger than 500 pages, run multiple audits targeting different site sections — blog, product pages, category pages — to ensure full coverage.
A 50-page audit typically completes in 5-8 minutes. A 200-page audit takes 20-30 minutes. The crawler processes pages in parallel while respecting your server resources.
Because a crawler produces lab data — one synthetic load on a simulated device — while Google assesses page experience using field data from the Chrome User Experience Report: real users, at the 75th percentile, over a 28-day rolling window. A page can pass in the lab and fail in the field because the slowest quarter of real visits are what the threshold protects. Low-traffic pages have no field data at all, so lab data is all you will ever get for them, and a deployed fix takes about four weeks to be fully reflected.
A missing return tag. If page A declares B as its French alternate, B must declare A back — without the return tag the entire relationship is discarded, silently. Close behind: a missing self-reference, and invalid region codes. en-UK is not a valid code; the ISO region code for the United Kingdom is GB, so it must be en-GB. Note also that hreflang does not improve rankings — it swaps which version of an already-ranking page a given user sees.
Probably not. Google's guidance is that sites below a few thousand URLs generally do not need to consider it. Where it is real — large ecommerce, large publishers, faceted navigation generating URLs combinatorially — the symptom is that new pages take weeks to index while Search Console reports huge numbers of low-value URLs being crawled. Note that neither canonical tags nor noindex save any crawl budget, since both live inside the page and must be fetched to be read. Only robots.txt, and not generating the links at all, prevent the crawl.
Because on a large site, issues are properties of templates rather than of pages. One product template with a missing canonical produces two thousand identical rows in a flat report, where it is buried; crawled as its own segment, it is obviously one defect and one fix. Segment by URL directory, and crawl the pages that earn money first and separately — a thorough audit of your two hundred most valuable URLs is worth more than a shallow one of five thousand.
Run the Site Audit Pro and get actionable results in minutes. Pay as you go — no subscription needed.
Run Site Audit Pro →aiwebpageseo.com is a data-driven SEO and AEO (Answer Engine Optimisation) platform providing a free suite of technical website tools. Rather than relying on AI-theorised assumptions, the platform analyses live URL performance, delivering objective diagnostics, page speed metrics, CLS debugging, and site crawl data alongside actionable technical tutorials.