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: for medium-sized websites, it can
  take a few weeks or more for Google to gradually start showing the new URLs instead of the old
  ones (and for larger sites, even 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 and
  other permanent 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 crawls 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 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 of URLs.
4. 
   If you’re changing domain names or subdomains, submit a
   Change of Address
   in Search Console for the old site.

   You only need this tool when moving from one domain or subdomain to another (such as
   example.com to example.net, or a.example.com to
   b.example.com). You don’t need it for HTTP to
   HTTPS moves, switching between www and non-www on the same domain, or moving paths
   within the same domain.

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.

Update links

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.