I Put a Redirect on Every Link of My Own Website

Search Console told me my own site had eleven pages that were "Page with redirect." A few weeks later it said twenty-one. Nothing had broken. I had simply added pages, and the number grew with them.

That is the shape of a configuration problem rather than a content problem, and it took me longer than it should have to find, so here is the whole thing.

What was actually happening

My pages are files. about.html, pricing.html, services.html. I write links the same way, as href="about.html".

The site also has to answer to the extensionless versions of those URLs — /about, /pricing — because the old version of the site served them that way and people have those links saved. So the host config sends each one to the file with a permanent redirect:

/about  →  /about.html   301

Both of those decisions are correct. One is how the site is built. The other keeps every link anyone ever saved working. Neither is the bug.

The bug is that the host also had a post-processing option switched on, cheerfully described as "pretty URLs," which rewrites links in the HTML as it serves them. So the page I wrote went out as something else:

I wrote:      href="about.html"
It served:    href='/about'
And /about:   301 → /about.html

Every internal link on the site pointed at a URL that immediately bounced somewhere else. The navigation. The footer. Every cross-link inside every article. All of it, on every page.

Why it is worth fixing

Nobody sees it. A visitor clicks, the redirect resolves in milliseconds, the right page loads.

The cost is on the other side. A crawler asks for /about, gets a 301, then asks for /about.html. That is two requests to read one page, on every link, on every crawl. On a small site that is merely untidy. On a large one it is a real tax on how much of your site gets looked at in a given visit.

It also fills the "why pages aren't indexed" report with entries that look alarming and mean nothing, which is worse than it sounds, because it buries the entries that do mean something. Mine had three genuine problems in that report. They were sitting underneath twenty-one URLs that were working exactly as designed.

How to check your own

Do not look at your source files. That is the trap — the file on your computer says about.html and everything looks fine. You have to look at what the server actually sends.

Open a terminal and ask for your own homepage:

curl -s https://yoursite.com/ | grep -o '<a [^>]*>' | head

Read the href values that come back. If they match what you wrote, nothing to do. If they have been rewritten — most often into rooted, extensionless form — then check whether those rewritten URLs redirect:

curl -s -o /dev/null -w '%{http_code} -> %{redirect_url}\n' https://yoursite.com/about

A 200 is fine. A 301 means every link on your site is taking the long way round.

One detail cost me twenty minutes: the post-processor re-emits attributes in single quotes. My first check searched for href=" and came back almost empty, and I briefly concluded the page had no links at all. Search for href= and read what follows.

The fix

Turn off the link rewriting. Keep the redirects.

The redirects are doing real work: they are what makes an old saved link still land somewhere. The rewriting was doing no work at all — it was taking correct links and making them indirect.

In my case that was one setting. Your host will have its own name for it; look for anything about pretty URLs, clean URLs, or trailing-slash normalization in the build or post-processing settings.

Then pick one form and make everything agree with it. My canonical tags, my sitemap and my structured data all said .html, so the links were the half that was wrong. If yours all say extensionless, the answer is the opposite: serve extensionless and drop the redirects. What you cannot do is have the two halves disagree, because that disagreement is exactly what a redirect on every link is.

The part I keep thinking about

Both settings were defensible. Someone turned on pretty URLs because pretty URLs are nicer. Someone wrote the redirects because old links must keep working. Each decision was right on the day it was made.

Nothing warned that together they cancelled out. No error, no failed build, no broken page — just a slow tax that showed up weeks later in a report most people never open, as a number that grew quietly every time the site did.

If you have never looked at what your server sends versus what you wrote, that is the thirty seconds I would spend first.