Planning
Planning a redesign without losing search visibility
Most search losses after a redesign come from changed addresses and missing redirects. This is the order of work that Google's own site-move guidance recommends, in plain language.
When a website is rebuilt, the pages usually get new addresses, even if the owner never meant them to. Search engines and visitors still know the old ones. If those addresses stop working, or lead somewhere unrelated, the pages that were found before stop being found. This note explains how to plan the change so that does not happen, based on Google’s own guidance on site moves.
No plan can guarantee that rankings stay where they are. Google says to expect temporary fluctuation after addresses change. What a plan does is remove the avoidable losses.
1. Decide whether the addresses need to change
The safest move is the one with the fewest changes. If the new design can use the same addresses for the pages that matter, keep them. Google’s guidance also advises changing one thing at a time, so moving to a new design, a new domain and a new structure all on one day multiplies the risk.
2. Make an inventory
List every address on the current site. Good sources are the site’s sitemap, your hosting or server records, your analytics, and the content system itself. Include pages that only show up in old links, brochures or emails. Mark the ones that bring visits or enquiries; Search Console and analytics will show which.
3. Map old addresses to new ones
For every old address, write down its new equivalent. Where a page is being removed, decide in advance what should happen: a similar page to redirect to, or a “not found” response if nothing equivalent exists. Do not send many unrelated old pages to the new home page, because Google specifically advises against it.
Update the things that point at addresses at the same time: internal links, canonical tags and the sitemap.
What a URL map looks like
A spreadsheet with four columns is enough. This is an invented example for an imaginary manufacturer, to show the shape; your rows will differ.
| Old address | Visits or enquiries from it | New address | Action |
|---|---|---|---|
/products.php?id=12 |
Several a month | /products/hex-bolts/ |
Permanent redirect |
/about-us.html |
A few | /about/ |
Permanent redirect |
/catalogue.pdf |
Often downloaded | /downloads/catalogue.pdf |
Keep the file, link to the new place, redirect the old one |
/old-offer-2019/ |
None | none | Let it return “not found” |
/contact.html |
Many | /contact/ |
Permanent redirect |
Rules that keep the map honest:
- One old address, one destination. If a page is split in two, choose the closer match and link to the other from it.
- Include addresses that are not pages: PDFs, images that other sites link to, and old
index.phpor.htmlforms of the same page. - Copy the old addresses from the sitemap, the hosting records and Search Console’s list of pages with impressions, not from memory.
- Record which ones are the money pages (the ones that brought enquiries), and test those first.
Testing the map
After the redirects are live, request every old address and read the answer rather than clicking and hoping. For a short list, a browser’s developer tools show the status code. For a long one, a few lines in a script can print, for each old address, the status code and the address it ends at. What you want to see is a single permanent redirect to the planned destination, with the final page returning success. Any row that shows two hops, a temporary redirect or a “not found” is a defect to fix before announcing the new site.
4. Use permanent redirects
Where an address changes, set up a server-side permanent redirect (the codes are 301 or 308) from the old address to the new one. Redirect straight to the final destination. A chain of redirects, where A goes to B and B goes to C, wastes crawling and is easy to break. Google can follow a long chain, but advises keeping chains short.
Redirects are set where the site is hosted, so ask the developer how and where they will be configured.
5. Test before launch
Check the new site on a staging copy that visitors cannot see. Click the main paths on a phone. Test every redirect in your map, not a sample, with a script if the list is long. Check that the pages you meant to keep still have a clear title, a description and a main heading, and that none is accidentally set to be excluded from search.
6. Launch, then submit and watch
When the redirects are live, submit the new sitemap in Search Console. If the domain name itself changes, Search Console also has a Change of Address tool for that case. It does not apply to changes within the same domain.
Watch the sitemap and indexing reports, search queries and your analytics for the first weeks. Traffic to the old addresses should fall as traffic to the new ones rises. For a site of medium size, Google says settling can take a few weeks or more.
7. Keep the redirects
Google advises keeping redirects for at least a year, and notes you may keep them indefinitely. Update your own links so they point straight at the new addresses, but leave the redirects for the people and sites that still use the old ones.
A short checklist
- Do the addresses really need to change?
- Is there a list of every old address and what it becomes?
- Is every changed address covered by a permanent redirect?
- Are there no chains and no mass-redirects to the home page?
- Were the redirects tested individually?
- Is tracking in place before launch, so you can compare afterwards? (How to measure enquiries)
- Is somebody responsible for watching the first month?
If you want this done for you, the website redesign page explains how I handle it and what each package includes.