How links rot when a URL changes

A URL is a promise. Someone saved it, someone else linked to it, and a search engine filed it. Change it without telling anybody and all three of those break at once: the bookmark fails, the link sends people to nothing, and the ranking you spent years earning is attached to an address that no longer answers.

This is link rot, and it is almost never caused by anything dramatic. It is caused by ordinary, sensible-looking work: a page renamed, a site rebuilt on a new platform, a product retired, a blog moved from one folder to another. Every one of those quietly orphans every link pointing at the old address.

The two kinds of rot, and only one is your fault

Outbound rot is when you link to somebody else’s page and they move or delete it. You cannot prevent this. Other people reorganise their sites and retire their content, and over enough years a meaningful share of any older article’s external links will stop working. All you can do is find them and repoint or remove them.

Inbound rot is when your own address changes and everything pointing at it breaks. This is entirely within your control, and it is the expensive one, because the links pointing at your pages are an asset you paid for. Some of them you earned with work. Some of them you cannot replace at any price, because the person who linked to you has moved on.

The cruel part is that inbound rot is invisible from inside your business. Nothing alerts you. The pages simply stop receiving visitors, and by the time anyone notices the traffic, the cause is six months in the past.

What the status codes actually mean

When a browser or a crawler asks for a page, your server answers with a three digit code before it sends anything else. Four of them matter here, and Google documents exactly how it treats each one in How HTTP status codes affect Google’s crawlers.

301, moved permanently. The page has a new address and this is the final answer. Google’s documentation says it “follows the redirect, and Google systems use the redirect as a strong signal that the redirect target should be processed”. This is the one you want when a page genuinely moves.

302, found. A temporary move. Google follows it too, but the documentation calls it a “weak signal”. Use a 302 when the move really is temporary, and not otherwise. Using a 302 for a permanent move is one of the most common technical mistakes on a rebuilt site, and it leaves the search engine hedging about which address is the real one.

404, not found. The address does not exist. Google’s documentation says that for a previously indexed URL “the indexing pipeline removes the URL from the index”, and that newly encountered 404 pages are not processed.

410, gone. Deliberately deleted, never coming back. It is worth knowing that Google treats this the same as a 404. The documentation is explicit that all 4xx errors except 429 are treated alike: the crawler informs the next system that the content does not exist.

So when should you use 410 rather than 404?

For search engines, the practical difference is close to nothing. Use 410 when you want to state your intent clearly for your own records and for other tools that do distinguish them, for example when a product line is discontinued permanently and you never want it reinstated. Use 404 for everything else. Do not spend money engineering a 410 in the belief that it removes a page from Google faster than a 404 does.

The status code that genuinely causes problems is neither of those. It is the soft 404: a page that says “sorry, not found” in the text while returning a 200 OK status. Google’s documentation notes that when content suggests an error, Search Console reports a soft 404. The crawler keeps returning to a page that will never have content, and you look like a site full of empty pages.

Redirect chains, the slow leak

A redirect that goes straight to the destination costs a visitor almost nothing. A chain does.

Chains build up over time without anybody deciding to make one. The site moves from HTTP to HTTPS, so there is a redirect. Later it moves from www to the bare domain, so there is another. Then a page is renamed. Now a single old link goes through three hops before the page loads, and each hop is a full round trip to the server before the browser can even start.

Google’s Redirects and Google Search documentation states that Googlebot follows up to 10 hops in a chain, while advising that you keep the number low, ideally no more than three, and that chaining adds latency for users and is not supported by every user agent. The safe habit: when you add a redirect, point it at the final destination, and update the older redirects to point there too rather than at each other.

Two related traps worth naming. A redirect loop, where A points to B and B points back to A, serves nothing at all. And a catch-all redirect, where every missing page is sent to the homepage, feels tidy and is not: the visitor who clicked a link about one specific thing lands on a generic page with no idea what happened, and search engines often classify the result as a soft 404 anyway.

What it costs you

Rankings. The authority attached to inbound links is attached to a specific address. A 301 passes it along. A 404 does not, because there is nothing to pass it to.

Visitors, at the worst moment. The person clicking a broken link had already decided to come to you. Losing them at that point costs more than losing someone who never clicked.

Trust. A broken link inside your own site reads as neglect, and readers generalise from it. If the site cannot keep its own pages connected, what else is not being maintained?

Crawl effort spent on nothing. Every request a crawler spends on a dead address or an extra redirect hop is one it did not spend on a page you want indexed.

Doing a URL change properly

The whole discipline fits in six steps.

1. Write down the old addresses before you change anything. Once the old site is gone, the complete list is very hard to reconstruct. Export it from your analytics, your sitemap and Search Console while you still can.
2. Map every old URL to its closest equivalent, one at a time. Not to the homepage. If there is genuinely no equivalent, that page gets a 404 on purpose, which is a decision rather than an accident.
3. Use 301 for anything permanent. Reserve 302 for things that are actually temporary.
4. Point every redirect at the final address, not at another redirect.
5. Keep the redirects. There is no safe date to delete them. Links on other people’s sites do not expire, and a redirect rule costs you nothing to keep.
6. Re-crawl afterwards and check the result, rather than assuming the rules did what you intended. Rule ordering catches people out constantly: a broad rule earlier in the file will swallow the specific one you added below it.

Then make it a habit. Run the Link Checker over the site a few times a year. Outbound rot accumulates whether or not you touch anything, so a site that has not changed in two years still develops broken links.

Where this fits

Keeping URLs alive is unglamorous and it never finishes, which is exactly why it gets skipped. Redirect maps, crawl checks and fixing rot as it appears are part of our ongoing hosting and care work. If you are about to rebuild or restructure a site, capture the old URL list first. That single step prevents most of the damage described above, and it is impossible to do after the fact.