17 pages stuck in redirect limbo. Indexed pages flat at 20 for three weeks while impressions dropped. Then our first attempted fix caused a real live outage. Here's the actual GSC data, the mistake, and the real fix — including the part where we got it backwards the first time.
Incident window: Aug 21 – Sep 20, 2026 · Fix deployed Sep 20 · Results section will be updated as real data comes in
Indexed pages sat flat at 20 for three straight weeks. Not-indexed climbed from 32 to 40.
Every guide shipped since late August landed in the not-indexed pile instead of the indexed one — and impressions fell from 55/day to single digits as a result.
If you deploy a static site to Cloudflare Pages, every foo.html file is automatically served at both /foo.html and the clean URL /foo — and by default, Cloudflare treats the clean URL as canonical, silently redirecting requests for /foo.html over to /foo. This behavior isn't loudly documented anywhere you'd naturally find it before it bites you.
That's fine, as long as your site agrees with it. Ours didn't. Every canonical tag, every sitemap entry, and every internal link across roughly 24 pages pointed to the .html version — built that way, ironically, as an earlier fix for a different duplicate-URL problem (an http/https split resolved with canonical tags and Cloudflare's HTTPS enforcement). Nobody had connected that fix to how Cloudflare's own clean-URL redirect actually behaves.
Google crawls a .html URL from your sitemap, gets redirected by Cloudflare to the clean URL, and then checks your canonical tag — which claims the .html version was the "real" one all along. That's a contradiction Google can't resolve cleanly, and it shows up in Search Console as exactly what it is: pages it can't confidently index.
We only found this because a routine Search Console Coverage export looked wrong. Here's what it actually showed, unedited.
| Date | Not indexed | Indexed | Impressions |
|---|---|---|---|
| Aug 21 | 32 | 17 | 31 |
| Aug 28 | 35 | 20 | 55 |
| Sep 4 | 40 | 20 | 12 |
| Sep 13 | 40 | 20 | 8 |
The critical-issues breakdown from that same export made the cause obvious:
| Issue | Pages |
|---|---|
| Page with redirect — validation Failed | 17 |
| Alternate page with proper canonical tag | 5 |
| Duplicate without user-selected canonical | 3 |
| Discovered — currently not indexed | 11 |
| Crawled — currently not indexed | 3 |
A quick grep of our own sitemap confirmed it: 23 of 24 <loc> entries pointed to .html URLs. That's not one mistyped link — it's the entire site's URL structure disagreeing with what the hosting platform actually serves.
Seeing one specific page — our top-performing guide — indexed twice with a huge position gap between the two versions (the .html form sitting at position 6.4, the clean URL buried at position 56.5), the first instinct was to add a redirect forcing the clean URL to the .html version, since that's what the canonical tag already claimed was correct:
/faceless-youtube-channel-guide /faceless-youtube-channel-guide.html 301
This was backwards. Cloudflare Pages was already redirecting .html requests to the clean URL automatically, sitewide, by default. Adding a rule that redirected the clean URL back to .html created a loop: request the clean URL → redirected to .html → Cloudflare redirects that back to the clean URL → repeat. The page went down with ERR_TOO_MANY_REDIRECTS within minutes of deploying.
We assumed the canonical tag reflected the platform's actual behavior, and built a fix on that assumption without first confirming what Cloudflare Pages does by default. It took a live outage to reveal the assumption was backwards. If you're debugging something similar, verify what your host actually does with a URL before writing a redirect rule that assumes it — a five-minute check that would have prevented this entirely.
The _redirects rule was pulled immediately to stop the outage. The real fix went the other direction from the first attempt: instead of forcing everything to .html, every canonical tag, every sitemap entry, and every internal link across the site was changed to the extensionless form — matching what Cloudflare actually serves, instead of fighting it.
Concretely, that meant:
<link rel="canonical"> tag updated to drop .html<loc> entry in sitemap.xml updated the same wayhref across roughly 24 pages updated, including absolute links back to the domainCloudflare's clean-URL redirect isn't something you can turn off with a canonical tag — it happens before your HTML is ever read. The only way to stop fighting it is to make your own URLs agree with it. Existing external links pointing to .html URLs (including ones already pinned on Pinterest) aren't affected — they still resolve, just through one redirect hop instead of zero.
If you're on Cloudflare Pages with a static site, three quick checks:
<link rel="canonical"> tag.sitemap.xml for .html — if most entries have it, you likely have this same mismatch..html URL directly in a browser and watch whether it silently redirects to the clean version — that redirect is the platform's real answer, regardless of what your canonical tag claims.If your sitemap and canonical tags already use the clean URL form, you don't have this problem. If they use .html like ours did, the fix in Part 4 is the same one we ran.
We'll update this page honestly once there's enough post-fix Search Console data to say whether it worked, including if it doesn't move the numbers the way we expect.
Follow the ongoing build log →This page was published only days after the fix was deployed. The Coverage and Performance numbers in Parts 1–3 are real and already confirmed. Whether the fix actually moves indexed-page counts and impressions back up is not yet confirmed as of publish — that section will be updated with real follow-up data once enough time has passed for Google to fully recrawl and re-evaluate the affected pages, which the previous canonical fix on this same site took several weeks to fully resolve.