Tutorials

Website migration without losing Google rankings: from URL inventory to monitoring

Inventorying old URLs, a 301 redirect map, testing before the switch, changing domains in Search Console and what to watch over the following weeks

DualFroz - VulCode CEO·3 September 2026·23 min read

After a website rebuild, the pages that lose their Google rankings are most often URLs nobody added to the redirect map: an old blog post an industry portal has been linking to for years, a PDF price list, a service page with a parameter in its URL. A website migration without losing rankings is first and foremost work on a list of URLs. The server configuration comes last and takes the least time.

It's also worth being honest about what to expect. In its guide to site moves, Google says that search visibility may fluctuate temporarily during a move and that this is normal, and that for a medium-sized site it can take a few weeks or longer for the new URLs to replace the old ones. A good migration doesn't eliminate that period, but it removes the reasons a site stays lower for good once it's over.

In short

Collect old URLs from several sources at once: the sitemap, Search Console, analytics, server logs and the CMS database. Each source catches something the others miss.
Redirect every old URL with a 301 or 308 to its closest equivalent. URLs with no equivalent should return a 404 or 410, not lead to the home page.
Test the whole map with a script before the switch and after it. Keep the redirects for at least a year, ideally forever.
When changing domains, use the Change of Address tool in Search Console for every variant of the domain, with and without www.
Change one thing at a time. A new domain, a new CMS and a new layout on the same day means three possible causes of a drop and no way to tell them apart.

Types of website migration and what each changes for Google

"Migration" covers very different changes, and the type determines how much SEO work it needs. One question settles it: do the URLs users see change? If not, little changes for Google. If they do, every old URL needs a redirect.

Change	Do the URLs change	What's needed
New hosting or CDN	No	DNS TTL lowered before the move, old server kept running until it stops receiving traffic
Moving from HTTP to HTTPS	Yes, the protocol changes	301 redirects from every http URL to its https equivalent, without the Change of Address tool
New URL structure on the same domain	Yes	A full redirect map, new internal links, a new sitemap
Domain change	Yes	A redirect map, the Change of Address tool in Search Console, requests to update links
New CMS or website rebuild	Usually yes, because every system builds URLs its own way	As with a new URL structure, plus checking content and templates
Merging several sites into one	Yes	A redirect map from every domain and a decision on which content stays

A hosting change on its own is the simplest. In its description of infrastructure moves, Google advises lowering the TTL of DNS records to a few hours at least a week in advance, and shutting down the old server only once traffic in its logs has dropped to zero. It also warns that right after a move, Googlebot usually slows down crawling temporarily and then increases it over the following days, sometimes above the previous level.

With every other change, the URLs are what count. The links and signals a site has collected over the years are attached to specific URLs. A 301 redirect tells the search engine that the new URL takes over the role of the old one. Without a redirect, the old URL ceases to exist and the new one starts from zero.

One change at a time

In its migration guide, Google advises planning changes one after another rather than all at once. As an example, it gives exactly the combination that happens most often: a new domain, a new CMS and a new layout. Each of these is better done separately.

The reason is practical. If traffic drops after a migration, and in the same week the domain, URL structure, content and template all changed, there's no way to establish what failed, because any one of these changes could have caused the drop on its own. With changes spread over time, each period tells you about only one of them.

It can't always be done by the book. A company changing its name wants the new domain and the new look on the same day. In that case, the risk can be reduced in three ways:

The same paths on the new domain. If /services/websites stays /services/websites, just on a different domain, the redirect map comes down to a single rule, and the risk of a mapping mistake drops to a minimum.
Unchanged content on the day of the move. Copy, titles and headings are carried over in the first version exactly as they were, and rewritten only after a few weeks, once the new URLs are in the index.
A large site in parts. Google allows large sites to be moved section by section. That makes it easier to spot a problem and fix it before it affects the whole site.

Inventory: the list of URLs that matter today

A redirect map is only as good as the list of old URLs it's built from. The most common mistake is building it from the menu or the old sitemap, which show the planned state, not the URLs that have collected links and traffic over the years.

In its guide, Google lists several sources for the old URL list: sitemaps, server logs, analytics, the Links report in Search Console and the content management system. Each catches something different:

Source	What it catches	What it misses
XML sitemap	URLs the system considers current	Old URLs, files, pages removed from the menu
A crawl of the current site	Everything internal links lead to, including files and images	Pages nothing links to any more
Search Console, Performance report, Pages tab	URLs with impressions and clicks in Google	URLs with no search traffic
Search Console, Links report	The pages most linked to from other sites	URLs without external links
Analytics, landing pages	Visits from campaigns, newsletters, social media	Traffic from before the period you have data for
Server logs from recent months	Every URL anyone requested, including Googlebot and old bookmarks	URLs nobody has requested recently
CMS database	All published content, including hidden content	URLs outside the CMS, such as files uploaded by hand

When exporting from Search Console, watch out for the limit. An export straight from the report is capped at 1,000 rows. For a larger site, you'll get more rows through the Search Console API. While you're at it, export the Performance report data for as long a period as possible. After the migration it will be your baseline for comparisons.

Add to the list the things no report shows, because they live outside the site: URLs printed on flyers and in QR codes, links in email signatures, in quote templates, in company profiles in directories and in active ad campaigns. Google also reminds you about embedded resources: images, video files, PDFs, even JavaScript and CSS files. Images that rank well in image search lose those rankings just like pages do.

Finally, merge the sources into one list without duplicates, and next to each URL record the number of visits from Google and the number of external links. Those two columns set the order of work: URLs with traffic and links are mapped by hand, and the long tail without traffic is handled with rules.

The redirect map: every old URL has its equivalent

A redirect map is a spreadsheet in which each row connects an old URL with a new one. The spreadsheet matters more than the server configuration: it's what the people who know the content work on, and the server gets a ready-made file generated from it.

Old URL	New URL	Decision
/about-us.html	/about	301, same content
/offer.php?id=3	/services/websites	301, same service at a new URL
/news/12-new-website.html	/blog/new-website	301, via a rule for the whole section
/portfolio/furniture-store.html	/portfolio/furniture-store	301, same case study
/spring-sale-2019.html	none	410, content removed with no equivalent

In a real spreadsheet it also helps to have columns for the number of visits, the number of external links and the name of the person who approved each mapping. A few rules apply to mapping:

The closest equivalent, not the closest category. An old service page leads to the new page for the same service. The parent category is a last resort.
Merged content leads to wherever its substance ended up. If three old posts were merged into one guide, all three redirect to that guide.
No equivalent means a 404 or 410. In its guide, Google advises against redirecting many old URLs to a single unrelated target, such as the home page, and Search Console Help calls a redirect to the home page in place of a 404 a soft 404. The user then gets a page they weren't looking for.
Old redirects need updating too. If the site has been through a migration before, it has redirects from even older URLs. They must lead straight to the new URLs, not to URLs that themselves redirect onwards after this migration.
Parameters, letter case, the trailing slash. Check what form the old URLs really appear in: /Contact.html and /contact.html may both have worked, and campaign parameters such as ?utm_source= shouldn't break the match.

Google treats 404 and 410 the same way: both say the content isn't there. The advantage of 410 is that the logs and the code show straight away that the removal was intentional and not a mistake in the map.

Server-side redirects: 301 or 308, no chains

Google distinguishes between permanent and temporary redirects, and the difference matters in a migration:

Type	How Google treats it	When to use it
Server-side 301 and 308	Permanent: a strong signal that the new URL should replace the old one in results	Every migration
302, 303 and 307	Temporary: the old URL stays in results	Short interruptions, such as a page that's temporarily unavailable
Meta refresh with zero delay	Permanent	When you have no access to the server configuration
JavaScript redirect	Permanent, but Google recommends it only as a last resort	When none of the methods above can be used

Googlebot follows a chain of up to 10 redirects, but Google recommends pointing straight at the final URL. Every extra hop is an extra request, a slower visit for the user and one more place where something can break.

With hundreds of URLs, the rules in the server configuration should be loaded from a file generated from the spreadsheet, not written by hand. In nginx, that's what the map directive is for. The configuration below handles a domain change from example.com to example.net combined with changes to some of the URLs:

redirects.map

/about-us.html                      https://www.example.net/about;
/portfolio/furniture-store.html     https://www.example.net/portfolio/furniture-store;
~^/news/\d+-(.+)\.html$             https://www.example.net/blog/$1;

example.com.conf

map $uri $new_url {
    default "";
    include /etc/nginx/redirects.map;
}

map $uri $gone {
    default 0;
    /spring-sale-2019.html 1;
}

map $arg_id $offer_by_id {
    default "";
    3 https://www.example.net/services/websites;
    7 https://www.example.net/services/online-stores;
}

server {
    listen 443 ssl;
    server_name example.com www.example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        if ($gone) {
            return 410;
        }
        if ($new_url) {
            return 301 $new_url$is_args$args;
        }
        return 301 https://www.example.net$request_uri;
    }

    location = /offer.php {
        if ($offer_by_id) {
            return 301 $offer_by_id;
        }
        return 404;
    }
}

A few details we checked on this configuration before it went into the article:

$uri instead of $request_uri. $uri doesn't include parameters, so /about-us.html?utm_source=newsletter hits the same entry as /about-us.html, and $is_args$args carries the parameters over to the new URL. With keys based on $request_uri, a URL like that matches nothing.
Letter case. Plain keys in map are compared case-insensitively, so /ABOUT-US.html also hits the right entry.
Regular expressions. An entry starting with ~ handles a whole section with one rule, and the captured part of the URL goes in place of $1.
URLs with a parameter as an identifier. When a parameter decided the content, as in /offer.php?id=3, a separate map on $arg_id redirects each offer, and unknown identifiers get a 404.
The last line in location /. URLs not in the map go to the same path on the new domain. If that path doesn't exist there, the user sees a 404, which is more honest than the home page.

With very long URLs, nginx may ask at startup for map_hash_bucket_size to be increased. That's an ordinary table size setting, not an error in the map.

How long should you keep redirects? Google says: as long as possible, generally at least a year. A year is the minimum that lets the search engine transfer the signals and recrawl the content. Links from other sites, bookmarks and printed materials won't disappear after a year, so in practice redirects are kept permanently, and the old domain is paid for as long as anyone still arrives through it.

Testing the redirect map before the switch

In its guide, Google advises testing redirects with the URL Inspection tool for individual URLs, and with a script for larger numbers. The script below reads the map from a CSV file exported from the spreadsheet and checks three things for each row: whether the old URL returns a 301 or 308, whether it leads exactly where it should, and whether the target URL responds with a 200 without further redirects.

check-redirects.sh · bash

#!/usr/bin/env bash
# Usage: ./check-redirects.sh map.csv https://www.example.com
# map.csv: old_path,new_full_url (no header row)
set -u
map_file="$1"
old_base="$2"
errors=0

while IFS=, read -r old_path expected || [ -n "$old_path" ]; do
  expected="${expected%#x27;\r'}"
  [ -z "$old_path" ] && continue

  read -r code target < <(curl -s -o /dev/null --max-time 15 \
    -w '%{http_code} %{redirect_url}\n' "$old_base$old_path")
  read -r final_code hops < <(curl -s -o /dev/null -L --max-redirs 10 --max-time 30 \
    -w '%{http_code} %{num_redirects}\n' "$old_base$old_path")

  if [ "$code" != "301" ] && [ "$code" != "308" ]; then
    echo "ERROR $old_path: status $code instead of 301 or 308"
  elif [ "$target" != "$expected" ]; then
    echo "ERROR $old_path: leads to $target instead of $expected"
  elif [ "$hops" != "1" ] || [ "$final_code" != "200" ]; then
    echo "ERROR $old_path: redirect chain ($hops), final URL returns $final_code"
  else
    echo "OK    $old_path"
    continue
  fi
  errors=$((errors + 1))
done < "$map_file"

echo "Rows with errors: $errors"
[ "$errors" -eq 0 ]

The script needs only bash and curl. The line with \r strips the line-ending character left by a CSV file saved in Excel. On a map with mistakes, the output looks like this:

output.txt

OK    /about-us.html
OK    /offer.php?id=3
ERROR /contact.html: status 302 instead of 301 or 308
ERROR /blog/old-post: redirect chain (2), final URL returns 200
ERROR /pricing: leads to https://www.example.net/ instead of https://www.example.net/services/pricing
Rows with errors: 3

Each of these three mistakes is typical. The first is a temporary redirect, which is often the default choice in plugins and hosting panels. The second is an old redirect that now leads to a URL that redirects onwards. The third is a row where someone hastily entered the home page.

The script can be run before the DNS change: on the testing machine, add the new server's IP address for both domains to the /etc/hosts file. You run the same script after the switch, on production, and after every change to the server configuration. A non-zero exit code lets you hook it into automatic checks during deployment.

The new site before the switch: canonical, internal links and sitemap

Redirects take care of the people and crawlers that arrive with old URLs. The new site also has to say consistently, on its own, which URLs are the right ones. The list from Google's guide is short:

The canonical on every new page points to the page itself. Not to the old URL, and not to the staging domain.
Internal links lead straight to the new URLs. A link through a redirect works, but it gives the crawler extra work. Links like that are most often left behind in the content of old posts imported into the new CMS.
The new sitemap contains only new URLs. Once it's submitted, Google lets you remove the old sitemap, as it will keep using the new one.
Language versions get the new URLs in hreflang. Each version points to the new equivalents of the others.
Migration blocks are removed. Every noindex and every robots.txt rule needed only for the move has to be lifted. The other launch-day items are covered in our technical SEO checklist before launch.
A server ready for more crawler visits. Google warns that after a migration it crawls the new site more intensively than usual.

When migrating to a new domain, also check whether the domain has a history. Google recommends that, with a purchased domain, you check in Search Console for manual actions or URL removal requests filed by the previous owner.

Changing domains: the Change of Address tool in Search Console

For moves to another domain or subdomain, Search Console has a Change of Address tool. It tells Google about the move and, for 180 days from its start, forwards signals from the old site to the new one, favouring the new one when choosing canonical pages. After that period, Google treats the two sites as unrelated.

The conditions for using it are specific:

You must be an owner of both properties in Search Console and manage them from the same Google account.
The tool works at domain level, not for individual directories.
The old domain's home page must 301-redirect to the new domain's home page.
The tool has to be run for every variant of the old domain, with and without www, and for subdomains. Google added this explicitly to the guide in June 2026, noting that domain migrations work best when all variants are moved.

The tool isn't for moving from HTTP to HTTPS, switching between the www and non-www version on the same domain, or moving pages within a single site. In those cases, redirects and the canonical are enough.

Outside Search Console, there's manual work left: requests to update links sent to the sites in the Links report, starting with those that bring the most traffic, and the new URLs in company profiles, email signatures, document templates and ad campaigns.

Switch day, step by step

When the map has been tested and the new site is ready, the order on switch day matters, because some steps depend on earlier ones:

A copy of the old site's data

an export of the Search Console Performance report and analytics, plus a full backup of the old site including the database.

Publishing the new site

the new site runs at its target address, with no blocks carried over from staging.

Enabling the redirects

the configuration with the redirect map uploaded to the server that handles the old URLs.

Testing the map on production

the script from the previous section runs without errors for the whole list.

Search Console for the new site

property verified, new sitemap submitted, key URLs checked with the URL Inspection tool.

Change of address

for a domain change, the Change of Address tool run for every variant of the old domain.

External links and campaigns

requests to update links sent, ad campaigns switched to the new URLs.

Analytics

check that visits to the new site are being counted, before anyone asks where the traffic went.

Plan the switch for a time when the team is available for the following hours, not for a Friday evening. A mistake in the map takes minutes to fix, provided someone notices it.

Monitoring after migration: the first days, weeks and months

After the switch, Google gradually replaces old URLs with new ones, and describes what to expect: the number of indexed URLs from the old sitemap falls and from the new one rises, traffic on the old site goes down and on the new one goes up. Monitoring means checking that exactly this is happening, and quickly catching the URLs that have fallen out of the pattern.

When	What to check	Where
Switch day and the day after	404 and 5xx responses on the new site, old URLs without a redirect, visit tracking	Server logs, the map test script, real-time analytics
First week	Whether Googlebot is crawling the new URLs and whether the server copes	Server logs, the Crawl stats report in Search Console settings
Weeks 2-8	URLs moving into the index, queries and clicks compared with the period before the migration	The Page indexing report and the Performance report with a date comparison
Months 2-6	Whether traffic has returned to the pre-migration level, whether the old domain still gets visits	The Performance report, old domain logs

In the server logs, look for URLs that return a 404 and are requested by people or by Googlebot. Each such URL is a missing row in the map. Only real traffic shows what else was linked, so add them to the spreadsheet, regenerate the file and run the test.

When comparing periods in the Performance report, compare weeks with weeks starting on the same day of the week, and for seasonal sites, also with the same period a year earlier. A drop in August compared with March may have nothing to do with the migration. General monitoring of a new site after launch, beyond SEO, is covered separately in our post on what to watch after launch.

When traffic drops: telling fluctuation from a mistake

A temporary drop comes with the territory. Google says visibility may fluctuate and will stabilise over time. The problem starts when the drop affects specific pages rather than the whole site, or when there's no sign of recovery after several weeks. The symptom then usually points to the cause:

Symptom	Likely cause	What to check
The drop affects a few specific pages	Missing or incorrect rows in the map	The old URLs of those pages in the test script
Old URLs still in results after many weeks	Temporary 302 redirects, or old URLs in the sitemap	Status codes, the contents of the submitted sitemap
New URLs marked as duplicates	The canonical points to old URLs or the staging domain	The canonical tag in the code of the new pages
Many soft 404 errors	Many URLs redirected to the home page or a listing	The redirect map, rows with a generic target
The new site doesn't appear in results at all	Noindex or a robots.txt block carried over from staging	Headers and meta tags on production
Rankings dropped despite correct redirects	Changed content, titles or heading structure	A comparison of the old and new content of the most important pages

The last row is the hardest, because the redirects have nothing to do with it. If the rebuild shortened the copy, removed sections that answered customers' questions or changed the titles, the new site may be less relevant for the queries the old one was visible for. With content carried over unchanged, you rule out this cause straight away.

Frequently asked questions about website migration

How long should 301 redirects stay in place after a migration?

Google says as long as possible, generally at least a year. In practice, redirects are kept permanently, because links from other sites, bookmarks and printed materials don't stop working after a year. With a domain change, that also means continuing to pay for the old domain.

Does a 301 redirect transfer a page's rankings?

A permanent redirect is a strong signal to Google that the new URL should replace the old one in results. Rankings also depend on content, though. If the same content sits at the new URL, the new URL takes over the role of the old one. If the content has changed, rankings depend on how well the new version answers the same queries.

Does changing hosting affect Google rankings?

A hosting change on its own, where the URLs stay the same, needs neither redirects nor the Change of Address tool. Google warns that right after the move Googlebot may temporarily crawl the site more slowly, and over the following days faster than before. What does matter is whether the new server responds without errors: with 5xx errors Google slows down crawling, and if they persist, pages can drop out of the index.

Can I redirect all old URLs to the home page?

Technically you can, but Google advises against it and calls a redirect to the home page in place of a 404 a soft 404. A URL with no equivalent should return a 404 or 410, and a URL with an equivalent should lead to exactly that.

How long does it take for rankings to come back after a migration?

Google says that for a medium-sized site it can take a few weeks or longer for new URLs to replace the old ones in results, and longer still for large sites. If after two or three months traffic is still clearly lower and the redirects work correctly, look for the cause in content changes, not in the configuration.

Migration in the project scope

Migration is a separate item in the scope of a new website, not an add-on "at the end". The URL list, the redirect map, testing and monitoring all take time, and if the quote says nothing about them, nobody has them in the plan. In our post on how to read a software house quote, we wrote that things not listed in the scope usually surface in the middle of the project. When rebuilding a site that gets traffic from Google, migration is the first of them.

We've been building websites since 2020, and when the project is handed over you receive full rights to the code and documentation, so the redirect map and configuration stay with you, not with the vendor. How working with us looks, from the first message to launch, is described on the How we work page, and the scope of our services is in the offer. If you're planning a rebuild or a domain change, write to us with the address of your current site.

Was this post helpful?

Website migration without losing Google rankings: from URL inventory to monitoring

Types of website migration and what each changes for Google

One change at a time

Inventory: the list of URLs that matter today

The redirect map: every old URL has its equivalent

Server-side redirects: 301 or 308, no chains

Testing the redirect map before the switch

The new site before the switch: canonical, internal links and sitemap

Changing domains: the Change of Address tool in Search Console

Switch day, step by step

Monitoring after migration: the first days, weeks and months

When traffic drops: telling fluctuation from a mistake

Frequently asked questions about website migration

How long should 301 redirects stay in place after a migration?

Does a 301 redirect transfer a page's rankings?

Does changing hosting affect Google rankings?

Can I redirect all old URLs to the home page?

How long does it take for rankings to come back after a migration?

Migration in the project scope

Read next

How to build an MVP: the first version of your product without burning through the budget

GDPR compliant website: forms, consent, cookies and privacy policy

How much does a website cost in 2026: price ranges and what drives them

Website migration without losing Google rankings: from URL inventory to monitoring

Types of website migration and what each changes for Google

One change at a time

Inventory: the list of URLs that matter today

The redirect map: every old URL has its equivalent

Server-side redirects: 301 or 308, no chains

Testing the redirect map before the switch

The new site before the switch: canonical, internal links and sitemap

Changing domains: the Change of Address tool in Search Console

Switch day, step by step

Monitoring after migration: the first days, weeks and months

When traffic drops: telling fluctuation from a mistake

Frequently asked questions about website migration

How long should 301 redirects stay in place after a migration?

Does a 301 redirect transfer a page's rankings?

Does changing hosting affect Google rankings?

Can I redirect all old URLs to the home page?

How long does it take for rankings to come back after a migration?

Migration in the project scope

Read next

How to build an MVP: the first version of your product without burning through the budget

GDPR compliant website: forms, consent, cookies and privacy policy

How much does a website cost in 2026: price ranges and what drives them