Redesigning or moving a website: the steps Google sets out, in its order

Google's documentation sorts a move by what changes. Where the addresses (URLs) of pages change, it is a site move with URL changes: from HTTP to HTTPS, to a new domain name, or to new paths, such as Google's example of example.com/page.php?id=1 becoming example.com/widget. Where only the hosting changes and every address stays the same, Google has a separate guide.

A new design that keeps every address changes no URLs, so there is nothing to redirect, though the new pages still have to be open to Google: why a website is not on Google goes through the checks. If the redesign also moves the site to another platform, what Wix, Squarespace and WordPress let you take with you decides how much of it comes across, and what a website costs in Ireland puts published prices for a rebuild side by side.

Among Google's general advice is to change one thing at a time. Its example is a business that wants a new domain, a new content management system and a new layout: do them one after the other, moving to the new domain first and changing the layout after.

The first item in the overview of Google's site move guide is to know what to expect. In its words: "With any significant change to a site, you may experience ranking fluctuations while Google recrawls and reindexes your site."

Its general rule is that for a medium-sized site it can take a few weeks or more for Google to start showing the new addresses in place of the old ones, and longer for a larger site, with the speed depending largely on the number of addresses and the speed of the server. The move happens one address at a time: Google says Googlebot has to visit every address on the old and the new site at least once before the move is complete.

On visibility during the move, Google writes: "Note that the visibility of your content in Search may fluctuate temporarily during the move. This is normal and a site's rankings will settle down over time." Its Change of Address help adds a warning for a redesign done at the same time: "If you combine a site move with a redesign of the site's content and URL structure in the new location, you will probably see some traffic loss as Google might need to relearn and reassess the individual pages."

After a change of domain, Google may also go on showing the old addresses now and then, as alternate names for the new ones. Its redirects guide calls this normal, and says the old names fade as people get used to the new domain.

A move from HTTP to HTTPS needs a TLS certificate on the new server first; SSL certificates covers how a site gets one free. Google lists the rest of what to have ready before the switch:

Google suggests starting with the important addresses, and gives three places to find them: your sitemaps, since the most important are likely to have been submitted that way; your server logs or analytics, for the pages with the most traffic; and Search Console's report of links to your site, for pages that other sites and your own pages link to. A content management system can usually list every address that holds content, and server logs show any address visited recently.

Include the files as well as the pages: images, videos, PDFs and other downloads, and the JavaScript and CSS files. Google says embedded content has to move in the same way as everything else.

Decide where each old address will redirect. Google warns against sending many old addresses to one unrelated page, such as the new home page, which can confuse users and may be treated as a soft 404 error. Where several old pages have been combined into one new page, redirecting them to that page is fine. For a change of domain alone, Google says a wildcard redirect on the server may make a full list unnecessary.

With the map made, Google asks for the new site to be updated to match:

Google recommends permanent server-side redirects, HTTP 301 or 308, from each old address to its new one. Platforms such as Shopify may have redirects built in, and Google suggests searching the platform's help for them. Where a server-side redirect is not possible, Google reads an instant meta refresh as permanent. A JavaScript redirect is the last resort, because Google might never see it if rendering the page fails.

Redirect straight to the final address. Googlebot can follow up to 10 hops in a chain of redirects, but Google advises keeping a chain, where there has to be one, ideally to no more than 3 and fewer than 5, since each hop adds delay for visitors.

For a small or medium site, Google recommends moving every address at the same time, which it says helps its systems detect the move and update the index faster. Once the redirects are live, check that the canonical links on the new site use the new addresses, remove any noindex rules added during the build, and test the redirects: Search Console's URL Inspection tool checks one address at a time.

Only a move from one domain or subdomain to another needs Search Console's Change of Address tool, used after the site has moved and the redirects are in place. Before using it, Google asks for a 301 redirect from the old home page to the new one, and recommends 301s for the old site's canonical pages too. Its requirements:

Keep the redirects for as long as possible: generally at least a year, Google's site move guide says, so that it can pass every signal to the new addresses, and from a visitor's point of view, consider keeping them indefinitely.

Submit the sitemap of the new addresses in Search Console, which Google says helps it learn about them. Google also says submitting a sitemap is a hint, and does not guarantee that the sitemap will be downloaded or used for crawling.

Then update the links you can: your own internal links, the links on your social media profiles and in your ad campaigns, and, where you can ask, the links on other sites, starting with those that send the most visits. Your Google Business Profile's link to the site is a profile link too.

Google's monitoring advice is to have a sitemap of the old addresses and one of the new in Search Console. At first the new sitemap shows no pages indexed and the old one many; over time the old count falls to zero as the new one rises. Search Console may warn that the old sitemap's addresses redirect, which Google says is normal and can be ignored.

The indexing report should show the old site's indexed pages falling and the new site's rising; check it for unexpected errors. Google's guide calls it the Index Coverage report, and its link goes to the Search Console page that Google's help calls the Page indexing report. As more of the new pages are indexed, the search queries reports start showing the new addresses with impressions and clicks.

Outside Search Console, Google suggests watching the server's access and error logs, for Googlebot's crawling and for addresses that unexpectedly return errors, and your analytics, where traffic should fall on the old site and rise on the new.

Google's troubleshooting section lists the mistakes that can stop a new site being indexed completely: