In short: Rankings are lost to missing URLs, not to a new design. Before anything changes, record your current URLs and the traffic and enquiries each page produces, then build a redirect map that sends every old URL to its own new one with a permanent server-side redirect. Google advises keeping redirects for at least a year and warns explicitly against pointing many old URLs at the home page of the new site.
A redesign is a good moment to fix your structure, your speed and your copy. It is also the classic moment for a site to lose a large share of its traffic overnight. The difference between those two outcomes is preparation, not the platform. The rules below come from Google Search Central documentation, with the date of each page. The timings for checks after launch are our recommendation.
What should you record before the work starts?
The first step is not design. It is a snapshot of where you are now. Without that snapshot you cannot later prove what dropped, or which page caused it.
- A full list of URLs: Google advises starting from the important URLs in your sitemaps, your server logs and your analytics, with the content management system supplying the complete list.
- Clicks and impressions per page: from Search Console, for the last 12 months, so you can see seasonality too.
- Enquiries and orders per page: from GA4 and from your own system. The page that leads on visits rarely leads on enquiries.
- Sites that link to you: Google advises keeping that list and asking those sites to update their links to the new URLs.
- Embedded content: images, video, PDFs, CSS and JavaScript all have URLs and all move too.
- Titles and headings: Google generates the title link in search results automatically, but names the content of the title element as its first source.
| What you record | Where from | What it is for |
|---|---|---|
| List of URLs | sitemap, CMS, server logs | the basis of the redirect map |
| Clicks and impressions per page | Search Console | which page carries visibility |
| Enquiries and orders per page | GA4 and your own system | which page carries revenue |
| Sites linking in | Search Console | who to ask to update a link |
| Titles and headings | a crawl of the site | what must not be lost in a rewrite |
| Embedded files | a crawl of the site | images and PDFs have URLs as well |
When should you keep your URLs, and when should you change them?
The rule is short: do not change a URL you have no reason to change. Every change needs a redirect, and every redirect is a place where something can break.
Good reasons are few: moving to another domain, moving to HTTPS, merging two pages with near-identical content, and a structure that no longer matches what you sell. A new design on its own is not a reason.
There is also the opposite case: changing hosting without changing URLs. Google documents that migration separately and advises lowering the TTL on your DNS records to a low value, a few hours for example, at least a week before the move. After launch, Googlebot’s crawl rate usually dips briefly and then climbs again over the following days. What to check when you change provider is covered in our article on your company’s domain and hosting.
What does a proper redirect map look like?
The map is a two column table: old URL, new URL. One row per old URL. That is the whole idea, and it is exactly where most of the damage happens.
- One to one: each old URL goes to the new page with the same content, not to a section or a listing.
- Permanent, server side: Google lists 301 and 308 as permanent. Temporary 302, 303 and 307 keep the source page in search results, while permanent redirects show the target.
- Short chains: Googlebot follows up to 10 hops, but Google advises keeping chains under 5 and ideally to no more than 3.
- Deleted content: pages that go nowhere should return 404 or 410 rather than a redirect.
What should you avoid? Google states plainly that you should not redirect many old URLs to one irrelevant destination, such as the home page of the new site, because it confuses people and may be treated as a soft 404. The exception is equally clear: where you genuinely merged several old pages into one new page, redirecting them there is correct.
ScaleLab tip: Hand the map to your developer as a file with two columns, not as a list in an email. Then spot check 20 rows yourself in a browser, and check them again after launch, because rewrite rules usually handle the pattern and miss the exceptions.
What should you keep from the content, and how do canonicals and hreflang fit in?
A new site often arrives with new copy. Rewriting a page that already brings in enquiries is a separate decision, and it is not a compulsory part of a redesign.
- Titles and copy: keep the topic and the scope of the page. If the old page answered a specific question, the new one has to answer it too.
- Canonical URL: Google advises every page to point to itself with a self-referential rel canonical, using an absolute URL. Specifying a canonical is a hint, though, not a rule: Google may still pick a different page.
- Do not mix signals: redirects and rel canonical are strong signals, inclusion in a sitemap is a weak one. Conflicting instructions given through different techniques only muddy the picture.
- hreflang on a bilingual site: each language version must list itself and all the others. If two pages do not point at each other, the annotations are ignored. The x-default value covers visitors whose settings match none of your versions.
On a Bulgarian and English site the common slip is to update the URLs in the redirects and leave the old URLs in the hreflang annotations. Check both.
Which settings from the staging site kill the new one?
A staging site is kept away from search engines while it is being built. The problem starts when that protection survives launch.
- robots.txt does not hide a page from Google: the documentation says it exists mainly to stop you overloading the site with requests. A page disallowed there can still appear in results if other sites link to it.
- The noindex trap: if a page is blocked in robots.txt, the crawler will never see the noindex rule, and the page can still show up. So the two are not combined.
- A launch day list: Google advises keeping a list, from the preparation stage, of the URLs that need noindex removed on launch day.
- A new sitemap: submit it in Search Console and drop the old one. Google uses the lastmod value only when it is consistent and verifiable, and ignores priority and changefreq entirely.
ScaleLab tip: On launch day, open robots.txt on the new address and check by hand that the rule which protected the staging site is gone. The check takes a minute, and missing it stops the whole site being indexed.
Changing domain: how does the Change of Address tool work?
When you move to another domain or subdomain, Search Console has a Change of Address tool. Its conditions are specific and worth knowing in advance.
- Domain level only: it moves example.com or m.example.com, but not properties at path level.
- Ownership of both: you must be a verified owner of the old and the new property in the same account.
- A redirect from the home page: a permanent redirect from the old home page to the new one is required.
- 180 days: Search Console states the action continues for 180 days after you start the migration, and that redirects should be kept at least that long, longer if traffic is still coming.
The tool is not used for moving from HTTP to HTTPS, for switching between www and non-www on the same domain, or for moving part of a site. The site move guidance, meanwhile, advises keeping redirects for as long as possible, generally at least one year. Where the two periods differ, follow the longer one.
The removals tool is a separate thing. It is temporary: a request lasts about six months and it does not stop crawling, only display. It is not a migration method.
What should you check in the first 30 days?
The plan below is our recommendation, not a Google rule. Google does say that on a small to medium site most pages take a few weeks to move, that larger sites take longer, and that visibility may fluctuate in the meantime.
Day 1: check access and redirects
Open robots.txt, confirm noindex is gone, walk through 20 rows of the map and check that the forms actually deliver enquiries. Submit the new sitemap in Search Console.
Days 2 to 7: watch errors, not rankings
Look at the page indexing report and at server logs for unexpected errors. Rankings in that week tell you nothing.
Days 8 to 30: compare page by page
Compare clicks per page with what you recorded before launch. Look for pages that have disappeared from the report rather than at the total. If a core update landed in the same window, separate the two causes: how to read a drop after an update is covered in our article on what to do after a Google core update.
Remember too that fewer clicks at the same rankings can have a cause that has nothing to do with the migration. What has changed in the results and how to read it is covered in our article on the organic traffic drop at unchanged rankings. So report on enquiries, not only on visits: what such a report looks like is described in the section on the monthly report.
The technical groundwork, the redirect map and the content are all part of SEO work: obstacles to crawling are cleared first, and results are reported as enquiries from unpaid search.
Frequently asked questions
Does traffic always drop after a redesign?
Not always, but fluctuation is normal. Google says a small to medium site takes a few weeks to move and that visibility may wobble until rankings settle. If the drop continues past that, the cause is usually the redirects or blocked crawling.
How long should I keep the redirects?
The site move guidance advises keeping them as long as possible, generally at least one year. The Change of Address tool sets a floor of 180 days, and longer if traffic to the old URLs is still arriving.
Can a canonical replace a redirect?
No. A canonical is a strong signal but remains a hint, and Google may choose a different page. When an old page has to disappear, the right answer is a permanent redirect.
Do I need the Change of Address tool if I move to HTTPS?
No. The tool is only for a change of domain or subdomain. Moving to HTTPS, and switching between www and non-www, are not submitted through it.
What do I do with pages I am removing altogether?
Let them return 404 or 410. Do not redirect them to the home page: Google warns that many old URLs pointed at one irrelevant destination confuse people and may be treated as a soft 404.
Sources
- Google Search Central: Site Moves and Migrations (updated 20 August 2026)
- Google Search Central: Changing Your Web Hosting and SEO (updated 10 December 2025)
- Google Search Central: Redirects and Google Search (updated 14 April 2026)
- Google Search Central: What is canonicalization (updated 20 August 2026)
- Google Search Central: How to specify a canonical URL (updated 10 July 2026)
- Google Search Central: Tell Google about localized versions of your page (updated 22 December 2025)
- Google Search Central: Introduction to robots.txt (updated 10 December 2025)
- Google Search Central: Block Search indexing with noindex (updated 10 December 2025)
- Google Search Central: Build and submit a sitemap (updated 8 July 2026)
- Google Search Central: Influencing your title links in search results (updated 10 December 2025)
- Google Search Central: Remove a page hosted on your site from Google (updated 10 December 2025)
- Search Console Help: Change of Address tool