The redirect plan: old addresses to new ones

When a website is rebuilt, the addresses almost always change. /services.html becomes /services/, /2019/03/new-location/ becomes /news/new-location/, and some pages disappear entirely. A redirect plan sends every old address whose content lives on to its new target — as a permanent redirect that stays in place for at least a year. What disappears without replacement honestly answers "not found". Without that plan a relaunch starts from zero — and the damage only shows weeks later.

What is lost when nobody redirects

An old address without a redirect leads to an error page. That affects:

• Search engines. The page was indexed and had a position. Without a redirect, neither carries over to the new address.
• Incoming links. Every link from elsewhere to the old address now points nowhere. This is the costliest loss, because nobody brings it back — hardly anyone changes a link they set years ago.
• Bookmarks of regular customers.
• Print: business cards, flyers, vehicle lettering, adverts.
• Directory entries, chamber listings, partner lists, email signatures.

Permanent or temporary

There are two kinds of redirect, and the difference matters:

Permanent (301 or 308). Google takes it as a signal that the target is the canonical address and shows the new address from then on. That is what a relaunch needs.

Temporary (302 or 307). Google follows it but does not take it as a signal for the new address — the old one can stay in the results. In a relaunch that is wrong, and it happens easily, because some tools default to temporary redirects.

Google also recommends redirecting on the server, not with JavaScript or a meta refresh in the page.

The plan

A redirect plan is a table with two columns: old address, new address. One row for every old address — Google calls it a one-to-one mapping.

It is built on a complete list of the old addresses, pulled before anything is changed. Without it you redirect the addresses you remember, and that is never all of them.

The mapping follows one rule: redirect to where the same content now lives. If it no longer exists, there is no target.

Old page	New target
Service page that still exists	the matching new service page
Three thin pages, now merged	the new merged page
Article that does not move over	no target — the address answers 404 or 410
Page of a discontinued offer	the successor offer if there is one, otherwise 404 or 410

What is explicitly not the answer: everything to the home page. Google warns against redirecting many old addresses to a single, unrelated target such as the home page. Such redirects are treated as a "soft 404" — an error page that just does not say so. And the visitor stands on the home page and has to search for what they wanted. Google states explicitly: content that is not moved should answer 404 or 410 on the new site. Only when several old pages were merged into one new page do they all redirect to it.

With a great many pages, mapping every address by hand is not feasible. Then you work with patterns — everything under /blog/ onto the matching new structure — and map only the most important ones individually: the most visited and those that other sites link to.

Chains and loops

Two problems that arise when redirects grow over several rebuilds.

Chains: A redirects to B, B redirects to C — typical when the redirects of the first relaunch stay in place at the second and new ones are laid on top. Googlebot follows up to ten hops, but Google advises redirecting to the final target directly, and where that is not possible, ideally no more than three hops. Every hop costs loading time, and not every browser follows long chains. The fix: A points straight to C. The old redirects are not deleted but rewritten to the current final target.

Loops: A redirects to B, B back to A. The result is an error in the browser — the page is unreachable for everyone. It happens when two rules from different sources work against each other, such as a server rule and a plugin.

One address, not four

Your home page is technically reachable at four variants: with and without www., encrypted and unencrypted. Then there is the trailing slash. Every variant has to lead to one single address by permanent redirect. Otherwise Google has several addresses for the same content and has to decide by itself which one counts.

How long redirects stay

Google recommends: as long as possible, generally at least one year. During that time Google transfers the signals to the new addresses. Clearing the redirects out after three months because they are "no longer needed" breaks that process off.

And the links from elsewhere stay forever anyway — a newspaper article from five years ago will not be updated. Leaving redirects in place costs nothing. Removing them does lasting damage.

The error page is part of the plan

Despite the best plan, someone will land on an address that does not exist — a typo, an old link, an address nobody had in view. A good error page is part of the safety net:

• in the website's design, not a bare server message,
• with a clear explanation of what happened,
• with links to the most important sections and the way to get in touch.

And it has to send the right status code: 404, "not found". An error page that answers "all fine" is reported in Search Console as a soft 404 — a page pretending to exist.

The practical use in a relaunch: the error page hits of the first weeks are the best source of forgotten redirects. Watching them finds exactly the addresses the plan was missing.

How to check the plan

• Before the switch: take the most important old addresses from your analytics and check that the plan has a sensible target for each.
• Right after the switch: open a sample of those addresses. Do you land on the right page? The "Network" tab of the developer tools shows the status code: 301 or 308 is right, 302 is wrong, two redirects in a row are a chain.
• Regularly in the first weeks: the "Page indexing" report in Search Console. Every old address showing up there as "not found" is a candidate for a redirect added later.
• Internal links: no link on your own website may point to an old address. Google explicitly recommends switching internal links to the new addresses after a move — redirects are for visitors from outside, not for your own site.

What to do

1. Pull the list of all old addresses before anything is changed.
2. Build the mapping table — every old address gets a target, or a deliberate 404 or 410.
3. Order by importance: the most visited and linked ones individually, the rest by pattern.
4. Set everything up as permanent redirects on the server.
5. Collapse chains, if there are redirects from earlier rebuilds.
6. Bring the address variants down to one.
7. Build a proper error page — with status code 404.
8. Test a sample right after the switch, then watch Search Console and add what is missing.
9. Switch internal links to the new addresses.
10. And leave everything in place — at least a year, better for good.

The redirect plan is the least spectacular work in the whole project and the one with the biggest risk when it is missing. A new website with a clean plan keeps growing on what the old one built. The same website without a plan starts again from the beginning.

Sources

• Google Search Central, site moves with URL changes — one-to-one mapping, no mass redirects to the home page, permanent server-side redirects, chains, internal links, at least a year: developers.google.com
• Google Search Central, redirects and Google Search — permanent and temporary redirects: developers.google.com
• Google Search Central, HTTP status codes and soft 404 errors: developers.google.com
• Google Search Central, consolidating duplicate URLs — one canonical address: developers.google.com
• Search Console Help, Page indexing report: support.google.com