Audit Your Own Site With Claude Code: The Prompts That Actually Work

The audit you can run yourself

The technical half of an SEO audit is mechanical. Load pages, read the HTML, check DNS records, compare what the code says against what the live site actually serves. It's exactly the kind of work an AI coding tool does well, and it's the kind of work agencies charge four figures for.

You can run it yourself in about an hour with Claude Code, or any agent that can run terminal commands against your repository. This guide is the prompts. If you want the checklist version instead — what to fix, in what order — start with the post-deploy checklist.

One honest caveat before you start: this covers the technical audit — indexing, metadata, structured data, email authentication. It doesn't cover keyword research, competitor analysis, or anything requiring ranking data, because those need paid tools and your Search Console login. Technical problems are the ones that stop your site working at all, so they're the right ones to fix first.

Why "audit my site for SEO" produces nothing useful

Ask an AI to audit your site in one sentence and you get a generic checklist. It will tell you to use descriptive titles, add alt text, and improve page speed. All true, none of it about your site.

That happens because the model is answering from memory instead of looking. The whole trick is to make it check rather than recall — give it commands to run, files to read, and real output to react to. A model with your actual HTML in front of it is a completely different tool from one being asked what it knows about SEO.

Three rules that make the difference:

• Demand evidence. Every finding must cite the command that produced it and the output that came back. This kills the confident-but-invented finding, which is the main failure mode.
• Compare live to source. The rendered HTML is the truth. Your code is intent. The gap between them is where the bugs live.
• Make it check every page, not one. Bugs of this kind are usually systematic. One page tells you nothing about the pattern.

What you need

Claude Code running in your project directory, with permission to run read-only shell commands (curl, dig, grep). Everything here is read-only — nothing modifies your site. If you use a different agent, the prompts work anywhere the tool can run a terminal.

Prompt 1 — What does Google actually have?

Start with reality, not code. This is the finding that tells you how urgent everything else is.

Check what search engines can actually see of my site at [YOUR DOMAIN].

Run these and show me the raw output of each:
1. curl the sitemap and count the <loc> entries
2. curl robots.txt and show it in full
3. curl -I the homepage and the apex domain, and show the status
   codes and any redirect chain
4. For every URL in the sitemap, fetch it and report the HTTP status

Then tell me: how many pages does my sitemap claim exist, how many
actually return 200, and does robots.txt block anything.

Do not give me recommendations yet. Just the numbers, with the
command output that produced each one.

Withholding recommendations matters. Let it establish facts before it starts reasoning, or it will pattern-match to advice and stop looking.

Prompt 2 — The canonical and metadata sweep

This is the prompt that would have caught my most expensive bug, and it's the highest-value one here.

For every page in my sitemap, fetch the live HTML and extract:
- the <title>
- the meta description
- the rel=canonical URL
- whether any JSON-LD structured data is present

Put it in a table, one row per page.

Then flag:
- any page whose canonical does NOT point at its own URL
- any two pages sharing a title or description
- any page with no structured data

For anything you flag, find the code that produces it in this repo
and show me the specific file and line. Explain why the code
produces that output.

The second half is what makes this worth running. Anything can tell you a canonical is wrong. Tracing it to the line of code that caused it is the difference between a report and a fix — in my case, four words in a root layout that every page silently inherited.

Prompt 3 — Domain and email health

Entirely separate from your site's code, and the reason your email lands in junk.

Audit the email authentication for [YOUR DOMAIN] using dig. Show
raw output for each lookup.

Check:
- MX records — who handles my mail
- SPF (TXT at the root) — is it valid, and does it cover every
  service that sends as me
- DKIM — check selector1._domainkey and selector2._domainkey, and
  also sweep common selectors for other providers
- DMARC (TXT at _dmarc) — what policy, and is there a reporting
  address
- Whether the domain is listed on Spamhaus DBL or SURBL
- The domain's registration date via whois

For DKIM, resolve the full CNAME chain and confirm a real public
key comes back at the end. A CNAME that exists but resolves to
nothing means DKIM is not actually working.

Tell me plainly which of SPF, DKIM and DMARC are working, which
are missing, and which are present but misconfigured.

That DKIM instruction is deliberate. A CNAME can exist and look correct while resolving to nothing, because publishing the record and enabling signing in your mail provider are two separate steps. Only following the chain to an actual key proves it works.

Prompt 4 — Internal links and content structure

For every content page in my sitemap, count how many links it has
to other pages on my own site, excluding nav and footer links.

Show me a table of page -> number of outbound internal links ->
which pages it links to.

Then map which of my pages are reachable only from the navigation
and not from any content link. Suggest specific, in-context links
worth adding, quoting the sentence in the existing copy where each
link would naturally go.

The last clause is what stops this producing a "related posts" box. Links belong inside sentences where a reader would actually want them.

Prompt 5 — Force it to argue with itself

Run this after the first four. It catches more than any of them.

Review every finding you have given me so far. For each one:

1. Restate it in one sentence.
2. Show the specific evidence — the command and its output.
3. Rate your confidence: confirmed by direct observation, inferred,
   or assumed.
4. For anything not confirmed by direct observation, run whatever
   command would confirm or disprove it, and report what you find.

Then tell me which findings you got wrong, and which you cannot
verify with the access you have.

Models produce plausible findings under pressure to be helpful. Asking directly what it can't verify tends to surface the soft ones, and the answer to "what can't you check" is genuinely useful — it tells you what still needs a human.

Which skills help

If your setup supports skills or similar extensions, two are worth having loaded. A web-fetching capability lets the agent read your live pages rather than only your source, which is essential — the whole method depends on comparing rendered output against code. And a browser automation capability lets it check things that only exist after JavaScript runs, and reach logged-in tools.

Beyond that, resist adding more. This audit is mostly curl, dig and grep. The value is in the prompting, not the tooling.

Verify before you act

Treat the output as a first draft from a capable new hire.

• Spot-check two or three findings by hand. View the page source yourself. Run one dig yourself. If those match, the rest is probably sound.
• Be more skeptical of counts than of individual facts. "This page's canonical is wrong" is easy to verify. "Six pages have this problem" requires it actually checked all six.
• Never let it change DNS. Read-only. DNS mistakes break email instantly, and the failure is silent.
• Watch for confident recall. If a finding has no command output behind it, the model is remembering, not checking. Ask it to prove that one.

What it can't do

Stated plainly, because knowing the boundary is what makes the rest trustworthy:

• It can't see your Search Console data. Impressions, queries, and Google's own index status need your login. It can tell you your canonical tags are wrong; only Search Console tells you what Google did about it.
• It can't tell you your rankings, and anything it says about them is guesswork.
• It can't judge whether your content is any good. It will happily audit the structure of a page nobody wants to read.
• It can't fix DNS, and should not be allowed to.

The one-hour sequence

That last row isn't optional. The site: search is the only step here that tells you what Google has actually done, and it takes thirty seconds.

Where Hoven fits

If you get stuck on any part of this — or you want help with any other AI solution, or AI training for your team — reach out.