QUAKE MEDIA / THE PRACTICAL GUIDE
Website migration best practices: plan, test and monitor the move
Plan a website migration with a URL inventory, relevant redirects, staging checks, data and form validation, a rollback plan, and post-launch monitoring.
Explore the guideBy Quake Media · 4 minute read
Move the site. Keep the connections.
A framework for the decisions in this guide.
Inventory / EXPLORE THE DETAILS
The starting point
A website migration can change hosting, a content management system, a domain, URL paths, or several of these at once. The work depends on what is changing. Start by defining the scope, assigning owners, and recording how the current site behaves so you can compare it with the new site.
Search visibility can fluctuate during a move, and no checklist can guarantee unchanged rankings. Google recommends preparing and testing the new site, mapping old URLs to their new destinations when URLs change, implementing redirects, submitting the new sitemap, and monitoring both sites. See Google’s site-move guidance and its separate hosting-change guidance.
Redirect map / EXPLORE THE DETAILS
Before the move: make an inventory
- Record the migration type: hosting change, domain change, URL restructuring, platform change, redesign, or a combination.
- Build a list of current URLs from the site crawl, XML sitemap, analytics, Search Console, and known campaign or partner links. Include important files and media URLs where they need to remain available.
- Record each page’s purpose, status code, title, description, canonical URL, indexability, and important internal links. Note forms, checkout steps, logins, search, downloads, and other functions that must continue to work.
- Save recoverable copies of the site files, database, configuration, DNS settings, and current redirect rules. Confirm that backups can be restored and identify who can do it.
- Capture a baseline for traffic, enquiries or sales, crawl errors, and key search pages. Keep the date range and data source with the record so post-launch comparisons are meaningful.
Launch checks / EXPLORE THE DETAILS
Map content and redirects
For every URL that changes, choose the closest equivalent destination that serves the same user need. Redirect changed pages with a permanent server-side redirect when appropriate. Do not send unrelated or deleted pages to the home page; keep a useful replacement when one exists, otherwise return the correct not-found or gone response. Test the mapping for loops, chains, wrong destinations, and missing pages.
Update internal links, navigation, canonical references, structured data URLs, campaign links, and other links you control to point directly to the final URLs. Keep redirects in place for as long as practical; Google recommends at least a year for URL-changing moves. For a hosting move with unchanged URLs, follow the infrastructure-change process rather than inventing URL redirects.
Inventory / EXPLORE THE DETAILS
Prepare and test the new site
- Build the destination on staging and compare representative page types against the inventory: pages, articles, products, categories, media, and any custom content.
- Check that important page content, headings, page titles, descriptions, structured data, and preferred canonical URLs have carried over correctly.
- Check that the production robots.txt will allow intended crawling and that migration-only noindex or crawl blocks are removed at launch. Do not use robots.txt as a way to prevent indexing of URLs that should be removed from search.
- Generate a sitemap containing the final, canonical URLs that should be discoverable. Validate its responses and submit it after launch. Keep redirects and sitemap entries consistent.
- Test forms, notifications, checkout, payment, account access, search, consent controls, analytics, and any integrations with realistic test data. Confirm that submissions reach the right systems.
- Check mobile and desktop rendering, accessibility basics, page errors, SSL, caching, and performance on the staging environment.
Redirect map / EXPLORE THE DETAILS
Launch with a rollback plan
Choose a launch window when the people who can change DNS, deploy the site, restore data, and verify business functions are available. Record the final backup, deployment steps, DNS or hosting changes, redirect activation, and the decision-maker for rollback. Agree in advance what failure conditions trigger a rollback and how to restore the previous site.
At launch, verify representative old URLs and their destinations, key new pages, media, forms, checkout or enquiry flows, analytics events, and server responses. Confirm that the new site is accessible to users and crawlers and that no staging restrictions remain. Keep the previous environment available until the new one is serving correctly and the recovery window has passed.
Launch checks / EXPLORE THE DETAILS
Monitor after launch
- Review server logs and uptime for both old and new infrastructure where available. Watch for errors, unexpected traffic patterns, redirect loops, and requests to URLs missing from the map.
- Use Search Console to review sitemap processing, indexing signals, crawl errors, and affected URLs. Inspect examples that are missing or returning unexpected responses.
- Compare analytics and business outcomes with the recorded baseline, accounting for seasonality, tracking changes, and other work happening at the same time.
- Fix redirect and internal-link issues promptly. Update external profiles and campaign links you control. Keep the migration log and note what was changed.
Google notes that visibility may fluctuate temporarily and that processing time depends on the number of URLs and server speed. Monitor the move until important old URLs have been recrawled and the new pages are functioning as intended; do not promise a fixed recovery date.
FROM READING TO DOING
Make your next
move a clear one.
Bring us your goals and the questions this guide raised. We’ll help you work out what belongs in your plan.
Talk it through with Quake