A drop in traffic after a new site goes live is common but preventable. What to do before and after launch.
Organic traffic halving a few weeks after a new site goes live is a picture we see very often. Almost every time the cause is the same: old addresses not linked to new ones, content depth lost, or technical settings forgotten. These are preventable problems.
Before going live
1. Extract the current address list
List all live addresses via Search Console and the sitemap. Which pages get traffic, which rank — don't redesign without knowing this.
2. Prepare a redirect map
Determine the new equivalent of every old address. Redirect pages with no equivalent not to the homepage but to the page on the closest topic. Redirects sent in bulk to the homepage are usually treated by Google as soft 404s and don't pass value.
3. Don't shorten the content
Shortening texts so they "look cleaner" may feel good design-wise but can lower ranking. If you're reducing the content of a page that ranks, make it a deliberate decision.
4. Migrate titles and descriptions
Your existing title and meta description values are already tested. Migrate them to the new site verbatim; if you're going to change them, do it after launch and one by one.
On launch day
- Make sure you've removed the
noindextag from the development environment. This is the most frequent and most expensive mistake. - Check that the robots.txt file isn't blocking the site.
- Create the new sitemap and submit it to Search Console.
- Verify that analytics and conversion tracking codes work on the new site.
- Test the forms with a real submission — is the e-mail actually arriving?
The first 30 days after launch
Check crawl errors in Search Console weekly. If addresses returning 404 appear, add redirects. Fluctuation in rankings during the first two weeks is normal; but if it still hasn't recovered by the fourth week, there's a technical problem.
Summary
Redesigning a site is not a risk for SEO but, done right, an opportunity. When speed, mobile compatibility and content structure improve, traffic increases after the redesign on most sites. What creates the risk is a lack of planning.
Why does a post-redesign drop happen?
What's lost in a site redesign is not the design but accumulated trust. Links have been given to your old addresses over the years, and Google has matched those addresses to certain searches. When the addresses change, this match breaks. If no redirect is set up, Google loses the old address and starts recognizing the new one from scratch.
The size of the drop usually depends on this: how many addresses changed, how much of them received traffic, and how correctly the redirects were set up.
The inventory to do before migration, without fail
- Extract the current address list. Search Console and the sitemap show which pages exist.
- Note which pages get traffic. Not all pages are equal; the top 20 pages carry the bulk of traffic on most sites.
- Save the current titles and descriptions. Losing these in the new design is one of the silent causes of a ranking drop.
- Write the new address mapping in advance. Which old address goes to which new one — one by one, not by guesswork.
Three common mistakes in redirecting
- Redirecting everything to the homepage. It looks easy but Google interprets it as "the page no longer exists" and doesn't transfer the ranking. Every page should go to its closest equivalent in content.
- Chain redirects. Chains that stretch out as A → B → C both slow things down and lose value. Set up A → C directly.
- Using a temporary redirect (302). A permanent move needs a 301; a 302 tells Google "this is temporary, keep holding the old address."
The first week after going live
The work isn't over the moment migration ends. In the first week, watch these:
- Coverage errors in Search Console — especially a jump in the "not found (404)" count.
- That the new sitemap has been submitted.
- That no block placed during development remains in the robots.txt file.
- That canonical addresses point to the new structure.
- That page speed hasn't regressed compared to the old site.
These five checks catch the bulk of post-redesign losses in the very first days.
What should you do if the domain or platform is changing?
If the domain, protocol or platform is changing, a redirect map isn’t enough; you need to open the new property in Search Console, use the Change of Address tool where needed and compare the URL rules of the new structure with the old one. These changes carry more risk than just a redesign.
Domain change
Add and verify the new domain in Search Console, 301-redirect every page on the old domain to its equivalent on the new one, then notify Google of the move with the Change of Address tool in the old property’s settings. Don’t stop renewing the old domain; the redirects only work as long as you still own it.
Platform change
When moving from an off-the-shelf system to custom software, or the other way round, the URL format can change quietly: trailing slashes, upper and lower case, file extensions, category folders and pagination structure. Each of these counts as a different URL. Write out a few sample URLs from the old and new systems side by side and lock down the rules from the start.
The same logic applies when moving from HTTP to HTTPS or from non-www to www: redirect all URLs to the new format with a single rule, and update canonical tags, the sitemap and internal links to the new format. The first requirement for an SEO-friendly website is that every piece of content has one consistent address.
How do you test redirects after launch?
The most reliable method is to feed your full list of old URLs into a crawler and confirm that each one goes to the right page in a single hop with a 301 status code. Clicking through a few pages by hand won’t catch most errors.
- List crawl: Load the old URLs in list mode in a crawler such as Screaming Frog SEO Spider; report the status code, the destination URL and whether there are any redirect chains.
- Spot checks: For the pages with the most traffic, use the URL Inspection tool in Search Console and confirm that the new URL is indexable.
- Page indexing report: In the first few weeks, watch how the “Not found” and “Page with redirect” counts change. A rise in pages with redirects is normal during a migration.
- Backlinks: Check separately the old URLs that receive the most external links; the value of these pages is passed on through the redirect.
Repeat this SEO check once on launch day, once at the end of the first week and once at the end of the first month. Some errors only become visible as Google recrawls the old URLs; a one-off check won’t catch them.
Internal links, images and structured data
Even if redirects are set up correctly, if links within the site still point to old URLs, every click triggers an unnecessary redirect. From a technical SEO point of view, internal links need to be updated to point directly at the new URLs.
- Menu, footer and in-text links: Should be updated to the new URLs; no internal links to old URLs should be left.
- Images: If you get traffic from image search, image URLs and alt text should be carried over too.
- Structured data: Markup such as organisation, product and FAQ should also be present in the new templates; you can check it with Google’s Rich Results Test.
- Multilingual sites: The hreflang tags that link language versions to each other should be regenerated with the new URLs.
- Ad and email links: Destination URLs in Google Ads, Meta ads and email templates should be updated.
Each of these looks small on its own, but when they aren’t handled together, the number of redirects balloons, crawl budget is spent on old URLs and discovery of new pages is delayed. In practice, the easiest approach is to crawl the staging environment with a crawler before launch, list every link pointing to the old domain or old URL structure, and fix them.
We cover what to monitor in the months after the migration in our article on the first 90 days of SEO on a new site. If you’d like to plan the migration from the start, see our SEO service page.
Frequently asked questions
How long does the post-redesign drop last?
In a correctly set-up migration, a few weeks of fluctuation is normal and recovers on its own. If there's a drop lasting months, it's not a "migration effect" but an uncorrected mistake.
Is it better not to change the addresses at all?
Yes, where possible this is the safest path. Renewing the design and content while preserving the address structure largely removes the risk of a redesign.
Should I delete old content?
Don't delete any content that gets traffic. If it's outdated, update it; if it's really unnecessary, redirect it to the closest relevant page. A page deleted silently is both a visitor and a ranking loss.
How long should redirects stay in place?
Google recommends keeping redirects for at least a year after a move. In practice, the safest course is not to remove them as long as external sites are linking to the old URLs. Removing a redirect also removes the value of that link.
How should a staging site be blocked from Google?
The most reliable method is to put the staging site behind password protection. Blocking it with robots.txt alone doesn’t stop the URLs from being discovered in other ways. Password protection is removed at launch, and you should check separately that none of the development settings remain on the live site.
Should the new sitemap include the old URLs as well?
No. The sitemap should contain only the new URLs you want indexed. Google already knows the old URLs; when it recrawls them, it sees the redirect and moves on to the new address.
