Skip to main content
A site audit produces a long list. This guide is about working it in the order that moves the most for the least effort.

​
1. Crawl with enough coverage

On Audits, click Run Audit. The target URL is pre-filled with your domain; the field that matters is Max pages to crawl. The default of 50 is a sample. It reliably catches sitewide problems — a template with no meta description, missing schema, mixed content — because those repeat on every page. It won’t catch per-page problems. Duplicate titles need both duplicates crawled. Orphan pages need a crawl broad enough to establish what links where. Thin content needs the thin pages themselves. Set the limit above your real page count for a proper audit. One audit costs the same against your monthly allowance whatever the page limit, so there’s no saving in running several small crawls.

​
2. Read the score, then ignore it

The score starts at 100 and deducts −2 per error (capped at 50), −0.5 per warning (capped at 30), and −0.1 per notice (capped at 10), then adds +5 each for HTTPS, robots.txt, and a sitemap. Because the deductions cap, a site with 25 errors scores the same as one with 250. It’s fine for reporting a trend and useless for deciding what to fix. Work from the issue list.

​
3. Fix in this order

Errors first. Missing titles, missing meta descriptions, missing H1s, broken internal links, redirect loops, broken images, mixed content, missing HTTPS. These are −2 each and genuinely damaging. Redirect loops and mixed content are the sharpest of these — a looping page is completely inaccessible, and mixed content breaks the page for users as well as search engines. Sitewide patterns before one-offs. An issue appearing on every page is one template change. Fixing a missing meta description in a layout file might clear 200 issues; fixing one page clears one. Sort your effort by issues-per-change, not by issue count. Then the three bonuses. HTTPS, robots.txt, and a sitemap are +5 each — 15 points for what is usually an afternoon. Then warnings, largest groups first. Titles and descriptions outside 50–60 and 120–155 characters, duplicates, missing canonicals, missing alt text, thin content under 300 words, slow pages over 3,000 ms, large pages over 3 MB. Notices last, and often not at all. noindex and robots.txt blocks are usually deliberate. Read them as a checklist — “did I mean to exclude these?” — rather than as defects. They’re also the first thing to check when a page mysteriously won’t rank.

​
4. Diagnose with page detail

When an issue doesn’t make sense, open the page detail for the affected URL. It shows the measurement behind the finding. Three fields do most of the work:
  • Word Count — a page flagged as thin that reads as substantial usually renders its text client-side, where the crawler never sees it.
  • Canonical URL — a canonical pointing at a different page tells search engines not to index this one. Easily missed, and a common cause of a page vanishing.
  • Render-Blocking Scripts — normally the direct cause of a high load time, and a smaller fix than the load time suggests.

​
5. Verify

The score belongs to the crawl that produced it and never recalculates. After deploying fixes, run a second audit with the same target URL and the same page limit, then use Compare audits. Matching the page limit is essential. A 500-page crawl compared against a 50-page one reports hundreds of “new” issues that were always there and simply weren’t crawled before. Nearly every confusing comparison is two crawls of different scope. Read Resolved Issues and New Issues rather than the score change. A crawl that resolves 30 and introduces 28 barely moves the score while telling you something important about your release process. The category table confirms the rest: work on meta tags should show meta_tags falling and everything else flat.

​
6. Keep it up

Audits don’t run on a schedule. One runs at project creation and after that only when you click Run Audit — an audit score months old usually means nobody has crawled since. Run one after any significant deploy, and monthly otherwise. Because every audit is kept, you accumulate a record of what changed and when, which is what lets you find the release that caused a regression.

​
Performance is measured elsewhere

Audit performance figures come from a single crawl request. For real diagnosis use Web vitals, which runs a full Lighthouse audit and reports LCP, INP, CLS, and four supporting metrics with specific opportunities. Use the audit to find which pages are slow, and web vitals to work out why on the worst ones. Note that vitals checks draw on the same monthly allowance as audits.

​
Next