Redesign Without Losing Your Search Traffic
5 min read
You pay for a redesign, and two weeks after launch search traffic is down seventy percent. This happens more often than people expect, and the cause is nearly always the same. The new site uses different addresses, the old ones were never redirected, and every ranking you had built up broke along with the links pointing at you. Design can be adjusted later. This kind of loss takes months to recover.
1. Build a URL map before the work starts
This belongs at the start of the project, not in the week before launch. You need a list of every old address still worth something and the page it corresponds to on the new site. Without that list there is nothing to configure redirects from, and nothing to check against once the site is live.
Three sources feed the list, each covering pages the other two miss. Merge them and drop the duplicates.
Pull the map from these three places
- The Performance report in Search Console. Export the pages with impressions. Those are the addresses actually bringing traffic, so they come first.
- The old sitemap. Export the full list to pick up pages that exist but never showed in the performance data.
- Pages other sites link to. Break those addresses and you throw away the recommendations other people gave you.
Then annotate each row with its address on the new site. Where there is no one-to-one match, send it to the closest category page. Pages you are deliberately removing need marking as such, because they should return a proper gone response rather than being pointed somewhere arbitrary.
2. Use permanent redirects
Redirects come in permanent and temporary forms. A redesign that changes addresses needs permanent ones, meaning status code 301. That tells search engines the page has moved and asks them to carry the old address's standing across. Set it as temporary and search engines keep the old address on file, so nothing you built up transfers.
This mistake is unusually hard to spot, because nothing about it is visible. The visitor lands on the new page either way. Confirming it means checking the response status code, or asking whoever built the site to state plainly which type they used. It belongs at the server or application level, not as a jump written into the page, since a jump inside the page only fires once the browser has read it and works far less well.
Writing the rules as patterns is easier to maintain than listing every address, so one class of page can share one rule. Keep the itemised map anyway, because that is what you verify against after launch. Watch out for redirect chains as well, where an old address points at an interim one which points at the final one. Every hop loses something and slows the page down. Go straight to the final address in one step.
| The old address | What to do with it |
|---|---|
| Has a matching page on the new site | Permanent redirect straight to it, one hop, no chains |
| Has no one-to-one match | Permanent redirect to the closest category page, not the homepage |
| Being retired, nothing links to it | Let it return a proper gone response, with an error page that gives the visitor somewhere to go |
| Being retired, but other sites link to it | Redirect it anyway, so the recommendation is not wasted |
3. Changing domain is riskier than redesigning
A redesign that changes only the design and leaves the address structure alone carries very little risk. What is genuinely dangerous is changing domain at the same time, or changing the address scheme at the same time. If the schedule allows, do not do two things at once. Change the design, let it settle for a month or two, then change the domain, so any problem can be traced to one of them.
If you do need to change domain, several things are worth doing properly. Use the Change of Address tool in Search Console to declare the relationship between the old and new domains, which is the only official way to tell search engines the two belong together. Keep both domains in the same account so you can watch traffic transfer between them. Submit a new sitemap once the new domain is live, and confirm the old one has been removed.
4. What to check in the first week
Launch is not the finish. Checks in the first week catch most of the problems. Noticing something odd in a traffic report a month later means the damage is already done, and it takes longer to undo.
Work through this within seven days of launch
- Test the redirects. Click through several important ones from the map by hand and check the rest in bulk, confirming each lands on the right new page in a single hop.
- Confirm no development-stage blocking survived. This is the most common reason a redesigned site cannot be found at all.
- Submit the sitemap again. Then watch the indexed count in Search Console.
- Check the Page Indexing report for a mass of not-found pages. That usually means a batch of addresses missed their redirect.
- Check that titles and descriptions came across. Plenty of redesigns leave those fields empty, which gives up the text that describes you in search results.
5. A short-term drop is normal
Even with every step done right, a period of lower traffic after a redesign is common. Search engines need time to re-crawl and re-assess the new addresses, and that usually runs from a few weeks to two or three months. Expect it in advance, so you do not panic on day ten and revert the new site.
Telling a normal transition from a real problem needs a baseline. Before the redesign, record the last three months of impressions, clicks and main queries, so there is something to compare against later. Without it, all you see is a line going down, with no way to separate the redesign from the seasonal dip you get every year.
The real risk in a redesign is not the design, it is the addresses. Build the map before work starts, verify against it row by row after launch, and most of the disasters are avoidable. If your site has already been redesigned and traffic never came back, checking what happened to the old addresses usually produces the answer.
Common questions
- We are only changing the design and keeping every URL. Do we still need this?
- The risk is much lower, but two things still need checking: whether page titles and descriptions came across, and whether any development-stage blocking survived into the new version. With addresses unchanged, existing rankings normally hold, and what the work affects is content and loading speed.
- Our old URLs have been returning 404 for a month. Is it recoverable?
- Yes, but do it soon. Collect the old addresses still worth something, add the redirects, and search engines will transfer the value across as they re-crawl. The longer it drags on, the more likely external links get removed and rankings get taken by somebody else. Start with the pages that have external links and the ones that used to get impressions.
- Should we build a staging site for the redesign?
- Yes, but block it from being indexed, or you end up with two identical copies competing with each other. When the staging site is signed off and the real one goes live, remember to reverse the blocking. That is the step people forget most.