I Ran Claude SEO on My Sites — Here's What It Found

The most effective SEO tool I own is not a dashboard with a monthly invoice. It is a folder of thirteen markdown files sitting in ~/.claude/skills, each one teaching Claude Code how to audit a specific slice of a website. I can say that without hedging because I have the ugliest possible proof: my own site lost roughly three quarters of its indexed pages in the spring of 2026, and it was this toolkit, pointed at my own codebase and my own Search Console exports, that found the causes a conventional crawler had no way to see.

This post is the honest version of "I ran an AI SEO audit on my site": what the toolkit is, what it actually found, and where it still needs a human.

The Toolkit: 13 Skills, Each With One Job

A Claude Code skill is a markdown file with instructions and a trigger description. Instead of one bloated "do SEO" prompt, I run a family of narrow skills, and the narrowness is the point:

• seo-audit — the orchestrator; runs the full pass and ranks findings
• seo-technical — crawlability, redirects, status codes, robots rules
• seo-schema — structured data validation against what the templates actually render
• seo-sitemap — sitemap completeness, lastmod accuracy, orphan detection
• seo-hreflang — locale alternates and canonical consistency
• seo-page / seo-content — single-URL and content-quality passes
• seo-images, seo-competitor-pages, seo-plan, seo-programmatic, seo-geo, and a general seo entry point

Each one can read the actual Blade templates, controllers, and route definitions in my Laravel repo, not just the rendered HTML. Hold that thought, because it is the entire reason this works.

The Crash That Made This Non-Optional

Between April and May 2026, my indexed page count in Google Search Console fell from about 7,000 to about 1,700. No manual action. No warning. Just a cliff.

A traditional rank tracker tells you that this happened. It cannot tell you why, because the why lived in three places at once: my templates, my routing config, and my GSC coverage report. Here is what the audit actually surfaced when I ran the toolkit against all three.

Finding 1: fabricated review schema my own past self shipped

The seo-schema pass flagged aggregateRating markup on marketing pages that had no real reviews behind it. Some of that structured data had been generated during earlier AI-assisted content work and shipped without me auditing it. Google treats fake review markup as deception, and the timeline lined up with the deindexing far too well to be coincidence. Every fabricated block got removed. This was the single most painful finding, because the call was coming from inside the house.

Finding 2: six locales multiplying every thin page

My site serves six locales (en, nl, de, es, pt, fr). The audit cross-referenced the routing config with GSC's "crawled – currently not indexed" bucket, which had swollen to about 14,500 URLs, and the pattern was obvious once stated: every English-only page existed at six URLs, five of them serving duplicate English content under a locale prefix. Google was crawling the multiplication table and indexing almost none of it. The fix was canonicalizing English-only locale URLs back to the English original, which shipped as a one-line-of-intent, many-files-of-diff change.

Finding 3: sitemap rot

The seo-sitemap pass found duplicate tag archives (62 groups of near-identical tag pages, since merged; one merged tag page went from 6 posts to 198) and lastmod values that never tracked content updates, so Google had no reason to recrawl updated posts. My sitemap now regenerates every five minutes via the Laravel scheduler, with model observers busting the cache on content changes.

The remediation started shipping on May 4. Recovery was not instant and no tool makes it instant: indexation climbed back over roughly three months. Anyone selling you a faster timeline is selling you something else.

How an Audit Actually Runs

The workflow, concretely:

1. Export the evidence. GSC coverage and page reports go into a working directory as CSVs. Claude cannot see Search Console directly; you bring the data to it.
2. Run the audit skill. It crawls the local repo (templates, routes, middleware), spot-checks live production URLs, and reconciles the two against the GSC exports.
3. Findings come back ranked, each with the file and line that causes it, which is the part no SaaS crawler can ever give you.
4. A human applies the fixes. My hard rule: the toolkit writes idempotent, transaction-wrapped SQL and code diffs for review. Nothing touches the production database directly. Ever.

The whole loop also runs on a schedule for regression-catching, which I covered in automating SEO checks with Claude Code routines.

Why This Beats a Crawler-Based Tool (For This Job)

A crawler sees your website the way Google sees it: from outside. That is genuinely useful, and I still look at crawl reports. But every finding that actually explained my crash required reading source code:

• The fake aggregateRating was valid, parseable schema. A validator says "looks great." Only reading the Blade template and asking "where does this rating number come from?" reveals there is no data behind it.
• The locale duplication looked like 14,500 individual page problems from outside. From inside config/app.php and the route definitions, it was one problem with one fix.
• The sitemap lastmod bug was invisible externally; the values were present and well-formed. They were just lies.

The pattern: crawlers detect symptoms, codebase-aware audits find causes. You want both, but only one of them was missing from my stack.

Where the Toolkit Falls Short

Three honest limits, from months of use:

1. No live GSC access. The export step is manual, and stale exports produce confident, wrong conclusions. I re-export before every serious pass.
2. It will over-report. A full audit surfaces everything, including nitpicks that do not move indexation. The ranking helps, but deciding what not to fix is still judgment. Content strategy work like programmatic SEO and content automation sits on top of this, not inside it.
3. Verification is on you. After every fix I re-check the live URLs with curl and validate the sitemaps with xmllint before trusting the change. The audit proposes; production verifies.

What to Do With This

If your indexed count is stable, run a schema and hreflang pass anyway; my worst problem was invisible until it wasn't. If your indexed count is falling, get your GSC exports and your codebase in front of an audit that can read both, this week. The features that make this workflow fast (skills, scheduled routines, permission allowlists) are the same ones I covered in Claude Code features most developers never find.

And if you are staring at a deindexing cliff on a Laravel or WordPress site and would rather hand the whole investigation to someone who has personally dug out of one, get in touch. Indexation recovery is slow enough without spending the first month finding the leak.