This walkthrough shows what Site Audit Pro returns when it crawls a 50+ page site — per-page Core Web Vitals, cross-page duplicate detection, structured-data validation and internal link analysis. It's the depth you can't get from a single-page check.
📊 Run Site Audit Pro Read the Guide →Instead of one domain-level speed score, Pro scores every page. A typical result table flags which specific pages fail:
| Page | LCP | CLS | INP | Status |
|---|---|---|---|---|
| / | 2.1s | 0.04 | 180ms | PASS |
| /products/widgets | 4.3s | 0.18 | 340ms | FAIL |
| /blog/long-post | 2.9s | 0.11 | 260ms | NEEDS WORK |
This tells you exactly which pages to fix first, rather than guessing from a single averaged number.
Pro compares titles, meta descriptions and content across every crawled page. The report groups collisions so you can see, for example, that six product pages all share the title "Buy Online | Brand" — a pattern that tells Google none of them is distinctly more relevant.
Every JSON-LD block on every page is validated against schema.org. The demo report shows which pages have valid markup, which have warnings (missing recommended properties) and which have errors that disqualify them from rich results entirely — even though the markup may look fine to the eye.
Pro maps your internal link graph to surface orphan pages (no inbound internal links), broken internal links, and pages buried too many clicks deep to be crawled or ranked well. On large sites this is where a lot of wasted crawl budget hides.
A 50-page audit typically completes in 5–8 minutes; a 200-page audit in 20–30 minutes. The crawler runs pages in parallel while respecting your server resources.
Pay as you go — no subscription. Get the full per-page breakdown in minutes.
Run Site Audit Pro →A domain-level score is a mean, and a mean is where the interesting cases go to hide. A site averaging 78 can contain a checkout page at 30 and forty blog posts at 95, and the average will tell you everything is fine while the one page that takes money is the one that is broken.
Per-page results invert the problem in exactly the right way. Instead of a number to feel vaguely good or bad about, you get a list of URLs — and a list can be sorted by something a crawler cannot know but you can: which of these pages actually matters to the business.
That sort is the whole discipline. Severity ranks the pages by how badly they fail. Commercial value ranks them by what the failure costs. Fixing the worst page on a site is rarely the right first move; fixing the worst page that people buy from always is, and no audit tool can make that judgement for you because no audit tool knows what you sell.
Six product pages sharing one title is a real problem and it is not the problem people think it is. There is no duplicate content penalty. There is no duplicate title penalty. Google consolidates near-identical signals; it does not punish sites for having them.
What duplication costs is precision. Six pages announcing the same title are six pages telling Google they are about the same thing, which forces it to choose which one to show for a query — and it will sometimes choose the one you did not want, or show none of them confidently. Each duplicate is also a wasted opportunity: a title is the strongest short statement a page makes about itself, and spending it on a template string that says nothing specific throws that away.
Worth knowing while you rewrite them: Google frequently replaces titles in the results when it judges the supplied one a poor fit for the query, drawing instead on the H1 or other on-page text. So the title you write is a strong suggestion rather than a guarantee, and the way to make it stick is to make it accurately describe the page. That is also, conveniently, the only reason to write one.
An orphan page is one that nothing on your own site links to. It may be in the sitemap, it may be indexed, and it may be excellent — but no visitor can reach it by browsing, and no crawler finds it by following a link.
That distinction matters because a sitemap and an internal link do different jobs. A sitemap says a URL exists. An internal link says a URL is important, says what it is about through the anchor text and the surrounding paragraph, and passes ranking signal from a page that already has some. Orphans get the first and none of the rest, which is why they reliably underperform even when the content is good.
Depth is the same story in a weaker form. There is no published threshold at which a page becomes too deep — anyone quoting one is inventing it — but click depth is a fair reading of what your own architecture says about a page's importance. Two clicks from the homepage is a structural statement that a page matters. Six clicks, reachable only by paginating through a listing, is a structural statement that it does not, and search engines tend to take you at your word.
The fix in both cases is architectural rather than technical: a hub page, a category listing, a related-content module that renders in the served HTML rather than after a click. If a page is genuinely important and nothing links to it, the problem was never the crawler's.
Every JSON-LD block on every page validated against schema.org is a genuinely useful check, and it is worth being exact about what it proves. It proves that the markup parses, that the types are recognised, and that the required properties are present. It proves nothing whatever about whether the markup is true.
A Product block can validate perfectly while asserting a price the page does not show, or availability that contradicts a disabled Add to Cart button. That block passes every automated test in existence and is the most damaging defect structured data can have: in Google's shopping surfaces it is grounds for item disapproval, and it misleads a shopper who arrives expecting the price they were promised in the results.
So treat validation as the floor. The check that matters is comparing the values in the JSON-LD against the values in the rendered HTML — price against price, availability against button state, headline against H1, date against the date the page displays. Structured data is a machine-readable restatement of what a human can see. Where the two disagree, the markup is wrong, however green the validator turns.
One further note on schema, since audits invite the opposite conclusion: adding more types does not help. There is no verified evidence that denser structured data wins citations from AI assistants, and marking up content the page does not contain is a policy violation rather than an optimisation. Accurate and modest beats extensive and imaginative every time.
Scoring every page rather than the domain is the right approach, and there is one limitation to hold in mind when you act on it. A crawler produces lab data: a simulated device on a simulated network, measured once. Google's ranking systems use field data — what real Chrome users, on real connections, actually experienced.
Those two diverge routinely. A page can post an excellent lab score while customers on mobile networks suffer, and a mediocre lab score can sit on top of perfectly acceptable field data. Neither is a fault in the tool; they are simply different measurements.
Use the per-page lab results for what they are good at: telling you which pages are worth investigating, and which specific thing on them is slow. Then check the field data before you conclude the problem is real, and remember the honest weighting — Core Web Vitals are a genuine ranking consideration and a small one, acting as a tie-breaker between pages of comparable relevance. Nobody outranks a better answer by being faster than it. The stronger argument for the work is that people abandon slow pages and lose their place when the layout shifts, which you can measure in your own analytics and which is worth more than the ranking effect on almost every commercial page.
A 50-page audit will find every broken link, every duplicate title, every invalid schema block and every slow page. It will not find the thing that is actually holding the site back on most sites, because that thing is not machine-detectable.
A page can pass every check here and still be the second-best answer to the query it targets — thinner than the page above it, vaguer, hedged where the competitor is specific, silent where the competitor admits a limitation. No crawler scores that, and no amount of technical remediation compensates for it.
So the honest way to use an audit like this one is as hygiene. Fix the defects, because defects have no upside and their cost is real. Then stop, and go and read the pages that outrank you. The remaining headroom on a technically clean site is almost entirely in the content, and the twenty minutes spent reading a competitor's page will tell you more than another pass of the crawler ever will.
Because a domain-level score is an average, and averages hide the pages that are actually costing you money. A site scoring 78 overall can have a checkout page scoring 30 and forty blog posts scoring 95, and the average tells you to relax while your most valuable page is the broken one. Per-page results invert that: they tell you which specific URLs fail, so you can sort by commercial value rather than by severity. Fixing the worst page on a site is rarely the right first move. Fixing the worst page that people actually buy from always is.
No — there is no duplicate content penalty, and there is no penalty for duplicate titles either. Google consolidates rather than punishing. What duplicates actually cost you is precision: six product pages sharing one title are six pages telling Google they are about the same thing, which forces it to guess which one to show for a query, and it will sometimes guess wrong. A duplicate title is also a wasted opportunity to say what makes each page different. Fix them because each page deserves an accurate description, not because a sanction is hanging over you.
A page with no inbound internal links. It may be in your sitemap and it may be perfectly good, but nothing on your own site points at it, which means no visitor can reach it by browsing and no crawler encounters it by following links. A sitemap tells Google a URL exists; internal links tell Google how important it is and what it is about, through the anchor text and the surrounding context. Orphans have the first and none of the second, so they tend to sit at the bottom of the crawl queue, ranking for nothing. Either link them into the site properly or accept that they will not perform.
The honest answer is that there is no fixed threshold — Google has never published one — but depth is a reasonable proxy for how important your own architecture says a page is. A page reachable in two clicks from the homepage is being told, structurally, that it matters. A page six clicks deep, reachable only through pagination, is being told the opposite, and Google generally agrees. If a page is commercially important and sits deep, the fix is not a technical tweak: it is a navigation or hub page that links to it, which also helps the humans who currently cannot find it either.
No, and this is the most consequential limitation of any schema validator. Validation checks structure: does the block parse, are the required properties present, are the types recognised. It cannot check truth. A Product block that validates perfectly while asserting a price different from the one on the page passes every automated test and is a serious defect — in Google's shopping surfaces it is grounds for item disapproval, and it misleads shoppers who arrive expecting the price they were shown. Structured data must describe the visible page, and the only check that catches a violation is comparing the values against the rendered HTML.
Not necessarily, and the difference catches teams out constantly. A crawler like this produces lab data: a simulated device, a simulated network, one measurement. Google's ranking systems use field data — what real Chrome users on real connections actually experienced on your pages. The two diverge routinely in both directions, so a page can post a strong lab score while your customers on mobile networks suffer, and vice versa. Use the per-page lab results to find which pages to investigate; use field data to decide whether the problem is real.
Anything that is broken, on the pages that make money, in that order. Broken means: pages returning errors, pages that are accidentally noindexed, schema that contradicts the visible page, and internal links that lead nowhere. Those are defects and they have no upside. After that, work down by commercial value rather than by severity score, because a nine-point improvement on a page nobody visits is worth less than a two-point improvement on the page where people check out. And once the defects are gone, stop: further technical polish has sharply diminishing returns, and the remaining headroom on almost every site is in the content, which no crawler can score.
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.