Traffic loss during a website redesign is the most expensive and most preventable side effect of redesign projects. The typical scenario goes like this: the new site goes live, everyone is happy, and a few weeks later requests from the contact form start to drop. When Search Console is opened, hundreds of "not found" errors show up. The cause is almost always the same: the old addresses weren't properly redirected to the new ones. In this article we walk step by step through the plan to follow to protect your Google traffic during a redesign or migration.
Why is traffic lost?
Google knows your site page by page. Over the years, each page has earned a place in certain searches, gained links from other sites and ended up in customers' bookmarks. When a page's address changes on the new site and the old address returns a "not found" (404) error, as far as Google is concerned that page has disappeared. The new page starts from scratch.
A 301 redirect is a server response that tells the browser and the search engine that the old address has moved permanently to a new one. As Google's site migration documentation also recommends, correctly configured 301 redirects help transfer the signals the old page has accumulated to the new page.
Step 1: A complete inventory of old addresses
The plan starts with extracting every address on the current site. A single source isn't enough; combine several:
- The site's current sitemap (sitemap.xml)
- The "Pages" and "Performance" reports in Search Console, especially addresses that get clicks
- The most visited pages in your analytics tool
- A full crawl of the site with a crawling tool
- Addresses that receive links from other sites
- Addresses printed in catalogs, on business cards or in QR codes
PDF files and images are addresses too. When a technical datasheet linked from a supplier's site moves to a different location on the new site, that link breaks.
Step 2: The redirect map
For each old address in the inventory, identify its closest equivalent on the new site. This table is the most important document in the project.
| Old address | New address | Note |
|---|---|---|
| /about-us.html | /company/about-us | One-to-one match |
| /products.php?cat=12 | /products/pump-group | Category match |
| /news/2019-trade-fair | /blog | No equivalent, closest parent page |
| /catalog-2021.pdf | /documents/catalog.pdf | Redirect to the current version |
Two rules matter here. First, don't redirect everything to the home page; Google generally treats this like a "not found," and users don't find what they were looking for either. Second, avoid redirect chains; the old address should go directly to the final address, with no second redirect in between.
Step 3: Preserving content on the new site
A redirect moves the address, not the content. If the old page ranked well for a certain search, the reason is its content. On the new page, the main headings of that content, the questions it answers and its key phrases should be preserved. Content that has been shortened, completely rewritten or buried in images can cause ranking losses even if the redirect is correct.
Title tags, meta descriptions and structured data are part of this check too.
Step 4: Launch day
Plan the go-live day for a quiet period; a campaign or trade fair week isn't suitable. During the switch:
- Set up and test the redirect rules on the new site before going live
- Make sure the test environment is closed to search engines and the live site is open
- Prepare the new sitemap and submit it to Search Console
- Test the addresses in the redirect map one by one or in bulk with a tool
- If the domain is changing, use the change of address tool in Search Console
Carrying the test environment's "no indexing" block over to the live site is a common mistake that cuts off traffic completely.
Step 5: The first weeks after launch
Watch Search Console closely for the first few weeks. New addresses returning "not found" errors point to old pages that were missed; set up additional redirects for them. If clicks for a specific page are falling in the performance report, check that page's content and redirect. Don't remove redirects soon after; they should stay in place for a long time, ideally permanently. We explained what to look at in Search Console in our article on reading Search Console reports.
Migration checklist
- All old addresses were collected from more than one source
- A redirect map was prepared, with no blanket redirects to the home page
- No redirect chains
- The content and headings of important pages were preserved
- The test environment is closed, the live site is open to indexing
- The new sitemap was submitted
- Error reports are monitored during the first weeks
How we do it at Globya
In redesign projects, the redirect map is one of the first documents prepared, before design. The new corporate website is built at a separate test address while your current site stays live; when it's ready, the switch happens in a single step together with the redirects. Post-launch monitoring is carried out together with our SEO and AI visibility team. If you're wondering whether it's time for a redesign, our article on when to redesign your website can help.
Frequently asked questions
With correct redirects, is there no traffic loss at all?
Short-term fluctuation is normal; rankings can shift for a few weeks while Google learns the new structure. A correct plan prevents permanent loss and speeds up recovery.
How long should 301 redirects stay in place?
As long as possible. Links to old addresses from other sites and printed materials live on for years; removing the redirects means losing those visitors.
Does changing hosting companies also cause traffic loss?
If the addresses stay the same and the server change is done without downtime, it usually doesn't. The risk is the site being unreachable for a long time during the switch, or settings being carried over incompletely.
The Globya assistant is online 24/7; it answers right away and passes your question to the team if needed.