Your Site Audit Found 400 Issues. You'll Fix Four.

The problem with single-page audits

Ask Claude to audit a page and it does a genuinely good job. Ask it to audit your site and something quietly goes wrong. It reads your homepage, tells you the title is a bit long, and calls that a site audit. You have not audited a site. You have audited one page and rounded up.

Four types of cross-page issues

The problems that cost you traffic are never on one page. They live in the pattern. Forty posts sharing one meta description because the template forgot to fill it in. Every product page rendering three H1s. A sitemap full of URLs that redirect. None of that is visible from inside one page, because the bug is the relationship between pages, not the page itself.

Four kinds of problem only show up when you look at many pages together:

• Duplicates across pages: Two pages with the same title compete with each other. You cannot see that from either page.
• Template bugs: If your blog layout drops the H1, every post is missing an H1. A page audit reports one missing H1 and you fix one page. A site audit reports "no H1 on 38 pages" and you fix the layout file. Same effort, forty times the result.
• Broken plumbing: Sitemap entries that 404, canonicals pointing at pages that no longer exist, redirect chains three hops deep.
• Scale, so you can prioritize: "Your title is long" is a shrug. "Your title is long on 61 pages, and 9 have no H1 at all" is a work order.

Why "audit my site" only audits one page

Hand Claude a URL and it fetches that page. That is the whole behavior. No crawler, no sitemap parser, no memory of the last forty pages it read. So when you say "audit my site," it does the only thing it can. This is the same limitation behind every other SEO job. Claude is excellent at judgment and blind to live data.

MCP is how you close that gap. An SEO MCP server gives Claude a tool that takes a domain, reads its sitemap, fetches a batch of pages, and returns structured data instead of a wall of HTML. Once that tool exists, "audit my site" becomes a real instruction.

Nobody fixes 400 issues

Here is the uncomfortable part, and it applies to nearly every audit product on the market, mine included until I built the thing that fixes it. Run a classic site audit and you get a number. 400 issues found. It feels thorough. It is also the most useless output in SEO, because nobody has ever fixed 400 issues. You skim it, fix the four that look easy, promise to come back, and never do.

The scary first-run number is a marketing asset. It sells the subscription. It does not improve the site. The run that improves the site is the second one. You fix a template, you re-audit, and you find out whether the number moved. That loop is where the work happens, and it is the part almost nothing is designed for. Most tools return you to a static report from last Tuesday, or worse, silently crawl a fresh set of pages so the comparison is meaningless. An audit you run once is a to-do list. An audit you run twice is a system. If your audit cannot answer "did my fix work," it is a report, not a tool.

The five-move workflow

1. Point it at the domain: "Audit mysite.com." It discovers the sitemap, ranks pages by structural importance, and audits the top batch.
2. Read the fix list from the top: Order by severity times pages affected. The top item is almost always a template bug, which is one edit with a large blast radius.
3. Fix the top item in the same session: This is the advantage of auditing inside an agent instead of a browser tab. Claude already has your repo open. Say "fix the missing H1s" and it edits the layout file rather than describing the edit. Review the diff like any other change.
4. Re-audit and read the delta: Same pages, not a fresh crawl. Health 74 to 89. Missing H1 fixed on 38 pages. One new issue introduced. That line is the whole point.
5. Then go page by page: Now that nothing is systematically broken, per-page work is worth doing.

Audit 25 pages, not 5,000

The instinct is to crawl everything. Resist it. Almost every site is a handful of templates wearing different content. Audit 25 pages chosen across those templates and you find nearly every repeating problem the site has. Auditing 5,000 finds the same ten problems five hundred times each and buries the two genuinely unique ones. Google puts the crawl-budget threshold at roughly a million pages changing weekly. If that is you, a dedicated crawler earns its place. For everyone else, the twenty-sixth page rarely tells you anything the first twenty-five did not.

There is a second reason. A fix list you can finish is worth more than a complete one you will not start.

What this will not do

• It is not an unlimited scheduled crawler: If you need a nightly crawl of every URL you own with historical graphs, a dedicated crawler is the right tool and I would say so.
• It grades mechanics, not quality: An automated check catches a missing H1 or a 404. It cannot tell you your post is boring or off-intent.
• Speed is a separate pass: Core Web Vitals need field data from real visitors. Reading your HTML is not measuring what your users experience.
• It cannot tell you what to care about: The audit sorts by severity and reach. It does not know that one of those 38 pages earns 80% of your traffic. Bring your own Search Console data and the priorities change.

How I run it

Full disclosure, I build one of these. ContextBolt SEO is a hosted SEO MCP server. You get one URL, you paste it into Claude Code, Claude Desktop, Cursor, or Codex, and your agent can run both audits. page_audit covers one URL, site_audit covers the site. It reads the sitemap, picks the structurally important pages, checks titles over 60 characters, descriptions outside 120 to 155, missing or multiple H1s, thin content, broken pages, redirecting sitemap entries, canonicals pointing nowhere, and missing alt text, then hands back a score out of 100 with a fix list sorted worst first. Cross-page duplicates come free, because it holds every page at once. The default run is 25 pages. It costs $35 a month.

The part I care about is the second run. Ask again and it re-checks the pages already in your report, least recently checked first, and leads with the delta rather than a fresh report. It never quietly audits new pages and bills you for it. Every run writes to one living report per site at ./seo-findings/audits/ as plain markdown, growing in place rather than spawning a new file each time. The audit trail sits in the repo next to the code it is grading.

If you would rather not pay for anything, you still get most of the way there. Search Console flags indexing problems across your whole site for free and it is your own data, which makes it the most trustworthy source you have. A free desktop crawler covers a few hundred URLs. The method works either way.

The longer walkthrough, with the full check list and the page-level companion, is in my site audit with Claude guide.

The version of a site audit worth running is not the one that finds the most problems. It is the one you run twice.