How to move a site

This document describes how to change the URLs of existing pages on your site while minimizing negative impact on your Google Search results. Examples of this kind of site move include:

  • URL changes from HTTP to HTTPS.
  • Domain name changes such as example.com to example.net or merging multiple domains or hostnames.
  • URL paths changes: example.com/page.php?id=1 to example.com/widget, or example.com/page.html to example.com/page.htm

Overview

  1. General best practices for site moves. Know what to expect, and how it might affect your users and rankings. If moving from HTTP to HTTPS, review the best practices for HTTPS.
  2. Prepare the new site and test it thoroughly.
  3. Prepare a URL mapping from the current URLs to their corresponding new format.
  4. Start the site move by configuring the server to redirect from the old URLs to the new ones.
  5. Monitor the traffic on both the old and new URLs.

General best practices for site moves

  • Split your move into smaller steps, if that makes sense for your site.
    If your site is large and it's technically possible, we recommend initially moving just a piece of the site to test any effects on traffic and search indexing. After that you can move the rest of your site all at once or in chunks. When choosing the initial test section of the site, pick a section that changes less frequently and isn't significantly affected by frequent or unpredictable events. Also keep in mind that while moving just one section is a great way to test your move, it's not necessarily representative of a whole site move when it comes to Search. The more pages that you move, the more likely you'll encounter additional problems to solve. Careful planning can minimize problems.
  • Change only one thing at a time
    Plan your changes to your site one after the other, not everything at the same time. For example, if you want to move your site to a new domain name, change your content management system (CMS), and update your site to use a new layout, do them one at a time: move to a new domain, then change your site's layout.
  • Time your move to coincide with lower traffic, if possible.
    If your traffic is seasonal or dips on certain weekdays, it makes sense to move your site during the recurring traffic dips. This means that fewer people will be affected by potential issues that can happen during the site move, and more of your server's resources can be dedicated to Googlebot crawling your site.
  • Expect temporary fluctuation in site ranking during the move.
    With any significant change to a site, you may experience ranking fluctuations while Google recrawls and reindexes your site. As a general rule, a medium-sized website can take a few weeks for most pages to move in our index; larger sites can take longer. The speed at which Googlebot and our systems discover and process moved URLs largely depends on the number of URLs and your server speed. Submitting a sitemap can help make the discovery process quicker, and it's fine to move your site in sections.
  • Don't worry about link credit.
    301, 302, and other server side redirects don't cause a loss in PageRank.
  • Make use of Search Console.
    Search Console is your friend, especially during a site move. Verify data for each property separately in Search Console. Use the Index Status report for a broad look. Use the Sitemaps report to view how many URLs submitted in a sitemap have been indexed.
  • Be patient, give it time
    To consider a site move complete, Googlebot will have to visit every URL on your old and new site at least once. There are no fixed crawl frequencies; how fast Googlebot crawl depends on the size of your site, and the speed of crawling that's possible. The move takes place on a per-URL basis.

Prepare the new site

The details of site preparation vary for each site move, but typically you'll do one or more of the following:

  • Set up the CMS (preferably the same as the old site used) and import the content from the old site.
  • Transfer images and downloads (such as PDF documents) that you host.
    These might already be getting traffic from Google Search or links, and it's useful to tell users and Googlebot about their new location.
  • For a move to HTTPS, get and configure the required TLS certificates on your server.

  • Set up a robots.txt for your new site and make sure the rules in the new site's robots.txt file correctly reflect the parts you want blocked from crawling.

    Note that some site owners block all crawling while in development. If you follow this strategy, make sure you prepare what the robots.txt file should look like once the site move starts. Likewise, if you use noindex rules during development, prepare a list of URLs from which you'll remove the noindex rules when you start the site move.

  • Provide errors for deleted or merged content if you're not moving to the new site all your old content, make sure those URLs correctly return an HTTP 404 or 410 error response code on the new site.

  • Ensure correct Search Console settings that may help with the site move.

    If you haven't already, verify both the old and new sites in Search Console. Be sure to verify all variants of both the old and new sites. For example, verify www.example.com and example.com, and include both the HTTPS and HTTP site variants if you use HTTPS URLs. Do this for both old and new sites.

    • Review the Search Console verification

      Make sure your Search Console verification will continue to work after the site move. If you're using a different method of verification, keep in mind that verification tokens may be different when the URL changes.

      If you're using the HTML file method to verify ownership of your site in Search Console, make sure you don't forget to include your current verification file in your new copy of the site.

      Likewise, if you verify ownership with an include file that references the meta tag or Google Analytics to verify ownership, ensure the new CMS copy includes these as well.

    • Review any configured settings in Search Console that you may have made for the old site, and make sure the new site's settings are updated to reflect those changes as well. For example:

      • Crawl rate: Set the crawl rate to "Let Googlebot determine" for both the old and new site.
      • Disavowed backlinks: If you've uploaded a file to disavow links on your old site, we recommend that you re-upload it again using the Search Console account of the new site.

    • Clean up your recently purchased domain; you'll want to make sure it's clean of any outstanding issues from the previous owner. Check the following settings:

      • Manual action for previous spam. If there are any manual actions applied to the new site, address any problems listed there and file a reconsideration request.
      • Removed URLs. Make sure that there aren't any URL removals left over from the previous owner, especially a site-wide URL removal.

  • Use web analytics to analyze usage on both the old and new sites. Web analytics software can help with this. Typically, web analytics configuration consists of a piece of JavaScript embedded in your pages. The details for tracking different sites varies depending on your analytics software and its logging, processing, or filtering settings. Check with your analytics software provider for help. Additionally, if you have been planning to make any configuration changes to your analytics software, now is a good time. If you use Google Analytics, consider creating a new profile for your new site if you want clean separation in your content reports.

  • Ensure that your server has enough computing resources: after a migration, Google will temporarily crawl your new site more heavily than usual. This is because your site redirects traffic from the old to the new site, and any crawls of the old site will be redirected to the new site, in addition to any other crawling. Ensure that your new site has sufficient capacity to handle the increased traffic from Google. If your site is particularly large, get in touch with your hosting providers and give them a heads-up about the site move you're planning.

Prepare URL mapping

It's important to map your old site's URLs to the URLs for the new site. This section describes a number of general approaches you can take to correctly assess the URLs on your two sites and facilitate mapping. The exact details of how you generate this mapping will vary depending on your current website infrastructure and the details of the site move.

Determine your old URLs

In the simplest of site moves, you may not need to generate a list of your old URLs. For example, you could use a wildcard server-side redirect if you're changing your site's domain (for example, moving from example.com to example.net).

In more complex site moves, you will need to generate a list of old URLs and map them to their new destinations. How you get a listing of old URLs depends on your current website's configuration, but here are some handy tips:

  • Start with your important URLs. To find them:
    • Look in your sitemaps because it's likely your most important URLs have been submitted in Search Console that way
    • Check your server logs or analytics software for the URLs that get the most traffic
    • Check the Links to your site feature in Search Console for pages that have internal and external links
  • Use your content management system, which can typically provide a straightforward way to get a listing of all URLs that host content.
  • Check your server logs for URLs that were visited at least once recently. Pick a time period that makes sense for your site, keeping in mind seasonal variation of traffic.
  • Include images and videos—Make sure that you include URLs of embedded content in your site move plans: videos, images, JavaScript, and CSS files. These URLs need to be moved in the same way as all other content on your website.

Create a mapping of old to new URLs

Once you have the listing of old URLs, decide where each one should redirect to. How you store this mapping depends on your servers and the site move. You might use a database, or configure some URL rewriting rules on your system for common redirect patterns.

Update all URL details on the new site

Once you have your URL mapping defined, you'll want to do three things to get the pages ready for receiving traffic.

  1. Update annotations to point to the new URLs in the HTML or sitemaps entry for each page:
    1. Each new URL should have a self-referencing rel="canonical" <link> tag.
    2. If the site you moved has multilingual or multinational pages annotated using rel-alternate-hreflang annotations, be sure to update the annotations to use the new URLs.
  2. Update internal links.
    Change the internal links on the new site from the old URLs to the new URLs. You can use the mapping generated earlier to help find and update the links as needed.
  3. Save the following lists for your final move:
    • A sitemap file containing the new URLs in the mapping. See our documentation about building a sitemap.
    • A list of sites linking to your old URLs. You can find the links to your site in Search Console.

Plan your redirect strategy

Once you have a mapping and your new site is ready, the next step is to plan your redirect strategy. We recommend server side permanent redirects from the old URLs to the new URLs as you indicated in your mapping. Check with your server administrator (or hosting company) about what kind of server side redirects you can technically do. It might be redirect rules in your .htaccess files if your server is using Apache HTTP server or redirect functions in your CMS.

If none of the server side redirect setups are possible, you can fall back to client side redirects as a last resort.

Decide how you will move your site – all at once, or in sections:

  • Small or medium sites: We recommend moving all URLs on your site simultaneously instead of moving one section at a time. This helps users interact with the site better in its new form, and helps our algorithms detect the site move and update our index faster.
  • Large sites: You can choose to move larger sites one section at a time. This can make it easier to monitor, detect, and fix problems faster.

Keep in mind the following:

  • Use server side permanent redirects if technically possible. Although Googlebot supports several kinds of redirects, we recommend that you use HTTP permanent redirects if possible, such as 301 and 308.
  • Avoid chaining redirects. While Googlebot can follow up to 10 hops in a "chain" of multiple redirects (for example, Page 1 > Page 2 > Page 3), we advise redirecting to the final destination directly. If this is not possible, keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5. Chaining redirects adds latency for users, and not all user agents and browsers support long redirect chains.

Start the site move

Once the URL mapping is accurate and you finalized the plan for how you're going to redirect, you're ready to move.

  1. Implement or turn on the redirects: depending on your decisions your redirect strategy, this might mean you push an update to your server configuration files or you update your CMS, likely with custom code.
  2. Check the rel="canonical" link annotations and robots meta rules: Once the redirects are active, ensure that the rel="canonical" link annotations on the new site are using the new URLs. Similarly, if you added noindex robots meta rules to the new site to avoid prematurely indexing the new URLs, make sure to update them.
  3. Test the redirects. You can use the URL Inspection Tool for testing individual URLs, or command line tools or scripts to test large numbers or URLs.
  4. Submit a Change of Address in Search Console for the old site.

  5. Keep the redirects for as long as possible, generally at least 1 year. This timeframe allows Google to transfer all signals to the new URLs, including recrawling and reassigning links on other sites that point to your old URLs.

    From users' perspective, consider keeping redirects indefinitely. However, redirects are slow for users, so try to update your own links and any high-volume links from other websites to point to the new URLs.

  6. Submit the new sitemap in Search Console. This will help Google learn about the new URLs. At this point you can remove your old sitemap, since Google will use the new sitemap going forward.

The time it takes Googlebot and our systems to discover and process all URLs in the site move depends on how fast your servers are and how many URLs are involved. As a general rule, a small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer. The speed at which Googlebot and our systems discover and process moved URLs depends on the number of URLs and the server speed.

Immediately after the site move is started, try to update as many links as possible to improve the user experience and reduce your server load. These include:

  • Internal links: based on the URL mapping you previously created, replace all URLs that pointed to your own pages.
  • External links: Try to contact the sites in the saved list of sites linking to your current content, asking them to update their links to your new site. Consider prioritizing your efforts by the number of inbound visits for each link.
  • Profile links such as from Facebook, Twitter, and LinkedIn.
  • Ad campaigns to point to the new landing pages.

Monitor traffic

Once you've started the site move, monitor how the user and crawler traffic changes on the new site and also the old site. Ideally the traffic on the old site will go down, while on the new site the traffic goes up. You can monitor user and crawler activity on the sites with Search Console and other tools.

Use Search Console to monitor traffic

Many features of Search Console help you monitor a site move, including:

  • Sitemaps: Submit the two sitemaps you saved earlier from the mapping. Initially, the sitemap containing the new URLs would have zero pages indexed, while the sitemap of the old URLs would have many pages indexed. Over time the number of pages indexed from the old URLs sitemap would drop to zero with a corresponding increase of indexing of the new URLs. Note that Search Console may show warnings for the sitemap that contains the old URLs about the URLs redirecting; this is normal and you can ignore these warnings: you are, in fact, moving to new URLs after all.
  • Index Coverage report: The graphs would reflect the site move, showing a drop in indexed URL counts on the old site and an increase of indexing on the new site. Check regularly for any unexpected crawl errors.
  • Search queries: As more pages of the new site get indexed and start ranking, the search queries reports would start showing the URLs on the new site getting search impressions and clicks.

Use other tools to monitor traffic

Keep an eye on your server access and error logs. In particular, check for crawling by Googlebot, any URLs that unexpectedly return HTTP error status codes, and normal user traffic.

If you installed any web analytics software on your site, or if your CMS provides analytics, it's also recommended that you review traffic this way so that you can see the progress of traffic from your old to new site. In particular, Google Analytics offers real-time reporting, and this is a handy feature to use during the initial site move phase. You should expect to see traffic drop on the old site and rise on the new site.

More resources

Site migrations can be overwhelming and complicated, so there are lots of takes on how to proceed. We found Aleyda Solis' site migration checklists particularly useful, and also the Screaming Frog tool guide for site migrations.

If you're stuck at any point, look for help on Google Search Central.
There is plenty of good advice on our help page and specific cases answered in our user forums. If you can't find an answer, you can ask a question to one of our Google Search specialists during our SEO office hours.

Troubleshooting your site move

Here are some common mistakes when migrating a site with URL changes (including HTTP to HTTPS). These mistakes can prevent your new site from being indexed completely.

Common mistakes

noindex or robots.txt blocks

Don't forget to remove any noindex or robots.txt blocks that were only needed for the migration.

It's fine if you don't have a robots.txt file on your site, but be sure to return a proper 404 HTTP status code if the robots.txt file doesn't exist.

To test:

  • Examine your robots.txt file in your HTTPS site and see if anything needs to be changed.
  • Use the URL inspection tool for any pages that seem to be missing from Google in the new site.

Incorrect redirects

Check your redirects from the old site to the new one. We frequently see people redirecting to the wrong (non-existent) URLs on the new site.

You can use Search Console to see if there are an unusually high number of "Not found" errors reported, or you can use other tools such as Screaming Frog to crawl your own site and see if the redirects work as expected.

Other crawl errors

Examine the Index Coverage report for a spike in other errors on your new site during migration events.

Insufficient server capacity

After a migration, Google will crawl your new site more heavily than usual. This is because your site redirects traffic from the old to the new site, and any crawls of the old site will be redirected to the new site, in addition to any other crawling. Ensure that your site has sufficient capacity to handle the increased traffic from Google.

Not updating sitemaps

Be sure that your sitemaps are all updated with the new URLs.