Search Migration: Canonicals, Sitemaps, and Indexation
This is the indexation job when the URLs change: permanent redirects, self-referencing canonicals, sitemaps, and what to watch in Search Console. The DNS cutover runbook is the other article.
You changed the addresses. HTTP became HTTPS, the domain changed, or the path changed. People and Google still have the old URLs. Your job is to get the new URLs crawled, chosen, and shown. That is indexation. Rankings will move around while that happens. You do not fix that by publishing a second copy of every page.
DNS cutover, certificates, and the hosting flip are the other runbook, website migration without losing search visibility. This page starts once the URLs themselves change.
This guide applies only when the URLs change
Sourced from Google. The site move guide covers URL changes from HTTP to HTTPS, a domain or hostname change (including merging hosts), and path changes, such as example.com/page.php?id=1 becoming example.com/widget. If the URLs stay the same and you are only changing infrastructure such as hosting, that is a different document: site move with no URL changes. This page does not summarize that one. Primary source: How to move a site (Search Central, page last updated 2026-08-20 UTC, checked 28 September 2026).
The order on that page is simple, and people still skip it. Know what to expect. Prepare the new site and test it. Map every old URL to one new URL. Turn on redirects from old to new. Then watch traffic on both.
Change one thing at a time
Plan the changes one after another, not on the same night. Google’s example is a new domain name, a content management system (CMS) change, and a new layout. Do them one at a time. The sequence written on the page is: move to the new domain, then change the layout. If you also swap the CMS, that is a third change, not a footnote on the domain move. When three things ship together and the new URLs do not appear, you cannot tell whether the redirect map, the templates, or the CMS output is the reason.
If the site is large and you can split the work, move one section first and watch indexing and traffic. Pick a section that does not change every day and is not tied to a messy seasonal spike. A section test is not a miniature version of a whole-site move. More pages means more problems. After the test, move the rest at once or in chunks.
For a small or medium site, the same guide recommends moving all URLs at the same time rather than section by section. That is easier for users, and it helps Google’s systems notice the move. Large sites can move one section at a time so you can see breakage faster. If traffic is seasonal, move during the dip so fewer people hit the rough edge, and so the server has more room for crawling.
Expect the rankings to wobble, and do not invent a deadline
Any significant change can bring ranking fluctuation while Google recrawls and reindexes. As a general rule, a medium-sized website can take a few weeks or more before Google gradually starts showing the new URLs instead of the old ones. Larger sites take longer. How fast discovery and processing go depends on how many URLs you have and how fast your server is. Submitting a sitemap can help discovery. Moving in sections is allowed.
There is no fixed crawl frequency. How fast Googlebot crawls depends on the size of the site and the speed of crawling that is possible. The move is per URL. To treat the move as complete, Googlebot has to visit every URL on the old site and the new site at least once. Later on the same page, Google says a small to medium site can take a few weeks for most pages to move, and larger sites take longer. Visibility in Search can fluctuate while that happens. The page calls that normal, and says rankings settle over time. Those are ranges, not a promise that week three is safe.
On link credit, use Google’s sentence, not a forum version. The guide says 301 and other permanent redirects do not cause a loss in PageRank. A permanent redirect to the correct new URL is the mechanism. A redirect to the wrong place is a different failure, covered below. The duplicate URL guide is for http, www, trailing slash, and parameters that stay in place after this move. Do not use a one-time domain project to skip that cleanup.
Map first, then redirect once
A simple domain change can be a wildcard server-side redirect. Anything more complicated needs a list. Start with the URLs that matter: the sitemap (important URLs are often already submitted that way), server logs or analytics for URLs that get traffic, and the links report in Search Console. Pull a full list from the CMS if it can give you one. Include images, video, JavaScript, and CSS. Those URLs move the same way as HTML.
- One destination: Each old URL points at its final new URL. Googlebot can follow up to 10 hops in a chain. The guide still says to redirect straight to the final URL. If you cannot, keep the chain short, ideally no more than 3 and fewer than 5. Chains add latency, and not every browser or user agent will follow a long one.
- Permanent and server-side: Use HTTP permanent redirects if you can, such as 301 and 308. Client-side redirects are a last resort when the server cannot do it. Check with whoever runs the server. Apache may use redirect rules. A CMS may expose a redirect function.
- Not the home page: Do not send many old URLs to one irrelevant URL, such as the home page of the new site. That can confuse users and might be treated as a soft 404. If you merged several old pages into one new page, redirect those old URLs to that new page. That is consolidation, not a dump.
- Leave them up: Keep the redirects for as long as you can, generally at least 1 year, so Google can transfer signals, recrawl, and reassign links that still point at the old URLs. For users, consider keeping redirects indefinitely. Redirects are slow for people, so update your own links, and ask high-traffic sites that link to you to update theirs.
After the redirects are on, check them. URL Inspection can test single URLs. Command line tools or scripts can test a long list. Also confirm the new pages. Each new URL should carry a self-referencing rel="canonical" link. If you had noindex on the new site so it would not be indexed early, remove it when the move starts. Update internal links from old URLs to new URLs. If you use hreflang, point those annotations at the new URLs too.
If you are not moving some old content, those URLs should return HTTP 404 or 410 on the new site. A soft success page for a deleted URL is not a favor. It looks like the content still exists.
Verify both properties, then read the right reports
Search Console is the tool for this move. Verify data for each property separately. Verify every variant of the old site and the new site: www and non-www, and both HTTPS and HTTP if you use HTTPS URLs. Verification can break when the URL changes. If you verify with an HTML file, put that file on the new copy. If you verify with a meta tag or Google Analytics, the new CMS copy has to include that too.
Set crawl rate to let Googlebot decide, on the old site and the new site. If you uploaded a disavow file for the old site, upload it again on the new site’s Search Console account. If you bought the new domain, check it for a manual action left by the previous owner, and for leftover URL removals, especially a site-wide removal. Fix a manual action and file a reconsideration request before you blame the redirects.
| What you open | What it is for on this move | What “normal” can look like |
|---|---|---|
| Each verified property | Old and new, including www, non-www, HTTP, and HTTPS variants | You are not guessing from one hostname |
| Index Status report | A broad look, which the best-practices section names for a site move | You review it while URLs shift, not once on launch day |
| Index Coverage graphs | The monitoring section points here: indexed URL counts on the old site and the new site | Indexed URLs drop on the old property and rise on the new one. Check for unexpected crawl errors. |
| Sitemaps report | How many URLs submitted in a sitemap have been indexed | The new sitemap starts with few or no indexed URLs. The old sitemap’s indexed count falls. Redirect warnings on the old sitemap are normal. |
| Search performance | Queries and pages once the new URLs are indexed and start ranking | Impressions and clicks begin to show on the new URLs. The old URLs fade. That handoff is not instant. |
The best-practices section says “Index Status report.” The monitoring section says “Index Coverage report” and describes those graphs. This page uses both names the way that guide uses them. Do not assume a screenshot from a blog matches the label in your account until you open the report.
Change of Address is a separate control, and only for some moves. Use it when you move from one domain or subdomain to another, such as example.com to example.net, or a.example.com to b.example.com. Submit it for every verified variant of the old domain, including subdomains and www and non-www, even if you do not actively use those variants. You do not need Change of Address for HTTP to HTTPS, for www versus non-www on the same domain, or for path changes on the same domain.
Do not launch behind the development block
Set up robots.txt on the new site so it blocks only what you still want blocked. Some owners block all crawling while the site is in development. If you did that, prepare the robots.txt you actually want before the move starts. If you used noindex during development, keep a list of URLs and remove those rules when the move starts. The troubleshooting section is blunt: remove any noindex or robots.txt blocks that existed only for the migration. If the site has no robots.txt file, return a proper 404 for that URL. Test the live file, and use URL Inspection on pages that are missing from Google on the new site.
After a migration, Google crawls the new site harder than usual. Crawls of the old URLs are redirected to the new site, on top of crawls of the new URLs. Give the new server room for that. If the site is large, tell the host before you flip redirects. Watch server logs for Googlebot, for URLs that return errors you did not expect, and for ordinary user traffic. If analytics is installed, you should see traffic fall on the old site and rise on the new one. Real-time reporting is useful in the first phase. That is a traffic handoff, not proof that every URL is indexed.
Submit the new sitemap, then stop debugging three projects at once
Save a sitemap of the new URLs from the mapping, and submit it in Search Console. That helps Google learn the new URLs. The start-the-move section says you can remove the old sitemap at that point, because Google will use the new one going forward. The monitoring section says to submit both sitemaps from the mapping and watch the indexed counts trade places: the new sitemap starts with no pages indexed, the old sitemap’s indexed count falls, and redirect warnings on the old URLs are normal. Use that pair while you are still checking the handoff. Submitting a sitemap helps discovery. It does not set a crawl frequency.
Update internal links as soon as the move starts, so users and your server are not paying for redirects you already understand. External links are a request, not a switch: contact sites that link to the old URLs, and prioritize the ones that send visits. Profile links and ad landing pages belong on that list too.
If the first HTML of the new site is empty, none of the reports above will save you. Inspect rendering with URL Inspection on a JavaScript site before you argue about sitemaps. The repeatable crawl, render, and index pass is the JavaScript technical SEO audit.
Filled hypothetical: three changes and a leftover block
Hypothetical, labeled as such. A studio moves to a new domain, swaps the CMS, and ships a new layout on the same evening. The staging robots.txt, which disallowed every crawler, is copied to the new host. A week later the old URLs redirect, and the new URLs are not showing. Nobody can say whether Google is still processing a medium-site move, whether the canonicals still point at the old templates, or whether the new host is simply not allowed to be crawled.
The honest sequence is the one on the guide. Finish the domain move. Confirm the new host is crawlable, self-canonical, and in the sitemap you submitted. Read Index Status, the coverage graphs, and the Sitemaps report on both properties. Change the layout later. Change the CMS in its own window. Fluctuation during those weeks is expected. A block you forgot is not fluctuation.
What this does not prove
A few weeks is not a service-level agreement. “Larger sites take longer” is the whole promise for a big site. Permanent redirects do not, in Google’s words, cause a loss in PageRank. That does not mean a wrong target, a long chain, or a home-page dump is harmless. Change of Address does not apply to every URL change. And this page does not move DNS.
If the new URLs are really a new site, build that as a website, then run this indexation pass. Start a conversation with the URL map and the two Search Console properties, not with a rank screenshot from day two.
Frequently asked questions
Do 301 redirects lose PageRank?
Google’s site move guide says 301 and other permanent redirects do not cause a loss in PageRank. That sentence is about the redirect type. It does not cover a chain, a redirect to a missing URL, or dumping many old URLs onto an unrelated home page. Source: Search Central, site move with URL changes, checked 28 September 2026.
How long until Google shows the new URLs?
There is no fixed crawl frequency. For a medium-sized site, Google says it can take a few weeks or more to start showing the new URLs instead of the old ones. Larger sites take longer. A small to medium site can take a few weeks for most pages to move. The move happens per URL, and Googlebot has to visit every old and new URL at least once before you treat the move as finished.
Do I need Change of Address for an HTTPS move?
No. Search Console’s Change of Address tool is for a move from one domain or subdomain to another. You do not need it for HTTP to HTTPS, for switching www and non-www on the same domain, or for path changes on the same domain. If you do change domain, submit it for every verified variant of the old host.
Should I leave the old sitemap in Google Search Console?
Google Search Console (GSC) is where you submit the new sitemap so Google can learn the new URLs. The site move guide says you can remove the old sitemap at that point, because Google will use the new one going forward. Redirect warnings on a sitemap of old URLs are normal during the move. The Sitemaps report is how you see how many submitted URLs are indexed.
What if the new site was blocked in robots.txt while we built it?
Take the block off before you call the move started. The site move guide warns that some owners block all crawling during development, and that you must have the live robots.txt ready when the move starts. The same applies to noindex rules you added so the new URLs would not be indexed early. A development block left in place can keep the new site from being indexed.