Key takeaways
- Export a full crawl with status codes and canonicals before planning the new site.
- Map every old URL to one closest replacement in a single permanent redirect.
- Keep staging authenticated, noindexed, and out of the sitemap.
- Verify redirects, indexation, and conversions in the first 48 hours after launch.
On this page
Crawl the current site and keep the evidence
Run a full crawl before planning anything and export every URL with its status code, canonical, title, meta robots directive, and internal link count. The digital marketing and SEO service covers the ongoing audit after migration. Add the pages that earn the most organic clicks and the pages with the most external links, because those are the ones a migration must not lose.
Save the export with the date and the crawl settings. When rankings move after launch, comparing the pre-migration inventory with the post-migration crawl is the fastest way to find what broke.
Map every URL to one destination
A redirect map is a list with one row per old URL and one destination. Every row should resolve in a single permanent redirect. Chains, where one URL redirects to another that redirects again, slow the request and dilute the signal.
- Map to the closest equivalent page, not the home page.
- Keep the trailing-slash policy identical on both sides.
- Preserve parameters that serve content; drop tracking parameters from redirects.
- Retire pages that genuinely no longer exist with a 404, not a redirect to an unrelated page.
- Keep the redirect map in version control so it can be reviewed and repeated.
Carry over the signals that earn traffic
Titles, descriptions, headings, and internal links should move with the content. Canonical tags must point to the new URL, and any hreflang cluster must be updated as a set; changing a single URL in a language pair breaks the pairing.
Structured data needs the same treatment. Update organisation, product, article, and breadcrumb markup to the new URLs, and keep the same entity identifiers where they exist. Search Console verification, analytics, and third-party verification files must move too.
Control staging before the cutover
Staging should never be indexable. Put authentication or an IP allowlist in front of it, and keep a noindex directive as a second layer in case the authentication is removed. Do not copy production canonicals onto staging pages, and do not let a staging sitemap reach search engines.
Rehearse the migration on staging with a hosts file entry so the domain resolves to the new environment. Test redirects, forms, navigation, and structured data there before touching production DNS.
Rehearse the switch and name the rollback
Lower the DNS time to live at least a day ahead and confirm the new environment can serve the site without the old one. Write the cutover order: deploy, verify on the new host, switch DNS, check the certificate, then submit the sitemap.
Name one person who decides whether to continue or roll back, and define the trigger in advance, such as a redirect failure rate or a form that stops delivering. A rollback plan written during an incident is not a plan.
Verify the migration in the first 48 hours
Sample redirects across each template and check the status code and destination. Watch server logs for 404 spikes, confirm the sitemap is reachable and submitted, and check that internal links point to the new domain rather than the old one.
Then follow the traffic. Compare landing pages, impressions, and conversions with the baseline. Recovery is rarely instant, but a sharp and sustained drop in indexed pages or a redirect loop is a fault to fix, not a waiting game.
| Phase | Check | Evidence |
|---|---|---|
| Before | Full crawl exported | URL inventory with status and canonical |
| Before | Redirect map complete | One destination per old URL |
| Before | Staging protected | Authentication and noindex verified |
| Launch | DNS and certificate | HTTPS loads without warnings |
| After | Redirect sample | Single 301 to the right page |
| After | Sitemap and indexation | Submitted, no noindex on production |
Frequently asked questions
How long should redirects stay in place?+
Keep permanent redirects indefinitely. They are cheap to serve and continue to help external links and bookmarks resolve. Remove them only when the old URLs no longer receive traffic or links.
Should every old URL redirect to the home page?+
No. A redirect to an unrelated page is treated as a soft 404 and wastes the value of the link. Map to the closest equivalent, and use a 404 for content that has genuinely been removed.
What is the biggest migration risk?+
An incomplete URL map is the first thing to check: pages that were never redirected, or canonicals that still point to the old domain.
Does the sitemap need to be resubmitted?+
Yes. Submit the new sitemap after the switch and keep the old one available briefly so crawlers can follow the redirects.
Need help applying this?
Get help with Digital Marketing & SEO.
Review the service scope or tell us what you are trying to improve. We will reply with a clear next step.
Free KPI definition templateRelated reading
A technical SEO audit checklist for an existing site
A practical technical SEO audit: crawl and compare, check indexation and canonicals, fix internal links, review performance, and monitor changes.
How to structure a service page for search and conversion
A practical service-page structure: one intent, a clear outcome, honest proof, deliverables, process, objections, internal links, and a measurable CTA.