Failure modes

Why this chapter exists

Every item here is something that looked like an improvement on the day it shipped. That is what makes them dangerous: they are not mistakes of ignorance, they are the correct technique applied slightly too far or without a check.

Each one gets the same treatment: what it looks like, how to detect it, and what to do about it.

Over-indexation of a thin tier

What it looks like

You ship a programmatic tier. Indexation climbs. Traffic does not. Some months later, rankings for your good pages, the ones you wrote by hand, start slipping for no visible reason.

Quality signals are evaluated at the site level as well as the page level. A thousand thin pages can suppress the fifty good ones, and the causal link is invisible in every report because the thin pages were never getting traffic to lose.

Detection

Compare indexed count against the count of pages with at least one impression in 90 days, per tier:

Tier            Indexed    With impressions    Ratio
tier-3            1,689              1,204      71%
tier-4              276                 31      11%   <- investigate

A tier where most indexed pages have never had an impression is a tier that is costing you something.

The fix

Reduce the tier rather than improving it. Set a data threshold below which an entity does not get a page: fewer than N records, no page. The entity list is the gate, and shrinking the list is a one-line change.

FAQ schema treated as spam

What it looks like

FAQ markup on every page regardless of relevance, or questions in the schema that are not visible in the HTML. Both are documented manual action triggers.

The innocent version is the common one: an accordion component that mounts its content on click, so the crawler sees an empty container while a human sees the answers.

Detection

curl -s URL | grep -F "$QUESTION"

For every question in the FAQPage node. If any one fails, the markup and the page disagree.

The fix

Native <details>, which puts the content in the HTML in both states. And a policy: FAQs only on pages where a reader would genuinely have questions, not as a template default.

Canonical chains and loops

What it looks like

Page A canonicalises to B. B canonicalises to C. Google follows one hop and gives up, so A drops out of the index entirely while still rendering perfectly to a human.

The loop version is worse and easier to create: A canonicalises to B, B canonicalises to A. Neither is indexed.

The usual cause is a normalisation rule applied in two places with slightly different logic, most often a trailing-slash rule in the framework and another in the CDN.

Detection

Follow the canonical and check where it points:

canonical=$(curl -s "$URL" | grep -o 'rel="canonical" href="[^"]*' | cut -d'"' -f4)
curl -s "$canonical" | grep -o 'rel="canonical" href="[^"]*'

On a healthy page the second command prints the same URL as the first. Run it once per template, not once per page.

The fix

One normalisation function, called from one place. This is the same rule as the Foundation chapter's single-origin constant, and it fails the same way when there are two implementations.

IndexNow key leakage

What it looks like

The key is committed to a repository, or hardcoded in a client bundle. Anyone holding it can submit arbitrary URLs on your host, which is a way to have your domain associated with content you never published.

Detection

git log -p --all -S "$INDEXNOW_KEY" | head

Empty output is the target. Also grep the built client chunks, because a key read from a NEXT_PUBLIC_ variable ends up in the bundle.

The fix

Environment variable, server-side only, served through a rewrite constrained to the key pattern. If it has leaked, rotate it: generate a new key, update the environment, and let the old key file 404.

Doorway page classification

What it looks like

The whole programmatic tier stops ranking at once. Not a gradual decline: a step change, usually across every page in the tier on the same day.

This is the failure that ends a programmatic strategy rather than slowing it, because the classification is applied at the site level and it is not appealable by argument. The only remedy is deletion or substantial rework, and recovery takes months.

Detection

The strip-the-entity-name test, run quarterly rather than only at launch. Content decays: a tier that passed at launch fails eighteen months later when the source data stops updating and every page falls back to the same generic text.

Also watch the ratio of indexed pages to pages with impressions, which usually degrades for a quarter before the step change.

The fix

Prevention is the only realistic answer. Per-entity numbers, computed FAQs, honest fallbacks, and a data threshold below which no page is generated. All four are covered in the Programmatic SEO chapter and all four are cheaper than recovery.

A tightened CSP silently breaking the funnel

What it looks like

You tighten the Content-Security-Policy. The site renders fine. Analytics stop reporting, or checkout stops working for a subset of browsers.

A CSP violation fails silently in production for most users. The page keeps rendering and stops reporting, which looks like a traffic drop rather than a bug, and traffic drops get investigated as SEO problems.

Detection

Deploy in report-only mode for one release:

{
  key: "Content-Security-Policy-Report-Only",
  value: contentSecurityPolicy({ reportUri: "/api/csp-report" }),
}

Collect the reports. Confirm zero involve your own scripts or your payment provider's domain. Then enforce.

The fix

Report-only first, always. And an uptime check on the endpoints the funnel depends on, so a silent break surfaces as an alert rather than as a monthly revenue review.