How a Missing Redirect Can Erase Years of PageRank
August 1, 2026
Occasionally, a webpage that ranked on the first page of Google for years may appear to simply vanish. While the cause may be a ranking penalty for some real or perceived content that runs afoul of Google standards, sometimes the cause isn't the content at all, but the architecture of the server response itself. One area to review is whether a site responds with identical content to two different addresses, without providing the engine with a proper answer on the canonical URL.
The Setup That Causes It
Most sites arrive at this state by accident rather than intent: a hosting migration runs over a weekend, a
registrar DNS change propagates while nobody is watching, or a CDN gets bolted onto an origin server that was
never quite finished being configured. Somewhere in that shuffle, the 301 that used to send the bare domain to
www — or the other way around — simply stops firing, and because both hostnames still return a
normal page in the browser, the problem can persist for months without anyone on the team noticing.
But a search engine does not experience “the site” the way a human does; it inventories URLs, and when
domain.com/your-page and www.domain.com/your-page both answer with HTTP 200 and the
same body text, Google is left holding two plausible candidates for a single piece of content. Every inbound
link that points at one hostname does nothing for the other, which means authority that took years to
accumulate is effectively halved instead of consolidating on one canonical address — and for a competitive
local keyword, that division is often the difference between page one and disappearance.
Canonical Tags Are Not a Substitute for a Redirect
A common half-measure makes the situation worse rather than better: someone adds a canonical tag pointing search engines toward the “correct” version and assumes the problem is solved, but a canonical hint is not a redirect — Google may still crawl both URLs, split signals between them, and treat the tag as a suggestion rather than a hard consolidation rule.
The nginx Gotcha
On nginx, the failure mode is deceptively easy to write into production. A single server block
can list example.com and www.example.com together, point both at the same root
directory, and return identical content for either hostname without ever issuing a redirect — which looks
efficient until you realize you have just told the entire internet that both addresses are equally valid.
server {
listen 443 ssl;
server_name example.com www.example.com;
root /var/www/example;
# Both hostnames serve the same files with HTTP 200. No winner declared.
}
The same damage happens when a catch-all default_server block accepts any hostname that
resolves to the box, or when several client domains are parked on one certificate and one document root with
no per-host redirect logic. The configuration file is valid, nginx starts cleanly, and the duplicate URLs are
baked in from day one. The fix is a separate block (or an explicit return 301) that sends every
non-canonical hostname to the one you have chosen, tested with curl -I against each variant so
you are verifying status codes and Location headers, not just whether the homepage “looks fine”
in a browser.
When Cloudflare Sits in the Middle
Cloudflare adds another layer that can override whatever careful redirect work you did on the origin. Once the
orange-cloud proxy is enabled, many requests never reach your server at all, so a perfect nginx rewrite is
irrelevant if the edge answers first. Settings like Always Use HTTPS sound harmless — and
usually are — but they redirect HTTP to HTTPS using whatever hostname appeared in the original request, which
means a visitor who types the apex can be pushed to https://example.com/ while your canonical
choice was https://www.example.com/, or vice versa, especially when Page Rules, Redirect Rules,
and Bulk Redirects disagree with each other.
We have seen teams fix nginx, confirm the origin behaves, and still watch Search Console report duplicate
indexing weeks later because Cloudflare was quietly sending a different answer at the edge. The check is the
same as on the origin: run curl -I against the public hostname through Cloudflare, compare the
status code and Location header to what the origin returns directly, and make sure only one
hostname ends in a 200 for any given path.
The Fix Belongs at the Edge, Not in the Application
The durable fix is intentionally boring: choose one hostname as canonical, then force every other variant —
different subdomain, bare domain, legacy hostname, HTTP — through a single permanent 301 before application
code runs, and make sure that redirect exists at every layer that can answer the request. If a CDN or reverse
proxy sits in front of the origin, the rule belongs there too, tested at both the edge and the origin so you
know which system actually responded. Pick www or apex, commit to it in DNS, in nginx, in
Cloudflare, and in your internal links.
