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

Ranking by how hard each is to catch

Not every failure mode is equally dangerous. The ranking isn't about frequency. It's about 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. Imagine an agent 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.

Wrong schema values, formulaic prose, subtle visual drift, and a broken internal link, which resolves to a valid, just wrong, page, are all things a build will happily pass while still being wrong in a way a human would immediately notice 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 isn't any single mistake above. It's an agent quietly doing more than what was asked, especially under an instruction to "just get it done." A request to fix one page's metadata can drift into restructuring navigation, renaming files, or touching components unrelated to the original ask, if nothing forces a check against the original scope before each change gets applied.

A related meta-failure: long-session context drift

A subtler cousin of scope creep. Over a long session covering many pages, an agent's effective adherence to instructions given early in the session, 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.

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.