How to migrate a website without losing search traffic

Most migrations start as a design or technology project, and search is added later. By then the decisions that set the risk have often been made: the new platform, the URL pattern, the domain, the launch date. Start by writing down everything that will be different on launch day, because each change is a separate thing Google has to process.

List every change, including the ones nobody called a migration

Go through the list below with whoever is running the build. Ask about each item directly, because some changes arrive as side effects. A new CMS usually brings its own URL patterns. A new design often drops copy from category and service pages. A move to a hosted platform changes hosting and the CDN without anyone deciding to.

It helps to see a site as layers. A change high in the stack, such as the domain, gives every URL below it a new address. A change lower down, such as the templates, leaves the addresses alone but changes what Google finds at them. Mark which layers your project touches before you talk about dates.

Take out anything that can wait

The safest sequence is one change at a time, each planned after the last.¹ Combining a move with a redesign of the content and URL structure will probably bring some traffic loss while Google relearns and reassesses the pages, and Google's own Change of Address help page says as much.² Few businesses can do everything in sequence, but most can take one or two things out of launch day. The ones I would move first are a content rewrite (do it after the move has settled), a hosting change that can happen weeks before (a move where URLs stay the same follows a separate, lower-risk process³), and an HTTP to HTTPS switch that should have happened years ago anyway.

Size also affects how you launch. Small and medium sites are best moved all at once, while large sites can move one section at a time.¹ Moving a section first lets you see how Google handles your redirects before the rest of the site depends on them, at the cost of running two structures side by side for a while.

Score the risk

Tick everything that changes in your migration in the tool below. It builds the checklist each change adds, grouped by phase, and gives an overall risk level. The kitchen company ticks domain, URL structure, platform, design, content being cut, hosting and merging two sites, which puts it at the top level. That is a fair reading: it is the riskiest kind of move most businesses make.

Pick the launch window

Time the move for a period of lower traffic if you can.¹ Use your own data: export organic sessions and conversions by week for the last two years and find the quietest stretch. Then work back from it. A launch date should have the full preparation time in front of it, and at least two working weeks after it with no other releases, no sales campaign and the developers who built the redirects still on the project. I would avoid launching on a Friday or before a holiday, because the first 48 hours are when a blocking fault does most damage and is cheapest to fix.

In the running example, say the kitchen company's enquiries peak from January to March and dip in late summer. The design agency proposed a launch in early February. The team moves it to the first week of September, which also gives two extra months for the merge.

The timeline below shows how the stages fit around a launch for a project like the kitchen company's, with about 12 weeks of preparation. A smaller project compresses the first four stages. The 90 days after launch compress much less, because they depend on how quickly Google recrawls the site.

Make search a launch gate

Agree in writing, before the build starts, that the site does not go live until the search checks pass, and name the person who signs them off. Without that agreement, a launch date set by a marketing campaign or a contract end date tends to win. The checks are concrete, which makes them easy to agree to now and hard to argue with later.

Two documents make the agreement easier to reach: a short briefing for the people who approve the budget and the date, and the go and no-go checklist itself. An AI assistant can draft both from your details. The prompts below are written to stop it inventing figures or rules.

The benchmark serves two jobs. It is the record you compare against after launch, so you can tell normal movement from damage. It is also the raw material for the redirect map and the parity check. Both jobs fail if the data is gathered after the old site has started to change, and much of it cannot be gathered at all once the old site is switched off.

Set up the folder first

Make one shared folder for the migration with a dated subfolder for each export, for example 2026-06-15-benchmark. Every file in this stage goes there, unedited, with a short readme saying what each file is and how it was exported. Nobody overwrites anything. You will take a second snapshot in launch week, and you need both.

Crawl the old site and save everything

Run a full crawl of each old site with JavaScript rendering on, and save the crawl file itself as well as the exports. Export, for every URL: status code, title, meta description, H1, canonical, meta robots and X-Robots-Tag, hreflang, word count, inlinks, outlinks and structured data types. If your crawler can store the HTML of each page, turn that on for the templates that matter. When someone asks in October what the old service page said, the answer is in that file.

Set up the crawler

Two desktop crawlers are common for this work, and either will do. Screaming Frog's SEO Spider is free for up to 500 URLs. JavaScript rendering, saving and opening crawls, crawl configuration and the Search Console and analytics integrations need a paid licence.⁶ Sitebulb is the other common choice. Any crawler works if it can render JavaScript, crawl a list of URLs, log in to a protected site and save the crawl.

• In Screaming Frog, open Configuration > Spider > Rendering and choose JavaScript, which renders each page in headless Chrome.⁷
• Under Configuration > Spider > Extraction, tick Store HTML and Store rendered HTML, so the raw and rendered source of every page is saved to disk.⁷
• Leave Configuration > Robots.txt on Respect robots.txt for the benchmark, which is the default, so the crawl sees what a search engine is allowed to see.⁷ Run a second crawl with Ignore robots.txt only if you need the blocked URLs in the inventory as well.
• Screaming Frog saves crawls automatically in its default database storage mode, and File > Crawls reopens them.⁸ Keep a copy of the crawl in the benchmark folder too.
• In Sitebulb, the site crawl and a URL list are both crawl sources in the audit settings, so you can add your sitemap URLs as an uploaded .csv or .txt list alongside the crawl.⁹

Collect old URLs from every source

No single source has every URL. Good starting points are your sitemaps, your server logs or analytics for the URLs with the most traffic, and your CMS.¹ Include images and downloads such as PDFs, because they can have search traffic or links of their own.¹ The website migrations guide sets out what each source adds and misses. Here is what to export from each, as files.

Use a long date range for Search Console and analytics. Sixteen months of data lets you tell a real drop from one that happens every year.¹³ For a seasonal business that context is the only way to read the post-launch numbers fairly.

In Search Console, open the Performance report for search results, set the date filter to the last 16 months, and export the page data. In Google Analytics 4, select Reports, then Engagement > Landing page, and add the secondary dimension Session default channel group so you can separate organic search from other traffic. If the report is missing from the menu, an editor can add it back to the navigation.¹⁴ Export the results with key events (conversions) included, because a page that brings in few visits can still produce most of the enquiries.

Build the protected list

From the exports, build a short list of the URLs that matter most. Take the top pages by organic clicks, the top pages by conversions or revenue, and every page with more than a handful of linking domains, and combine them. Keep it short enough that a person can check every URL on it by hand. Every URL on the protected list gets hand-checked at every stage that follows: mapped by a person, compared for content on staging, tested by hand on launch day and reported on individually afterwards.

In the running example, say the kitchen site's protected list comes to 54 URLs: the homepage, 9 service pages, 12 area pages, 18 blog posts that bring in most of the organic clicks, 8 project case studies and 6 brochure PDFs that local sites link to. The bathroom site adds 21 more. The PDFs would not have appeared in a crawl at all, because the current design no longer links to them. They came from the backlink export.

Set up Search Console for the new site now

Verify both the old and new sites in Search Console, including all their variants, and review any settings you made for the old site.¹ Do it in this stage. A Domain property covers every subdomain and protocol, and it can only be verified with a DNS record.¹⁵ Verifying the new domain weeks before launch means its property is ready on launch day, and that whoever controls DNS has already been found. The Crawl Stats report is only available for root-level properties, which is another reason to use Domain properties or root URL-prefix properties.¹²

This stage produces two spreadsheets. The redirect map says what every old URL should do on launch day. The parity check says whether each important page on the new site still has what the old page had. In my view these two sheets prevent more avoidable losses than anything else in the project.

The redirect map

The method is set out step by step in how to build a redirect map: exact matches from the CMS first, pattern rules for whole templates second, and a manual pass for every URL with traffic or links. Here are the rules the map has to follow, and the decisions you will have to make on the way.

• One to one wherever an equivalent exists. Decide where each old URL should redirect to.¹ A service page goes to the same service page, a case study to the same case study, a PDF to the same PDF on the new site.
• The closest equivalent where the page has changed. Where several old pages have been merged into one, redirecting all of them to the merged page is fine.¹ A discontinued service can go to the parent page that covers what replaced it.
• Never mass-redirect to the homepage. Redirecting many old URLs to one irrelevant destination such as the homepage can confuse users, and Google may treat it as a soft 404.¹ If there is no equivalent, return a 404 or 410.¹ In the HTTP standard, a 410 means the page is gone and that this is likely to be permanent.¹⁶
• Permanent, server-side redirects: a 301 or a 308.¹ The HTTP standard defines both as a move to a new permanent URI. The difference is that a browser may turn a POST into a GET after a 301 but must not after a 308,¹⁶ which matters for forms and not for ordinary pages.¹⁷ Google's indexing pipeline uses a 301 or 308 as a signal that the target should be canonical, and does not treat a 302 or 307 that way.¹⁸ Bing's guidelines ask for 301s for permanent URL changes and keep 302s for changes of less than two days.¹⁹
• No chains. Googlebot can follow up to 10 hops, but each old URL should redirect straight to its final destination.¹ Add every existing redirect from the old site to the map and point it at the final new URL.

Use the template below as the starting sheet. The example rows are invented for the kitchen company and show the four cases you will meet most: an exact match, a pattern match, a manual match for a file with links, and a retired page. Delete them before you start.

Use an assistant for first-draft matches

For the manual pass, an AI assistant can suggest matches between two lists of URLs much faster than you can by eye. Treat its output as suggestions for a person to approve. Work in batches of a few hundred rows, include page titles as well as URLs, and check that the number of rows that comes back equals the number you sent.

Decisions that need a person

Merges and rebrands produce overlapping pages. In the running example both old sites have a Leeds showroom page, a finance page and an about page. For each pair, compare clicks, linking domains and copy, keep the stronger page as the base for the new one, bring across anything useful from the weaker one, and redirect both old URLs to the new page. Write the decision in the Notes column.

Blog archives are the other common argument. Cutting old posts with no clicks and no links is reasonable, and they can return 410. Posts with links but no successor are a judgement: if the subject still matters to the business, keep the post. Before cutting a group of posts, check the conversions column as well as clicks. A post that brings in few visits can still be the one that people read before they ask for a quote.

Check the map for chains and loops

Before the map goes to the developer, check it in the spreadsheet. Normalise trailing slashes and hostnames in both columns first, so the comparisons work. With Old URL in column A and New URL in column B, put =IF(COUNTIF(A:A,B2)>0,"Chain","") in a new column and fill it down. A flagged row points at a URL that itself redirects, so change its New URL to that row's destination. Then =IF(A2=B2,"Loop",IF(COUNTIFS(A:A,B2,B:B,A2)>0,"Loop","")) flags a row that points at itself, or two rows that point at each other. Fix every flagged row and run both formulas again until nothing is flagged.

Decide where the redirects will live

The redirects have to run on whatever answers requests for the old URLs. For a domain change, the old domain must keep pointing at something that returns them, for at least a year. These are the common options, with short examples using the kitchen company's URLs. Each provider's documentation has the full syntax, and the platform, server or CDN you are on will usually decide it for you.

• Apache. Redirect and RedirectMatch come from mod_alias, and with no status given Redirect sends a temporary 302, so always state one: Redirect 301 /services/shaker-kitchens.php https://www.example.com/kitchens/shaker/. A pattern rule reads RedirectMatch 301 ^/blog/[0-9]+/[0-9]+/(.+)$ https://www.example.com/guides/$1, and a retired page can return 410 with Redirect gone /offers/spring-sale-2023/. Apache applies these in the order they appear and the first match wins, so put one-to-one rules above patterns.²⁰
• nginx. One URL: location = /services/shaker-kitchens.php { return 301 https://www.example.com/kitchens/shaker/; }. A pattern: rewrite ^/blog/[0-9]+/[0-9]+/(.+)$ https://www.example.com/guides/$1 permanent;, where the permanent flag returns a 301.²¹ For hundreds of one-to-one rows, a map block can hold the list, loaded from a separate file with include, which keeps the server block short.²²
• Cloudflare Bulk Redirects. A large list of static redirects defined at account level, which can apply across the domains in the account, so it suits a domain change where the old domain stays on Cloudflare. It does not support regular expressions.²³ The CSV columns are source URL, target URL and status code, then four optional settings, so a row reads www.example.net/services/shaker-kitchens.php,https://www.example.com/kitchens/shaker/,301,,,,.²⁴ The status can be 301, 302, 307 or 308, and defaults to 301.²⁵ In the dashboard, create a Bulk Redirect List, import the CSV, then create a Bulk Redirect Rule that uses the list and select Save and Deploy. A source URL cannot include a query string.²⁶
• Shopify. In the admin, go to Content > Menus > URL redirects, select Import, add the CSV with Redirect from and Redirect to columns, and import it. Shopify only redirects from broken URLs, so a page that still loads at the old path will not redirect, and a store can hold up to 100,000 redirects, or 20,000,000 on Plus.²⁷ The paths it cannot redirect are covered in migrating to or from Shopify.
• WordPress. The Redirection plugin is a common choice. It manages redirects, logs 404 errors, supports regular expressions, imports and exports CSV, and can create a redirect when a post's permalink changes.²⁸ Its import takes source and target, with optional regex and HTTP code columns, for example /old-url/.*,/new-url,1,301.²⁹ Several SEO plugins include redirect managers too. Whichever you use, check the status code the server sends.

If the new site is being built with an AI coding agent such as Claude Code or Cursor, the free Migrations skill in my skill pack is written for this step. It plans the redirect map, implements it for the framework in use, and verifies every mapping on the served output.

The content and metadata parity check

A redirect passes signals to a new URL. The page at that URL still has to deserve what it inherits. Build a second sheet with one row per URL on the protected list, and columns for what the old page had and what the new page has: title, meta description, H1, approximate word count of the main copy, number of internal links pointing to it, structured data types, canonical and indexability. Fill the old columns from the benchmark crawl now. Fill the new columns from the staging crawl in the next stage.

Several parts of the new site have to point at the new URLs: internal links, a self-referencing canonical on each new URL, and hreflang annotations if the site uses them.¹ Add those to the parity sheet as yes or no columns. Internal links should go straight to the canonical URL.³⁰

Staging is where you find out whether the map and the templates work. Everything you can test here is cheaper to fix than the same fault found in production. It also has to be kept out of Google while you test it, and the way that is done matters on launch day.

Protect staging with a password

Use HTTP authentication or an IP allow-list for staging, and do not rely on robots.txt. robots.txt is not a mechanism for keeping a page out of search results, and a disallowed URL can still be indexed if it is linked from elsewhere.³¹ Bing's guidelines say the same: robots.txt controls crawl access, not indexing.¹⁹ The standard itself says its rules are not a form of access authorisation.³² A noindex tag only works if the page can be crawled, because a crawler blocked by robots.txt never sees it.³³ Password protection keeps URLs out of results as well as away from crawlers.³¹ It also has the advantage that it cannot be carried into production as a search directive by mistake, because the site plainly does not work for visitors until it is removed.

Some teams block crawling on the development site with robots.txt anyway. If you do, prepare what the robots.txt should look like once the move starts.¹ Whatever you use on staging, write the production robots.txt now as a separate file in the deployment, review it, and add it to the launch day checks.

How to put staging behind a password

• Apache. Create a password file with htpasswd -c /path/to/.htpasswd staging, then protect the staging site in its config or .htaccess with AuthType Basic, AuthName "Staging", AuthUserFile /path/to/.htpasswd and Require valid-user. Basic authentication sends the password unencrypted, so serve staging over HTTPS.³⁴
• nginx. Add auth_basic "Staging"; and auth_basic_user_file /etc/nginx/.htpasswd; to the staging server block. The password file can be made with htpasswd or openssl passwd.³⁵
• Cloudflare Access. If staging sits behind Cloudflare, Access can put a login in front of the staging hostname. Access is deny by default, and an Allow policy can admit people by email address or by email domain.³⁶ For crawlers and scripts, create a service token and send it as the CF-Access-Client-Id and CF-Access-Client-Secret headers,³⁷ with a Service Auth policy that accepts it.³⁶
• Hosted platforms and site builders. Many have their own password or preview features. Whatever you use, check from a logged-out browser that a visitor gets a login prompt and no content.

Test every redirect from the list

Ask the developer to deploy the redirect rules on staging so that the old paths resolve against the staging hostname. Then run the whole Old URL column through a crawler in list mode, or a script, with redirects followed and recorded. The URL Inspection tool suits single URLs; for large numbers, use command line tools or scripts.¹ For each row, record the first status code, the final URL, the final status code and the number of hops, and write the result into the Tested column. Every moved row should show one 301 or 308 to its New URL, and that URL should return 200. Every retired row should return its 404 or 410.

Check the status code the server returns, because the setting in an admin screen can be wrong. Some platforms and redirect plugins default to temporary redirects. A 302 is followed, but Google's indexing pipeline does not use it as a signal that the target should be canonical.¹⁸ Fix mismatches at their source, in the rule or the row, then rerun the full list. Partial reruns miss a rule that broke something else.

Running the list test in a crawler or with curl

In Screaming Frog, switch to Mode > List and upload or paste the Old URL column, rewritten to the staging hostname.⁸ Turn on Configuration > Spider > Advanced > Always Follow Redirects, which follows each redirect to its final target in list mode.⁷ Add the staging credentials under Configuration > Authentication, which handles basic and digest authentication and forms-based logins.⁸ When the crawl finishes, Reports gives you All Redirects and Redirect Chains, the second listing every URL that redirects two or more times. Export from list mode with the Export button to keep the rows in the order you uploaded them, so they line up with the map.⁸

In Sitebulb, start an audit, tick URL List under Crawl Sources, upload the list as a .csv or .txt file, and untick Crawl Website if the list is the only source. Links are not followed in this mode, and every URL in the list has to be on the same subdomain as the start URL, so a merge of two old domains needs one audit per domain.⁹ Credentials go on the Authentication tab of the audit settings. Ticking Is Staging Site under Robots Directives lets the crawl ignore a root Disallow on staging.⁴⁰

For a quick check without a crawler, curl tests one URL at a time, or a list in a loop. curl -s -o /dev/null -u user:password -w "%{http_code} %{redirect_url}\n" https://staging.example.com/services/shaker-kitchens.php prints the first status code and the URL the redirect points to. Add -L to follow the redirects, and %{num_redirects} and %{url_effective} to the format to print the number of hops and the final URL.⁴¹ The Shopify migration post has a full loop over a CSV for bash and PowerShell.

Crawl staging and compare it with the benchmark

Crawl staging from the homepage with rendering on and the same settings as the benchmark crawl. Fill in the new columns of the parity sheet, then look across the whole crawl for the faults that hide in templates.

If the site moves to a JavaScript framework, compare the raw HTML response of each new template with the rendered version, and treat a thin raw HTML as a launch blocker. Vercel's analysis of crawler traffic on its own network, published in December 2024, found that none of the major AI crawlers it tracked, including OpenAI's, Anthropic's and Perplexity's, executed JavaScript, so content that only appears after rendering is invisible to them.⁴³ Google may skip rendering when it finds a noindex in the initial HTML, so a noindex that JavaScript is meant to remove can keep the page out entirely.⁴ The method is covered in checking what crawlers see on a JavaScript site.

In the running example, say the staging crawl turns up three faults. The new service template outputs about a third of the old copy because the designer moved the long text into a tab that is only filled in by JavaScript. Canonicals use the staging hostname because the developer hard-coded it. And the area pages are reachable only from a map widget, so they have almost no internal links. All three are fixed on staging and the full test is run again.

Hold the go and no-go review

About a week before launch, walk through the criteria agreed in stage 1 with the sponsor and the developer, using the test results as evidence. If a criterion fails, the launch moves. That is cheaper than launching and fixing forward under pressure, and it is why the criteria were agreed at the start.

Launch day is a sequence. Most of the faults that do lasting damage are visible within minutes to someone who knows where to look, and fixed in minutes by the developer who built the site. So the order matters, and so does who is in the room.

The day before

Freeze content changes on the old site 24 to 48 hours before launch, so nothing is published that the map does not cover. Take the final crawl and the final Search Console and analytics exports, and save them in a new dated folder next to the benchmark. If the hosting is changing, the DNS TTL should have been lowered to a few hours at least a week before the move,³ so check that was done. Confirm who is on call: the developer who built the redirects, the person who signs off search, and someone who can make DNS changes.

The first hour

Deploy the new site and the redirects together. Then remove the staging protection and check robots.txt before anything else. Any noindex or robots.txt blocks that were only needed for the migration come off now.¹ Two details make robots.txt worth checking first. The Robots Exclusion Protocol lets crawlers use a cached copy for up to 24 hours,³² and Google generally caches it for that long,⁴⁴ so a Disallow that is live for even a short time may be what crawlers work from for the rest of the day. And if robots.txt returns a server error, the standard tells crawlers to assume everything is disallowed.³² Google stops crawling the site for the first 12 hours while it keeps trying to fetch the file.⁴⁴ A robots.txt that returns a 404 is treated as if there were no file, with no restrictions.³²⁴⁴

Then run the full redirect list against production, and the protected list by hand in a browser. Expect Google to crawl the new site more heavily than usual after a migration, and make sure the site has the capacity to handle it,¹ so tell the host to expect it and watch the server for errors.

Telling search engines about the move

Submit the new XML sitemap in Search Console so Google learns about the new URLs.¹ The migrations guide also covers submitting a sitemap of the old URLs so their redirects are found sooner. Search Console may warn that the URLs in it redirect, which is expected here.¹ A sitemap is a hint, and submitting one does not guarantee it will be downloaded or used.⁴² Submit the new sitemap in Bing Webmaster Tools too. Bing treats sitemaps as a way to improve accuracy and freshness without guaranteeing visibility, and asks site owners to use IndexNow to tell it when URLs are added, updated or removed.¹⁹

To submit, open the Sitemaps report in the new property, paste the sitemap URL into the submission box and select Submit. The status should read Success. Couldn't fetch or Has errors needs fixing the same day.⁴⁵ To spot-check pages, type the full URL into the inspection bar at the top of any Search Console screen, select Test live URL, then View tested page to see the screenshot, HTML and HTTP headers Google received.³⁹ Inspecting an old URL that redirects shows the result for the old URL itself, not for the redirect target.³⁹

If the domain or subdomain changed, submit a Change of Address in Search Console for the old site.¹ The tool has conditions, and it is worth checking each one before you start it.

• You must own both the old and new properties in Search Console, using the same Google account.²
• The tool works on domain-level properties, such as example.com, and not on path-level ones such as example.com/shop.²
• The old homepage must 301 redirect to the new homepage. The tool runs a quick check that you own both sites and that a few pages return 301s before it sends the request.²
• Use it for every subdomain variant of the old domain, including www and non-www.²
• Do not use it for HTTP to HTTPS moves, path changes within a domain, www to non-www changes, or moves without URL changes.²
• Do not chain moves. After moving site A to site B, you cannot immediately submit another move from B to C.²

To file the move, open the Change of Address tool in the old site's domain-level property and follow its instructions. It runs pre-move checks first. Critical failures have to be fixed before you can go on, while warnings can be passed. Once the critical checks pass, every site in the move shows a notice in Search Console that the move is in progress, for 180 days.² If you have to roll back within that time, the steps are to remove the redirects, add 301s from the new site to the old one, and select Cancel Move in the tool on the old site, for each affected domain.²

Merges raise a case Google's help page does not spell out. In the running example, the bathroom site's homepage redirects to www.example.com/bathrooms/, not to the new homepage, because that is the right equivalent for users. The tool's condition is a redirect from old homepage to new homepage, so its check may not pass for that domain. The same help page does describe traffic from the other site, or sites, being added to the new one as a move progresses,² which suggests more than one site can move into one. I would submit the request for the kitchen domain, whose homepage does redirect to the new homepage, and rely on clean one-to-one redirects for the bathroom domain if its check fails. The redirects do the main work either way.

Review the settings you configured for the old site in Search Console and carry them over, point ad campaigns at the new landing pages, and ask the sites that link to your old content to update their links.¹ That last job starts today with the profiles and listings you control.

If the site was built with an AI coding agent, the Launch QA skill in my skill pack runs against the production URL and checks the things that most often stop a new site being indexed, including staging noindex and robots blocks, auth walls, preview hosts in canonicals and sitemaps, and redirects. It splits the results into launch blockers and fix-this-week. It does not replace the full redirect test.

In the first month, judge the migration on whether the mechanics work. Visibility in search may fluctuate temporarily during a move; this is normal, and rankings settle down over time.¹ For a medium-sized site it can take a few weeks or more for Google to start showing the new URLs instead of the old ones, and longer for larger sites.¹ That is the only timeline Google publishes. Traffic in week one tells you little, so watch the redirects, crawling and indexing.

The detailed reading of each Search Console report, and a table of signals that separate normal movement from a fault, are in what to check in the first month after a migration. This stage sets out the routine around them: what to check, how often, and what to do with what you find.

The check routine

In the Page indexing report, old URLs should move into Page with redirect, and new URLs should become indexed. You can filter the report to a single sitemap,¹¹ so filter to the new sitemap and look at why any of those URLs are not indexed. Reasons such as Not found (404), Soft 404, Redirect error, URL blocked by robots.txt and URL marked 'noindex' each point at a specific fault.¹¹

In the Crawl Stats report, most responses should be 200 or similar unless you are doing a site reorganisation or move, in which case 301 and 308 responses are probably what you wanted.¹² Watch host status for robots.txt fetching, DNS resolution and server connectivity.¹² Server errors matter most: 5xx and 429 responses make Google's crawlers slow down, and indexed URLs that keep returning them are eventually dropped.⁴⁶ If the hosting changed too, a temporary drop in crawl rate straight after the change is normal, followed by a steady increase over the next few days.³

To open the Crawl Stats report, select Settings in the property, then Crawl stats, and open the report. Selecting a row in the response table, such as Not found (404), lists example URLs with the crawl time and response code for each request.¹² Do this in both the old and the new property.

Triage 404s against the map

Every 404 that appears after launch has one of three explanations, and the redirect map tells you which. Export new 404s from the logs and from the Page indexing report each day and look each one up.

In Google, a 404 and a 410 have the same effect: an indexed URL that returns either is removed from the index.⁴⁶ So a valuable URL that 404s for weeks loses its place, and fixing it early is worth far more than fixing it late. After a fix that the Page indexing report flagged, use Validate fix. Validation typically takes up to about two weeks.¹¹

Find 404 patterns in the logs

Missing redirects usually come in groups that share a pattern, such as print versions, old tag pages or paginated archives. On servers that write the common combined log format, the status code is the ninth space-separated field and the path the seventh, so grep Googlebot access.log | awk '$9 == 404 {print $7}' | sort | uniq -c | sort -rn | head -50 lists the 50 paths that requests claiming to be Googlebot most often get a 404 for. Check your log format first, and verify that the requests really come from Google, as described in the first month after a migration. On WordPress, the Redirection plugin's 404 log does a similar job inside the admin.²⁸

Use Request indexing sparingly

The URL Inspection tool lets you request indexing for a URL, but there is a daily limit to how many requests you can submit.³⁹ Use it for the homepage and a handful of the most valuable pages, and for any page you have just fixed. For everything else, the redirects and sitemaps do the job. The same tool shows the Google-selected canonical next to the one you declared,³⁹ which is the quickest way to confirm Google is treating a new URL as the canonical.

By the second month the mechanics should be settled and the question becomes whether search traffic has transferred. This stage is about measuring that fairly, finishing the work that launch day left, and handing the site back to normal running with nothing that can quietly break later.

Compare like with like

Compare each template against the benchmark, and compare the same weeks a year earlier as well as the weeks before launch. Comparing the last three months year on year, as well as against the previous period, rules out drops that happen every year.¹³ Search Console assigns clicks and impressions to the canonical URL Google selects for each page,⁴⁷ so add the old property and the new property together for each template until the old URLs have dropped out.

A small drop in position, such as from 2 to 4, is a different thing from a large drop, such as from the top 10 to position 29 across many queries.¹³ The second kind, still present after the first month and concentrated in one template, is a fault to investigate. Compare that template's raw HTML, internal links and redirects with the benchmark crawl, which is exactly what the saved files are for.

Decide when the move is done

Google gives no point at which a migration is finished, so set your own criteria. These are the ones I would use, and the move is complete when all of them are true.

• Most old URLs show as Page with redirect in the old property, and the new sitemap shows most of its URLs indexed.
• No unexplained 404s or soft 404s have appeared for two weeks.
• Crawl Stats shows a stable pattern of mostly 200 responses on the new property, with no host status problems.
• Clicks for each template are within the range you would expect from the same period last year, or the gap is explained and has an owner.
• Every item on the fault log is fixed or has an agreed plan.

Once most of the old URLs have left the index, remove the old URL sitemap. A sitemap should list the URLs you want in search results,⁴² and Bing's guidelines ask for deleted or redirected URLs to be removed from sitemaps promptly.¹⁹ If the hosting changed, shut down the old infrastructure only once its traffic reaches zero.³

To remove a sitemap, select it in the Sitemaps report, open the three-dot menu and choose Remove sitemap. Removing it from the report does not stop Google visiting those URLs,⁴⁵ which is what you want while the redirects do their work.

What stays in place for a year or more

Google's site move guide says to keep the redirects for as long as possible, generally at least one year.¹ The Change of Address help page asks for at least 180 days, longer if you still see traffic to them from Google Search, and recommends continuing to pay for the old domain for at least a year so nobody else can buy it and use it for malicious purposes.² I would treat a year as the minimum for both and keep the redirects indefinitely. They cost almost nothing, and links, bookmarks and printed brochures keep sending people to the old URLs for years.

Write the closing report

Keep it short and factual. The people who read it are the sponsor who approved the project and whoever looks after the site next. It should cover what changed and when, clicks and conversions by template against the benchmark and against last year, the faults found and fixed, anything still open with an owner, and what has to stay in place. File it in the migration folder with the redirect map, the benchmark and the fault log.

In the running example, say the report at day 90 shows service and area pages back in line with the same months last year, the blog still slightly behind with its new URLs now indexed, and the bathroom site's former pages above last year because they now have links from the kitchen pages. The open items are a backlink outreach list of 30 sites and two case studies still missing structured data. Those numbers are invented for the example. Yours will differ, and the report should say plainly where they are worse.