A redesign is usually briefed as a visual project: new brand, new layout, better on a phone. The search consequences are treated as something to check after launch. By then the damage is done, because the decisions that protect a site's rankings are made in the first week of the project, when the page list is drawn up, not in the last.
What actually causes the drop
| Cause | What happens | How it is prevented |
|---|---|---|
| URLs changed without redirects | Every link and every ranking pointing at the old address now lands on an error page | A one-to-one redirect map, tested before launch |
| Everything redirected to the homepage | Search engines treat the old page as gone rather than moved | Redirect each old page to its closest real equivalent |
| Ranking pages cut or merged | The content that earned the position no longer exists | An inventory of what earns traffic before the sitemap is drawn |
| Staging block left on | A noindex tag or a robots rule tells search engines to ignore the new site | A launch checklist with a named person signing it off |
| Titles and headings rewritten for style | Pages stop matching the searches they used to answer | Keep what works, rewrite only with a reason |
| Tracking not carried over | Traffic looks like it fell when only the measurement did | Analytics and tag manager tested on the new site before launch |
The last row deserves a moment. Some post-launch panics turn out to be measurement rather than traffic: the analytics tag was in the old template and nobody added it to the new one. It is the cheapest problem on the list to prevent and the most confusing one to diagnose afterwards.
Before anything is designed: inventory what earns
The first deliverable on a redesign should be a list, not a mockup. Every URL on the current site, with what it is worth.
- Crawl the existing site so every live URL is known, including the ones not in the menu.
- Export the pages that receive clicks from Google Search Console, over at least the past year so seasonal pages are not missed.
- List the pages other sites link to. Those links carry value that a dropped URL throws away.
- Mark which pages produce enquiries, from analytics or from asking whoever answers the phone.
- For each URL, decide: keep as is, keep and improve, merge into another page, or retire. Write the decision down.
This list becomes the backbone of the new sitemap. Pages that earn traffic get a home in the new structure before anyone draws a navigation menu, rather than being discovered missing after launch.
The redirect map is the deliverable
Every old URL that changes needs a permanent 301 redirect to its closest equivalent on the new site. Not to the homepage, not to a category page that roughly covers it, but to the page a visitor following the old link would actually want. Redirects should go straight to the destination rather than through a chain of hops, and they should stay in place for a long time: Google's guidance is at least a year, and there is rarely a good reason to remove them at all.
Launch day checklist
- 01Remove any noindex tag and any robots rule that blocked the staging site, and confirm it on the live domain.
- 02Test the redirect map against the live site, every row, not a sample.
- 03Check that canonical tags point to the new URLs, not to staging or to the old structure.
- 04Submit the new XML sitemap in Google Search Console. If the domain itself has changed, use Search Console's change of address tool as well.
- 05Confirm analytics and tag manager fire on every template, and that conversions record: forms, phone clicks and WhatsApp clicks.
- 06Submit every form and tap every WhatsApp and call button on a phone, and confirm each enquiry arrives where it should.
- 07If the site is bilingual, check that the English and Arabic versions still reference each other correctly.
The first eight weeks after launch
Some movement in rankings after a significant change is normal, and Google's own documentation on site moves says to expect it. The job in the weeks after launch is to tell normal settling apart from a real problem, and to fix the real problems quickly.
- Watch Search Console for pages reported as not found, and add redirects for any old URLs the map missed.
- Compare clicks to the top pages from the inventory against the same weeks before launch, page by page rather than as a site total.
- Check that the new pages are being indexed, and investigate any important page that is not.
- Resist redesigning again in week three. Changing pages while search engines are still processing the move makes it harder to see what is working.
Platform changes and store migrations
Moving platform is a redesign with an extra layer of risk, because platforms impose their own URL patterns. Shopify, for example, places products under /products/ and categories under /collections/, so a store moving onto it from WooCommerce or Magento will change almost every product URL whether anyone intends it or not. Store migrations therefore need a redirect for every product and category that earned traffic, alongside the product data, customer accounts and order history.
The same applies when a site moves from one CMS to another, or from a single-language site to a bilingual one with a new folder structure. Whatever the reason for the change, the old addresses need somewhere to go.
Where these figures come from
- Google Search Central documentation on site moves with URL changes and on redirects, including the guidance to keep redirects in place for at least a year and to expect temporary ranking fluctuation during a move, as published at the time of writing.
- No traffic figures or client results appear in this piece. The checklist reflects how we scope our own rebuilds and migrations.