Site Audit With Claude: Crawl, Fix, Then Verify

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.

The gap matters more than it sounds. The problems that actually cost you traffic almost never live on a single 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.

This guide is the site-wide version. What a site audit catches that a page audit cannot, how to run one inside Claude, and the step almost every audit tool skips, which is proving the fixes you made actually worked.

What a site audit catches that a page audit cannot

A page audit asks whether one page serves one query. A site audit asks a different question. Does this site have anything systematically broken across it?

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

Duplicates across pages: Two pages with the same title are competing with each other in the same results. You cannot see that from either page. Google’s own guidance on consolidating duplicate URLs exists because this is common and quietly expensive. A site audit spots it in one pass because it holds every title at once.

Template bugs: If your blog layout drops the H1, every post is missing an H1. One 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 instead. Same effort, forty times the result.

Broken plumbing: Sitemap entries that 404 or redirect, canonical tags pointing at pages that no longer exist, redirect chains three hops deep. Google publishes guidance on keeping sitemaps clean for exactly this reason, and none of it is visible from a single URL.

Scale, so you can prioritize: “Your title is long” is a shrug. “Your title is long on 61 pages, and 9 pages have no H1 at all” is a work order. Severity times the number of pages affected is the only sane way to sort a fix list, and you need the whole set to compute it.

Why “audit my site” usually only audits one page

Hand Claude a URL and it fetches that page. That is the whole behavior. It has no crawler, no sitemap parser, and no memory of the last forty pages it read. So when you say “audit my site,” it does the only thing it can and audits the page you gave it.

This is the same limitation behind every other SEO job. Claude is excellent at judgment and blind to live data. The Model Context Protocol, the open standard Anthropic released for connecting AI tools to external systems, 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 them as structured data rather than a wall of HTML.

Once that tool exists, “audit my site” becomes a real instruction. Claude calls the tool, gets back every page’s title, headings, word count, status code, canonical, and image alt coverage, then does what it is actually good at, which is reading all of it and telling you what matters. The same pattern covers SEO analysis at the domain level and the page-level work in on-page SEO audits.

Nobody fixes 400 issues

Here is the uncomfortable part, and it applies to nearly every site 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 single 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 actual 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. The second run needs to re-check the same pages you already covered and lead with the delta, health before against health after, what got fixed, what broke since. If your audit cannot answer “did my fix work,” it is a report, not a tool.

How to run a site audit with Claude, step by step

Once Claude can fetch pages at scale, the audit is a short conversation. Five moves.

Step one. Point it at the domain: Say “audit contextbolt.com.” Claude discovers the sitemap, ranks pages by how structurally important they are, shallow URLs and hub pages first, and audits the top batch. You want roughly 25 pages, not everything. More on why below.

Step two. Read the fix list from the top: Ask for the issues ordered by severity times pages affected. The top item is almost always a template bug, which is a single edit with a large blast radius. Resist the urge to start at the bottom where the easy wins live.

Step three. 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 repository open. Say “fix the missing H1s” and it edits the layout file rather than describing the edit to you. Review the diff like any other change.

Step four. Re-audit and read the delta: Run the audit again on the same pages. You want a response that opens with what changed, not a fresh report. Health 74 to 89. Missing H1 fixed on 38 pages. One new issue introduced. That line is the entire point of the exercise.

Step five. Then go page by page: Now that nothing is systematically broken, the on-page audit is worth running on your money pages, because you are optimizing a page rather than papering over a template. Pull your real numbers from Search Console at this point so you know which pages deserve the attention.

The first pass takes a few minutes. The fix takes as long as the fix takes. The re-audit takes another few minutes and is the only part that tells you whether any of it worked.

What a site-wide audit actually checks

Here is the split between what only a site audit sees, what a page audit already covers, and what neither can judge without you.

The first five rows are the reason to run a site audit at all. The last two are the reason a site audit is never the whole job.

Why 25 pages beats 5,000

The instinct is to crawl everything. Resist it.

Almost every site is a handful of templates wearing different content. A blog layout, a product layout, a landing layout, a docs layout. If you audit 25 pages chosen across those templates, you will find nearly every repeating problem the site has. Auditing 5,000 pages finds the same ten problems five hundred times each and buries the two genuinely unique ones.

Large sites do have a real reason to care about full crawls, mostly around crawl budget. Google puts that threshold at roughly a million pages changing weekly, or ten thousand pages changing daily. If that is you, a dedicated crawler earns its place. For everyone else the honest answer is that the twenty-sixth page rarely tells you anything the first twenty-five did not.

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

What a site audit with Claude will not do

The limits, stated plainly, because a tool that oversells itself wastes your afternoon.

It is not an unlimited scheduled crawler: An agent-based audit runs when you ask it to, over a sensible batch of pages. If you need a nightly crawl of every URL you own with historical graphs, a dedicated crawler is still the right tool and I would say so.

It grades mechanics, not quality: An automated check reliably catches a missing H1, a duplicate title, or a 404. It cannot tell you your post is boring or off-intent. That judgment comes from Claude reading the content the audit surfaced, against the live results for the query. Two different jobs.

Speed is a separate pass: Core Web Vitals, including INP, which replaced FID in March 2024, need field data from real visitors. An audit that reads 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.

Running the audit with ContextBolt SEO

Full disclosure, since you are reading this on the ContextBolt blog. I build one of these.

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

The default run is 25 pages, deliberately, for the reason above. It costs 1 credit per page out of the 1,000 you get each month, so a full audit is 2.5% of your allowance. Pricing is $35 a month, roughly a quarter of an Ahrefs plan.

The part I actually care about is the second run. Say “audit my site” again and it re-checks the pages already in your report, least recently checked first, and leads with the delta. Health 74 to 89 since July 14. Fixed: missing H1 on 38 pages. It never quietly audits fresh pages and bills you for it. New pages only get added when you explicitly ask. And because the whole thing lives in your agent, the loop closes in one chat. Audit, fix the top three, audit again, watch the number move.

Every run writes to one living report per site at ./seo-findings/audits/ in your project, as plain markdown, growing in place rather than spawning a new file each time. So the audit trail sits in your repo next to the code it is grading, and it remembers what changed.

If you would rather not pay for anything, you can still get most of the way there. Google 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 will cover a few hundred URLs. The method in this guide works either way.

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