Website migration SEO checklist: URL mapping, 301 redirects, launch and post-move monitoring

What counts as an SEO migration, and which types carry the most risk?

An SEO migration is any change that alters the URLs, platform, structure or hosting of a site in a way that search engines must reprocess. The more the URLs, content and templates change at once, the greater the risk to rankings, so identify the type before you plan.

Which migration types exist?

Migration type	What changes	Typical risk
HTTP to HTTPS	Protocol	Low if redirects and canonicals are consistent
Domain or subdomain change	Hostname, sometimes brand	Medium to high
URL structure change	Paths, folders, parameters	Medium to high
Platform or CMS replatform	Templates, rendering, URL patterns, plugins	High
Redesign with new information architecture	Navigation, page types, content	Medium to high
Site consolidation or merger	Several sites into one	High
International restructure	Subfolders, subdomains or ccTLDs, hreflang	Medium to high

Which combinations are most dangerous?

Changing the domain, the platform, the URLs and the content in one release. Each change has its own failure modes, and bundling them makes problems almost impossible to isolate. Stagger changes where you can.

Why do rankings fluctuate after a move?

Google must discover the redirects, recrawl old and new URLs, reprocess signals and consolidate them on the new addresses. Google's guidance says to expect ranking fluctuations during the move, and that recrawling can take weeks or longer for larger sites. A short dip is common, and a sustained, steep fall points to a redirect, indexing or content problem.

Can you migrate without any loss?

Rarely perfect. A careful migration with one-to-one mapping and unchanged content limits the loss and shortens recovery, but nobody can promise zero change.

Which businesses should be most cautious?

Ecommerce stores with thousands of product URLs, publishers with deep archives, multi-location firms with many location pages and lead-generation sites that depend on a handful of high-converting pages. The dedicated SEO migration service exists because the cost of a mistake is measured in lost revenue.

When is not migrating the better choice?

When the benefits are cosmetic and the site ranks well. A redesign can often keep URLs and content structure intact, which avoids the largest risks.

How do you plan the scope, team and timeline?

Define goals, freeze the scope, record a performance baseline and assign owners for content, development, SEO and analytics. Start planning months before launch for large sites, and weeks for small ones.

What should you document before anything changes?

The reason for the migration, the type, the launch window, the stakeholders and the success criteria. Capture a baseline: Search Console performance for at least sixteen months, top landing pages, top queries, conversions, backlinks, crawl stats, indexed page counts and current rankings for priority keywords. Save these exports, since you will compare against them for months.

Why sixteen months of data?

It lets you compare against the same period a year earlier and see seasonality, which prevents false alarms after launch.

Who needs to be involved?

An SEO lead who owns the redirect map and checks, developers who build and test the redirects and templates, content editors who migrate and improve pages, an analytics owner who preserves tracking, a project manager who controls timing and a business owner who signs off. Misaligned teams are a more common cause of failure than any technical detail.

How do you avoid launching at a bad time?

Avoid peak seasons, campaigns and holidays, and avoid Fridays. Choose a window when developers are available to fix problems quickly.

How long should a migration take?

A small brochure site can be planned and tested in a few weeks. Large ecommerce or publisher migrations often take several months of preparation. Build time for staging tests, redirect testing and at least one rehearsal.

What goes into the risk register?

Missing redirects, template regressions, blocked crawling, lost analytics tags, server overload, content gaps, hreflang errors and tracking changes, each with an owner and a mitigation.

How do you inventory old URLs and build the redirect map?

Compile every old URL that has value or might receive requests, then map each to the best new equivalent. This URL map is the single most important artifact in the project, and Google's guidance names it as a core step.

Where do you collect old URLs?

From XML sitemaps, a full crawl, analytics landing pages, Search Console performance and Page indexing exports, server logs, the CMS database, backlink tools and your Business Profile and social profiles. Include images, PDFs, videos and scripts that have their own URLs. Deduplicate and normalize case, trailing slashes and parameters. The same thinking applies when you hunt for forgotten pages, as the walkthrough on orphan page identification describes.

Should you include URLs with no traffic?

Include any with backlinks, rankings or indexing. Others can be handled by pattern rules or allowed to return 404 or 410 if they have no value.

How do you decide the destination for each URL?

Map each old URL to the new page that best matches its topic and intent. If the page is unchanged in meaning, use a one-to-one mapping. If several old pages are merged, map them all to the new merged page. If a page has no equivalent, redirect it to the closest relevant parent category, or let it return 404 or 410 when it has no value. Google warns against redirecting many unrelated pages to an irrelevant destination such as the home page, since that can be treated like a soft 404. The consolidation rules in the content pruning and consolidation plan apply here too.

When is pattern-based mapping acceptable?

When the URL structure changes in a predictable way, such as /blog/post-name/ to /articles/post-name/. Write regex or rewrite rules, then test them against the full list of old URLs.

What columns should the map contain?

Old URL, new URL, redirect type, page type, traffic and backlink data, notes on content changes, owner and test status. Keep it in a spreadsheet under version control, and give developers a clean CSV.

How do you handle parameters and duplicates?

Map canonical URLs, and let parameter variants redirect to or canonicalize to their clean equivalents. Decisions about which variants matter belong in the same plan as the clean versus parameterized URL choices.

How do you prepare the new site before launch?

Build and test the new site on a staging environment that crawlers cannot index, replicate all signals that matter and check performance and rendering. Google's guidance starts with preparing the new site, including TLS, robots.txt, noindex settings and Search Console verification.

What must be in place technically?

HTTPS configured correctly, a clean robots.txt that does not block important resources, intentional noindex only on pages that should be excluded, canonical tags pointing to the new URLs, hreflang annotations updated for the new addresses, XML sitemaps containing the new canonical URLs, structured data intact, meta titles and descriptions carried over, internal links pointing directly to new URLs and analytics and conversion tracking installed. Google also notes that the new site needs enough server capacity for heavier Googlebot crawling.

How do you keep staging out of the index?

Protect it with HTTP authentication, which is the most reliable method. Do not rely on robots.txt alone, and make sure that staging noindex rules and robots blocks are removed on the live site at launch. Leaving them in place is among the most common and costly launch mistakes.

How do you validate content and templates?

Crawl staging and compare it with a crawl of the live site: page counts, titles, headings, word counts, canonical tags, status codes, internal links, structured data and images. Investigate every difference. Content that has been shortened, hidden or moved behind scripts can cost rankings, so confirm that key text is present in the rendered HTML, as the guide to Googlebot, rendering and the DOM explains.

Which template checks matter most?

Title and H1 patterns, main content visibility, internal link modules, breadcrumbs, pagination, faceted URLs and structured data on product, article and local pages.

What about performance and Core Web Vitals?

A slower new site can offset every other gain. Test Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift on key templates, using the checks in the Core Web Vitals guide, and fix regressions before launch. Check server capacity too, since Googlebot may crawl more heavily after the move, as the notes on server response time and crawl frequency describe.

Should you improve content during the migration?

Keep core content stable at launch and improve afterwards. Changing URLs, templates and content together makes it hard to learn what caused any movement.

How do you implement 301 redirects correctly?

Use server-side permanent redirects, 301 or 308, from each old URL to its mapped new URL in a single hop. Google's guidance treats server-side redirects as the standard method and client-side redirects as a last resort.

Which redirect types should you use?

A 301 or 308 signals a permanent move and tells Google to transfer indexing and signals to the new URL. A 302 or 307 signals a temporary move and should not be used for permanent migrations. Avoid meta refresh and JavaScript redirects except where server access is impossible.

What is the difference between 301 and 308?

Both are permanent. A 308 preserves the HTTP method, while a 301 may allow clients to change POST to GET. For standard page navigation, either works.

How do you avoid redirect chains and loops?

Point every old URL directly to its final destination. Google advises avoiding chains, with a rough ceiling of about three hops, but one hop is the goal. Remove legacy redirect layers, such as HTTP to HTTPS to www to a new path, by combining them into a single rule. Test for loops, where URL A redirects to B and B back to A, and for redirects to URLs that return 404.

How do you test redirects at scale?

Run the full list of old URLs through a crawler or script in list mode, record the final URL, the status code and the number of hops, and compare them with the map. Fix mismatches before and after launch.

How should redirects be implemented technically?

At the server or CDN level, for example in the web server configuration, or in a redirect manager with performance safeguards. For thousands of URLs, use maps or database lookups rather than long rule lists that slow each request. Keep rules ordered and commented, and store them in version control. Our comparison of noindex and disallow is a reminder that blocking old URLs in robots.txt prevents Google from seeing redirects, so do not block them.

Should the old site's robots.txt change?

Never block old URLs that redirect. Googlebot must be able to crawl them to discover the redirects.

How long should redirects stay in place?

Google recommends keeping redirects for at least one year, and longer if the old URLs still receive traffic or have backlinks. Many sites keep them indefinitely. Removing them early can strip signals and send visitors to error pages.

What should happen to URLs that no longer exist?

Return 404 or 410 for pages that have no equivalent and no value. Provide a helpful custom error page that still returns a real error status, and avoid soft 404s.

What should you do on launch day?

Turn on the redirects, confirm that canonicals and robots rules point to the new URLs, test critical journeys and submit the sitemap. Google's guidance says to verify redirects, for example with the URL Inspection tool or scripts, and to submit a Change of Address for domain moves.

What is the launch checklist?

1. Remove staging protection and any noindex or robots blocks intended only for staging.
2. Switch DNS or deploy the new site, and enable the redirect rules.
3. Check the home page, top landing pages, key templates and conversion paths in a browser.
4. Run the redirect list test and review failures.
5. Confirm canonical tags, hreflang, structured data and meta robots on sample URLs.
6. Submit the new XML sitemap and remove the old sitemap from the new property.
7. For domain or subdomain changes, use Search Console's Change of Address tool on each verified old property variant.
8. Confirm analytics, conversion tracking and call tracking fire correctly.
9. Monitor server errors and response times.

Which checks must a human perform?

Placing a test order or enquiry, calling the tracked phone number and reading key pages as a customer. Automated checks miss broken journeys.

How does the Change of Address tool work?

For moves between domains or subdomains, Search Console's Change of Address tool lets you tell Google that the old property has moved to the new one. You verify both properties, set up redirects first and then submit the request for each old variant. It complements redirects and does not replace them, and it does not apply to URL changes within the same domain.

Do you need Search Console properties for every variant?

Yes. Verify the old and new sites, including HTTP, HTTPS, www and non-www variants, so that you can watch all of them and submit the change for each old one.

What about the rollback plan?

Decide in advance what failures trigger a rollback, such as widespread 5xx errors, broken checkout or a site-wide noindex, and rehearse it. A rollback plan lets you act decisively instead of arguing under pressure.

Who has authority to call a rollback?

Name one person, usually the project lead, before launch day.

How do you update links, sitemaps and external signals after launch?

Update internal links to point directly to the new URLs, refresh external references you control, correct profiles and listings, and ask important linking sites to update links. Google's guidance lists updating links as a distinct step.

Which internal elements need updating?

Navigation, footers, body links, breadcrumbs, canonical tags, hreflang annotations, XML sitemaps, image sources, structured data URLs and any hard-coded URLs in templates and scripts. Internal links that pass through redirects waste crawl effort, so fix them. The principles in the guide to crawlable internal links and anchor text help you rebuild navigation properly.

How do you find leftover old URLs?

Crawl the new site and search for links, canonicals, hreflang entries and sitemap URLs that contain the old domain or path. Fix them at the template or database level.

Which external signals should you update?

Business Profile website links, social profiles, directory listings and citations, email signatures, ad campaigns, Merchant Center feeds, partner and supplier sites and high-value backlinks. Keep name, address and phone consistent, as the guide to local citations explains. For links from other sites, a short, polite request with the new URL works best, as the practices in digital PR for local and ecommerce brands describe.

Do you need every backlink updated?

No. Redirects pass signals, so focus on the most valuable links and on links where a direct update improves user experience.

How do you handle ecommerce feeds and local data?

Update product feed landing page URLs and make sure structured data and feed prices match the new pages, as in the comparison of Merchant Center feeds and structured data. For local businesses, align the website URL on the Business Profile, citations and LocalBusiness markup, as the LocalBusiness schema guide describes.

Should feeds be updated before or after launch?

Immediately after launch, once the new URLs are live, and watch diagnostics for disapprovals.

How do you monitor a migration after launch?

Watch Search Console reports, server logs, analytics and rankings daily for the first weeks, then weekly. Google's guidance says traffic should decline on the old site and rise on the new one, and tells you to monitor Sitemaps, indexing and search performance reports.

Which reports show problems fastest?

Server logs and the Crawl stats report show whether Googlebot is requesting the new and old URLs and whether it meets errors. The Page indexing report shows indexing shifts and new exclusions, and the sitemap report shows how many submitted URLs are indexed. The Performance report shows impressions and clicks per URL. Analytics shows traffic and conversions.

How often should you check?

Daily in the first week, a few times a week for the next month and weekly after that, until metrics stabilize and the old property fades.

What patterns signal trouble?

A surge of 404s for URLs that should redirect, redirect chains, a drop in indexed pages with no matching rise on the new site, large numbers of pages in "Crawled - currently not indexed" or "Discovered - currently not indexed", slow response times, missing structured data and traffic that stays on the old URLs. The explanation of Page indexing statuses helps you triage the exclusions.

When is a drop normal?

A modest dip in the first weeks while Google reprocesses is common. A steep, persistent decline in key pages deserves investigation of redirects, rendering and content parity.

How do you separate migration effects from other causes?

Compare against your baseline and the same period last year, annotate analytics with the launch date and note Google updates in that window. The method for separating causes appears in the guide to diagnosing a traffic drop after a core update, and it applies equally to migrations.

How long until things settle?

Google says recrawling can take weeks or longer for large sites. Set expectations with stakeholders before launch, as the guide to how long SEO takes explains for other changes.

How do ecommerce, local and international migrations differ?

The checklist stays the same, but each type of site adds checks around products, locations or languages. Plan these extras early, because they are the ones most often forgotten.

What extra checks apply to ecommerce migrations?

Preserve product identifiers, variant URLs, canonical rules, faceted navigation controls, pagination, product structured data, reviews and availability markup. Redirect discontinued products to the closest replacement or category, and return 404 or 410 when there is none. Rebuild feeds so that landing page URLs, prices and availability match the new pages. Retest checkout, tax and shipping logic, since a perfect redirect map cannot save a broken basket.

Should you migrate reviews and ratings?

Yes, with their markup, provided they are genuine and visible on the page. Losing review content can reduce rich result eligibility and customer trust.

What extra checks apply to local and multi-location businesses?

Keep location page URLs stable where possible, update the website link on every Business Profile, keep name, address and phone details identical across the site, citations and LocalBusiness markup, and preserve opening hours, service lists and review links. If a location URL must change, redirect it one-to-one and update the profile the same day. A broken link from a profile to a 404 costs calls immediately.

How do you protect call tracking?

Test the tracking numbers and form submissions on the new site before launch, and make sure that the primary phone number on the profile still matches the website.

What extra checks apply to international migrations?

Update hreflang annotations so that every language or region version points to the new URLs and links back, keep language and writing system consistent in titles and content, avoid IP-based redirects that hide versions from crawlers and decide on subfolders, subdomains or country domains deliberately. Verify each version in Search Console and watch regional performance separately.

Should you launch all markets at once?

Where risk is high, stage the launch by market, starting with a smaller one, and learn from it before moving the largest.

What does a real migration look like in practice?

This is a fictional example that illustrates the method. The outcomes are invented.

What was the situation?

A fictional furniture retailer moved from a legacy platform to a new ecommerce system and changed its URL structure from /shop/category/product-id to /category/product-name/. The site had 8,400 indexable URLs, 640 referring domains and strong rankings for 120 product terms.

What did the team do before launch?

They collected URLs from sitemaps, analytics, logs and backlink data, mapped 7,900 URLs one-to-one, merged 300 discontinued products into category pages, marked 200 low-value URLs for 410, built redirect rules by pattern with an exception file, crawled staging, compared titles and canonicals with the old site, fixed three template issues that hid product descriptions in the rendered HTML and load-tested the server.

What happened at launch and afterward?

They launched on a Tuesday morning, removed staging blocks, ran the redirect test on all 8,400 old URLs, found 41 chains and fixed them the same day, submitted the new sitemap, updated the feed and Business Profile links and monitored daily. Impressions dipped for two weeks, then recovered, and they logged each fix and noted that other seasonal factors and a Google update in the same month made exact attribution impossible.

What was the lesson?

The map, the test run and the rehearsal prevented the large errors. The small ones, such as chains, were found because someone checked.

Which migration mistakes cost the most traffic?

The same errors recur in failed migrations. Most are process failures, not technical mysteries.

What do teams get wrong most often?

Redirecting everything to the home page, leaving noindex or robots blocks from staging, forgetting to redirect images and PDFs, using temporary redirects, creating chains and loops, dropping content or structured data in the new templates, changing too many things at once, launching without a baseline, switching off the old site too soon and neglecting analytics and tracking.

Which mistake is the easiest to prevent?

Leaving staging blocks in place. A launch checklist item and an automated check of robots.txt and meta robots on live pages catch it in minutes.

How do you build a safety net?

Use a documented checklist, automated tests for redirects and critical tags, a rehearsal, a rollback plan, daily monitoring and a named owner for every task. The routine in the technical SEO audit checklist doubles as a post-launch health check.

When should you bring in specialists?

For large sites, domain changes, platform changes and international restructures, where the cost of a mistake exceeds the cost of expertise.

How does AH SEO Agency help with website migrations?

We scope the move, build the URL inventory and redirect map, audit staging for crawlability, rendering and content parity, supervise launch and monitor recovery with a daily dashboard. We follow Google's site move guidance and tell you plainly what risks remain.

Where do you start?

Plan your move with our SEO migration team, add a pre-launch SEO audit or start with a free SEO audit of your current site.

Summary: how do you migrate a website without losing search visibility?

Prepare the new site, map every URL, implement single-hop permanent redirects, launch with a tested checklist, update links and sitemaps, submit a Change of Address when the domain changes and monitor for weeks. Keep redirects for at least a year.

• Follow Google's six stages: prepare, map, redirect, launch, update links, monitor.
• Use 301 or 308 server-side redirects to the closest equivalent page, with no chains.
• Keep staging blocked until launch, and remove those blocks at launch.
• Record a baseline and compare it for months.
• Expect temporary fluctuation while Google recrawls.