Redesigning a website without losing your URLs

A redesigned website can look better and still bring in fewer enquiries. The usual reason is not the design — it is lost addresses. If an old page that other sites link to, and that people used to find in search, returns an error after launch, you lose more than that one link: you lose everything it had accumulated. So the URL plan belongs before the launch rather than after it.

In short

• Start with an inventory of existing URLs rather than with redirect rules — otherwise you will only redirect what you happen to remember.
• Give every old URL one of three decisions: an exact equivalent, a merge into a close page, or a deliberate error code.
• Use a permanent redirect (301) and avoid intermediate hops — send the request straight to the final URL.
• Do not redirect everything to the home page. It feels safe, but in practice it means there is no equivalent page.
• Change one thing at a time: addresses first, then the design or the system. Do it all at once and nobody can tell what broke what.

Step one: an inventory of existing URLs

The point of the inventory is the most complete possible list of addresses that work today and matter to somebody. The site menu is not enough: the most valuable URLs are often the ones not in the menu — old articles, standalone service pages, addresses from old campaigns.

• The existing sitemap file — the fastest start, but usually incomplete.
• The content management system's own list: everything published, including old items.
• Server logs: the addresses that actually received requests over recent months.
• Analytics: the pages people genuinely opened.
• Search Console: the addresses a search engine indexed and that receive clicks.
• External links: the addresses other websites point at — these are the ones you cannot afford to lose.
• Internal links and old campaigns: in emails, on social platforms, in printed material.

Step two: one decision per address

Once the list exists, each old URL gets one of three decisions. What matters is that the decision is written down rather than left to memory — that record is what you verify against later.

• Exact equivalent: the same content exists on the new site at a different address. Redirect to it.
• Merge: the content no longer stands alone, but a new page genuinely answers the same question. Redirect there — but only if it answers it.
• Deliberate retirement: the page is gone and there is no equivalent. Then the correct answer is an error code, not a redirect to something unrelated.
• Their own lines: addresses with parameters and language variants get lost easily, because in a list they look like duplicates.

Google's documentation is explicit that unrelated, discontinued content should not be redirected to the home page. In practice: if there is no honest equivalent, it is better to return an error code and let the search engine understand the page is gone.

Step three: redirects without intermediate hops

The type of redirect matters. A permanent redirect (301) means "this address has changed for good", which is what a redesign needs. A temporary redirect is only right if you genuinely plan to bring the old address back. The second issue is chains. If an old URL redirects to another old URL which then redirects to the final one, you have intermediate hops. Google recommends redirecting straight to the final address rather than through intermediate stops. Chains appear especially easily when the protocol, the "www" form of the domain and the URL structure all change at once.

• Use a permanent redirect unless you are bringing the old address back.
• Redirect straight to the final URL — review the rules so one does not feed a chain into another.
• Normalise the protocol and the domain form in one rule rather than several sequential ones.
• Check for loops: A redirects to B while B redirects back to A.
• Leave redirects in place for a long time. Google's guidance is to keep them for at least a year — links from other sites do not disappear on launch day.

Step four: change one thing at a time

Google's site-move documentation recommends planning changes one after another rather than all at once — for example, move to the new domain first, then change the layout. The reason is practical. If addresses, design, content and the system all change on the same day and the result gets worse, there is no way to say what caused it, and therefore no clean way back.

Step five: verification after launch

Verification should be a procedure rather than a look around. It helps to run the same inventory list again after launch and record, next to each address, what it actually returns.

• For every address in the inventory: which response code, and which URL it finally arrives at.
• That no important address returns an error you did not plan for.
• That no chains or loops appeared anywhere.
• That the new sitemap lists only new, working addresses, with nothing that redirects.
• That canonical URLs point at the new addresses rather than the old ones.
• That language variants reference each other correctly.
• That internal links point at new addresses directly, not through redirects.

An illustrative example

Illustrative scenario, not a description of a client project. Imagine a company redesigning its website and tidying up its URL structure at the same time. The inventory holds a few hundred addresses, most of them old articles. The design is ready, so launching everything together looks logical. Instead the team ships the new URL structure with redirects first, and the new look only two weeks later. If something drops, it is immediately clear which half to look in. A second decision: articles with no equivalent are not redirected to the home page but left returning an error code — because redirecting to something unrelated solves nothing.

What this guide does not tell you

It makes no promises about positions and gives no timelines. A careful URL plan protects you from damage you would otherwise do to yourself, but it is not a ranking instrument: even a perfectly executed move does not assure the same visibility, because visibility also depends on things you do not control. Nor does it recommend a specific tool — an inventory can be assembled several ways, and what matters is the list itself and the decision on each line.

There is one artefact worth having before a redesign begins: a table giving every old address either a new address or a deliberate error code. Produce that and the biggest risk in the project is already under control.