Site Migrations and URL Changes

A site migration changes the addresses of existing pages: HTTP to HTTPS, a new domain or subdomain, merging sites, changing paths. Google presents it as a process that can be done with little loss if you prepare. The guide's main ideas: change one thing at a time, prepare the mapping of old to new addresses, turn on server-side permanent redirects, watch both sites and be patient. Below are the stages from the documentation and, separately, what in this lesson is the author's practice rather than a Google rule.

The basis is Google's guide to moving a site with URL changes and the separate guide to changing hosting when addresses stay the same.

Which case is it

• Addresses change (HTTP to HTTPS, a new domain, merged domains, new paths): you need the guide to moving a site with URL changes;
• Addresses stay, hosting changes or a CDN is added: a separate guide. The move starts by switching DNS, and the old infrastructure is shut down when you are confident all users, including Googlebot, get content from the new one. The test site is kept out of the index with a noindex rule.

Principles: change one thing at a time

• One change at a time. If you want to change the domain, the management system and the layout, do them one after the other: the domain first, then the layout. The most dangerous option, a new design, new CMS, new URLs and a content cleanup in one release, directly contradicts this advice;
• A time of low traffic. If possible pick a dip, to affect fewer people and give the server more resources for Googlebot;
• All at once or in parts. Small and medium sites are advised to move everything at once: it helps users and speeds up recognition of the move. Large sites can move section by section; for a trial use a section that changes less often;
• Patience. For a medium-sized site it takes a few weeks or more for Google to gradually start showing the new URLs instead of the old ones, for large ones longer. The move happens per URL and is complete once Googlebot has visited every address of the old and new site at least once. There are no fixed crawl frequencies.

Preparing the new site

1. The list of old URLs. Start with the important ones: sitemaps, the most visited addresses from logs or analytics, pages with links from the Search Console report, the list from the CMS. Add the URLs of images, videos, JavaScript and CSS: they are moved like everything else;
2. The mapping of old to new. For each old URL decide where it goes. For a domain change a rule for the whole domain may be enough;
3. Set up the new system. Preferably the same CMS the old site used; transfer images and downloads. See the lesson on choosing a CMS;
4. robots.txt and noindex. Many block the site during development. Prepare in advance what the file should look like when the move starts and a list of pages from which noindex must be removed. See the lesson on robots.txt and meta robots;
5. Removed content. Addresses you do not move must return a 404 or 410 on the new site;
6. Annotations on the new site. Each new URL gets a self-referencing canonical; if you have hreflang update it to the new addresses; replace internal links with new ones. See the canonical tag;
7. Search Console. Verify both sites, all variants (www and non-www, HTTPS and HTTP). Make sure the verification method will keep working on the new site; review settings of the old site, such as a disavow file;
8. Server capacity. After a move Google temporarily crawls the new site more heavily: crawls of the old addresses with redirects are added to the usual ones. Make sure the new one can cope.

Save two things for the final: a sitemap with the new addresses from the mapping and a list of sites linking to the old addresses.

Redirects

Use server-side permanent redirects (301 or 308); client-side only if there is no alternative. Avoid chains: Googlebot follows up to 10 hops, but redirect straight to the final destination; if impossible, ideally no more than 3 and fewer than 5. And do not send many old addresses to one irrelevant one, such as the home page: it may be treated as a soft 404. The exception is consolidating several pages into one. More in the lesson on redirects. The good news: 301 and other permanent redirects don't cause a loss in PageRank.

Launch

1. Turn on the redirects.
2. Check that canonical on the new site points to the new addresses and temporary noindex is removed.
3. Test the redirects: URL inspection for single addresses, scripts or the redirect checker for many.
4. If the domain or subdomain changes, submit a Change of Address in Search Console. For HTTP to HTTPS, www to non-www and moving paths within a domain it is not needed. For a domain change submit it for all verified variants of the old one.
5. Keep redirects as long as possible, generally at least 1 year.
6. Submit the new sitemap; the old one can be removed. See the lesson on XML sitemaps.
7. Update links straight away: internal, external (ask the owners of the sites on your list), social profiles, ad campaigns.

Monitoring

• Sitemaps. Submit both, old and new. At first the new one has zero indexed pages and the old one many; over time it mirrors. Warnings about redirects in the old sitemap are normal and can be ignored. A sitemap monitor helps watch this;
• Indexing and queries. The indexing report will show a fall on the old site and a rise on the new; the queries report will start showing addresses of the new site. Watch for unexpected crawl errors, such as "not found", and for addresses that mistakenly lead to nonexistent ones. For bulk status checks use the URL audit; for 404s, organic 404s;
• Logs and analytics. Look at Googlebot crawling, addresses with unexpected errors and normal traffic. On the old site traffic should fall, on the new one rise.

Common mistakes per the documentation

• noindex or robots.txt blocks left over that were only needed for the migration. If there is no robots.txt it must return a 404;
• Incorrect redirects: to nonexistent addresses on the new site;
• old canonical and hreflang pointing to old addresses;
• forgotten images, files and resources.

The author's practice: content parity and the first 72 hours

What follows is not Google requirements but working habits. Content parity: if after a redesign a page lost its tables, FAQ or important headings, it answers the query worse even though the address and redirect are right. Compare the main meaning and blocks, and check the mobile version separately: Google mostly indexes the mobile version of content. The first 72 hours: make sure noindex is lifted on the live site; run batches of old addresses; check that new addresses return 200 with a canonical to themselves; that the sitemap holds only final addresses; that internal links do not lead through redirects. You can crawl the site with the crawler. The documentation gives its own set of checks, above.

Checklist

1. One thing changes at a time; a time of low traffic is chosen.
2. There is a list of old URLs including images and resources, and a mapping to the new ones.
3. The new site has self-referencing canonicals, updated hreflang and internal links.
4. Redirects are server-side permanent, with no chains and no mass sending to the home page.
5. Everything that blocked indexing during development is removed.
6. A Change of Address is submitted if the domain or subdomain changes.
7. The new sitemap is submitted; redirects are kept for at least a year.
8. Both sites are being monitored.

Mistakes

• Changing everything in one release.
• Submitting a Change of Address for a move to HTTPS.
• Leaving noindex and blocks from the test site.
• Removing redirects after a couple of months.
• Considering the move complete on launch day.

What comes next

The rules of addresses, on which any move is built, are in the lessons on URL structure and domains and subdomains.