Site Audit

Summary#

Site Audit takes a domain, crawls its most important pages live, and returns one health score out of 100 plus every technical check that failed, grouped by category and severity. It is the fastest way to find out what is technically wrong with a site when you do not yet know where to look.

Purpose#

On-page tools answer "is this page correct?". Site Audit answers a different question: "where on my site is the damage?" A site rots one page at a time, and the quiet problems sit on the pages nobody has opened in months — a missing canonical, a thin product page, a title that never got written. Site Audit crawls the pages that actually carry your organic traffic and tells you which checks fail on them, so your fix list is ordered by real impact rather than by whatever you happened to notice.

The decision it helps you make is what to fix first.

Overview#

You enter a domain. Metric Vault builds the crawl list from your site's own sitemap, orders it so the pages carrying the most organic traffic are reached first, and always includes the domain root. How far down that list it goes depends on your plan. Each URL is then crawled live and run through the provider's on-page check suite — titles, descriptions, headings, canonicals, HTTPS, response codes, compression, load time, page weight, images, URL structure and more.

How many pages your plan crawls#

An audit runs inside a single request with a hard time limit, so a run also stops when that budget is spent even if your plan allows more pages. When that happens the report says so, and names the depth it did not reach — a slow site becomes a smaller honest audit rather than a failed one.

robots.txt is obeyed. Metric Vault reads your robots.txt and skips any URL it disallows for our crawler, following the same rules a search engine does: the group naming our agent wins over the * group, the longest matching pattern wins, and Allow beats Disallow at equal length. If that removes URLs from the crawl, the report says how many rather than quietly shrinking.

Only pages on the audited domain (or a subdomain of it) are crawled, so a sitemap that points somewhere else cannot pull unrelated pages into your audit.

What the audit says it crawled#

Eight pages is a sample, not a whole site, and the result says so. Under the domain in the report header is a line reading, for example:

That second number is counted, not estimated. Metric Vault reads your robots.txt for Sitemap: directives (falling back to /sitemap.xml), expands a sitemap index into its child sitemaps, and counts the URLs they list. Gzipped sitemaps (.xml.gz) are decompressed and read like any other, media entries inside a page record are not counted as pages, and a URL listed in two child sitemaps counts once. Namespace-prefixed sitemaps (<sm:loc>) and plain-text sitemaps (one URL per line) are both read.

A sitemap that will not load — a 403 from a firewall, a timeout — is a hole in the count, not a zero. Any such failure means the total is reported as a floor rather than an exact figure, and the line says how many could not be loaded.

The line has four forms, and which one you see tells you how much to trust the total:

Sites without a sitemap still get a full audit of their eight pages; only the site-wide total is unavailable.

Every check comes back as a boolean, and each is read in its own sense: a check that asserts a problem (is_4xx_code, no_content_encoding) has failed when it is true, while one that asserts something good is present (is_https, has_meta_title) has failed when it is false. A few are informational — from_sitemap says where the URL was found, canonical says which copy is the master — and those are never scored at all.

How the health score is calculated#

health = 100 − the sum of (weight × % of crawled pages affected)

Some faults are reported by the provider twice, from both sides: a page with no title comes back as both no_title and a failed has_meta_title, and a 404 as both is_4xx_code and is_broken. Those are collapsed to a single issue before scoring, so one fault costs one deduction and appears as one row. You can add the deductions in the table up yourself and reach the score shown.

Each distinct failing check is counted once and costs its weight scaled by how much of the crawl it affects. A critical issue on every page costs 15 points; the same issue on half the pages costs 7.5. Worked through, for a ten-page crawl:

100 − 12.0 = 88. The results screen prints this same table under the gauge, so the number can be added up by anyone reading the report rather than taken on trust. Each row's cost is its weight times the reach printed next to it, and the total is the sum of the costs as printed, so both columns can be checked with nothing but the figures on screen.

The subtraction shown is always the true one, and anything the gauge does to it afterwards is said in words rather than folded into the equals sign. Two things can happen:

• The gauge is a whole number and the total often is not. A total of 12.5 reads 100 − 12.5 = 87.5, followed by Rounded to 88. Most reports carry a line like this.
• A score never goes below 0. Eight distinct critical issues across every crawled page deduct 120, which reads 100 − 120.0 = −20, followed by Floored to 0, because a score does not go below zero.

A page's own score is the same formula with every issue on it counted at 100%, so the site score is also the average of the page scores — except where a page is damaged enough to floor at 0, since a page cannot score below zero to average out. When that happens the site score is the lower of the two readings, which is the conservative direction.

The categories are scored from the same checks, and the recurring-issue table counts how many of the crawled pages each failing check appears on. No number in the report is invented. If the provider returns nothing for the domain, the tool says so rather than filling the gap.

Benefits#

• One number to track. A single 0-100 health score you can re-run weekly and watch move.
• Severity, not noise. Every check carries a severity, and failed checks are split into critical, warning and notice, so you always know what to open first. The provider grades nothing, so the classification is ours.
• Fix-once-gain-everywhere issues. The recurring-issue table shows which problems repeat across pages, which are the cheapest wins on the whole site.
• Real crawl data. The report is built from a live crawl, not from a cached index or an AI summary.
• Costs one credit. A whole-site technical read for the price of the platform's lightest tools.

Use Cases#

• Taking over an unfamiliar site. You inherited a client or a legacy property and need a technical baseline in minutes; the health score and critical list give you an agenda for the first call.
• Pre-launch or post-migration check. After a redesign or a domain move, the audit catches the canonical, HTTPS and viewport regressions that migrations reliably break.
• Monthly health tracking. Re-run on a schedule and use the score trend as the technical KPI in your reporting.
• Prioritizing a backlog. The recurring-issue table turns "we should do some technical SEO" into a ranked list of five things.
• Auditing a prospect before a pitch. Run the audit on a prospect's domain and lead with the criticals you found.

Requirements#

• A signed-in Metric Vault account.
• A paid plan. Site Audit costs credits, so the Free plan cannot run it — see What you get on Free.
• A publicly reachable domain. Private, internal and loopback hosts are refused.
• One available credit. See How credits work.

No integration and no site verification are needed. You can audit any public domain, including a competitor's.

Permissions#

There is no per-role restriction: every member of a workspace can run Site Audit. See Roles and what each can do.

Cost#

1 credit per run. The button prints the cost as Run Audit · 1 report.

Site Audit results are held in the shared data cache for 1 day. If someone has already run the same domain with the same filters inside that window, your result is served from the cache — it returns almost instantly, but the credit is still charged. Reopening a run you already paid for from the "You already ran this" prompt or from your Library costs nothing. See Result caching and freshness and How credits work.

Navigation Path#

Dashboard → Site Health → Site Audit

Inputs#

Step-by-Step Guide#

1. Open Dashboard → Site Health → Site Audit.
2. Press See example first if you want to see the report shape at no cost. A banner reads "Sample preview. Example output so you can see exactly what this tool returns — no credits used."
3. Type your domain in the field marked e.g. nike.com, or click one of the TRY: chips.
4. Click Run Audit · 1 report, or press Enter in the field.
5. If you have audited this domain before, the You already ran this dialog appears. Choose Open saved result (free) or Run fresh (1 credits).
6. Wait while the result area shows Analyzing… this can take a few seconds for live data. A whole-domain audit crawls several pages in parallel and takes longer than the single-page tools.
7. Read the report top to bottom, starting with the score and the Critical Issues card.
8. Use Export PDF, Export CSV or Schedule Weekly in the result header, or the export row at the top of the screen for PDF, Excel, CSV, JSON and Share public link. See Exporting results.

Reading the Results#

The hero band. Your domain, its favicon, and three badges: VERIFIED · Real crawl, and a status pill reading Strong Health (score 80+), Needs Attention (60-79) or Critical Issues (below 60). On the right, the score out of 100. Below it, five tiles: Health Score, Critical, Warnings, Notices and Passed.

Read the tiles precisely. All five describe every page crawled. The Health Score is the weighted figure described in How the health score is calculated: 100 less the cost of every distinct failing check, scaled by how much of the crawl it reaches. The Critical, Warnings, Notices and Passed counts beside it are crawl-wide too, counted as one instance per failing check per page. Those three failure counts used to be the counts for the first page crawled alone, so one page's numbers sat beside a whole-crawl score and disagreed with the crawl figure further down the report. A high critical count against a strong score means the same few issues recur across pages, which is what the recurring-issue table is for.

Site Health Score. A large gauge repeating the score, with a one-line verdict: "Excellent — your technical foundation is strong." at 80+, "Needs attention — fix the criticals first." at 60-79, and "Major issues found — prioritize the red items below." below 60. Four tiles beside it break the checks into Critical, Warning, Notice and Passed with a short caption each ("1 issue to fix now", "All clear", "2 listed, never deducted", "12 checks passed").

What good looks like: 80 or above with zero criticals. What bad looks like: anything under 60, or any non-zero critical count — a critical means a search engine treats the signal as broken, not merely weak.

Critical Issues. The failed checks from the primary page, named in plain words (for example "Has H1", "Is Https"). These are your first five jobs.

Performance Metrics. Eight speed indicators — Time to First Byte, First Contentful Paint, Largest Contentful Paint, Speed Index, Total Blocking Time, Cumulative Layout Shift, HTTP Requests and Page Weight — each with a target and a score out of 100. Important: a real crawl does not produce these. The audit used to invent all eight by multiplying one crawl load time by fixed constants, which is why that was removed. On a measured run the card now says the scores were not measured and points you at PageSpeed, and tells you the average load time the crawl really did record. The eight indicators only appear on the AI-estimated path, where they are model output rather than measurement. For real lab and field timings, run PageSpeed & Vitals.

Security Checklist. Five pass/fail rows: HTTPS/SSL Certificate, Content Security Policy, X-Frame-Options, HSTS Header and No Mixed Content. Anything failing here is worth a look in Security Headers, which explains each header and gives you the exact line to add.

Full Audit Report. Four categories, each scored out of 100 as the average of its items (a pass counts 100, a warning 50, a critical 0):

Any category below 70 is where your next hour should go.

Crawl Stats. Pages Crawled, Indexed, Orphans, Broken Internal, Broken External and Avg Response. Broken links and orphan pages should be zero; average response under 600 ms is good, over 1,500 ms is a problem.

Core Web Vitals. LCP, FID, CLS, TTFB and INP against Google's thresholds — green when LCP is at or under 2.5 s, CLS at or under 0.1, and INP at or under 200 ms.

Issues Over Time (12M). A real 12-month issue-count history, stacked by severity. What matters is the slope: flat or falling is healthy, a rising line means you are creating problems faster than you fix them.

Top Recurring Issues. Every failing check, with what it means, why it costs you, and the pages it appears on. This is the highest-leverage panel in the report. An issue failing on six of eight pages is almost always a template problem: fix it once in the theme and the whole site improves.

Open an issue and it expands into the pages that failed it. Each page has three actions:

Generate fix produces the actual thing you need to paste, and what it produces depends on the issue. For a title or description problem it runs the meta generator against that exact page, which reads the live page and writes alternatives from what the page really says. That costs one credit, the same as running the meta generator yourself. For a canonical problem it writes the canonical tag, and for a redirect problem it writes the redirect-map row with the source filled in from the crawl. Those two cost nothing, because they are assembled rather than generated. The destination of a redirect is left for you: nothing here can know what replaced a page, and a wrong 301 is worse than none. For anything that is a change to the server rather than a piece of markup, it shows what to change instead of pretending to write it.

Mark fixed records that you have made the change. Ignore records that you have decided not to, and removes the Generate fix action for that page, since you are not fixing it.

What happens on the next crawl#

Both marks are remembered per website and survive a rerun, which is the point of them. A page you marked fixed does not come back as a fresh finding.

What happens next depends on whether the crawl agrees with you:

• The check now passes. The page moves into Verified fixed under its issue, naming the page, and the open count drops. The loop is closed.
• The check still fails. The page stays listed under its issue with the Marked fixed label, and a line at the top of the panel says how many pages are in that state. It is not hidden. Usually it means the change has not deployed, or it was made somewhere the crawler does not see, such as client-side rendering.

Marks are saved to your account, against the site they belong to, so they follow you to another browser or another device and are still there on your next audit of that site. They are also written into the browser you made them in, which is what lets a row update the instant you click it rather than waiting on the network, and means a mark made while your connection drops is not lost.

A mark belongs to one site. Marking a page fixed on one website does not mark a page with the same path on another.

Clicking Mark fixed or Ignore again on a row that already has it clears the mark, on your account as well as in the browser.

Under the report, the AI Action Plan panel offers to turn the findings into a prioritized, step-by-step plan. See Get Recommendations.

The plan is written from the same classified issue list the report shows you, not from the raw check results and not from a summary of them. Each finding it is given carries the check it came from, the share of the crawl affected, and the same "why it matters" and "how to fix it" text the issue rows carry. So every recommendation traces back to an issue you can find in the table, and the plan cannot suggest fixing something the audit did not report or skip something it did. If a recommendation looks unfamiliar, the issue it answers is in the recurring-issue list under the score.

Examples#

Screenshots#

Tips#

• Run See example before your first real audit. It renders a full stored report for free, so you learn the layout without spending a credit.
• Audit a competitor's domain the same way you audit your own. Nothing about the tool requires you to own the site.
• Use Schedule Weekly in the result header to have the audit re-run and emailed automatically. See Scheduled reports.
• Start with Top Recurring Issues, not with Critical Issues. Recurring problems are template-level and cheaper per page fixed.
• Screenshot or export the score each month; the trend is more persuasive to stakeholders than any single number.

Best Practices#

• Fix criticals before warnings, and template issues before page issues.
• Re-run after each batch of fixes so the score records the improvement while you still remember what you changed.
• Pair the audit with PageSpeed & Vitals for measured speed and Security Headers for header detail — Site Audit flags those areas but the specialist tools tell you exactly what to change.
• Keep the domain form consistent (always example.com, never sometimes www.example.com) so the "You already ran this" prompt can find your history.

Common Mistakes#

• Pasting a full page URL. Site Audit works at domain level. For a single page, use On-Page SEO Checker.
• Reading the Critical count as site-wide. It is the primary page's count. The site-wide picture is the health score and the recurring-issue table.
• Treating Performance Metrics as measured speed. A real crawl leaves that card empty apart from the average load time it actually recorded. Measured numbers live in PageSpeed & Vitals.
• Re-running the same domain minutes apart. Inside the 1-day cache window the data is identical, and you are charged again.
• Ignoring warnings entirely. Warnings are how a page becomes weak before it becomes broken.

Limitations#

• Up to 8 pages per run. The audit crawls the domain root plus up to seven of the domain's highest-traffic pages. It is not a full-site crawler and will not find a problem on a page it did not visit.
• Page discovery is US / English. The pages chosen for the crawl come from Google's United States, English index regardless of the country picker.
• New or very small domains may return nothing. If the provider has no organic data for the domain, only the root is available and the audit can return the honest no-data card.
• Performance and crawl-stat figures are derived, not measured, when the provider does not supply them.
• Core Web Vitals shown here are indicative. Field data comes from PageSpeed & Vitals.
• Results are kept for 90 days in your Library. See Saved Work.

Troubleshooting#

FAQs#

Does Site Audit crawl my whole site? No. It crawls the domain root plus up to seven of your highest-traffic pages — eight URLs in total. That is enough to expose template-level problems, which are most of them, but a page outside the top eight will not be checked.

Do I need to verify my domain or install anything? No. There is no tag, no script and no ownership check. You can audit any public domain, including one you do not own.

Why is my Health Score lower than my critical count suggests? They measure different things. The score is site-wide and weighted: every distinct failing check costs 15 if critical or 5 if a warning, scaled by the share of crawled pages it reaches. The Critical count beside it is the check count for the primary page only. Three criticals confined to one page of an eight-page crawl cost 3 × 15 × ⅛, which is 5.6, so they alone would leave the score near 94; a materially lower number means warnings, or issues recurring across the other pages, are carrying the rest. The recurring-issue table under the gauge lists every one of them with what it cost.

How much does it cost, and does a cached result still charge me? One credit per run. Yes — a shared-cache hit still charges the credit, because you are being served a fresh-enough dataset. Reopening your own saved result from the Library or from the "You already ran this" prompt is always free. See How credits work.

Can I automate it? Yes. Schedule Weekly in the result header sets up a recurring audit emailed to you. Weekly scheduling requires a paid plan; on Free it returns Weekly scheduling is available on paid plans. Upgrade to schedule automatic reports. See Scheduled reports.

What is the difference between this and On-Page SEO Checker? Site Audit is domain-level and costs a credit; On-Page SEO Checker is a single-URL, zero-credit check of one page's live HTML. Use Site Audit to find where the problems are, then the On-Page checker to work on one page at a time.