Technical SEO guide
SEO migration checklist: move or rebuild a website without losing the thread
A migration is a change to the routes through which customers and search engines find the business. Treat it like a move: prepare the new place, leave a clear forwarding address and monitor the handoff.
The migration principles I keep returning to.
- Define exactly which domain, URL, platform and content changes are happening before the build starts.
- Map every meaningful old URL to the closest honest new equivalent, then test redirects directly.
- Expect temporary fluctuation and monitor it; do not make several reactive changes at once.
Define exactly what is changing—and what should stay stable
A migration might be a domain change, a move from HTTP to HTTPS, a change from old page paths to cleaner ones, or a full platform rebuild. Each introduces different risks. Google’s site-move documentation recommends changing one thing at a time where possible, because simultaneous domain, CMS, design and content changes make it much harder to isolate a problem.
Before building, I write a one-page migration brief: old hostnames, new hostnames, current indexable pages, pages that bring enquiries, key conversion paths and the launch date. This is also when I identify content that should be retired deliberately rather than accidentally disappearing.
- List the exact domains, subdomains and URL patterns involved.
- Identify important pages from analytics, Search Console and actual customer journeys.
- Choose a quieter period where possible, not the middle of a campaign or seasonal peak.
- Avoid combining an SEO migration with unreviewed copy deletion.
Build a one-to-one URL map before launch
The central migration document is a URL map: every meaningful old URL, its intended new equivalent, and the redirect status. A service page should redirect to the matching new service page; an old guide should redirect to its updated successor. Sending everything to the homepage is tempting, but it gives customers a worse experience and discards the page-level context the old URL had accumulated.
If there is no honest replacement, I decide that openly. Some expired pages may deserve a proper 404 or 410 rather than a misleading redirect. The decision must be purposeful, not an artefact of launching a new template with missing pages.
- Map every old URL to the closest relevant new URL.
- Use permanent server-side redirects for genuine permanent moves.
- Do not create redirect chains; an old URL should reach the final destination in one hop.
- Keep a copy of the map for testing and support.
Make the destination site crawlable and internally coherent
Before switching, I crawl the new site as if I had never seen it. Every public page should return the right status, have a sensible title and main heading, be linked from appropriate navigation or a related page, and name its preferred canonical URL. Robots.txt should allow crawling of pages and essential resources that need to be understood. The XML sitemap should list only final, indexable canonical URLs.
A migration is also where temporary development protections can leak into production. I check for noindex tags, password prompts, blocked styles or scripts, test-subdomain canonicals, and staging addresses in structured data. One leftover setting can make an otherwise polished site invisible to search systems.
- Test important paths on mobile as well as desktop.
- Remove noindex and authentication from public pages at launch.
- Ensure canonical URLs point to the new preferred production URLs.
- Generate a clean sitemap and expose it through robots.txt.
Launch in a way that preserves people and signals
At launch, I enable the redirects, publish the new pages, confirm the preferred HTTPS host, and check the critical routes immediately: homepage, leading services, contact page, old high-value URLs and sitemap. Google’s recommended sequence is to prepare and test the new site, prepare the URL mapping, configure redirects, then monitor old and new URLs.
For a domain change, I keep the old domain under control and keep redirects operating. Customers may use an old brochure, a saved WhatsApp preview or an external link for months. Removing the old domain early is not a clean break; it is a broken handoff.
- Test redirects with exact old URLs, not just a homepage redirect.
- Submit the new sitemap in the correct Search Console property.
- Use Search Console’s Change of Address process when the move qualifies.
- Update essential external profiles and business listings to the preferred new URL.
Monitor calmly after the switch
Temporary movement in search visibility can happen during a site move. I do not react to a one-day fluctuation by changing titles, canonicals and redirects all at once. I monitor Search Console indexing, crawl errors, the sitemap report, selected redirects, organic landing pages and enquiries. The goal is to spot a real pattern: pages not moving, redirects failing, an accidental noindex, or a spike in 404s.
If something looks wrong, I start with the URL map and the live page. A public-page check can help identify a page-level issue, but the migration record is what tells me whether an old address was actually given the correct new destination.
- Monitor both old and new URLs during the transition.
- Keep redirects live while customers and search engines still use old links.
- Prioritise pages that previously brought qualified enquiries.
- Document fixes so later changes do not recreate the same fault.
Common questions
Questions worth settling before you commit.
Will a website migration always reduce rankings?
A migration can cause temporary fluctuation, and there is no way to guarantee identical results throughout the change. Careful mapping, redirects, testing and monitoring reduce avoidable loss.
Can I redesign, change domain and rewrite all content at once?
You can, but it is harder to diagnose and riskier. Google recommends changing one thing at a time where practical. If a combined move is unavoidable, make URL mapping and pre-launch testing especially rigorous.
How long should I keep redirects?
Keep them while old URLs can reasonably be reached through search, links, saved bookmarks and printed material. A permanent migration needs a durable forwarding plan, not a short launch-week workaround.