Claude Code SEO failure modes

Why publish failures at all

A tool that's only ever described in success stories tells you nothing about its actual reliability. The same logic that leads this site to publish null results in its research program applies here: knowing specifically where agentic SEO tooling goes wrong is more useful to a practitioner deciding whether to trust it than another glowing case study.

The failure catalogue

How to read the two right-hand columns. Severity is how much damage the failure does if it ships. Critical means a whole subtree can drop out of an index; High means a page or section is misrepresented to crawlers; Medium means degraded quality; Low means cosmetic.

Detectability is the odds an ordinary reviewer catches it. High means a routine check finds it. Very low means nothing on the rendered page or in the build output will ever tell you. The rows to fear pair high severity with very low detectability, and a review checklist has to name those rows explicitly, because no reviewer stumbles onto them.

Ranking by how hard each is to catch

Not every failure mode is equally dangerous. The ranking isn't about frequency. It's about severity multiplied by how easily each one slips past a reviewer who isn't specifically looking for it. Confident wrong schema is the most dangerous by this measure. It validates cleanly and looks correct at a glance. It requires a reviewer to actually cross-check every generated value against the source content, not just confirm the markup parses.

Build passes, page is still broken is a close second, precisely because a green build result feels like confirmation when it confirms something much narrower. Over-eager bulk changes and silent design-system drift are comparatively easier to catch, since they tend to be visible on a normal read-through or a visual spot-check, once someone remembers to actually do one, rather than trusting the build alone.

A worked illustration: confident wrong schema

Here's the failure made concrete, without claiming it as a specific logged incident. Say an agent is asked to add Article schema to a batch of older pages. For a page whose author byline was updated at some point after original publication, the agent could plausibly pull the wrong name, if it reads a cached or partial version of the page rather than the current rendered content. That produces schema that's syntactically flawless, and would pass any structured-data validator, while asserting something false about who wrote the piece.

Nothing about the validation step would catch this. Schema validators check shape and required fields, not whether the values are true. That's exactly why the review step has to include checking generated values against the actual page content, not just confirming the generated block parses correctly.

A worked illustration: over-eager bulk changes

Similarly illustrative: an instruction like "rewrite every meta description under 160 characters," given without further guidance, can produce technically-compliant output that reads as formulaic once you look at ten of them in a row. Same sentence structure, same opening phrase, varied only by the specific product or topic name.

Each individual description might pass a length check and look reasonable in isolation. The failure only becomes visible when reviewing the batch as a set. That's a different, easily-skipped review step from checking any single page on its own.

Why a passing build catches so little of this

It's worth stating plainly why "the build passed" is such a weak signal for several of these failure modes. A build verifies that code compiles and renders without throwing an error, a syntax-level and structural check. None of the failure modes above are syntax errors.

A build passes wrong schema values, formulaic prose, subtle visual drift, and a broken internal link that resolves to a valid but wrong page. Every one of those is obvious to a human on inspection. This is precisely why the safety practices below insist on a visual and content spot-check as a separate step from the build, not a substitute for it.

Meta-failure: silent scope creep

The most consequential failure mode is not any single mistake above. It is an agent quietly doing more than it was asked, especially under an instruction to "just get it done." A request to fix one page's metadata drifts into restructuring navigation, renaming files, or touching unrelated components. Nothing stops it unless something forces a check against the original scope before each change is applied.

A related meta-failure: long-session context drift

A subtler cousin of scope creep. Over a long session covering many pages, adherence to an instruction given early — a specific style rule, a specific exclusion — can degrade relative to instructions given more recently, simply because more has happened since.

The practical mitigation is the same one that helps with scope creep generally. Periodically restate the governing constraints, rather than assuming they remain perfectly salient across an arbitrarily long session. Treat a long audit as a series of shorter, checkpointed passes, rather than one unbroken run.

What actually prevents these

• Review every diff before it's applied — the single highest-leverage safeguard, and the one most often skipped under time pressure.
• Build and visually check after each meaningful change, not just at the end of a long session.
• State scope explicitly and treat anything beyond it as a separate decision, not an assumed extension of the original request.
• Keep commits small and incremental so a bad change is easy to isolate and revert without losing everything else done in the session.

This site's own experience

This site is itself built and maintained using Claude Code, following the practices this page describes: dry-run review, incremental builds, and visual spot-checks before publishing. That's the source of the failure patterns catalogued above. Direct, first-party observation, not a synthesis of other people's reported experiences.

Why agents fail at SEO specifically

Agentic coding tools are unusually good at some tasks and unusually bad at others. SEO work sits awkwardly across the boundary. It is worth understanding why.

Most code has a fast, honest oracle. SEO does not. A failing test tells you the code is wrong within seconds. A wrong canonical tag tells you nothing for weeks, and then only indirectly. Agents improve fastest where feedback is immediate. Here it is slow and noisy.

Correctness is partly a matter of truth, not syntax. A compiler can check that a string is a string. It cannot check that the author name in your schema is the person who wrote the page. Any task where the failure is a false statement rather than a broken one loses the usual safety net.

Uniformity is a virtue in code and a defect in prose. Applying one clean pattern across forty files is exactly what you want from a refactor. It is exactly what you do not want from forty meta descriptions. The same instinct that makes an agent good at the first makes it bad at the second.

The blast radius is asymmetric. A bad function affects the code path that calls it. A bad robots directive affects every page behind it. Site-wide files concentrate risk in a way most application code does not.

The second-tier failure catalogue

The five modes in the first table are the ones we see discussed, when they are discussed at all. These are quieter and, in several cases, more expensive.

The common thread is invisibility. None of these change how the page looks. All of them change how it is treated by a crawler, and by the AI bots that read the same markup. A reviewer checking the rendered page will pass every one of them.

A worked illustration: the canonical tag

This is hypothetical. It is not a logged incident on this site. It is written out because the shape of the failure is more instructive than any single anecdote.

Take a site serving article URLs both with and without a trailing slash. An agent is asked to add canonical tags across the article template. It has no reliable way to observe which variant the routing layer treats as primary. So it infers one from the examples in front of it.

Suppose it infers wrongly. The markup is valid. The tag renders. The build passes. Every automated checker reports a canonical tag present, which is what most checkers test for. A human reviewing the diff sees a sensible-looking URL and moves on.

The consequence surfaces later, and indirectly. Signals split across two variants instead of consolidating on one. Nobody attributes the change to a two-line template edit made a month earlier.

The lesson is not "agents get canonicals wrong." It is that a task whose correct answer lives in configuration the agent cannot observe should never be inferred. Either give it the answer, or do not delegate that task.

Which SEO tasks are safe to delegate

Blanket rules are useless here. The useful question is per-task. Two properties predict most of the risk: how visible the failure is, and how wide the blast radius.

The pattern in the right-hand column is consistent. Where the failure is visible, delegation is cheap because review is cheap. Where the failure is invisible, the review cost is the real cost, and it often exceeds doing the task yourself.

The review pass, step by step

"Review the diff" is correct advice and too vague to follow. Here is what the pass actually contains, in the order that catches the most for the least effort.

Step 1. Read the file list before the diff. Count the files touched. Compare that to the number you expected. Scope creep shows up here faster than anywhere else, and it takes ten seconds.

Step 2. Check for site-wide files first. Anything under a config, template, layout, robots or sitemap path gets read line by line. These are where the blast radius lives.

Step 3. Verify truth-valued fields against the page. Author names, dates, prices, counts, headline text. Do not check that they parse. Check that they are true.

Step 4. Read batch output as a batch. Put ten generated descriptions in one view. Formulaic output is invisible one at a time and obvious in a column.

Step 5. Build, then actually open the page. A green build is a syntax check. Open two or three affected pages and look at them.

Step 6. Diff the rendered head. Title, description, canonical, robots, and structured data. Comparing the rendered head before and after catches most of the invisible failures in one look.

Step 7. Commit small, with the scope in the message. A message that names the intended scope makes a later "why did this change" answerable.

Steps 1, 2 and 6 catch a disproportionate share for the time they cost. If you are going to skip parts of this under pressure, skip the others.

Who this applies to, and who it does not

Failure catalogues are only useful when scoped. This one has a specific reader in mind.

It applies to you if you are the only reviewer. Solo operators and small teams carry the whole risk themselves. There is no second pair of eyes to catch a wrong canonical, so the discipline has to be explicit.

It applies if your changes reach production quickly. A site that deploys on merge has a much shorter window to catch anything.

It applies most to sites where a template covers many pages. Blast radius scales with templating. One bad line reaches everything the template renders.

It applies less if you already have staged review. A team with mandatory code review, a staging environment and a crawl diff in CI already has most of these covered by process. For them this page is a list of what their process is for, not new work.

It does not apply to purely local experimentation. If nothing reaches a live site, the cost of every failure here is your own time. That is a reasonable price for moving fast.

What these failures actually cost

Cost is the part nobody quantifies, so decisions get made on vibes. We cannot give you numbers we have not measured. We can give you the shape of the cost.

Detection lag is the dominant term. A visible failure costs the time to fix it. An invisible one costs that plus however long it went unnoticed. For index-level directives, that lag can span a full re-crawl cycle.

Recovery is rarely symmetric with the mistake. Reverting a bad canonical takes one commit. Waiting for signals to reconsolidate afterwards takes as long as it takes, and you cannot speed it up.

Attribution cost is real and usually ignored. When traffic moves, the investigation itself is expensive. Small commits with scoped messages are the cheapest insurance available against that cost.

Trust cost compounds. One confidently wrong output makes a team review everything twice as slowly for a month. That drag is larger than the original error, and it never appears in any incident report.

Null results we would publish

This page would be more credible with a measurement behind it. These are the results we would publish even if they undercut the argument here.

If a structured review checklist did not reduce error rate. We recommend the checklist above on reasoning, not evidence. If a controlled comparison showed no difference, that would be worth saying loudly.

If agent-drafted meta descriptions performed no differently from hand-written ones. The formulaic-output concern is an aesthetic judgement. It may not correspond to any measurable outcome at all.

If newer model versions showed no reduction in confident wrong values. The obvious expectation is that they improve. An unchanged rate across versions would be the more interesting finding.

If commit size showed no relationship to recovery time. Small commits are close to received wisdom in software. We have not seen it tested in this specific context.

What would change this page

A catalogue that never updates is a catalogue nobody is checking. Here is what would force a revision.

A tool that verifies truth-valued fields automatically. If structured data could be checked against rendered page content by default, the most dangerous entry here drops several places.

Crawl diffing as a standard pre-merge step. Comparing the rendered head across a whole site before and after a change would catch most of the second-tier table mechanically. That would move this page from "things to watch for" to "things your pipeline should catch."

Evidence that these modes do not generalise. This is one site's experience. A cross-team study finding a different distribution would change the ranking here, and we would publish that.

A model that reliably declines to infer unobservable facts. Much of the risk here comes from plausible guessing where an admission of uncertainty would be correct. A consistent change in that behaviour would narrow the catalogue considerably.

Limitations

• This catalogue reflects one team's usage pattern — a single site's experience, not a controlled, cross-team study of agentic SEO tooling failures.
• Tooling improves quickly — some specific failure modes described here may already be less common with newer model versions by the time this is read.