A website migration can change hosting, code, design, content, URLs or the domain. Each change creates different search risks, so the checklist should start by defining exactly what is moving rather than treating every launch as the same project.
The goal is not to promise that visibility will remain perfectly stable. Google notes that rankings can fluctuate during a site move and processing time varies. A useful migration plan preserves valuable signals where possible, exposes failures quickly and gives a named person authority to fix or reverse a release.
Use the guide with the downloadable CSV. Assign every check, record the verification evidence and agree on rollback triggers before the production launch begins.
Free working file
Download the template and assign the work
Use the CSV with your project records. Add owners, evidence and due dates without submitting any information to SEO Guys.
Classify the move before choosing the checks
Write down every material change in the release. A hosting move with the same visible URLs follows a different process from a domain change or a new platform that rewrites thousands of paths. A redesign can also become a content migration when headings, copy, internal links and templates change.
Google maintains separate guidance for hosting changes without visible URL changes and site moves that change URLs. If several changes are optional, separate them where practical. Changing the domain, platform, design and content at once makes a failure harder to isolate.
Hosting or CDN change
Visible URLs stay the same, but DNS, serving infrastructure, performance, firewall rules or server behaviour may change.
Platform or redesign
Templates, rendering, navigation, content, structured data, forms and analytics can change even when many URLs remain stable.
URL restructure
Paths change within the same domain and require a complete mapping, redirects, updated internal links and new canonicals.
Domain or subdomain move
The hostname changes and may require verification of old and new Search Console properties plus an eligible Change of Address request.
Assign owners, approvals and a launch boundary
Name the business owner, developer, SEO reviewer, analytics owner and person authorised to pause or roll back the release. Record how they will communicate during launch and where issues will be logged. A checklist without owners becomes a list of assumptions.
Set a launch boundary. Non-essential design, content and feature changes can be scheduled after the migration when they would make validation harder. If they must ship together, record them explicitly so their effects can be investigated.
- A business owner approves the commercial pages and acceptable downtime.
- A developer owns deployment, redirects, server responses and rollback execution.
- An SEO reviewer owns URL mapping, crawl controls, canonical checks and search monitoring.
- An analytics owner verifies page views, key events, forms and campaign parameters.
- Customer-facing teams know when the release may affect forms, calls or transactions.
- Every rollback trigger names the person with authority to act.
Capture the baseline and complete URL inventory
Crawl the current production site and save the evidence with an extraction date. Combine crawl discovery with the XML sitemap, analytics landing pages, Search Console pages and queries, backlink destinations, paid campaign URLs and business records. No single source will contain every URL that matters.
Mark priority URLs by commercial value, qualified conversions, search visibility, external links or operational importance. This creates a test set for the first minutes after launch and prevents a low-volume but valuable page from disappearing inside sitewide totals.
Technical inventory
Save status codes, indexability, canonicals, titles, headings, structured data, internal links, images and important rendered content.
Search inventory
Export relevant pages, query groups, clicks, impressions, CTR and position with property, filters and date range recorded.
Behaviour inventory
Record organic landing sessions and configured key events while keeping these analytics measures separate from Search Console clicks.
Business inventory
Identify pages that produce qualified enquiries, sales, subscriptions or other outcomes that analytics alone may not verify.
Build a one-to-one URL map with a reason for every change
Give every changing URL an intended action. Preserve the same URL when it remains useful and the information architecture allows it. When a URL must change, map it to the most relevant replacement. When content has no replacement, a clear 404 or 410 response can be more accurate than an irrelevant redirect.
Google warns against redirecting many unrelated old URLs to one destination such as the home page because this can confuse people and may be treated as a soft 404. Consolidation is different when several old pages genuinely become one useful replacement.
- Every indexable current URL has a keep, redirect, consolidate or remove decision.
- Priority URLs have a named content owner and business approval.
- Redirect destinations match the former purpose closely enough to help the visitor.
- Internal links will point directly to final URLs instead of relying on redirects.
- Canonical URLs, sitemap entries, hreflang and campaign links use the final format where applicable.
- The map includes a test result and an owner for every failure.
Preserve useful content, metadata and internal context
A redesign can keep the same URL while removing the information that made the page useful. Compare priority pages before and after the rebuild. Check the purpose, title, main heading, body content, images, structured data, canonical, indexability and links from other relevant pages.
Preservation does not mean freezing poor content forever. It means changing important elements deliberately, with a clear reason and an ability to identify which change may have affected performance. Schedule speculative rewrites after the migration when they are not required for the release.
Page purpose
The new page still answers the valuable customer need and gives the intended visitor a clear next action.
Search context
Useful titles, headings, copy, media, structured information and descriptive internal links are retained or improved intentionally.
Template behaviour
Mobile rendering, navigation, pagination, filters, JavaScript content and response codes work on representative page types.
Business function
Forms, calls, carts, bookings, logins, downloads and consent controls work in the production configuration.
Test redirects, canonicals and internal links before launch
Test the redirect map in a staging, preview or local environment when the infrastructure allows it. Permanent server-side redirects are appropriate for lasting URL changes. Reject loops, chains, temporary responses used by mistake and destinations that do not match the map.
Check that new pages use their intended canonical URLs and that internal links, structured data, sitemaps and alternate language annotations point to the final production addresses. Redirects can transfer users and signals, but clean internal references reduce unnecessary hops and simplify future maintenance.
- Each old priority URL returns one expected redirect to one working destination.
- No priority redirect enters a loop or unnecessary chain.
- Every priority destination returns the expected working response.
- New indexable pages self-canonicalise unless an intentional alternative is documented.
- Navigation, body links, breadcrumbs and XML sitemaps use final production URLs.
- Redirect rules preserve needed paths and query behaviour without creating broad accidental matches.
- The production test plan repeats these checks immediately after deployment.
Test crawl controls, forms and measurement in staging
Protect staging from unintended indexing, but do not rely on a rule that can silently reach production. Google recommends removing temporary crawl blocks and noindex rules when the new site goes live. Assign one person to verify the rendered page, response headers and robots.txt on production.
Test analytics and enquiry paths with the production configuration. Confirm that page views and meaningful actions carry the correct page, form and campaign context. A successful form screen is not enough if the enquiry never reaches the business or the event fires twice.
- Staging access controls and noindex behaviour are documented.
- A production check will confirm no unintended robots or noindex blocks remain.
- Search Console verification methods survive the move.
- GA4 configuration, consent behaviour and key events work without duplicate firing.
- Forms and transactional paths reach the expected people and systems.
- The launch team can distinguish a tracking failure from a real conversion decline.
Use a controlled launch sequence
Record the deployment time and version, then work through the priority test set before broad spot checks. Verify server responses, redirects, canonicals, crawl controls, content, navigation, forms and analytics. Log failures with the time found, owner, fix and verification result.
Publish the final XML sitemap and submit it in Search Console. Verify the relevant properties. Use Search Console's Change of Address tool only for an eligible domain or subdomain move, not for path-only changes, an HTTP to HTTPS move or a www change. Check the current eligibility rules before submitting.
- Deployment, DNS or routing changes have a timestamp and named owner.
- Priority old and new URLs pass the expected response and content checks.
- Production robots, noindex and canonical rules match the approved state.
- Internal links and the XML sitemap expose the final URLs.
- Search Console verification and any eligible Change of Address action are complete.
- The business confirms that important customer actions work end to end.
Check the first hour, day, week and month
Monitor the release at increasing intervals. Start with server health, priority pages and conversion paths. Then review crawl errors, indexing, sitemap processing, search pages and query groups, organic landing behaviour and verified lead quality.
Google states that temporary visibility fluctuations can occur during a URL-changing move and that processing depends on factors including site size and server speed. Avoid promising a fixed recovery date. Compare like periods, annotate the launch and investigate page groups rather than treating one sitewide average as the explanation.
Google recommends keeping redirects for as long as possible and generally at least one year. Update important internal links immediately and ask owners of valuable external links to use the final URLs where appropriate.
First hour
Check availability, priority responses, redirects, crawl controls, forms, key events and severe server errors.
First day
Run a broader crawl, inspect sitemap access, verify analytics coverage and resolve patterns that affect multiple templates.
First week
Review Search Console discovery, indexing and relevant page or query groups beside organic landing behaviour and lead records.
First month
Compare the agreed baseline, document unresolved changes and decide which post-migration improvements can begin safely.
Document failures, fixes and rollback decisions
Define rollback triggers before launch. Examples can include widespread server errors, broken priority redirects, production noindex rules, failed checkout or lead forms, or a deployment that cannot serve essential content. The trigger should state the evidence and who decides, not rely on an argument during the incident.
Keep the issue log after launch. It becomes evidence for the closeout review and the next release. Record what failed, why it mattered, when it was corrected and how the correction was verified. Close the migration only when critical issues have owners or confirmed resolution and the business accepts the remaining risk.
- Every critical failure category has a measurable trigger and authorised decision owner.
- The team knows whether rollback is technically possible and what data could be lost.
- Issues record the affected URL or function, time, evidence, owner and status.
- A correction is not closed until the original check passes again.
- Post-launch work separates migration defects from optional improvements.
- The final review records lessons, outstanding risk and ownership after handover.
Sources and further reading
Primary and authoritative sources used to support the factual guidance in this resource.
- Source 01Google site moves with URL changes, opens in a new tabOfficial planning, redirect, sitemap, monitoring and link update guidance for moves that change visible URLs.
- Source 02Google hosting changes without URL changes, opens in a new tabOfficial preparation, DNS, crawl access and monitoring guidance for infrastructure moves with stable URLs.
- Source 03Google redirects guidance, opens in a new tabOfficial guidance on permanent, temporary and alternative redirect methods for Google Search.
- Source 04Google canonical URL guidance, opens in a new tabOfficial guidance for communicating a preferred URL among duplicate or similar pages.
- Source 05Google XML sitemap guidance, opens in a new tabOfficial requirements and recommendations for building and submitting sitemaps.
- Source 06Search Console Change of Address guidance, opens in a new tabGoogle's eligibility, preparation and monitoring guidance for qualified domain and subdomain moves.