Claude for Technical SEO: Audit the Repo, Not the Crawl

Search for how to use Claude for technical SEO and the advice you find is some variant of the same move: export a crawl, paste the worst rows into a chat window, and ask Claude what to do about them. That workflow treats Claude as a smarter place to read a crawler report — and it wastes almost everything the model is actually good at. Technical SEO on a modern site is not a rendered-page problem that happens to have code behind it. It is code: robots rules, sitemap generation, canonical logic, metadata, redirects, and structured data are all source files. The right place to put Claude is not on the export side of a crawler. It is inside the repository, where it can read the files that cause the symptoms the crawler photographs — and then fix them in the same session, as a pull request a human reviews.

This guide is the technical-SEO spoke of our Claude for SEO pillar. It covers what Claude can determine about your technical SEO statically — before anything is crawled — the concrete file-by-file checklist, how fixes ship as PRs, and the part almost every AI-SEO workflow skips: verifying each fix in Search Console about three weeks later, so “Claude fixed it” becomes a measured claim instead of a hopeful one. One honest disclosure up front: the query this article targets records essentially no search volume yet. The practice is ahead of the demand. That is usually the best time to write the guide.

The crawler found the symptom. The repo contains the cause

A crawler works from the outside in. It fetches rendered pages, samples what it can reach, and reports symptoms: two conflicting canonicals here, a redirect chain there, a cluster of pages missing from the sitemap. Every one of those symptoms has a cause, and on a framework-built site the cause is almost never on the page — it is in a template, a config file, or a middleware branch. The crawler can tell you a hundred pages carry the wrong canonical. It cannot tell you that all hundred are rendered by one layout file with one bad line, because it has never seen the layout file.

Claude running inside the repo starts from the cause. It reads the template and knows — without fetching a single URL — that every page the template renders inherits the bug. That inversion changes the economics of the audit twice over. Coverage: a crawler samples, but a file read is exhaustive, because one generateMetadata function is the metadata of every route that uses it. Speed: the first pass of a technical audit on a Next.js site is reading perhaps ten files, which takes Claude seconds, not the hours a full crawl takes on a large site.

On a site we audited, the sitemap route mapped over a content collection that had been restructured months earlier. The sitemap compiled, deployed, and returned a valid 200 — it had simply stopped including an entire template’s pages. A crawler saw nothing wrong, because every page it reached was fine; the missing ones were exactly the ones it had no path to. Reading app/sitemap.ts against the actual route tree surfaced the gap in one pass. That is the category of bug repo-first auditing exists for: invisible from outside, one file read from inside.

A crawler reports that a hundred pages carry the wrong canonical. The repo shows you the one line, in one template, that all hundred inherit it from — and Claude can read that line, fix it, and open the PR in the same session.

What Claude can read that a crawler cannot

On a Next.js site — and every serious framework has equivalents — the technical-SEO surface area concentrates into a short list of files. This is the map Claude works from, and each file has a characteristic failure class that is fully visible in source and largely invisible in a crawl.

Notice what unites the emphasized rows: they are bugs that pass every build, deploy without an error, and produce no visible defect on any individual page. They only exist as a relationship between files — sitemap versus route tree, canonical versus origin — which is precisely the kind of cross-file reasoning a language model with repository access is built for, and a page-by-page crawler is not.

The repo-first checklist, file by file

Here is the concrete pass, in the order Claude should run it — each check paired with the pass condition and the Search Console metric that will verify the fix. The metric is committed when the finding is filed, not after the fix ships; that discipline, and why the deeper five-layer version of this audit is structured the way it is, are covered in the sibling guide on technical SEO audits.

Two habits make this checklist work in practice. First, Claude should read the files as a system, not a list — the redirect check only means something whennext.config redirects and middleware rewrites are composed together, and the canonical check only means something against the live origin. Second, every finding should be filed before anything is fixed, with its expected impact and verify metric attached, so the audit produces an accountable queue rather than a heroic afternoon of unrecorded edits.

Fixes ship as pull requests, not tickets

This is where the repo-first frame stops being an audit optimization and becomes a different operating model. In the crawler-and-chat workflow, a finding becomes a ticket, the ticket waits for a developer, the developer re-derives the context the tool already had, and the fix lands weeks later — if it lands. When Claude is already in the repo, the entity that found the missing metadataBase is the entity that edits the file. The distance between diagnosis and fix collapses from a sprint to a diff.

The control point does not disappear — it moves to where software teams already have one: the pull request. Claude opens a PR with the finding, the evidence, and the change; a human reviews and merges. Nothing lands silently. This matters more in technical SEO than almost anywhere else, because the same files that fix indexation can destroy it — a bad robots rule or a wrong redirect is a sitewide incident, and a one-line canonical fix and a one-line canonical catastrophe look nearly identical in a diff. The PR is the human-review gate, and it produces something tickets never do: a timestamped, reviewable record of exactly what changed, which the verification step is about to need.

Not done until Search Console says so

A merged PR is still only a claim. The robots fix should restore impressions on the blocked section; the canonical consolidation should lift position on the surviving URL. Whether it did is a fact that does not exist until Google recrawls, reprocesses, and accumulates enough fresh query data to compare — in practice, about three weeks. Most AI-assisted SEO workflows end at the merge and let the claim stand forever. That is the half-job this whole method exists to avoid.

The working shape is a task board that closes the loop. Every checklist finding lands as a task carrying its verify metric and target; the merged PR flips the task to done with the PR URL attached; and a weekly monitor re-reads Search Console on anything past its verification date and writes down the verdict — confirmed, regressed, or inconclusive. Claude does the reading and the fixing; the board does the remembering; Search Console does the judging. The mechanics of that loop — and why three weeks is the physics of the data source rather than a product choice — are the subject of the sibling guide on closed-loop SEO.

Run this for a quarter and the byproduct becomes the asset: a per-site record of which technical fixes actually verify. Canonical consolidations confirming reliably, rendering work reading inconclusive twice in a row — the next audit pass starts from that measured history instead of a generic severity scale, which is how the loop gets smarter about one site instead of auditing it from scratch forever.

What Claude cannot see from the repo

Repo-first is a large share of technical SEO. It is not all of it, and pretending otherwise would break the method’s own honesty rule. Three blind spots stay outside the source tree no matter how good the model is.

What Google actually did. The repo shows intent; only Search Console shows outcome — what got indexed, what gets shown, what earns clicks. The audit reads GSC throughout as the record of reality, not just at verification time. What real users experience. Core Web Vitals are judged on field data at the 75th percentile of real visits. Claude can spot the unsized image and the blocking script in source, but the verdict comes from field measurement, and lab scores flatter every site. What sits outside the repo. CDN rules, edge configuration, a reverse proxy someone set up in 2021 — if it is not in the source tree, a source read cannot find it, and a confirming crawl of the live site remains the honest cross-check that what the code intends is what the server serves.

How to run this on your own site

The setup is deliberately boring. Claude Code runs in your website repository — the same place your developers already work — and connects over MCP to the data it cannot know from source: Search Console performance, the shared task board, and the crawl fallback. The connect guide covers the one-command install. From there, the loop above is the operating manual: read the ten files, file the findings with their verify metrics, ship the selected fixes as PRs, and let the weekly monitor write the verdicts.

If you want to see the find half run against your own data first, the free SEO report connects your Search Console and surfaces where the technical layer is already costing you — the sections shown but never chosen, the URLs competing with themselves. And if you would rather the whole loop ran as a service — findings filed, PRs opened, verdicts read — book a call and we will walk through what it looks like on your repository.