A page that used to rank near the top for its main keyword, and now doesn't, is one of the more unsettling things that can happen to a website. There's no error message. Nothing in Search Console necessarily flags it as a violation. The traffic just thins out over a few weeks until it's gone. The instinct at that point is to assume something dramatic happened — a penalty, an algorithm update, a competitor that out-produced you. Sometimes that's the answer. More often, the real cause is smaller, more specific, and fixable in an afternoon once you know where to look.

This is the framework we use to find out which one it actually is, in order, before touching a single line of code.

Start With What's Actually Happening in Search, Not What You Assume

Before editing anything, check the real, current search results for the page's target terms. Two outcomes are common, and they call for very different responses. Either the page genuinely doesn't appear anywhere for terms it used to rank for, or — more often than site owners expect — it's still ranking, just not where it used to, or not for the exact phrase being checked. A page sitting at position 8 instead of position 2 is a very different problem from a page that has vanished entirely, and treating the two the same way wastes effort on the wrong fix.

The Most Common Reason a Page Quietly Disappears: Keyword Cannibalization

One pattern shows up more than almost anything else on sites with more than a handful of pages: a second page on the same domain has started ranking for a query that used to belong to the page you're investigating. This is keyword cannibalization — two pages competing for the same search intent, with Google's algorithms picking one and quietly demoting the other, because showing both in the same results page rarely serves the searcher.

It's easy to miss because nothing about it looks like an error. Both pages are live, both are indexed, both look "fine" individually. The only way to catch it is to actually search the target terms and check which URL comes back — not assume it's still the page you built for that purpose. And it's not fixable by editing one page in isolation; it requires a decision about how the two pages should differentiate their targeting or be consolidated into one.

The Code-Level Problems That Quietly Kill Rankings

Once cannibalization is ruled out or addressed, the next place to look is the page's own code — specifically, the handful of issues that Google's spam and quality guidelines exist to catch. These are common enough that we check for all of them as a matter of routine on any page that's underperforming.

Duplicate, conflicting structured data

It's common for a page to accumulate three or four separate JSON-LD schema blocks over time — added by different people, at different points, none of them removed when a new one was added. When those blocks disagree with each other — mismatched URLs (www versus non-www), different currencies, or two different review counts for what's supposed to be the same aggregate rating — search engines are reading contradictory facts about the same entity. At best that gets ignored; at worst it undermines trust in the rest of the page's markup.

Hidden, keyword-stuffed text

Content pushed off-screen with CSS tricks — negative positioning, zero-height containers, sr-only-style clipping used to hide rather than aid accessibility — stuffed with dense, sentence-less keyword lists meant for crawlers rather than visitors. This is a direct violation of Google's spam policies, not a gray area, and it's one of the more common leftovers from an earlier, more aggressive era of on-page SEO.

Reciprocal or paid-style link schemes

Cross-promotion sections that exist purely to exchange dofollow, keyword-stuffed anchor text with an unrelated business — sometimes with that business's own schema embedded directly into your page — are treated as a manipulative link scheme once identified, regardless of how the arrangement was framed when it was set up.

Canonical and hreflang mismatches

Canonical tags, hreflang tags, Open Graph URLs, and Twitter card URLs that disagree with each other on details like www versus non-www split ranking signal across what search engines can treat as separate URLs for the same content. It's a small technical detail with an outsized effect, because it undermines the one signal ("this is the definitive URL for this page") that everything else on the page is supposed to reinforce.

Unverifiable claims baked into schema

A "sameAs" link to a social profile that isn't actually the business's, or a review count that can't be traced to any real review — these are easy to add and easy to forget about, but they're structured data making a factual claim search engines can, in principle, attempt to verify. When a claim can't be confirmed, the safer move is removing it, not guessing at a number that sounds plausible.

Multiple H1s diluting topical signal

A page should generally have one clear answer to "what is this page about," expressed as a single <h1>. Four separate H1 tags — especially if one is buried in a hidden content block about a different topic entirely — sends four competing signals instead of one clear one.

Fixing It Without Guessing at the Fix, Either

The fix for each of these is specific, not a wholesale rewrite. Legitimate marketing content — pricing, testimonials, interactive tools, lead forms — stays untouched. What comes out is specifically the hidden text, the duplicate schema, the unverifiable claims, and any link-scheme content. What gets corrected is specifically the canonical/hreflang inconsistency and the H1 count.

And before calling it done, validate the result programmatically rather than eyeballing it: confirm every remaining JSON-LD block parses as valid JSON, confirm every HTML tag has a matching close, and if the page claims a specific count of something in its schema — FAQ items, pricing tiers, reviews — count the actual visible elements on the page and make sure the number matches exactly.

Why validate programmatically instead of just reading it back? A schema block that looks correct to a human eye can still fail to parse, or can list a count that no longer matches what's actually on the page after an edit. Both are invisible until something — a script, a linter, a structured-data testing tool — actually checks.

Once It's Clean, Give It More Reasons to Rank

Removing violations gets a page out of its own way. It doesn't necessarily give it anything new to rank for. A useful second pass adds real substance instead of just cleaning up the old: a genuine FAQ section paired with matching FAQPage schema — verified question-for-question against what's actually visible on the page, since a mismatch between the two undermines the rich-result eligibility it's meant to earn. Real educational content that goes deeper than the sales copy already on the page. Internal links to genuinely related pages already live on the site, rather than invented URLs. And visual polish that matches how seriously the page is asking to be taken — consistent iconography instead of a mix of emoji and stock imagery, clean typography, a design that reads as intentional rather than assembled in pieces over time.

A Quick Diagnostic Checklist

None of this is clever. All of it is checkable. That's what makes it reliable to repeat on the next page that quietly stops ranking.