Redirecting URLs is the practice of resolving an existing URL to a different one, effectively telling your visitors and Google Search that a page has a new location. Redirects are particularly useful in the following circumstances:<\/p>\n\n\n\n
You\u2019ve moved your site to a new domain, and you want to make the transition as seamless as possible.<\/p>\n\n\n\n
People access your site through several different URLs. If, for example, your home page can be reached in multiple ways (for instance, http:\/\/example.com\/home , http:\/\/home.example.com , or http:\/\/www.example.com ), it\u2019s a good idea to pick one of those URLs as your preferred ( canonical ) destination, and use redirects to send traffic from the other URLs to your preferred URL.<\/p>\n\n\n\n
You\u2019re merging two websites and want to make sure that links to outdated URLs are redirected to the correct pages.<\/p>\n\n\n\n
If you\u2019re using a platform like Blogger or Shopify, the platform may already have built-in redirect solutions. Try searching for help articles (for example, search for \u201cblogger redirects\u201d).<\/p>\n\n\n\n
While your users generally won\u2019t be able to tell the difference between the different types of redirects, Google Search uses redirects as a strong or weak signal that the redirect target should be canonical. Choosing a redirect depends on how long you expect the redirect will be in place and what page you want Google Search to show in search results:<\/p>\n\n\n\n
The following table explains the various ways you can use to set up permanent and temporary redirects, ordered by how likely Google is able to interpret correctly (for example, a server side redirect has the highest chance of being interpreted correctly by Google). Choose the redirect type that works for your situation and site:<\/p>\n\n\n\n
Setting up server side redirects requires access to the server configuration files (for example, the .htaccess file on Apache) or setting the redirect headers with server side scripts (for example, PHP). You can create both permanent and temporary redirects on the server side.<\/p>\n\n\n\n
If you need to change the URL of a page as it is shown in search engine results, we recommend that you use a permanent server side redirect whenever possible. This is the best way to ensure that Google Search and people are directed to the correct page. The 301 and 308 status codes mean that a page has permanently moved to a new location.<\/p>\n\n\n\n
If you just want to send users to a different page temporarily, use a temporary redirect. This will also ensure that Google keeps the old URL in its results for a longer time. For example, if a service your site offers is temporarily unavailable, you can set up a temporary redirect to send users to a page that explains what\u2019s happening, without compromising the original URL in search results.<\/p>\n\n\n\n
The implementation of server side redirects depends on your hosting and server environment, or the scripting language of your site\u2019s backend.<\/p>\n\n\n\n
To set up a permanent redirect with PHP, use the header() function. You must set the headers before sending anything to the screen:<\/p>\n\n\n\n
If you have access to your web server configuration files, you may be able to write the redirect rules yourself. Follow your web server\u2019s guides:<\/p>\n\n\n\n
Apache: Consult the Apache .htaccess Tutorial , the Apache URL Rewriting Guide , and the Apache mod_alias documentation . For example, you can use mod_alias to set up the simplest form of redirects:# Permanent redirect: Redirect permanent \u201c\/old\u201d \u201chttp:\/\/example.com\/new\u201d # Temporary redirect: Redirect temp \u201c\/two-old\u201d \u201chttp:\/\/example.com\/two-new\u201dFor more complex redirects, use mod_rewrite . For example:RewriteEngine on # redirect the service page to a new page with a permanent redirect RewriteRule \u201c^\/service$\u201d \u201c\/about\/service\u201d [R=301] # redirect the service page to a new page with a temporary redirect RewriteRule \u201c^\/service$\u201d \u201c\/about\/service\u201d [R]<\/p>\n\n\n\n
NGINX: Read about Creating NGINX Rewrite Rules on the NGINX blog. As with Apache, you have multiple choices to create redirects. For example:location = \/service { # for a permanent redirect return 301 $scheme:\/\/example.com\/about\/service # for a temporary redirect return 302 $scheme:\/\/example.com\/about\/service }For more complex redirects, use the rewrite directive:location = \/service { # for a permanent redirect rewrite service?name=$1 ^service\/offline\/([a-z]+)\/?$ permanent; # for a temporary redirect rewrite service?name=$1 ^service\/offline\/([a-z]+)\/?$ redirect; }<\/p>\n\n\n\n
For all other web servers, check with your server manager or hoster, or search for guides on your favorite search engine (for example, search for \u201cLiteSpeed redirects\u201d).<\/p>\n\n\n\n
If server side redirects aren\u2019t possible to implement on your platform, meta refresh redirects may be a viable alternative. Google differentiates between two kinds of meta refresh redirects:<\/p>\n\n\n\n
Instant meta refresh redirect : Triggers as soon as the page is loaded in a browser. Google Search interprets instant meta refresh redirects as permanent redirects.<\/p>\n\n\n\n
Delayed meta refresh redirect : Triggers only after an arbitrary number of seconds set by the site owner. Google Search interprets delayed meta refresh redirects as temporary redirects.<\/p>\n\n\n\n
Place the meta refresh redirect either in the head section of the HTML or in the HTTP header with server side code. For example, here\u2019s an instant meta refresh redirect in the head section of the HTML:<\/p>\n\n\n\n
Here\u2019s an example of the HTTP header equivalent, which you can inject with server side scripts:<\/p>\n\n\n\n
To create a delayed redirect, which is interpreted as a temporary redirect by Google, set the content attribute to the number of seconds that the redirect should be delayed:<\/p>\n\n\n\n
Google Search interprets and executes JavaScript using the Web Rendering Service once crawling of the URL has completed.Only use JavaScript redirects if you can\u2019t do server side or meta refresh redirects. While Google attempts to render every URL Googlebot crawled, rendering may fail for various reasons. This means that if you set a JavaScript redirect, Google might never see it if rendering of the content failed.<\/p>\n\n\n\n
To set up a JavaScript redirect, set the location property to the redirect target URL in a script block in the HTML head. For example:<\/p>\n\n\n\n
If you can\u2019t implement any of the traditional redirect methods, you should still make an effort to let your users know that the page or its content has moved. The simplest way to do this is to add a link pointing to the new page accompanied by a short explanation. For example:<\/p>\n\n\n\n
This helps users find your new site and Google may understand this as a crypto redirect.Don\u2019t rely on crypto redirects for letting search engines know that your content has moved unless you have no other choice. Contact your hosting provider for help with traditional redirects before resorting to crypto redirects.<\/p>\n\n\n\n
When you redirect a URL, Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical ; which one, depends on signals such as whether the redirect was temporary or permanent. The other URL becomes an alternate name of the canonical URL. Alternate names are different versions of a canonical URL that users might recognize and trust more. Alternate names may appear in search results when a user\u2019s query hints that they might trust the old URL more.<\/p>\n\n\n\n
For example, if you moved to a new domain name , it\u2019s very likely that Google will continue to occasionally show the old URLs in the results, even though the new URLs are already indexed. This is normal and as users get used to the new domain name, the alternate names will fade away without you doing anything.<\/p>\n\n\n\n
As a site owner, it is possible that at some point you\u2019ll want to move your site to a different URL or different infrastructure. This page covers the different scenarios of site moves and gives you tips about how to prepare, implement, and monitor the move.https:\/\/www.youtube.com\/embed\/bGPB-rtxt-I?origin=https%3A%2F%2Fdevelopers.google.com&video-id=bGPB-rtxt-I&enablejsapi=1&widgetid=3<\/p>\n\n\n\n
In this documentation, a site redesign is not considered a site move , even if it involves adding extra URLs. A redesign is changing the layout of existing pages, or adding pages of new content. A move is moving existing pages in one of the following ways:<\/p>\n\n\n\n
Site move without URL changes The underlying infrastructure serving the website is changed, but there are no visible changes to the URL. For example, if you move www.example.com to a different hosting provider while keeping www.example.com as the same root URL for your site.<\/p>\n\n\n\n
Site move with URL changes The page URLs change. For example: Protocol changes \u2014 http :\/\/www.example.com to https :\/\/www.example.com<\/p>\n\n\n\n
To change how your site serves mobile versus desktop users, see the mobile-friendly site design guide .<\/p>\n\n\n\n
Split your move into smaller steps, if that makes sense for your site. 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\u2019t 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\u2019s not necessarily representative of a whole site move when it comes to search. The more pages that you move, the more likely you\u2019ll encounter additional problems to solve. Careful planning can minimize problems.<\/p>\n\n\n\n
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\u2019s resources can be dedicated to Googlebot crawling your site.<\/p>\n\n\n\n
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\u2019s fine to move your site in sections.<\/p>\n\n\n\n
Ask questions 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\u2019t find an answer, you can ask a live question to one of our Google Search specialists during our SEO office hours .<\/p>\n\n\n\n
If it involves a URL change, you might consider an A\/B test or trial run. Plan for a few weeks to allow for crawling and indexing to pick up changes, plus time to monitor traffic.<\/p>\n\n\n\n
This guide shows how to minimize the impact on your Google Search performance when migrating your site\u2019s hosting infrastructure. For example, when switching hosting providers or moving to a content distribution network (CDN). This guide is only for migrations that don\u2019t affect the user-visible URL. Changing the URLs? If you\u2019re making visible URL changes, start with Site moves with URL changes .<\/p>\n\n\n\n
Review FAQs and basic information about site moves . Know what to expect, and how it might affect your users and rankings.<\/p>\n\n\n\n
Prepare the new hosting infrastructure . Upload your content to the new servers or configure your CDN and your origin servers, and test it.<\/p>\n\n\n\n
Start the site move . Change the DNS settings of your domain name to point to the new hosting infrastructure. This step is the actual site move step that starts the process of sending your traffic to the new infrastructure.<\/p>\n\n\n\n
Shut down . Shut down the old hosting infrastructure when you\u2019re confident that all users are receiving content correctly from the new infrastructure and no one is using the old infrastructure.<\/p>\n\n\n\n
First, upload a copy of your site to your new hosting provider. Once you do that, verify that it works as expected by thoroughly testing all aspects of how your users interact with your site. Here are a few suggestions:<\/p>\n\n\n\n
Open your new site in a web browser and review all elements of your site: webpages, images, forms, and downloads (such as PDF files).<\/p>\n\n\n\n
Create a testing environment , perhaps with IP-restricted access, through which you test all of the features before the website goes live.<\/p>\n\n\n\n
Allow for public testing with a temporary hostname for your new infrastructure (like beta.example.com) so you can test accessibility by browsers. A temporary hostname can help you test whether Googlebot can reach your site or not.<\/p>\n\n\n\n
If you don\u2019t already have a Search Console account, create a new account for your site to help you monitor Google access and traffic. If you created a temporary hostname for your new site, create an account for that hostname as well. Check that Googlebot can access your new infrastructure using the URL Inspection Tool in Search Console. Caution : Check your firewall configuration or denial of service (DoS) protection. Make sure it does not block Googlebot\u2019s ability to reach the DNS or the hosting provider\u2019s servers.<\/p>\n\n\n\n
You can help make your site move go faster if you lower your site DNS records\u2019 TTL value, which will allow the new settings to propagate to ISPs faster. DNS settings are usually cached by ISPs based on the specified Time to Live (TTL) setting . Consider lowering the TTL to a conservative low value (for example, a few hours) at least a week in advance of the site move to refresh DNS caches faster.<\/p>\n\n\n\n
If you\u2019re using the HTML file method to verify ownership of your site in Search Console, make sure you don\u2019t forget to include your current verification file in your new copy of the site.<\/p>\n\n\n\n
Likewise, if you include in your content management system\u2019s templates a meta tag or Google Analytics to verify ownership, ensure the new CMS copy includes these as well.<\/p>\n\n\n\n
Remove any temporary blocks to crawling . While building the new copy of a site, some site owners use a robots.txt file to disallow all crawling by Googlebot and other crawlers, or use noindex meta tags or HTTP headers to block indexing of content. Be sure to remove any such blocks from the new copy of the site when you\u2019re ready to start the move.<\/p>\n\n\n\n
Update the DNS settings . You start the site move by updating the DNS records to point to the new hosting provider. Check with your DNS provider for how to do that. Because the DNS cache setting is cached, the records takes some time to fully propagate to all users on the internet.<\/p>\n\n\n\n
Keep an eye on the server logs on both new and old servers. As DNS setting propagates and the site traffic moves, you\u2019ll notice a drop in traffic logged on the old servers and a corresponding increase in traffic on the new servers.<\/p>\n\n\n\n
Use different public DNS checking tools. Check that different ISPs around the world are updating to your new DNS settings correctly.<\/p>\n\n\n\n
Monitor crawling. Monitor the Index coverage graphs in Search Console. Let Googlebot decide. Rather than manually setting a maximum crawl rate in Search Console , keep the setting at Let Googlebot decide . This way, settings designed only for the old system won\u2019t interfere with the requirements of your new system.<\/p>\n\n\n\n
It\u2019s normal to see a temporary drop in Googlebot\u2019s crawl rate immediately after the launch, followed by a steady increase over the next few weeks, potentially to rates that may be higher than before the move.<\/p>\n\n\n\n
This fluctuation occurs because we determine crawl rate for a site based on many signals, and these signals change when your hosting changes. As long as Googlebot doesn\u2019t encounter any serious problems or slowdowns when accessing your new serving infrastructure, it will try to crawl your site as fast as necessary and possible.<\/p>\n\n\n\n
Check the server logs on the old provider and, once the traffic to the old provider reaches zero, you can shut down your old hosting infrastructure. This completes the site move.<\/p>\n\n\n\n
This article describes how to change the URLs of existing pages on your site with minimal impact on your Google Search results. Examples of this kind of site move include:<\/p>\n\n\n\n
Not changing the URLs? If you are making site changes without visible URL changes, start here instead .<\/p>\n\n\n\n
Review basic information about 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 .<\/p>\n\n\n\n
Start the site move by configuring the server to redirect from the old URLs to the new ones.<\/p>\n\n\n\n
Does Google recommend that you move everything together, or is it fine to move in sections? Moving in sections is fine.<\/p>\n\n\n\n
How can you test how many pages were indexed? 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.<\/p>\n\n\n\n
How long will it take for Google to recognize URL changes? There are no fixed crawl frequencies; it depends on the size of your site, and the speed of crawling that\u2019s possible. The move takes place on a per-URL basis.<\/p>\n\n\n\n
Do you lose credit for links when you redirect to new URLs? No, 301 or 302 redirects do not cause a loss in PageRank .<\/p>\n\n\n\n
Be sure to add the HTTPS property to Search Console. Search Console treats HTTP and HTTPS separately; data for these properties is not shared in Search Console. So if you have pages in both protocols, you must have a separate Search Console property for each one.<\/p>\n\n\n\n
As with all migrations, you may experience some ranking fluctuation during a migration. However, to avoid HTTPS-specific pitfalls, review the best practices information for HTTPS pages .<\/p>\n\n\n\n
HTTPS sites receive a small ranking boost, but don\u2019t expect a visible change. Google uses HTTPS as a positive ranking signal. This signal is one amongst many others, and currently carries less weight than high-quality site content; you should not expect a major SEO advantage for moving to HTTPS in the short term. In the longer term, Google may increase the strength of the HTTPS boost.<\/p>\n\n\n\n
Yes, that\u2019s okay. Start with a part, test it, then move more at your own pace.<\/p>\n\n\n\n
If you are migrating from HTTP to HTTPS in pieces, and you want to avoid early indexing of the staged URLs, we recommend using rel=canonical rather than redirects. If you use redirects, you won\u2019t be able to test the redirected pages.<\/p>\n\n\n\n
Verify HTTP and HTTPS separately in Search Console, and use the Index Coverage report to see which pages have been indexed.<\/p>\n\n\n\n
There are no fixed crawl frequencies; it depends on the size of your site and the speed of crawling that\u2019s possible. The move takes place on a per-URL basis.<\/p>\n\n\n\n
We recommend that you update your robots.txt file to point to the HTTPS version of your sitemap files. We also recommend listing only the HTTPS URLs in your sitemap.<\/p>\n\n\n\n
Keep in mind that if you\u2019re redirecting each URL on your site from HTTP to HTTPS, you will still have only one robots.txt file accessible to crawlers. For example, if http:\/\/example.com\/robots.txt redirects to https:\/\/example.com\/robots.txt , the contents of the HTTP version won\u2019t be visible to Google and other search engines.<\/p>\n\n\n\n
You can create a separate sitemap just for the updated section of your site. This will enable you to track indexing of the trial section more precisely. Be sure not to duplicate these URLs in any other sitemaps, though.<\/p>\n\n\n\n
List all the new HTTPS URLs in your sitemap, and remove the old HTTP URLs. If you prefer creating a new sitemap, list only the new HTTPS URLs in it.<\/p>\n\n\n\n
HSTS increases security, but adds complexity to your rollback strategy. See HTTPS best practices for more information.<\/p>\n\n\n\n
If you want to use a Google News sitemap for the new HTTPS section, you will have to contact the News team to let them know about the protocol change, and then in your HTTPS property in Search Console you can submit a new Google News sitemap as you migrate each section of your site to HTTPS.<\/p>\n\n\n\n
Google News Publisher Center handles the HTTP to HTTPS moves transparently. In general you don\u2019t have to do anything from Google News perspective, unless you\u2019re also making use of News sitemaps. In that case, contact the News team and let them know about the change. You can also let the team know about changing sections, for example in case you\u2019re moving to HTTPS, you can specify that you\u2019re moving http:\/\/example.com\/section to https:\/\/example.com\/section .<\/p>\n\n\n\n
The details of site preparation vary for each site move, but typically you\u2019ll do one or more of the following:<\/p>\n\n\n\n
Transfer images and downloads (such as PDF documents) that you currently host. These might already be getting traffic from Google Search or links, and it\u2019s useful to tell users and Googlebot about their new location.<\/p>\n\n\n\n
For a move to HTTPS , get and configure the required TLS certificates on your server.<\/p>\n\n\n\n
The robots.txt file for a site controls which areas Googlebot can crawl. Make sure the directives in the new site\u2019s robots.txt file correctly reflect the parts you want blocked from crawling.<\/p>\n\n\n\n
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 directives during development, prepare a list of URLs from which you\u2019ll remove the noindex directives when you start the site move.<\/p>\n\n\n\n
For content on the old site that will not be transferred to the new site, make sure those orphaned URLs correctly return an HTTP 404 or 410 error response code. You can return the error response code at the old URL in the configuration panel for your new site, or you can create a redirect for a new URL and have that return the HTTP error code. Avoid irrelevant redirects<\/p>\n\n\n\n
Don\u2019t redirect many old URLs to one irrelevant destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error . However, if you have consolidated content previously hosted on multiple pages to a new single page, it is acceptable to redirect the older URLs to that new, consolidated page.<\/p>\n\n\n\n
If you haven\u2019t already, verify that you own 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.<\/p>\n\n\n\n
Make sure your Search Console verification will continue to work after the site move. If you\u2019re using a different method of verification, keep in mind that verification tokens may be different when the URL changes.<\/p>\n\n\n\n
If you\u2019re using the HTML file method to verify ownership of your site in Search Console, make sure you don\u2019t forget to include your current verification file in your new copy of the site.<\/p>\n\n\n\n
Likewise, if you verify ownership with an include file that references meta tag or Google Analytics to verify ownership, ensure the new CMS copy includes these as well.<\/p>\n\n\n\n
If you had changed some of the configuration settings in Search Console for your old site, make sure the new site\u2019s settings are updated to reflect those changes as well. For example:<\/p>\n\n\n\n
URL parameters : If you\u2019ve configured URL parameters to control the crawling or indexing of your old URLs, make sure the settings are also applied to the new site if needed.<\/p>\n\n\n\n
Geotargeting : Your old site might have explicit geotargeting, such as a geotargetable domain or a country-coded top-level domain (such as .co.uk ). Apply the same setting to the new site if you want to continue targeting for the same region. However, if your site move is meant to help your business expand globally and you do not wish your site to be associated with any country or region, select Unlisted in the drop-down list of the Site Settings page.<\/p>\n\n\n\n
Crawl rate : We recommend not limiting Googlebot\u2019s crawl rate in Search Console for both old and new URLs. We advise you don\u2019t configure a crawl rate setting, either. Only do this if you know that your site cannot handle Googlebot\u2019s volume of crawling. If you have already limited Googlebot\u2019s crawl rate for your old site, consider removing it. Google has algorithms that automatically detect that a site move has been implemented and we alter Googlebot\u2019s crawling behavior so that our indexing quickly reflects the site move.<\/p>\n\n\n\n
Disavowed backlinks : If you\u2019ve 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.<\/p>\n\n\n\n
If your new site is for a recently purchased domain, you\u2019ll want to make sure it\u2019s clean of any outstanding issues from the previous owner. Check the following settings:<\/p>\n\n\n\n
Manual action for previous spam. For sites that don\u2019t comply with our spam policies , Google is willing to take manual action, such as demoting them or even removing them from our search results altogether. Check the Manual Actions page in Search Console to see if any manual actions have been applied to the new site, and address any problems listed there before filing a reconsideration request .<\/p>\n\n\n\n
Removed URLs . Make sure that there aren\u2019t any URL removals left over from the previous owner, especially a site-wide URL removal. Also, before submitting URL removal requests for your content, make sure that you understand when not to use the URL removals tool .<\/p>\n\n\n\n
During a site move, it\u2019s important 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.<\/p>\n\n\n\n
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 new site has sufficient capacity to handle the increased traffic from Google.<\/p>\n\n\n\n
If you used Data Highlighter to map your old pages, be sure to redo the mapping for your new site.<\/p>\n\n\n\n
As soon as your HTTPS pages are ready, update any app links intended to open your web pages in an app when displayed in Google Search results. Update these links to point to the new HTTPS URLs. Redirects won\u2019t work for these links; mobile browser clicks will open the page in the browser instead of the app unless you update your app link handling.<\/p>\n\n\n\n
It\u2019s important to map your old site\u2019s 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.<\/p>\n\n\n\n
It\u2019s important to map your old site\u2019s 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.<\/p>\n\n\n\n
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\u2019re changing your site\u2019s domain (for example, moving from example.com to example.net ).<\/p>\n\n\n\n
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\u2019s configuration, but here are some handy tips:<\/p>\n\n\n\n
Start with your important URLs . To find them: Look in your sitemaps because it\u2019s likely your most important URLs have been submitted in Search Console that way<\/p>\n\n\n\n
Check the Links to your site feature in Search Console for pages that have internal and external links<\/p>\n\n\n\n
Use your content management system, which can typically provide an easy way to get a listing of all URLs that host content.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Include images and videos \u2014Make 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Once you have your URL mapping defined, you\u2019ll want to do three things to get the pages ready for the move.<\/p>\n\n\n\n
Update annotations to point to the new URLs in the HTML or sitemaps entry for each page: Each destination URL should have a self-referencing rel=”canonical” tag.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
If the site you moved has a mobile counterpart, make sure you update the rel-alternate-media annotations to use the new URLs. Learn more in our smartphone websites guidelines .<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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 .<\/p>\n\n\n\n
A list of sites linking to your old URLs. You can find the links to your site in Search Console.<\/p>\n\n\n\n
Once you have a mapping and your new site is ready, the next step is to set up HTTP 301 redirects on your server from the old URLs to the new URLs as you indicated in your mapping.<\/p>\n\n\n\n
Use HTTP 301 redirects. Although Googlebot supports several kinds of redirects , we recommend that you use HTTP 301 redirects if possible.<\/p>\n\n\n\n
Avoid chaining redirects. While Googlebot can follow up to 10 hops in a \u201cchain\u201d of multiple redirects (for example, Page 1 > Page 2 > Page 3), we advise redirecting to the final destination. 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Decide how you will move your site \u2014 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Update your robots.txt files : On the old site , remove all robots.txt directives. This allows Googlebot to discover all redirects to the new site and update our index. Keep in mind that crawlers will not see the contents of the old robots.txt file once you enabled redirects.<\/p>\n\n\n\n
On the new site , make sure the robots.txt file allows all crawling. This includes crawling of images, CSS, JavaScript, and other page assets, apart from the URLs you are certain you do not want crawled.<\/p>\n\n\n\n
Configure the old website to redirect users and Googlebot to the new site based on the URL mapping.<\/p>\n\n\n\n
Submit a Change of Address in Search Console for the old site .If you\u2019re moving your site from HTTP to HTTPS, you don\u2019t need to use the Change of Address tool.<\/p>\n\n\n\n
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\u2019 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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 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.Note that the visibility of your content in web search may fluctuate temporarily during the move. This is normal and a site\u2019s rankings will settle down over time.<\/p>\n\n\n\n
Immediately after the site move is started, try to update as many incoming links as possible to improve the user experience and reduce your server load. These include:<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Once you\u2019ve 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
If you installed any web analytics software on your site, or if your CMS provides analytics, it\u2019s 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
This page covers how to ensure that testing variations in page content or page URLs has minimal impact on your Google Search performance. It does not give instructions on how to build or design tests, but you can find more resources about testing at the end of this page.<\/p>\n\n\n\n
Website testing is when you try out different versions of your website (or a part of your website) and collect data about how users react to each version.<\/p>\n\n\n\n
A\/B testing is where you test two (or more) variations of a change. For example, you may test different fonts on a button to see if you can increase button clicks.<\/p>\n\n\n\n
Multivariate testing is where you test more than one type of change at a time, looking for the impact of each change as well as potential synergies between the changes. For example, you might try several fonts for a button, but also try changing (and not changing) the font of the rest of the page at the same time. Is a new font easier to read and so should be used everywhere? Or is the benefit that the button font looks different to the rest of the page, helping it draw attention?<\/p>\n\n\n\n
You can use software to compare behavior with different variations of your pages (parts of a page, entire pages, or entire multi-page flows), and track which version is most effective with your users.<\/p>\n\n\n\n
You can run tests by creating multiple versions of a page, each with its own URL. When users try to access the original URL, you redirect some of them to each of the variation URLs and then compare users\u2019 behavior to see which page is most effective.<\/p>\n\n\n\n
You can also run tests without changing the URL by inserting variations dynamically on the page. You can use JavaScript to decide which variation to display.<\/p>\n\n\n\n
Depending on what types of content you\u2019re testing, it may not even matter much if Google crawls or indexes some of your content variations while you\u2019re testing. Small changes, such as the size, color, or placement of a button or image, or the text of your \u201ccall to action\u201d (\u201cAdd to cart\u201d vs. \u201cBuy now!\u201d), can have a surprising impact on users\u2019 interactions with your page, but often have little or no impact on that page\u2019s search result snippet or ranking.<\/p>\n\n\n\n
In addition, if we crawl your site often enough to detect and index your experiment, we\u2019ll probably index the eventual updates you make to your site fairly quickly after you\u2019ve concluded the experiment.<\/p>\n\n\n\n
Here is a list of best practices to avoid any bad effects on your Google Search behavior while testing site variations:<\/p>\n\n\n\n
Don\u2019t show one set of URLs to Googlebot, and a different set to humans. This is called Cloaking , and is against our spam policies , whether you\u2019re running a test or not. Remember that infringing our spam policies can get your site demoted or removed from Google search results\u2014probably not the desired outcome of your test.<\/p>\n\n\n\n
Cloaking counts whether you do it by server logic or by robots.txt, or any other method. Instead, use links or redirects as described next.<\/p>\n\n\n\n
If you\u2019re using cookies to control the test, keep in mind that Googlebot generally doesn\u2019t support cookies. This means it will only see the content version that\u2019s accessible to users with browsers that don\u2019t accept cookies.<\/p>\n\n\n\n
If you\u2019re running a test with multiple URLs, you can use the rel=”canonical” link attribute on all of your alternate URLs to indicate that the original URL is the preferred version. We recommend using rel=”canonical” rather than a noindex meta tag because it more closely matches your intent in this situation. For instance, if you are testing variations of your home page, you don\u2019t want search engines not to index your homepage; you just want them to understand that all the test URLs are close duplicates or variations on the original URL and should be grouped together, with the original URL as the canonical. Using noindex rather than rel=”canonical” in such a situation can sometimes have unexpected bad effects.<\/p>\n\n\n\n
If you\u2019re running a test that redirects users from the original URL to a variation URL, use a 302 (temporary) redirect , not a 301 (permanent) redirect. This tells search engines that this redirect is temporary\u2014it will only be in place as long as you\u2019re running the experiment \u2014 and that they should keep the original URL in their index rather than replacing it with the target of the redirect (the test page). JavaScript-based redirects are also fine.<\/p>\n\n\n\n
The amount of time required for a reliable test will vary depending on factors like your conversion rates, and how much traffic your website gets; a good testing tool tells you when you\u2019ve gathered enough data to draw a reliable conclusion. Once you\u2019ve concluded the test, update your site with the desired content variation(s) and remove all elements of the test as soon as possible, such as alternate URLs or testing scripts and markup. If we discover a site running an experiment for an unnecessarily long time, we may interpret this as an attempt to deceive search engines and take action accordingly. This is especially true if you\u2019re serving one content variant to a large percentage of your users.<\/p>\n\n\n\n
If you\u2019re unable to fulfill orders or many of your products out of stock, you may be considering temporarily closing your online business. If the situation is temporary, meaning you expect to be able to sell products in the coming weeks or months, we recommend that you take action that preserves as much of your site\u2019s standing in Search as possible. This guide explains how you can safely pause your online business.<\/p>\n\n\n\n
If your situation is temporary and you plan to reopen your online business, we recommend that you keep your site online and limit the functionality. This is the recommended approach since it minimizes any negative effects on your site\u2019s presence in Search. People can still find your products, read reviews, or add wishlists so they can purchase at a later time. We recommend doing the following:<\/p>\n\n\n\n
Disable the cart functionality : Disabling the cart functionality is the simplest approach, and doesn\u2019t change anything for your site\u2019s visibility in Search.<\/p>\n\n\n\n
Display a banner or popup : A banner or popup div on all pages including the landing page quickly makes the status clear to users. Mention any known and unusual delays, shipping times, pick-up or delivery options, so that users continue with the right expectations. To prevent the content in the banner or popup from being shown in a snippet in Search results, use the data-nosnippet HTML attribute . Make sure to follow our guidelines on popups and banners .<\/p>\n\n\n\n
Update your structured data : If your site uses structured data (for example, Product , Book , Event ), make sure to adjust it appropriately (reflecting the current product availability, or changing events to cancelled). If your business has a physical storefront, update Local Business structured data to reflect current opening hours.<\/p>\n\n\n\n
Check your Merchant Center feed : If you use Merchant Center, follow the best practices for the availability attribute .<\/p>\n\n\n\n
Tell Google about your updates : To ask Google to recrawl a limited number of pages (for example, the homepage), use Search Console . For a larger number of pages (for example, all of your product pages), use sitemaps .<\/p>\n\n\n\n
Warning : Google\u2019s systems are designed to be robust and to help websites recover from temporary issues. However, removing a site completely from Google\u2019s index is a significant change that can take quite some time to recover from. There\u2019s no fixed time for a recovery from a complete removal, and there\u2019s no mechanism to speed that up. This is why we strongly recommend limiting functionality instead of removing the site from Search.<\/p>\n\n\n\n
You may decide to disable the whole website. This is an extreme measure that should only be taken for a very short period of time (a few days at most), as it will otherwise have significant effects on the website in Search, even when implemented properly.<\/p>\n\n\n\n
Your customers won\u2019t know what\u2019s happening with your business if they can\u2019t find your business online at all.<\/p>\n\n\n\n
Your customers can\u2019t find or read first-hand information about your business and its example, reviews, specs, repair guides, or manuals won\u2019t be findable. Third-party information may not be as correct or comprehensive as what you can provide. This often also affects future purchase decisions.<\/p>\n\n\n\n
Search Console verification will fail, and you will lose all access to information about your business in Search. Aggregate reports in Search Console will lose data as pages are dropped from the index.<\/p>\n\n\n\n
Ramping back up after a prolonged period of time will be significantly harder if your website needs to be reindexed first. Additionally, it\u2019s uncertain how long this would take, and whether the site would appear similarly in Search afterwards.<\/p>\n\n\n\n
If you decide that you need to do this (again, not recommended ), here are some options:<\/p>\n\n\n\n
If you need to urgently disable the site for 1-2 days, then return an informational error page with a 503 HTTP response status code instead of all content. Make sure to follow the best practices for disabling a site .<\/p>\n\n\n\n
If you need to disable the site for a longer time, then provide an indexable homepage as a placeholder for users to find in Search by using the 200 HTTP status code.<\/p>\n\n\n\n
If you quickly need to hide your site in Search while you consider the options, you can temporarily remove a website from Search .<\/p>\n\n\n\n
Warning : Keep in mind that it\u2019s not possible for Google\u2019s systems to refresh titles, descriptions, metadata, or structured data included on a website if a page returns a 503 HTTP response status code.<\/p>\n\n\n\n
While we don\u2019t recommend disabling your site, here are some best practices if you decide to do this:<\/p>\n\n\n\n
Continue to allow crawling through the robots.txt file. Don\u2019t return a 503 HTTP response status code for the robots.txt file because this blocks all crawling .<\/p>\n\n\n\n
Confirm a 503 HTTP response status code locally by using curl or a similar tool. For example:curl -I -X GET \u201chttps:\/\/www.example.com\/\u201d HTTP\/1.1 503 Service Unavailable Mime-Version: 1.0 Content-Type: text\/html (\u2026)<\/p>\n\n\n\n
To minimize the server-side and client-side load of a 503 error page, follow these best practices: Use the retry-after HTTP header with a best effort date or duration.<\/p>\n\n\n\n
Give your users clear guidance on future steps within the content of the error page. This could include: Links to more information<\/p>\n\n\n\n
The date when you expect the website to be online again, or when the information will be updated<\/p>\n\n\n\n
Don\u2019t disallow all crawling in the robots.txt file. Returning a valid robots.txt file that disallows all crawling may remove the website\u2019s content, and potentially its URLs, from Google Search.<\/p>\n\n\n\n
Don\u2019t block the website by returning 403 , 404 , 410 HTTP status codes, or with a noindex robots meta tag or x-robots-tag HTTP header. This will remove the website\u2019s URLs from Google Search.<\/p>\n\n\n\n
Don\u2019t use the temporary website removal tool in Search Console for closures. Doing so will make it impossible for users to find your website so that they can learn its status. Also, potential resellers or affiliates of your business\u2019s products may continue to be shown in Search.<\/p>\n\n\n\n
What if I only close the site for a few weeks? What if I want to exclude all non-essential products? Can I ask Google to crawl less while my site is temporarily closed? How do I get a page indexed or updated quickly? What if I block a specific region from accessing my site?<\/p>\n\n\n","protected":false},"excerpt":{"rendered":"
Redirecting URLs is the practice of resolving an existing URL to a different one, effectively telling your visitors and Google Search that a page has a new<\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-31944","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/alienroad.com\/wp-json\/wp\/v2\/posts\/31944","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alienroad.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/alienroad.com\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/alienroad.com\/wp-json\/wp\/v2\/comments?post=31944"}],"version-history":[{"count":1,"href":"https:\/\/alienroad.com\/wp-json\/wp\/v2\/posts\/31944\/revisions"}],"predecessor-version":[{"id":32187,"href":"https:\/\/alienroad.com\/wp-json\/wp\/v2\/posts\/31944\/revisions\/32187"}],"wp:attachment":[{"href":"https:\/\/alienroad.com\/wp-json\/wp\/v2\/media?parent=31944"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alienroad.com\/wp-json\/wp\/v2\/categories?post=31944"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alienroad.com\/wp-json\/wp\/v2\/tags?post=31944"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}