Website Migration SEO: How to Redesign Without Losing Rankings, With 301 Redirects, a Redirect Map and a Launch Checklist (2026)

Redesign meetings tend to focus on design and features. Yet it is common to hear, a month after launch, that enquiries have dropped and search traffic has halved. The cause is usually not the design but how the URL move was handled.

When URLs change, search engines rely on redirects to decide where existing signals should go. If redirects are missing or point to the wrong place, the value built up over years does not reach the new pages.

This article follows Google's official guidance to explain how to build a redirect map (a table of old URLs and their new URLs), the differences between status codes, common faults, server-specific examples, how long fluctuation lasts, and effort ranges. Whether you need a redesign at all is covered in "10 Signs You Need a Website Redesign", and overall costs in "Website Redesign Cost and How to Read a Quote".

Main sources for this article

• Google Search Central: site moves with URL changes, redirects, HTTP status codes, and consolidating duplicate URLs
• Search Console Help on the Change of Address tool, and the IETF's RFC 9110
• Bing Webmaster Blog, "Website Migration with Bing" (December 2020)
• Search Engine Journal's study of 892 domain migrations (January 2025)

What you will learn	Key point
What happens when URLs change	Signals move via redirects; rankings fluctuate during the move (section 1)
Where to start	Collect every old URL and build a map (sections 3 and 4)
Which status code to use	301 or 308 for moves; 302 and 307 only for temporary redirects (section 5)
What usually goes wrong	Chains, loops, mass redirects to the home page, leftover noindex (sections 6 and 12)
How long until things settle	Officially "a few weeks or more"; reported cases vary widely (section 10)
What it costs	About 10 to 20 hours for up to 50 URLs (section 11)

1. What happens when URLs change

Search engines remember pages by address

Search engines attach signals such as backlinks, internal links and clicks in search results to individual URLs. When a URL changes, the new address looks like a page they have never seen.

Only a permanent redirect from the old URL to the new one tells them the page has moved. Google describes such redirects as "a strong signal that the target of the redirect should become canonical".

As the W3C note "Cool URIs don't change" (1998) argues, changing a URL also cuts every reference that lives outside your site: other sites' links, bookmarks, and QR codes on printed material.

PageRank is not lost, but rankings will move

Google's site move guide states that 301 and other permanent redirects don't cause a loss in PageRank. The same guide tells you to expect temporary fluctuation in site ranking during the move.

Official statement	What it means for you
Permanent redirects don't lose PageRank	Done correctly, value carries over
Expect temporary fluctuation	Some dip right after launch is normal
Medium sites take a few weeks or more	Don't judge the result after one month
Keep redirects generally at least 1 year	Removing them early cuts the move short

So the outcome depends on two things: whether the redirects are correct, and how long you wait.

2. The type of move determines the work

Five types of site move

"Redesign" covers very different URL changes. The type decides which tasks you need and what you do in Search Console.

Type of move	Example	Redirects	Change of Address tool
URLs unchanged	New server or CMS only	Not needed	Not needed
Protocol change	http to https	301 for all URLs	Not needed
Host name change	Standardise www or non-www	301 for all URLs	Not needed
Path change	/service.html to /services/	301 via the map	Not needed
Domain change	example.jp to example.com	301 via the map	Needed

A move without URL changes needs no redirects, but it has its own steps, such as lowering the DNS TTL in advance and keeping the old server running until its traffic stops.

Change one thing at a time

Google recommends moving in smaller steps and changing only one thing at a time where practical. The Change of Address help page also warns that combining a move with a redesign can cause traffic loss.

If you change the domain, the structure and the CMS on the same day, you cannot tell which change caused a drop. Even when you cannot stage the work, not changing URLs that don't need to change limits the impact. At the design stage, ask once whether the old URLs could simply be kept.

3. Google's official process, step by step

Start six to eight weeks before launch

Google splits the work into five stages: review best practices, prepare the new site, prepare the URL mapping, start the move, and monitor traffic.

Google's documents give no timings; these are DevNJ's working estimates. Finishing the map four weeks ahead leaves time to test and fix redirects on a staging site.

Stage	Main tasks	Easy to miss
1. Prepare	Build the new site, verify old and new in Search Console	robots.txt and noindex on the new site
2. Map	Collect old URLs, match them to new ones	Images, PDFs, URLs with parameters
3. Switch	Enable redirects, submit sitemap	Internal links and canonical tags
4. Monitor	Search Console, logs, analytics	Whether old-site traffic is falling

The right-hand column is where most post-launch traffic losses begin.

What to check when preparing the new site

Staging sites are usually hidden from search with a robots.txt block or a site-wide noindex. Google says to remove any noindex or robots.txt blocks that were only needed during development. If you forget, the new pages will not appear in search, however perfect your redirects are.

4. How to build a redirect map

Collect every old URL

A redirect map is only as good as its list of old URLs. If you list only the pages in your CMS, you will miss PDFs, campaign pages, URLs with parameters, and deleted pages that other sites still link to.

Source	What it finds	Watch out for
Current XML sitemap	Public pages the CMS knows about	Many pages are missing
Crawler	URLs reachable through internal links	Orphan pages are missed
Search Console	URLs shown or clicked in search	Last 16 months only
Analytics	Pages people actually viewed	Pages without tracking are missing
Server logs	URLs requested by people and bots	Use a long time range
Backlink tool	URLs linked from other sites	Also finds deleted pages

The last two rows are among the few ways to find URLs you thought were gone but other sites still link to.

Columns and mapping patterns

Put one URL per row, with columns for old URL, new URL, action (301, 410 or unchanged), priority, reason and test result. Recording the reason lets you trace why a page was sent where it was if its traffic falls after launch.

Pattern	Example	Action
One to one	Old "About us" to new "About us"	301
Merge (many to one)	Three old case studies to one new page	301 if the content carries over
Removed (one to none)	A campaign that has ended	Return 404 or 410

Merges are where judgement is needed. Google says not to redirect many old URLs to one irrelevant destination, such as the new home page. If there is no matching page, returning a 404 or 410 is the honest answer.

Use priorities to spend testing time wisely

In Search Console, mark pages with the most clicks, and pages with the most backlinks, as priority A, and check each of their destinations by eye before launch. In most cases, search traffic is concentrated on a small share of pages.

5. 301, 302, 307 and 308: the differences and how Google treats them

What RFC 9110 says

The meaning of HTTP redirects is defined in the IETF's RFC 9110. 301 (Moved Permanently) and 308 (Permanent Redirect) mean the resource has been assigned a new permanent URI. 302 (Found) and 307 (Temporary Redirect) mean it resides temporarily under a different URI.

The difference is how form submissions are handled. For 301 and 302, RFC 9110 notes that for historical reasons a user agent may change the request method from POST to GET, and points to 308 and 307 if that is not wanted. 308 is the younger code, first defined in RFC 7538 in 2014.

How Google treats them

Google treats 301 and 308 as a strong signal that the target should be canonical, and 302 and 307 as a weak signal. It still asks you to use the code that fits the situation, because they mean different things. Here is how each method is handled.

Method	Permanent or temporary	Google's treatment	When to use
301 / 308	Permanent	Target becomes canonical	Standard for moves
302 / 303 / 307	Temporary	Source stays canonical	Maintenance
Instant meta refresh	Permanent	Treated as permanent	No server access
JavaScript redirect	Permanent	Missed if rendering fails	Last resort

Server-side 301s and 308s are the most reliable. Treat meta refresh and JavaScript as fallbacks for hosting where you cannot change server settings.

Which one to choose

For moving pages, a 301 is enough. Opening a page is a GET request, so the POST issue does not arise. If you are moving a form endpoint or an API URL, use a 308.

Two cautions. RFC 9110 says 301 and 308 responses are heuristically cacheable, so a wrong 301 can stay in visitors' browsers for a while after you fix it. And some frameworks default to 302, so check that a move is not sending 302s (see section 8).

6. Preventing chains, loops and soft 404s

Chains: don't stack redirects

A redirect chain is when several redirects stand between the old URL and the final one, for example "old http URL → https → non-www → new path". It happens when you add new redirects on top of old ones.

Google's crawlers follow up to 10 redirect hops. But the site move guide says to redirect straight to the final destination, and if that is impossible, keep chains to ideally no more than 3 hops and fewer than 5.

Chains also cost speed. Chrome for Developers notes that each redirect adds a network round trip that can delay loading by hundreds of milliseconds. To prevent chains, write only the final URL in the map's new-URL column, and normalise http, www and trailing slashes in a single hop. Update the targets of older redirects to the new URLs as well.

Loops: redirects that come back

A loop is when A redirects to B and B redirects back to A. A common cause is the server adding a trailing slash while the application removes it.

Soft 404s: over-redirecting is also a problem

A soft 404 is when a page that does not exist returns "success" (200) or redirects somewhere unrelated. Search Console Help warns that redirecting users to another page, such as the home page, instead of returning a 404 makes it harder for Google to understand your site.

Fault	Symptom	How to check
Chain	Two or more redirects in a row	Count hops with curl or a crawler
Loop	"Too many redirects"	Browser and Search Console
Soft 404	Unrelated redirect or empty page	Soft 404 status in Search Console
Still 302	Old URLs stay in search results	Check the response status code
Lost parameters	Filters vanish after redirect	Test URLs with ? in them

Chains and loops sometimes appear only on the production CDN, so test on the live site right after launch too.

7. Aligning canonical, hreflang, sitemaps and internal links

Point every signal the same way

Google's documentation on consolidating duplicate URLs lists redirects (strong signal), rel="canonical" (strong signal) and sitemap inclusion (weak signal), and says these methods stack and become more effective when combined. If different methods name different URLs, the canonical URL becomes unclear.

Item	How to align	Official caution
rel="canonical"	Each new URL points to itself	Not to the old URL
hreflang	Language versions point to each other's new URLs	Ignored if not mutual
XML sitemap	Submit new URLs only	Full URLs; 50,000 URLs or 50MB max
Internal links	Update body text, menus, footer	Link consistently to canonical URLs
robots.txt	Block only what you mean to	Not for canonicalisation

If internal links still point to old URLs, every click inside the site triggers a redirect, which can also create chains.

Don't block old URLs in robots.txt

Google says not to use robots.txt for canonicalisation, and does not recommend using noindex to choose a canonical within one site.

Blocking old URLs because they still show in search is counterproductive: crawlers can no longer read the redirect, and the move stalls. Leave old URLs crawlable and keep returning 301s.

hreflang and sitemaps

Google explains that hreflang annotations are ignored if two pages don't both point to each other, and that URLs must be fully qualified, including https. Three language versions mean three times the mapping and testing, so add a language column to the map.

Submit a sitemap of the new URLs; the old sitemap can be removed later. Google uses lastmod only when it is consistently accurate, and ignores priority and changefreq.

8. Server-specific examples

Decide where to redirect first

Redirects can be set in the web server, the application or a CMS plugin. Search engines see the same result, but speed and ease of management differ.

Where	Suitable scale	Strength	Caution
Apache (.htaccess)	Up to a few hundred rules	Works on shared hosting	Many rules slow every request
Nginx (map, return)	Thousands of rules	Fast with large maps	Needs server access
Laravel routes	Tens to hundreds	Managed with the code	Defaults to 302
WordPress plugin	Up to a few hundred	Editable in the admin	Slower, runs through PHP

The larger the map, the better it is to handle redirects in the web server, before the application. The examples below move /service.html to /services/, move old blog posts from /blog/2019/post-name.html to /column/post-name/, and return 410 for an ended campaign.

Apache (.htaccess)

Adding R=301 to a mod_rewrite RewriteRule makes it permanent. Mixing mod_alias Redirect lines with RewriteRule can produce surprises in processing order, so stick to one.

RewriteEngine On
RewriteRule ^service\.html$ /services/ [R=301,L]
RewriteRule ^blog/[0-9]{4}/([a-z0-9-]+)\.html$ /column/$1/ [R=301,L]
RewriteRule ^campaign-2019/ - [G,L]

[G] returns 410 (Gone). For thousands of rules, RewriteMap in the server configuration is faster.

Nginx

Use return 301. Large one-to-one maps fit neatly in a map block, so you can copy the redirect map almost directly.

map $uri $new_uri {
    default        "";
    /service.html  /services/;
}
server {
    if ($new_uri) { return 301 $new_uri; }
    location ~ ^/blog/[0-9]{4}/([a-z0-9-]+)\.html$ { return 301 /column/$1/; }
    location ^~ /campaign-2019/ { return 410; }
}

The map block goes in the http context. $uri excludes the query string, so if old URLs depend on parameters such as ?id=12, include $args in the condition.

Laravel routes

As the official documentation says, Route::redirect returns 302 by default. For moves, pass 301 as the third argument or use Route::permanentRedirect.

Route::permanentRedirect('/service.html', '/services/');
Route::get('/blog/{year}/{slug}.html', fn (string $year, string $slug) =>
    redirect("/column/{$slug}/", 301))->whereNumber('year');

WordPress plugins

WordPress core redirects an old post slug to the new URL when you change it (wp_old_slug_redirect). That works per post, so it is not enough for a redesign that changes the whole structure.

A widely used option is the Redirection plugin, active on more than 2 million sites as of October 2026. It supports regular expressions, 404 logging, CSV import, and export to Apache and Nginx configuration. You can import your map as CSV, then move it into the web server configuration as the site grows.

9. Search Console and Bing

When the Change of Address tool applies

Use the Change of Address tool only for domain or subdomain changes. Do not use it for HTTP to HTTPS, www changes, hosting or CDN changes, or moving some pages within a site.

Requirement	Details
Eligible moves	Domain or subdomain changes
Ownership	Old and new verified with the same Google account
Pre-work	301 from old home page to new, plus key pages
Effect period	180 days from the start of the move
Keep redirects	At least 180 days; longer if old URLs get traffic
Cancelling	Possible within 180 days

The tool is not a substitute for redirects. It prioritises the move of signals to the new site, on the assumption that redirects are correct. The help page also advises against chaining moves (A to B, then B to C) and against merging several sites into one at the same time.

Bing's Site Move tool

For sites serving European audiences, cover Bing too. Bing's Webmaster Blog (December 2020) recommends keeping old-domain redirects live for at least one to two years, preferably longer, and telling Bing about the move with the Site Move tool once ownership is verified. You can also report redirected and removed URLs through URL submission or IndexNow, a shared protocol for notifying search engines of changes.

Reports to watch after launch

Report	What to look at	How often
Page indexing	Indexed new URLs; 404, soft 404 and redirect errors	Weekly in month one
URL Inspection	Index status of priority A pages	One by one at launch
Performance	Clicks for old and new URLs	Weekly for 3 months
Crawl stats	Response breakdown (301, 404, 5xx)	Weekly

Google's guide says that ideally traffic on the old site goes down while traffic on the new site goes up. If both fall at the same time, something is wrong with the redirects or the new site.

10. How long does the fluctuation last?

What Google says

Google says little about timing. Its guide says to expect temporary fluctuation, and that for medium-sized sites it can take a few weeks or more for new URLs to replace old ones, with larger sites taking longer. Other official figures are the Change of Address tool's 180 days and the recommended redirect lifetimes.

Reported cases: a long average, a wide spread

The most quoted non-official figure is Dan Taylor's study in Search Engine Journal (updated January 2025, data collated on 22 October 2024). Across 892 domain migrations, it counted the days until the new domain matched the old domain's estimated organic traffic.

Item	2025 update	2023 first edition
Sample	892 domain migrations	171
Average days to recover	523	229
Not recovered after 1,000 days	17%	42%
Fastest recoveries	19, 22, 23 and 33 days	Not stated

Read these numbers with care. They are estimates from third-party tools, not the sites' own analytics. They cover domain changes, which differ from redesigns that only change paths. Part of the sample was crowdsourced from SEO practitioners, so it does not represent the whole market. Still, it shows that some sites recover in weeks and others take more than a year.

What shortens or lengthens the dip

These are tendencies drawn from the official documents and reported cases, not proven causes.

Shortens the dip	Lengthens the dip
One-to-one redirects, same content	Mass redirects to the home page
One hop to the final URL	Chains, or 302s left in place
Change URLs only, keep structure and content	Change domain, structure and content at once
Internal links and canonicals aligned	Internal links to old URLs remain
Errors fixed weekly after launch	Nobody checks after launch

Rushing to restructure because of an early dip can make the fluctuation last longer. Treat fixing errors and changing structure as separate decisions.

11. Effort and cost ranges

Rules of thumb by size

There is no published benchmark for redirect work alone. The ranges below are working estimates, not statistics. They use Dutch hourly-rate surveys (freelance web developers €73, agency average €106, excluding BTW, the Dutch VAT) and the European Central Bank reference rate of 22 October 2026 (€1 = ¥175.97). The rate sources are explained in "Website Redesign Cost and How to Read a Quote".

Size (old URLs)	Effort	In euros	In yen (approx.)
Up to 50 (company site)	10–20 hours	€730–€2,120	¥130,000–¥370,000
50–500 (cases, blog)	20–50 hours	€1,460–€5,300	¥260,000–¥930,000
500–5,000 (shop, multilingual)	50–120 hours	€3,650–€12,720	¥640,000–¥2,240,000

The effort covers everything from collecting old URLs to three months of monitoring. Sites whose URLs change by a rule sit at the low end; sites where each page needs a decision sit at the high end.

What to check in a quote

If a quote says only "redirect setup", ask what it covers. Otherwise you may hear just before launch that the map is your job.

Check	What happens if it is vague
Who collects the old URLs	Built from the CMS list only; PDFs and backlinks missed
Who decides the mapping	Someone unfamiliar with the content sends pages to the home page
Scope of pre-launch testing	Partial, or none
Canonical, hreflang, internal links	Redirects only; signals conflict
Length of post-launch monitoring	Contract ends at launch; errors are left

If these five items are in the quote, differences in hours become differences in scope that you can compare.

12. Common failures

Failures on launch day

These are not real company cases, but points the official documents warn about and patterns often seen in practice.

Failure	What happens	Prevention
noindex or robots.txt left in place	New site disappears from search	URL Inspection right after launch
Everything redirected to the home page	Treated as soft 404s	Build a one-to-one map
Set up as 302	Old URLs stay canonical	Check status codes before launch
Internal links still old	More redirects, chains	Bulk-replace links in content and menus
hreflang points to old URLs	Language pairs ignored	Add a language column to the map

Failures six months to a year later

First, removing redirects too early, for instance during a server migration. Links on other sites are rarely updated, so manage redirects on the assumption that they stay.

Second, letting the old domain lapse. The redirects disappear, and if someone else registers it, links to your old domain point to their site.

Third, stacking redirects at the next redesign. Keep the map and, next time, update the targets of past redirects too.

13. Extra work for sites serving Japan and Europe

What changes on multilingual sites

Sites used in both Japan and Europe have URLs for each language, so the work grows. Google's documentation on multi-regional and multilingual sites lists country domains, subdomains and subdirectories as options, and does not recommend URL parameters for switching languages.

Item	Japan-only site	Site for Japan and Europe
Rows in the map	Number of pages	Pages × languages
hreflang updates	Often not needed	Update all versions mutually
Search engines to check	Mainly Google	Google and Bing
Automatic language redirects	Rarely an issue	Avoid

Merging a Japanese site on example.jp and an English site on example.com into one domain is a move that combines two sites. As the Change of Address help page advises, it is safer to move them one at a time.

Avoid automatic language redirects

Redirecting visitors to a language version based on browser language or IP address is something Google tells you to avoid, because users and search engines may not be able to see all versions. Offer language links on the page and use hreflang instead.

14. Worked examples (fictional)

The three cases below show different move types. They are fictional, not real companies.

Case A: a Japanese manufacturer switching CMS

About 40 old URLs. Addresses like /?page_id=12 become /products/, and the domain stays the same. Five product pages and the company profile bring 80% of search traffic, so they are priority A. A PDF catalogue linked from a distributor's site gets its own redirect.

Case B: a Japanese-owned service company in the Netherlands merging two domains

The Japanese site on example.jp and the English site on example.nl move to /ja/ and /en/ on example.com. About 300 old URLs across two languages. The English site moves first, and the Japanese site one to two months later. hreflang is reset mutually, Bing is notified, and both old domains are renewed for at least two years.

Case C: an online shop selling into the EU, with rule-based product URLs

About 3,000 old URLs. /item.php?id=123 becomes /products/123-name/. The mapping can be generated from product IDs in the database and exported to an Nginx map. Discontinued products redirect to a successor if there is one, and return 410 if not.

Item	Case A	Case B	Case C
Old URLs	About 40	About 300 (2 languages)	About 3,000
Type of move	Path change	Domain merge	Path change
Change of Address tool	No	Yes, one at a time	No
How the map is built	By hand	By hand, plus language column	Generated from the database
Effort	10–20 hours	30–50 hours	60–100 hours

The type of move and whether mapping can be automated change the nature of the work more than page count does.

15. Checklist before and after launch

Four weeks before launch

• Old URLs collected from all six sources
• Every old URL has an action: 301, 410 or unchanged
• Priority A destinations checked, including their content
• No mass redirects to the home page

The day before launch

• Every row of the map tested automatically on staging
• Every redirect reaches the final URL in one hop
• No loops from trailing slashes or http and https rules
• canonical, hreflang and internal links point to new URLs

Launch day

• Development noindex and robots.txt blocks removed
• Production returns 301 (or 308), not 302
• New sitemap submitted to Google and Bing
• Change of Address submitted if the domain changed

First three months

• 404, soft 404 and redirect errors checked weekly
• Old URLs that still return 404 found in logs and added to the map
• Maintenance team told to keep redirects at least one year (two, for Bing)
• Renewal of the old domain arranged

Summary

• When URLs change, search signals move via redirects. If you can keep URLs, that is the safest option
• Google says permanent redirects don't lose PageRank, but also says to expect temporary fluctuation during a move
• A redirect map depends on collecting every old URL. Redirect one to one, and return 404 or 410 where there is no match
• Use 301 or 308 for moves. 302 and 307 are for temporary redirects only
• Make redirects reach the final URL in one hop, and align canonical, hreflang, sitemaps and internal links
• Use the Change of Address tool only for domain changes. Keep redirects at least one year for Google and one to two years or more for Bing
• Officially, settling takes "a few weeks or more". Reported cases vary widely, so keep fixing errors and changing structure separate

Sources

Google Search

• Site moves with URL changes — Google Search Central: stages, 301 and 308, chains, one-year retention, temporary fluctuation
• Site moves without URL changes — Google Search Central: server moves that keep URLs
• Redirects and Google Search — Google Search Central: how each redirect method is treated
• How HTTP status codes affect Google's crawlers — Google Search Central: 10 hops, signal strength, soft 404s
• How to specify a canonical URL — Google Search Central: canonicalisation methods and signal strength
• Tell Google about localized versions of your page — Google Search Central: mutual hreflang
• Managing multi-regional and multilingual sites — Google Search Central: URL structures, avoiding automatic redirects
• Build and submit a sitemap — Google Search Central: limits and lastmod
• Change of Address tool — Search Console Help: eligibility and 180 days
• 404 (Page Not Found) errors — Search Console Help: soft 404s
• Page indexing report — Search Console Help: index status and errors
• URL Inspection tool — Search Console Help: checking individual URLs
• Crawl Stats report — Search Console Help: response code breakdown

HTTP standards and web basics

• RFC 9110: HTTP Semantics — IETF: definitions of 301, 302, 307 and 308
• RFC 7538 — IETF: the original definition of 308
• Cool URIs don't change — W3C: why URLs should not change
• Avoid multiple page redirects — Chrome for Developers: latency from redirects

Servers and CMS

• Redirecting and Remapping with mod_rewrite — Apache HTTP Server: RewriteRule and RewriteMap
• mod_alias — Apache HTTP Server: Redirect syntax
• ngx_http_rewrite_module — nginx: return
• Routing — Laravel 13.x: Route::redirect defaults to 302
• wp_old_slug_redirect() — WordPress Developer Resources: redirects after slug changes
• Redirection — WordPress.org: features and active installations

Bing and reported cases

• Website Migration with Bing — Bing Webmaster Blog: migration steps and redirect lifetime
• URL Submission — Bing Webmaster Tools: reporting redirects and removals
• IndexNow: notifying search engines of changes
• How Long Should An SEO Migration Take? — Search Engine Journal: study of 892 domain migrations

All sources were checked on 23 October 2026. Search engine behaviour and report names change, so check the latest documentation before you start. The timings in Figure 1, the factors in section 10, the effort ranges in section 11 and the cases in section 14 are DevNJ's own working estimates, not statistical benchmarks.