A website migration changes how a site is hosted, structured, designed, or reached. Common examples include changing domains, moving from HTTP to HTTPS, changing URL paths, switching CMS platforms, redesigning templates, or merging websites. A migration can affect search visibility because Google must recrawl pages, process redirects, and understand which URLs should replace the old ones.
This guide is a practical migration runbook for website owners, developers, and SEO teams. It covers planning, URL mapping, staging, launch-day checks, redirects, Search Console, analytics, and post-launch monitoring. The aim is not to promise that rankings will never fluctuate; it is to prevent avoidable errors and make problems easier to diagnose.
Quick website migration SEO checklist
- Define the migration scope and assign one owner for SEO sign-off.
- Export old URLs, titles, canonicals, status codes, backlinks, traffic, and conversions.
- Record a baseline for important landing pages and queries in Google Search Console and analytics.
- Map every valuable old URL to its closest equivalent destination.
- Prepare server-side permanent redirects where URLs change.
- Keep staging protected, but document every robots.txt and noindex change that must be reversed.
- Test templates, navigation, forms, tracking, mobile layouts, and page rendering before launch.
- Check canonical tags, internal links, hreflang, structured data, and XML sitemaps on the new site.
- Launch, test redirects and status codes, and remove temporary crawl blocks.
- Submit the new sitemap and monitor both old and new URL patterns in Search Console.
1. Identify the type and scope of migration
Start by writing down exactly what is changing. A domain move, URL redesign, HTTPS migration, CMS change, hosting move, and visual redesign do not carry identical risks. Some projects combine several changes, which makes it harder to identify the cause of a traffic change.
| Migration type | What changes | Key SEO checks |
|---|---|---|
| Domain or subdomain | example.com moves to a different domain or subdomain | URL map, redirects, verified Search Console properties, Change of Address when eligible |
| URL structure | Page paths or folder structure change | One-to-one redirects, internal links, canonicals, sitemap |
| HTTP to HTTPS | Protocol changes | TLS certificate, HTTP-to-HTTPS redirects, secure canonicals, mixed content |
| CMS or platform | WordPress, Shopify, custom CMS, or another platform replaces the old system | URL parity, rendering, metadata, schema, image and file URLs, tracking |
| Redesign or theme change | Templates, navigation, content presentation change | Content preservation, headings, internal links, mobile usability, performance |
| Hosting or infrastructure | Server, CDN, DNS, or hosting provider changes without intended URL changes | DNS, TLS, status codes, server capacity, caching, robots access |
| Site consolidation | Multiple sites or sections merge | Page-level mapping, content consolidation, redirects, ownership and analytics |
For a lower-risk project, separate major changes where practical. For example, avoid changing the domain, CMS, URL structure, design, and content strategy all at the same time unless there is a strong operational reason.
2. Build a reliable pre-migration baseline
Do not rely on memory or a few screenshots. Capture the state of the old website so that the team can compare like with like after launch.
Export and preserve these items
- URL inventory: crawl the old site and export indexable URLs, response codes, titles, meta descriptions, H1 headings, canonical URLs, robots directives, word counts, and internal link counts.
- Search performance: export clicks, impressions, CTR, average position, and important query-to-page relationships from Google Search Console.
- Business performance: record organic sessions, leads, sales, revenue, and conversion rates by landing page where analytics is configured.
- Backlinks: identify important referring domains and pages with valuable external links.
- Media and files: list image, PDF, video, downloadable asset, and other file URLs that receive traffic or links.
- Technical configuration: save robots.txt, XML sitemaps, redirects, canonical rules, hreflang, structured data, DNS records, and key server settings.
Keep dated copies of the exports. Record the date range, timezone, filters, and tools used. This makes later comparisons more reliable.
3. Create a page-level URL mapping
The redirect map is one of the most important migration documents. Each old URL should have a clear decision: keep the same URL, redirect to a relevant replacement, consolidate into a genuinely equivalent page, or return an appropriate not-found or gone response when the content has been permanently removed.
| Old URL | New URL | Action | Reason / status |
|---|---|---|---|
| /old-services/ | /services/ | 301 redirect | Equivalent service page |
| /blog/seo-basics/ | /resources/seo-basics/ | 301 redirect | Same article, new path |
| /old-product-a/ | /products/product-a/ | 301 redirect | Same product |
| /discontinued-item/ | — | 410 or 404 | No relevant replacement exists |
These are illustrative examples, not instructions to redirect real URLs. Choose destinations based on equivalent content and user intent. Do not send unrelated old pages to the homepage or a generic category just to avoid 404s; irrelevant redirects can be confusing and may be treated as soft 404s.
Prioritise the mapping
- Start with pages that receive organic clicks, conversions, or valuable referral visits.
- Include pages with strong external links and important internal links.
- Include all indexable URLs from the old sitemap and crawl.
- Include images, PDFs, videos, and other assets where their URLs are changing.
- Review parameterised and duplicate URL variants so they do not create accidental redirect loops or duplicate destinations.
4. Prepare the new website in staging
Before launch, crawl the staging site and compare it with the old site. Use a password-protected or otherwise access-controlled staging environment where possible. If robots.txt blocks or noindex directives are used during development, document exactly where they apply and who will remove them at launch.
- Confirm that important pages return the intended response code and load without authentication for public users.
- Check that key copy, headings, titles, descriptions, images, navigation, and calls to action have not disappeared unintentionally.
- Confirm that each indexable page has the intended canonical URL.
- Check that internal links point to the final new URLs, not staging URLs or old redirected URLs.
- Test mobile layouts, JavaScript rendering, forms, checkout, login, and other critical user journeys.
- Validate analytics and conversion events in a test environment before launch.
- Check structured data for accuracy and remove markup that no longer matches visible page content.
- Check hreflang references where multilingual or regional pages are used.
- Verify image paths, alt text, downloadable files, and media embeds.
Do not assume that a page is search-ready just because it looks correct in a browser while logged in. Test the public version and inspect the rendered HTML and server responses.
5. Implement redirects correctly
When a URL changes, use a server-side permanent redirect such as HTTP 301 or 308 where technically possible. Map old URLs directly to their final destinations. Avoid chains, loops, and broad rules that send unrelated URLs to the same page.
- Use one-to-one redirects for pages that have equivalent replacements.
- Preserve relevant path and query behaviour where the new site requires it.
- Redirect old HTTP URLs to the final HTTPS version in a single step where possible.
- Do not redirect a removed page to an unrelated page merely to make the old URL return a 200 response.
- Keep redirects active for at least a year as a practical baseline; keep them longer when users or links still reach old URLs.
- Update internal links to point directly to final URLs rather than relying on redirects.
Google states that permanent redirects do not cause PageRank loss. The purpose of redirects is to guide users and crawlers to the correct replacement, not to manufacture a destination for every obsolete URL.
6. Check canonical tags, robots rules, and indexability
After the new site is live, each indexable page should send consistent signals. Check that canonical tags reference the preferred new URLs, robots meta directives do not unintentionally block pages, and robots.txt does not prevent crawling of important resources or sections.
| Element | What to verify |
|---|---|
| Canonical | Points to the preferred final URL, normally a self-referencing canonical for unique pages |
| Meta robots | No unintended noindex or nofollow directives remain from staging |
| robots.txt | Important pages and resources are not accidentally blocked |
| HTTP status | New canonical pages return 200; old moved URLs redirect as mapped |
| Hreflang | References use the new URLs and valid reciprocal relationships |
| Structured data | Markup reflects the visible page and correct new URLs |
| Internal links | Menus, breadcrumbs, body links, and footer links use final destinations |
Remember that robots.txt blocking and noindex are not interchangeable. A robots.txt block can prevent crawlers from seeing a page-level noindex directive. Diagnose the actual response and indexing state before changing directives.
7. Update XML sitemaps and Search Console
Generate an XML sitemap containing the preferred, indexable URLs on the new site. Remove old URLs that now redirect, return errors, or are not intended for indexing. Submit the new sitemap in the appropriate Search Console property and monitor processing and indexing reports.
For a domain or subdomain move, verify both the old and new properties in Search Console before migration. Use the Change of Address tool only for eligible moves between domains or subdomains after redirects are in place. It is not needed for an HTTP-to-HTTPS move, a www/non-www preference change on the same domain, or a path change within the same site.
For a URL move, inspect representative old and new URLs with URL Inspection. Check that the new page is accessible to Google and that Google-selected canonical information is consistent with the intended destination. A sitemap submission or indexing request does not guarantee indexing.
8. Launch-day SEO checklist
- Confirm DNS, hosting, TLS certificates, CDN, and caching are working.
- Remove staging-only noindex directives and crawl blocks from the live pages that should be indexed.
- Activate the approved redirect map and test representative URLs from every pattern.
- Check old URLs redirect directly to the correct final destinations.
- Check new pages return the intended status code and canonical URL.
- Confirm navigation, breadcrumbs, internal links, and XML sitemaps use new URLs.
- Test robots.txt, important page rendering, and mobile usability.
- Test analytics, consent behaviour, lead forms, checkout, and conversion tracking.
- Check for spikes in 404, 5xx, redirect loop, and soft 404 responses.
- Submit the new sitemap and record the launch time and release version.
9. Monitor the migration after launch
Do not judge the migration from one day of rankings. Google needs to recrawl and process old and new URLs, and temporary ranking fluctuations can occur. Monitor technical health and business outcomes together.
| When | Checks | What to do if something is wrong |
|---|---|---|
| Launch day | Redirects, status codes, robots, canonicals, sitemap, analytics | Fix blocking errors and broken redirect rules immediately |
| Days 1–3 | Server logs, crawl activity, 404/5xx errors, key landing pages | Investigate patterns and restore missing pages or destinations |
| Weeks 1–2 | Search Console indexing, sitemap processing, clicks and impressions | Inspect affected URL groups and compare old/new URL behaviour |
| Weeks 3–6 | Organic traffic, conversions, query-to-page changes, crawl errors | Fix remaining mapping, content, canonical, or performance problems |
| Ongoing | Redirect health, backlinks, traffic, leads and sales | Update important external links and retain redirects while useful |
Use the same date ranges and comparable weekdays when comparing performance. Segment data by page type, directory, device, country, and brand/non-brand queries where useful. A site-wide total can hide a problem affecting one important section.
10. Common migration mistakes to avoid
- Launching without a complete URL map: important pages are missed and old links lead to errors.
- Redirecting everything to the homepage: unrelated destinations confuse users and can be treated as soft 404s.
- Leaving staging blocks in place: important new pages remain unavailable to crawlers.
- Keeping old canonicals: new pages continue signalling the previous URL as preferred.
- Forgetting internal links: navigation and content links continue passing users through redirects.
- Changing everything at once: when traffic changes, it becomes harder to identify the cause.
- Deleting old domains or redirects too soon: users and external links may still depend on them.
- Ignoring analytics and conversions: rankings may look stable while forms, checkout, or tracking are broken.
- Expecting instant recovery: crawling and processing happen over time, and there is no guaranteed recovery date.
11. Migration troubleshooting guide
| Symptom | Likely areas to investigate | First action |
|---|---|---|
| Many old URLs return 404 | Missing or incorrect redirect rules | Compare failed URLs against the redirect map and add relevant destinations |
| New pages are not indexed | Noindex, robots blocks, canonical mismatch, server errors, weak or missing content | Inspect affected URLs and test the live page |
| Traffic drops for one directory | Template, redirect pattern, content or internal-link issue | Segment by directory and compare old/new URLs |
| Redirect loops or chains | Conflicting server, CDN, CMS, or plugin rules | Trace the full redirect path and point directly to the final URL |
| Organic sessions fall but clicks do not | Analytics tag, consent, attribution, or event issue | Validate measurement before concluding that search visibility fell |
| Google selects an unexpected canonical | Conflicting redirects, internal links, sitemap entries, or canonical annotations | Make all URL signals consistent and inspect again |
12. Practical migration project tracker
Use this simple tracker to assign responsibility and record evidence. A task should not be marked complete just because someone says it was done; keep a test URL, export, screenshot, or deployment reference wherever possible.
| Task | Owner | Evidence to retain |
|---|---|---|
| Old-site crawl and baseline | SEO | Timestamped crawl and performance export |
| URL mapping approved | SEO + development | Reviewed redirect spreadsheet |
| Staging QA passed | Development + QA | Test results and issue log |
| Redirects deployed | Development | Redirect test report |
| Indexability and canonicals checked | SEO | URL Inspection and crawl evidence |
| Analytics and conversions tested | Analytics / marketing | Test events and conversion records |
| Sitemap submitted | SEO | Search Console sitemap status |
| Post-launch monitoring | SEO + development | Weekly issue and performance log |
Frequently asked questions
Will a website migration reduce Google rankings?
It can cause temporary ranking fluctuations while Google recrawls and processes the changed URLs. Missing redirects, blocked pages, incorrect canonicals, server errors, and major content changes can create avoidable losses. Careful planning reduces risk but cannot guarantee that rankings will remain unchanged.
How long does SEO recovery take after a migration?
There is no fixed timeline. Google explains that smaller and medium-sized sites may take a few weeks for most URLs to move, while larger sites can take longer. Processing happens URL by URL and depends on crawl capacity, site size, and server performance.
Should I redirect every old URL to the homepage?
No. Redirect each old URL to its closest relevant replacement. If there is no suitable replacement and the content is permanently removed, return an appropriate 404 or 410 response instead of sending visitors to an unrelated page.
Do I need the Change of Address tool for every migration?
No. It is intended for eligible moves between domains or subdomains. It is not required for HTTP-to-HTTPS changes, www preference changes on the same domain, or URL path changes within the same site.
How long should I keep redirects?
Google recommends keeping redirects for as long as possible, generally at least one year for site moves. Keeping them longer is useful when visitors or external links still reach the old URLs.
Should I change the design and domain at the same time?
If practical, separate major changes. Moving the domain first and changing the design later makes it easier to identify and fix issues. Some projects must combine changes, but they need more detailed testing and monitoring.
Does submitting a sitemap guarantee that Google will index the new pages?
No. A sitemap helps Google discover URLs, but it does not guarantee crawling, indexing, or rankings. Pages still need to be accessible, indexable, useful, and consistent with the site’s technical signals.
Official Google resources
- Google Search Central: How to move a site with URL changes
- Google Search Central: Redirects and Google Search
- Google Search Console Help: Change of Address tool
- Google Search Central: Learn about sitemaps
Final recommendation: Treat a migration as a controlled technical project, not just a website launch. Preserve a reliable baseline, map URLs carefully, test redirects and indexability, validate tracking, and keep monitoring until the important pages and business outcomes have stabilised.