How to Do a Technical SEO Audit with Claude

A complete technical SEO audit, run as a conversation: your Search Console history, a first-party crawl, Google's index status for your URLs and optional DataForSEO market data, joined in one local database and prioritised by the clicks each fix should recover. Free, apart from Claude and the DataForSEO credits if you choose to add them.

If you run technical SEO for a living, you know how the audit week goes. The crawl runs overnight. Tuesday is exports: the Internal tab, the Bulk Export menu, Redirect Chains, Orphan Pages. Then the spreadsheet work begins, joining crawl data against Search Console by hand, and by Thursday there's a findings list and very little time left to read it properly. Most of that week was data collection. The judgement, the part a client is paying for, got squeezed into whatever was left.

What a technical audit costs

Start with the standard instrument. Screaming Frog's SEO Spider has been the working SEO's crawler for the best part of two decades, and it has earned that position: £199 a year for a licence (with a free tier capped at 500 URLs per crawl), and on the paid tier it pulls GA4, Search Console and PageSpeed data in through API integrations. I've run more audits with it than I could count. Nothing in this article is a complaint about the crawler.

The cost is everything around the crawler. The authority walkthroughs for a Screaming Frog audit (Screaming Frog's own guide and Seer Interactive's, both excellent) run to 26 steps before anyone mentions log files: crawl configuration, near-duplicate detection, response codes, redirect chains, canonicals, titles and metas, H1s, thin content, sitemap diffs, orphan pages, internal linking, hreflang, JavaScript rendering, Core Web Vitals, and a final human triage of the Issues tab. Each step is an export and a filter. And when two datasets need joining, the guides print the spreadsheet formula for you. This is Seer's, verbatim, for tracing redirect destinations:

=VLOOKUP([@Destination],'response_codes_redirection_(3xx).csv'!$A$3:$F$50,6,FALSE)

Read that formula as an admission. The workflow's own documentation concedes that the joins (crawl against GSC, redirects against status codes, sitemaps against reality) are manual labour, done in Excel, by you, every audit. Seer's guide even says the quiet part: "the real skill is how to filter what comes back."

The filtering and the deciding are judgement. Everything before them is collection, and collection is now a machine's job.

What SEO Audit Console is

SEO Audit Console is an MCP server (if MCP is a new term, start with what an MCP server is ) that puts four data sources into one SQLite database per property, on your own disk: your full Search Console history, a first-party crawl of your site, Google's URL Inspection verdicts, and on-demand DataForSEO market data. You then run the audit by talking to it, in Claude Desktop or Claude Code.

Install is npx @houtini/seo-audit-console (Node 20 or newer), or a one-click .mcpb desktop extension if you'd rather not see a terminal at all; the repo covers both routes. The licence is source-available: free for personal use and evaluation, a commercial licence for agency and client work, and each release becomes Apache 2.0 after three years. So for auditing your own sites the whole thing costs nothing beyond your Claude subscription, plus DataForSEO credits if you want the market data later on.

If you want the Search Console half on its own, without a crawl, Better Search Console is the smaller sibling. This article covers the full merged audit, because the merge is where the checks live that a crawler can't run alone.

You stay in control

SEOs are a suspicious bunch, and rightly so; nobody wants to present a client with a number an AI dreamed up. So here is the engineering, plainly. Every figure in the audit is the result of an API call or a SQL query against the database on your disk. Claude orchestrates the queries and reads the results back to you; the numbers themselves come out of the tables. It does not imagine anything.

You can inspect all of it, too. query_data answers ad-hoc questions from the raw tables ("how many indexable pages return 200 but have no internal links pointing at them?"). normalize_url shows you the exact join key any URL resolves to, so you can see precisely how the crawl row met the GSC row. And the SQLite file is a normal SQLite file: open it in any database client and check the workings whenever you like.

The audit itself runs 93 checks, and every check is labelled one of two ways. Deterministic checks cite bytes: the canonical points at a redirect, this page 404s with external links still aimed at it. Judgement checks are the model's opinion (this page doesn't answer the intent of its top query), and they are off by default; you request them explicitly. That labelling is what makes the report defensible in front of a sceptical developer, or a board. For every number, you can say: here is the query that produced it.

Setup, and the step everyone misses

Setup is a ten-minute job, and most of those minutes are Google's. You create a Google Cloud project, enable the Search Console API, create a service account, and download its JSON key. The repo walks through each screen, and adding an MCP server to Claude Desktop covers the Claude side if this is your first server. (New to Claude entirely? A new account comes with a free week of Claude Code , which is plenty to run your first audit.)

Then the step everyone misses. The service account has its own email address, and that email address must be added as a user on your Search Console property, inside the GSC interface, under Settings and then Users and permissions. Miss it and everything installs cleanly, the server starts, and list properties comes back empty. The empty list is the symptom; the missing user is the cause, every time. It is the number-one setup question by a distance.

Point GOOGLE_APPLICATION_CREDENTIALS at the JSON key in your MCP config, restart Claude Desktop properly (quit from the tray; closing the window is not a restart), and you're ready to pull data.

Pull the data

Two prompts. First, in a new chat:

list properties

Your Search Console properties come back as a list. If yours is missing, it's the service-account step above. Then:

refresh sc-domain:yoursite.com

One prompt runs the whole acquisition: the GSC history sync, a polite first-party crawl, URL Inspection for your key pages, and an internal link-value calculation over the result. Two numbers from my own site are worth knowing before you run it. The first sync pulls your full history and is the slow one: 33 minutes for me. Every refresh after that is incremental; mine take 19 seconds.

The crawl seeds itself from your internal links, your sitemaps and your GSC URL inventory together, which on my site lifted coverage from 29% to 70% of the pages Google knows about. That gap is orphan pages: URLs still earning impressions that your own navigation no longer reaches. A crawler starting from your homepage cannot find them, by definition, because nothing links to them. Seeding from GSC finds them by default.

Run the audit

Run an SEO audit on yoursite.com

The 93 checks run against the merged data, and what comes back is ranked by a priority score: the traffic at stake, times the share of it the fix should recover, times how certain the evidence is, divided by the effort in developer-hours. A title rewrite worth a few thousand clicks outranks a fiddly structural fix worth a dozen, whatever colour a severity scale would have painted them.

On my sim racing site the current run shows 1,473 findings, 5 of them critical, against 24.4K clicks in the last 28 days, with an estimated 24.9K clicks recoverable across the whole list. Nobody reads 1,473 findings, and the scoring model exists so that you don't have to. Each finding carries its evidence (which pages, which queries, which numbers), the traffic at stake, and the fix. Read the top five properly and you have a morning's plan.

The dashboard

There's a proper control room as well. serve_dashboard starts a localhost-only web dashboard in your browser: six tabs (overview with the executive summary, issues and fixes, site health, opportunities, search performance, architecture), a property switcher, and CSV downloads for findings, keywords, striking-distance queries and page movement. It reads the same SQLite database the audit writes, so it is live rather than a snapshot; refresh the data and the dashboard follows.

If you're the sort of SEO who wants a screen to live in while the conversation does the work, this is that screen. Nothing is hosted anywhere; it serves on localhost and stops when you stop it.

Ask it questions

Your crawl is what your site says about itself. Search Console is what Google did about it. The checks that need both are the ones a standalone crawler cannot run, and they're the ones that pay for the whole exercise. Some worked examples from my own property:

Cannibalisation, with thresholds that respect the noise. One page holds 59,570 impressions for its term; nine other pages each held between one and seven impressions for the same query. A naive report flags all ten as competitors. The thresholds ignore the nine (incidental long-tail overlap) and the findings that survive are genuine splits, where two pages are trading a ranking between them.

Striking distance: queries ranking just off page one where the ranking page's title never uses the term. The crawl holds the title, GSC holds the query, and the fix is usually an afternoon's copywriting.

Ghost pages: URLs earning impressions that no longer exist in your link graph. 404s with backlinks: equity you've earned and are throwing away, with the check confirming whether each linked page still resolves. Orphan pages with impressions, per the coverage gap in the refresh step.

The architecture tab draws the same idea as one picture: internal link equity on one axis, actual search performance on the other. Pages your architecture favours that earn nothing; pages that earn plenty while buried at click depth five. The crawl supplies one axis and GSC supplies the other.

The newest question the console answers is the harder one: not what is broken, but why a page is losing. Point recon_targets at your declining or striking-distance pages and it fetches your live page alongside the live Google results, then sorts each one onto a rank-by-AI-Overview matrix - defend it and go deeper, refresh it for accuracy, consolidate a weak page, or accept it cannot rank and move on. The verdicts land on a per-page to-do board (recon_todos), and when you ship a fix and tell it to remeasure, it re-pulls the SERP and records whether the ranking moved. That last part is the bit most tools skip: proof the fix was worth the afternoon.

Fixes as artefacts

Generate the fix for the broken links on /old-page

Findings come with fixes, and the fixes are artefacts. Redirect rules arrive in your server's flavour (.htaccess, nginx or Next.js), dry-run, as text for you to review. Structured data arrives as a complete JSON-LD block built from the page's own content, so there's nothing invented to fact-check. Internal-link recommendations arrive as a ranked list of donor pages, chosen from the same link-equity data the architecture chart plots.

One boundary stated plainly: the tool never touches your site. It writes the rule; applying it stays your job. Obviously you'd test the redirect map before deploying it, same as any redirect work, and having the artefact in hand makes that testing the whole of the remaining task.

How it compares to a Screaming Frog audit

Put the classic walkthrough next to this workflow and the coverage reads like this. Crawl configuration, response codes, redirect chains, canonicals, titles and metas, H1s, thin and duplicate content, sitemap-versus-crawl diffs, orphan pages, internal linking and crawl depth, hreflang, structured data validation: covered, and the orphan and sitemap steps come out stronger here because the GSC join is native where the crawler needs a paid API connection. JavaScript rendering is covered as a rendered-versus-source comparison stored per page. Core Web Vitals runs per URL through Lighthouse in the paid DataForSEO tier. Spelling and grammar isn't a check category here; Screaming Frog has one. Log-file analysis is absent from both sides: Screaming Frog sells a separate Log File Analyser for it, and here it remains a separate discipline entirely.

The ledger, then. Screaming Frog: £199 a year, the GA4/GSC/PSI integrations on the paid tier, a free 500-URL version, and twenty years of earned trust. This: free apart from Claude, GSC native, and 23 merged crawl-and-GSC checks that need the join a crawler doesn't have. If you've been searching for a Screaming Frog alternative because the annual licence for crawling software has started to grate, the licence terms are the other half of the comparison. This isn't a closed binary you renew each year: the code is source-available and readable, free to run on your own properties, the crawler component began life as an open-source project , and each release lands in Apache 2.0 three years after it ships. Agency and client work still needs a commercial licence, so the precise claim is "readable, and free for your own sites", which is the claim that matters to an in-house team.

I should also be straight about the direction of travel: Screaming Frog now ships its own AI integrations and its own MCP server, so "the crawler has no AI" stopped being true a while ago. The difference today is the database, four sources under one set of join keys, priced in recoverable clicks. I haven't run their MCP server against a large crawl in anger yet, so I can't tell you where its edges are; that comparison will have to wait.

Going outward with DataForSEO

Everything so far uses only your own data. Search Console's blind spot is that it only describes searches where you already appear; it cannot size a market, and it cannot show what competitors rank for in places you're absent. That's the one optional paid piece: a DataForSEO account (affiliate link; the DataForSEO MCP article covers the same account used for general keyword work).

What's the search volume for "sim racing cockpit"?
What do my competitors rank for that I don't?

The outward-looking set does the rest. serp_features shows which of your queries now carry AI Overviews and other SERP features taking your clicks; I've written separately about generative engine optimisation , and this is where the two lenses meet. market_sizing estimates share of voice against up to four rivals. keyword_list and content_opportunities cost nothing at all, because they cluster demand from your own GSC data and produce a write-next, refresh-now, rewrite-snippets list.

On cost: calls are fractions of a cent, responses cache for 20 days, and the API is only called when you ask a question that needs it. A few dollars a month in normal use, in my experience. One gotcha before you buy: DataForSEO's Backlinks API is a separate subscription from the SERP, Keywords and Labs APIs, and the backlink tools will tell you if your account lacks it. The one I reach for there is link_intersect - it lists the sites linking to your competitors but not to you, sorted by trust rather than raw count (and re-sorted by Majestic's Trust Flow if you add a Majestic key), which turns "who should we chase for a link" from a hunch into a ranked list.

The personal view

I ran a technical SEO agency for around fifteen years (SEOgadget, which became Builtvisible), so this section is written from the inside. On a typical technical engagement, most of the invoice pays for collection: crawling, exporting, joining, formatting, building the deliverable. The interpretation, the part the client believes they're buying, is the thin layer at the top. That was a fair trade when collection took a skilled person a week. It stops being a fair trade when collection takes a conversation and 33 minutes.

As this MCP develops, my view is there will be little need for an agency on this kind of work if you have a good in-house team willing to learn responsible AI use. The agencies that survive will be selling interpretation: the judgement about which five findings deserve the developer's afternoon, and the experience to know when the data is misleading you. That was always the valuable part of the trade. Now it's the only part left to sell.

Your first run, in order:

1. Install: npx @houtini/seo-audit-console (or the .mcpb from the repo)
2. Create the service account, download the JSON key, and add the service-account email as a user on your GSC property
3. list properties to confirm the plumbing
4. refresh sc-domain:yoursite.com (33 minutes or so first time; seconds thereafter)
5. Run an SEO audit on yoursite.com
6. Read the top five findings and ship fix number one

Then the routine: refresh weekly, and run detect changes straight after (it diffs your two most recent crawls, which is how you catch a bad deploy in a day rather than three weeks later in a traffic graph). Full audit monthly. Re-run after any fix ships and watch the finding drop off the list. The Tuesday that used to be exports is now twenty minutes reading five findings, and the rest of the week is yours for the work that was always the point.