The redirect that works and is still wrong

There is one kind of error that is harder to find than all the others: the kind where nothing looks broken.

You click an item in the menu. The right page appears. All good.

Except the browser set off twice. It first requested an address, got the answer “that no longer exists here, go over there”, and then set off again. The second attempt worked.

The result is right. The way there is not.

How it happens

Almost always during a rebuild, and almost always for the same reason: the addresses changed, the links in the content did not.

A menu item still points to the old address. A link in the middle of a text points to a post that now lives somewhere else. A tile on the home page points to a directory that was renamed.

Because the redirects are in place — and that is how it should be — the visitor still arrives. That is why nobody notices. It is not an error you see. It is one you have to measure.

There is also a second variant: a redirect that points to an address which is itself redirected. Two hops, sometimes three. It happens when a site is rebuilt for the second time and nobody collected the old redirects before the new ones were added.

Why it matters when it works anyway

Four reasons, from the smallest to the biggest.

It costs time. Every hop is a complete request — send, wait, receive the answer. At a desk you hardly notice. On a phone in a poor network an extra round trip is noticeable, and on every single click that runs through an old link.

It costs redirects. Every redirect you set up is a line that has to be maintained for good. If half of them exist only because your own site links to itself wrongly, you are maintaining a list that does not need to exist.

It makes later rebuilds more expensive. Next time, somebody faces a list of redirects and can no longer tell which ones are needed for real old addresses out in the world and which ones only catch your own sloppiness. So they all stay. And the chain grows longer.

It is a sign. If your own site points to addresses that no longer exist, the rebuild was not finished. And what was not checked here was probably not checked elsewhere either.

The difference from a real redirect

A redirect is not bad in itself — it is the right tool for a particular purpose.

For addresses you do not control, it is indispensable. A link from a search engine, a bookmark, a link from somebody else's site, an address on an old invoice — you cannot reach any of these. For these cases a redirect is exactly right and stays for good.

For addresses on your own site, it is a stopgap. You can change those links. They should point directly.

The rule behind it fits in one sentence: A redirect catches what you cannot change. What you can change, you change.

How you find it

It cannot be done by hand. The error is invisible, after all — you click and you arrive.

You need a tool that crawls the whole website and records, for every address it finds, what the server answers. Then you sort by the answer.

What you want to see: the same answer everywhere, everything fine.

What you find if the problem exists: a handful of rows saying “permanently redirected”. And a good tool also tells you on which pages the link that points there sits.

That is the genuinely useful part. You do not just get the broken address, you get where it is used. That turns the fix into plain work: open the page, correct the link, move on.

And where the links hide

The obvious places are done quickly. The inconspicuous ones are the ones that remain:

The menu — usually already right, because it gets touched during a rebuild anyway.

Links in the middle of texts — the most common place, because nobody goes through old posts.

Tiles, buttons and links inside blocks — they often do not live in the text but in settings, and get missed when reading through.

The footer — it is on every page, which is why it never gets checked on its own.

Images and files — an image path can be redirected too. That is noticed even less often, because the image does appear.

Redirects that point to redirects — not in the content, but in your redirect list itself. You only find those if you check that list against itself once.

When you do this

Twice.

Before the switch-over, on the staging site. Then most cases are gone before they affect anyone.

After the switch-over, on the finished site. Because the move creates new ones: addresses that had a different name on the staging site, links the transfer did not adjust.

And after that, once a year. Not because of the rebuild — but because in day-to-day operation pages get renamed and moved, and every time a link stays behind somewhere.

The unspectacular core

This error is interesting because it is the opposite of what you would expect. It does not hurt, it does not show, and nobody complains.

It still says something: a website whose links point to its own old addresses was rebuilt and not measured afterwards.

The measurement takes half an hour. The fix takes half a day, depending on size. And after that one thing is done that would otherwise get a little more expensive with every further rebuild.

Sources

• Udemy, Der perfekte Webseiten-Relaunch, phase 4 — the observation, when crawling the finished site, that besides several addresses not found a redirect also showed up; that the cause was an internal link on the home page still pointing to a directory that no longer existed in that form; that the redirect did work but was explicitly called unnecessary and fixed; and that the place it is used can be found through the list of incoming links in the crawl tool.
• Udemy, Der perfekte Webseiten-Relaunch, phase 3b — that broken links and internal redirects are a check of their own on the development environment, that is, before the switch-over.
• Sitebulb webinar Website Migrations & Redirect Mapping Dos & Don'ts, November 2024 — that existing redirects have to be collected before new ones are created, because otherwise chains form in which an old address points via a middle one to the new one.
• Own practice — the distinction between redirects for addresses you do not control and those for your own site; the list of places where old links typically remain, in particular links in block settings, the footer and image paths; the recommendation to measure before and after the switch-over and yearly after that; and the observation that an unmanageable redirect list makes every further rebuild more expensive, because it is no longer possible to tell which entries are still needed.