Most technical SEO audits sold for two thousand dollars are 80% mechanical. A specialist crawls the site, runs a few tools, copies the output into a deck, and writes some prose around the findings. The actual judgment, the part that needs a human, is maybe two hours of work.
I figured out about six months ago that Claude Code, run inside a folder with a CSV from Search Console and a fresh sitemap, can do that mechanical 80% in under an hour. I still do the judgment work myself. But the audit document I hand a client now lands the same day they sign, not three weeks later.
This is the playbook. Twelve prompts I run on every site, in the order I run them. Every prompt is copy-paste ready, written to be parameterized with your URLs, your Search Console export, your Lighthouse JSON. If you want the whole thing packaged, the Claude Code SEO Operator Kit is the productized version of exactly this.
Why a $2,000 audit is mostly repeatable pattern matching.
I’ve sat through enough agency audits to know what’s inside them. About 80% of every audit is the same recurring patterns: orphan pages, broken canonicals, missing schema fields, third-party script bloat, thin content, internal link gaps. The site changes; the patterns repeat.
Running the same checks by hand on every new client is the SEO equivalent of resetting a database with a clipboard. Claude Code does the pattern-matching part faster, more thoroughly, and without forgetting which checks ran. The audit deliverable I produce now has the same depth as a $2k report, but the work behind it costs me an hour, not a week.
The remaining 20% is judgment: which findings actually move revenue, which to ignore, which to sequence first. That’s where ten years of SEO since 2016, shipping through Medic, BERT, Helpful Content, and AI Overviews, makes the difference. The prompts below are the leverage. The judgment on top is what you’re hiring for.
The setup before any prompt.
Every prompt below assumes Claude Code is running inside a project folder with three things: a fresh sitemap.xml downloaded from the live site, a Search Console queries-and-pages CSV export from the last 90 days, and a Lighthouse JSON export from npx lighthouse [URL] --output=json for the homepage and three priority pages.
If your site is on WordPress, also drop in a CSV export of published posts and pages from your database. The prompts get sharper with this because Claude can cross-reference what is actually published against what is linked from the live HTML.
One safety rule: every prompt outputs a report or a CSV. None of them write to your site. The fixes go through your hands, on your timeline, after you read what was found. Claude Code is the analyst, not the surgeon.
Group 01: Crawl and indexing.
The first three prompts find pages Google cannot rank because they are unreachable, blocked, or pointing somewhere broken. Fixing these is usually the highest-leverage hour of work on any site over 50 pages.
Prompt 01 · The orphan-page finder
An orphan page is a published URL that no other page on the site links to in body content. Google can technically reach it via the sitemap, but without internal link equity it cannot rank. Most sites have between 5% and 15% of their pages stuck in this state.
Read sitemap.xml. For each URL, fetch the page and crawl every other page on the site looking for at least one internal anchor link pointing TO it. Count only links inside body content, not navigation, footer, sidebar, or breadcrumbs.
Output a CSV with columns: url, body_inbound_links, last_modified, suggested_link_source. The suggested_link_source should be a published page on a topically related theme where this orphan could be linked from a body sentence rather than a nav menu.
Sort by body_inbound_links ascending so true orphans (zero links) appear first.Run this once per quarter. Every new orphan that shows up is a content piece that shipped without an internal link plan. Fixing them is usually a 10-minute job per page: open the suggested source, drop in one body sentence with a natural anchor.
Prompt 02 · The indexable-but-noindexed sniffer
The bug here is subtle. A page is in your sitemap, has body content, and you expect it to rank, but a stray noindex tag, a misconfigured X-Robots-Tag header, or a robots.txt block is keeping it out of the index. I find this on roughly one in three new client sites.
For every URL in sitemap.xml, fetch the page and report any URL where:
- the robots meta tag contains "noindex", OR
- the X-Robots-Tag response header contains "noindex", OR
- the page is blocked in robots.txt at the path level
For each hit output: url, signal_that_fired, exact_text_or_header_value, intent_assessment.
Intent assessment: based on the URL pattern, is this likely intentional (search results pages, staging URLs, thank-you pages) or unintentional (a service page, a blog post, a category)? Flag the unintentional ones at the top of the report.This is the prompt that has saved more client revenue than any other on the list. I’ve seen entire blog categories silently noindexed for months because a developer set noindex in a custom field default and nobody caught it.
Prompt 03 · The canonical conflict auditor
Canonicals point Google to the version of a URL you want indexed. When they’re wrong, Google indexes the wrong page or none at all. The pattern that bleeds the most traffic is canonicals pointing to dead, redirected, or noindexed pages.
Crawl every URL in sitemap.xml. For each, extract the canonical link tag value. Build a table:
- source_url
- canonical_value
- canonical_equals_self (yes/no)
- canonical_target_status (200, 301, 404, noindex, blocked)
- canonical_target_in_sitemap (yes/no)
Flag every row where canonical_equals_self is "no" AND canonical_target_status is anything other than 200. Also flag rows where canonical_value points to a URL not in the sitemap. Group output by canonical_target so I can see clusters.This catches the worst SEO bug pattern that exists: a hundred service pages canonical-pointing to a dead URL that returned 200 six months ago and now 404s. Every one of those pages is invisible to Google.
Group 02: Schema.
Schema is the entity-disambiguation layer for Google and AI search. The next three prompts let you generate, validate, and audit schema across a site without hand-writing JSON-LD on every page.
Prompt 04 · The auto-FAQ schema generator
Most service pages have an FAQ section in the visible body content but no FAQPage schema in the head. Adding it is a five-minute win per page, and Claude Code can generate the JSON-LD directly from the existing visible text.
Read [page URL]. Extract every question-and-answer pair from the visible body content. Look for question-shaped headings (h2/h3/h4 ending in a question mark) followed by answer paragraphs, OR accordion blocks with a question label and an answer panel.
Output valid FAQPage JSON-LD with @context schema.org, @type FAQPage, and a mainEntity array. Use the actual answer text verbatim, do not paraphrase. Wrap the output in the standard JSON-LD script tag (type application/ld+json) ready to paste into the page head.
If fewer than two question-and-answer pairs exist on the page, return an empty result and tell me the page is not FAQ-eligible. Do not invent questions to pad the schema.The “do not invent questions” line matters. Faking FAQ schema with questions nobody asks is a Google quiet-downweight pattern. Only mark up real FAQ sections.
Prompt 05 · The Organization graph builder
This is the schema that makes you a known entity to AI systems. Most sites either have nothing or a Yoast-generated stub that’s missing the fields AI search actually reads.
Build a single Organization JSON-LD block for [domain]. Pull data from these specific sources:
- name from the title tag on the homepage
- logo URL from the link rel="icon" tag or the theme header
- sameAs array from social links in the footer
- contactPoint from the /contact page (extract phone, email, areaServed if listed)
- founder from the /about page if a founder name and title appear
Output one valid JSON-LD block with @context schema.org, @type Organization, a stable @id ending in #organization, and a Person sub-graph linked via founder if applicable.
Validate the final output against schema.org spec. Tell me which fields are missing that I should add manually before shipping.Run this once per site, ship it sitewide via the head, then forget about it. The sameAs array is the most important part. Every verified external link to your business is a citation signal for AI search.
Prompt 06 · The breadcrumb consistency checker
Visible breadcrumbs and BreadcrumbList schema disagree on roughly 30% of WordPress sites I audit. The visible chain says one thing, the schema says another, and Google trusts neither.
Crawl this list of URLs. For each, extract the BreadcrumbList JSON-LD if present and the visible breadcrumb HTML if present. Verify:
- the breadcrumb sequence matches the actual URL path segments
- every breadcrumb itemListElement has a valid @id (full URL, not relative)
- the last item is the current page
- position numbers start at 1 and increment without gaps
- the visible breadcrumb chain matches the schema chain item-for-item
Report a table: url, breadcrumb_present_yes_no, schema_present_yes_no, errors_found.Fix the schema-only errors first, those are five-minute jobs. Visible breadcrumb fixes usually need a theme-template edit, which is a different conversation.
Group 03: Performance.
The next three prompts find the speed and Core Web Vitals issues that move actual ranking. INP became the third Core Web Vital in 2024 and is now the metric most sites are quietly failing in 2026.
Prompt 07 · The CWV regression hunter
If your CWV scores got worse but you don’t know why, this prompt walks you back to the change that caused it.
I have two PageSpeed Insights JSON exports for [URL]: one from [date A] and one from [date B]. Diff them.
Output a markdown report with:
- which Core Web Vitals metrics moved more than 10% in either direction
- for INP specifically, which third-party scripts increased their main-thread blocking time
- which images contributed most to the LCP delta
- which JavaScript bundles increased in transfer size
Rank findings by user-impact (INP regression > LCP regression > CLS regression). For each regression, suggest the smallest fix that would reverse it. Do not suggest "remove all scripts" or "use a CDN" generic advice. Be specific to what the diff shows.Run this monthly on your top five revenue pages. CWV scores drift quietly. The diff makes the drift visible before Google starts demoting you for it.
Prompt 08 · The third-party script bloat audit
Every script you add costs INP. Most sites have at least three scripts they cannot identify and two more that should be deferred but aren’t.
From this Lighthouse JSON [paste the path or content], list every third-party origin loading scripts on the page. Show: origin, total_kb_transferred, main_thread_blocking_time_ms, count_of_scripts, async_or_deferred (yes/no/partial).
Rank the table by main_thread_blocking_time_ms descending.
For the top 5 origins, tell me what the script likely does (analytics, chat widget, tag manager, fingerprinting, retargeting) and recommend one of: move to GTM, defer with a load delay, self-host, or remove entirely. Be opinionated. Do not give "consider whether you need this" non-answers.The output of this prompt is usually three to five scripts that can be killed without revenue impact, and one or two that need a conversation with the marketing team. That conversation is faster when you have the table to point at.
Prompt 09 · The lazyload gap finder
Every below-the-fold image that is not lazy-loaded is delaying LCP for no reason. WordPress core does most of this automatically, but custom themes and Elementor templates routinely miss it.
For [page URL], list every image and embed element below the fold. Below the fold means the element's vertical position is greater than the viewport height when the page is rendered at 1366 by 768.
For each element show:
- has the lazy-loading attribute set (yes/no)
- has explicit width and height attributes (yes/no)
- appears before the LCP element in DOM order (yes/no)
Output a table: url, total_below_fold_elements, missing_lazy_count, missing_dimensions_count, suggested_fixes.
The goal is to surface every below-fold media element that should be lazy but is not, plus every element missing the dimensions that prevent CLS.Most fixes from this prompt are one-line additions to the theme’s image template. Big LCP wins for an hour of work.
Group 04: Content and internal links.
The last three prompts are about the content layer: which pages are too thin to rank, where internal links are missing, and which queries you’re cannibalizing yourself on.
Prompt 10 · The thin-page detector
Pages under 300 words with fewer than two inbound internal links are starvation pages. They cannot rank for anything competitive and they dilute the site’s overall topical authority.
Crawl this list of URLs. For each, count:
- visible body word count, excluding navigation, footer, sidebar, and comment counts
- internal links pointing TO this URL from body content (not nav/footer)
- last-modified date from the response header or sitemap
Flag every page where word_count is less than 300 AND inbound_internal_links is less than 2. These are starvation-pattern pages.
Output a CSV: url, words, inbound_internal_links, last_modified, suggested_action. Suggested action is one of: expand to 800+ words, merge with [related URL], 301 to [related URL], delete with no redirect.The merge-or-delete decision is judgment work. Use the suggestion as a starting point, then make the actual call yourself.
Prompt 11 · The internal link gap matrix
Topical clusters need internal linking between related pages, in body content, with descriptive anchor text. Most sites are missing 60% to 80% of the links a healthy cluster would have.
From this list of URLs about [topic X], build a matrix where rows are source pages and columns are target pages. Mark 1 if the source links TO the target in body content (not nav/footer), mark 0 otherwise.
Then flag every cell where 0 should be 1 because the topical relationship justifies a body link. For each suggested link give me:
- source URL
- target URL
- proposed anchor text (3 to 6 words, natural-sounding, not exact-match-stuffed)
- the existing sentence in the source where the link could slot in naturally
Sort by source URL so I can fix one page at a time.This is the single highest-leverage prompt for a site that already has good content but no internal link strategy. I’ve seen sites pick up 30% organic traffic in 90 days from running this once and acting on the output.
Prompt 12 · The cannibalization clusterer
Cannibalization is when two URLs from your site rank for the same query and split the click-through. Google ends up demoting both because neither has a clear win signal.
From this Search Console export of queries and landing pages over the last 90 days, group queries where:
- two or more URLs from my site rank in the top 20 simultaneously
- the URLs are not part of the same intentional topical cluster
- impression share is split (no single URL holds more than 70% of impressions for that query)
Output a table: query, urls_competing, current_top_url, total_impressions, current_total_clicks, recommended_action.
Recommended action is one of: consolidate via 301 redirect, merge content into one URL, internal-link the weaker page to the stronger one, or differentiate intent (rewrite one to target a different sub-query). Sort by total_impressions descending so the highest-traffic cannibalizations appear first.The output of this prompt usually has 5 to 15 cannibalization clusters on a healthy mid-size site. Fixing the top three is often a one-day project that recovers measurable traffic within 30 days.
The real before/after from one client.
Anonymized, but every number is real. Mid-size service-business site, around 180 pages, came to me in February 2026 with flat traffic for nine months. I ran the twelve prompts above over a single afternoon.
| Metric | Before (Feb 1, 2026) | After (May 1, 2026) | Delta |
|---|---|---|---|
| Indexed pages (Search Console) | 142 | 178 | +25% |
| Orphan pages | 27 | 3 | -89% |
| Pages with FAQ schema | 0 | 34 | +34 |
| INP (75th percentile, mobile) | 312ms | 184ms | -41% |
| Cannibalization clusters | 11 | 2 | -82% |
| Organic clicks (28-day) | 4,216 | 7,894 | +87% |
The traffic delta is what the client paid for. Everything else is leading indicators that explain why the traffic moved. The whole engagement cost the client a fraction of the $5,000 to $8,000 a US agency would have charged for the same scope.
What Claude Code can’t replace yet.
Three things, and these are the reason an SEO who knows their craft is still worth hiring.
Sequencing. A 50-finding audit is useless without a sequence. Which finding moves revenue first? Which depends on another fix being done first? Which can be batched into one engineering sprint? That’s pattern recognition built from shipping audits over years, not from any prompt.
Stakeholder reading. The technical SEO who is also a developer rarely understands why the marketing director is afraid to touch the homepage hero. The audit that gets shipped is the one that respects political constraints inside the client’s company. Claude can’t read a client’s discomfort. I can.
The unfindable bug. Once or twice an audit, there is a finding that doesn’t show up in any tool. A pattern of bot traffic that’s eating crawl budget, an Elementor widget injecting render-blocking JS only on Tuesdays, a CDN edge caching a noindex header for 24 hours. These need a human watching network tabs and reading server logs.
The prompts get me to the same depth as a $2k audit in an hour. The judgment on top of that is what you’re paying for. Take the prompts, ship the audits yourself if you want. Or hire me, and I’ll ship the audit plus the judgment plus the implementation in a week.
FAQ.
Do I need to know how to code to use these prompts?
You need to know how to install Claude Code and run it inside a folder. That’s a 10-minute setup. The prompts themselves require no coding. They output reports and CSVs you read in a spreadsheet. The fixes go through your existing CMS or developer.
Will Google penalize me for using AI in my SEO workflow?
No. Google’s policy is about the output, not the workflow. Using Claude Code to find orphan pages is identical, from Google’s perspective, to using Screaming Frog. The fix to the orphan page is the same either way: a real human writing a real internal link in real body content. Nothing AI-generated touches the live site.
How long does the full 12-prompt run take?
For a site under 200 pages, about 90 minutes of Claude Code wall-clock time, mostly waiting for crawls. Active human time, around 20 minutes of pasting prompts and watching output. Reading and acting on the output is a separate four to six hours, depending on how many findings you choose to fix.
Can I run these on a client site or only my own?
Either. The prompts only need a sitemap and public HTML to do most of their work. The Search Console and Lighthouse data are optional but sharpen the output. You can run the full audit on a prospect’s public site before they sign anything.
What happens if a prompt returns nothing?
That’s a clean result. Some sites genuinely have no orphan pages, no canonical conflicts, no thin pages. Move on to the next prompt. The value is in the prompts that do return findings, not in finding something for the sake of it.
What to do this week.
Two concrete actions, ranked by leverage:
- Install Claude Code if you haven’t. Run the orphan-page finder (Prompt 01) on your own site. The first time you see your own orphan list, the value of the rest of this playbook becomes obvious.
- Pick the prompt that maps to the SEO bottleneck you’ve been ignoring. Slow site? Run prompts 07 to 09. Suspicious traffic flat-line? Run prompts 02 and 03. Recent content investment with no ranking lift? Run prompts 10 to 12. One prompt, one afternoon, one ranked output.
If you’d rather skip the setup, the Claude Code SEO Operator Kit packages this exact playbook with my sequencing notes on top, ready to run on your own URLs.
