A new website is usually the right decision. It is also the moment when a business is most likely to lose search traffic it spent years building, and the loss tends to show up a few weeks after launch, when everyone has moved on to the next thing.
The cause is rarely the design. It is the addresses. Search engines know your old site page by page, and a rebuild that changes those addresses without telling them properly asks them to start again. Google publishes a detailed guide to site moves, and almost everything below comes from it. What follows is a practical version of it, in the order it needs doing.
The key idea
Search engines know your site by its addresses. A rebuild is safe when every address that mattered either still works, or points permanently to its closest replacement.
Start with the list of addresses you already have
Before anyone designs a page, collect every URL the current site has. Google suggests working from your sitemaps, server logs, analytics and the list of content in your CMS, because each one catches pages the others miss. Server logs and analytics show the pages people actually visit, including ones nobody remembers creating. The CMS shows pages nobody visits but search engines may still hold.
Add two things people forget. The first is Search Console’s performance report, filtered to pages, which shows the addresses that currently earn clicks. The second is files: PDFs, images and downloads that other sites link to. A price list PDF from four years ago can be among the most linked-to pages a small business has.
Map every old address to its new home
The map is a simple two-column sheet: old URL on the left, new URL on the right. It is tedious, and it is the single most valuable document in the project. Work through it page by page, choosing the closest equivalent on the new site, not the nearest convenient page.
The tempting shortcut is to send everything that no longer has an obvious match to the homepage. Google specifically advises against redirecting many old URLs to one irrelevant destination, such as the home page. If a page has genuinely been retired and nothing on the new site replaces it, let it return a proper not-found response rather than a misleading redirect.
For example, a trades business moving from /services.php?id=4 style addresses to /services/boiler-servicing/ would map each service page individually. Its old “special offers” page, with nothing on the new site to replace it, would simply be allowed to go.
Use permanent redirects, set up on the server
How you redirect matters as much as where to. Google treats permanent redirects, HTTP 301 and 308, as “a signal that the redirect target should be canonical”, in other words as the address to show in results from now on. Temporary redirects, 302 and 307, do not send that signal. For a rebuild, the answer is almost always a server-side 301.
JavaScript redirects are a last resort. Google notes that rendering can fail and that it might never see a JavaScript redirect if it does. Avoid chains as well: if an address was already redirected once in a previous rebuild, point the oldest version straight at the new page rather than stacking hops. Google’s site-move guide suggests keeping any chain to ideally no more than three redirects, and fewer than five.
Then leave the redirects in place. Google’s advice is to keep them for as long as possible, generally at least one year. Old links on other websites do not update themselves, and removing redirects early throws that value away.
The launch-day list
Several of the most common rebuild problems come from a launch-day step being missed. None of these takes long.
- Remove the development blocks. Staging sites are usually hidden with a
noindexrule or arobots.txtblock, and Google’s guide lists removing any noindex or robots.txt blocks that were only needed for the migration as a launch step for a reason. - Add a self-referencing canonical tag to each new page, so each page names itself as the version to index.
- Update internal links to point at the new addresses directly, instead of relying on the redirects to catch them.
- Submit the new sitemap in Search Console, and remove the old one.
- Only if the domain itself is changing, for example from one .co.uk to another, use Search Console’s Change of Address tool. Google is clear that it is not needed for a move from HTTP to HTTPS, a change to or from www, or new paths on the same domain.
What to expect afterwards
Some movement is normal. Google says to expect temporary fluctuation in rankings during the move, and that for a medium-sized site it can take a few weeks or more for Google to start showing the new addresses. That is a reason to watch closely, not a reason to worry.
For the first month, check Search Console weekly. The page indexing report should show new addresses being indexed and old ones dropping out as redirected. The performance report should show clicks moving from old pages to their replacements. A page that drops out without a replacement appearing is the one to investigate, and it is usually a missing line in the map.
If only the hosting is changing
Moving to a new server without changing any addresses is simpler, but it has its own quirks. Google recommends lowering your DNS TTL at least a week in advance, keeping the old hosting running until traffic to it reaches zero, and not being alarmed by a temporary dip in crawling straight after the switch, which it describes as normal.
Before you switch
Where to start
- Export every URL from your sitemap, CMS and analytics into one sheet, and add the pages with clicks from Search Console.
- Give every old URL a new destination, or mark it as deliberately retired. No blank rows, and no mass redirects to the homepage.
- Set up 301 redirects on the server and test a sample, including old PDFs and images.
- Check that the new site has no staging noindex or robots.txt block left in place.
- Submit the new sitemap on launch day, then check the page indexing and performance reports every week for a month.
Most traffic lost in a rebuild is lost in the spreadsheet, not the design.
Where this fits
A redirect map belongs in the scope of any web development or web design project that replaces an existing site, not as an extra. If your current site has search visibility worth protecting, the SEO foundations are worth checking before the rebuild starts, and the weeks after launch are worth watching as part of ongoing SEO work.
Planning a new website and want to keep the search traffic you already have? Get in touch and we can talk through how the move should be handled.
