How to migrate a website without losing rankings: the complete procedure

What counts as a migration, and why it is risky

In SEO, a migration is any change that significantly alters how Google discovers, crawls or interprets your website. You do not have to change domain:

Type	Example	Main risk
Domain change	from company.es to company.com	Every URL changes; signals must be passed on through redirects.
Protocol or subdomain change	HTTP to HTTPS, www to non-www	Incomplete redirects, mixed content, old canonicals.
URL structure change	/blog/2023/post to /resources/post	Incomplete redirect map, broken internal links.
CMS or platform change	From one CMS to another, or to a hosted shop platform	Unplanned changes to URLs, templates, metadata and structured data.
Redesign or content change	A new site with fewer pages or shorter copy	Loss of content that ranked, changes to internal linking.
Language or country change	Moving from subdomains to language folders	hreflang and canonicalisation errors.

Most often several types are combined: new CMS, new design and new structure all at once. Each layer adds risk, and when something goes wrong it is hard to tell which change caused it. If you can split the changes into phases (for example, the platform first while keeping URLs, and the restructure afterwards), diagnosis becomes far simpler.

It is also worth setting expectations: even a well-executed migration can cause temporary fluctuations while Google crawls and reprocesses the new URLs. The aim is for them to be short and moderate, not for them not to exist.

Step 1: a complete URL inventory

You cannot redirect what you do not know exists. The inventory must gather every URL with value, not just those in the menu. The sources we combine:

• A full crawl of the current site with a crawling tool (Screaming Frog, Sitebulb or similar), including images and PDFs.
• Current XML sitemaps.
• Google Search Console: pages with impressions or clicks over the last 16 months (the most the tool keeps) and the indexing report.
• Google Analytics: landing pages with organic sessions and conversions.
• Backlink tools: URLs that receive external links, including old pages that already return 404 but are still linked to.
• Server logs, if available: URLs Googlebot actually visits.

The result is a spreadsheet with one row per URL and columns for organic traffic, conversions, external links, indexing status and page type. That sheet becomes the basis for everything else, and your "before" snapshot for comparison.

Before the map: keep, consolidate or remove

A migration is a good opportunity to tidy up content, but it is also the quickest way to lose what was working. With the inventory in front of you, assign each URL one of four decisions:

Decision	When it applies	What to do
Keep	The page has traffic, links or conversions, and its content is still valid.	Migrate it with the same main content; improve it later, not at the same time.
Consolidate	Several pages compete for the same intent or are near-identical variations.	Merge them into one more complete page and redirect all the old ones to it.
Update	The topic is valuable but the content is out of date.	Rewrite it, keeping the URL or redirecting to the new version.
Remove	No traffic, no links, no value to users (expired promotions, test pages).	Return 404 or 410, and take it out of internal linking and the sitemap.

Do not forget resources that are not pages. Images can receive traffic from Google Images and direct links; if their paths change, redirect them too, especially those that appear in the inventory with visits or links. PDFs (catalogues, technical sheets, guides) tend to collect external links for years and are the classic forgotten asset. And if you are rebranding at the same time as changing domain, remember that the entity changes too: update your Organization structured data, the profiles linked through sameAs and your directory listings, so that search engines and AI assistants connect the new brand with the old one's reputation.

Step 2: the redirect map

The map assigns each old URL its destination on the new site. The basic rules:

1. One-to-one 301 (or 308) redirects to the most equivalent new page. Google treats permanent redirects as a strong signal that the new URL is canonical.
2. Do not redirect everything to the homepage. Google tends to treat mass redirects to an unrelated page as soft 404 errors, and the value of those URLs is lost.
3. No chains. If a URL already redirected somewhere, update the old rule so it points straight to the final destination.
4. For removed content with no equivalent, a 404 or 410 is more honest than a forced redirect. Check first that the page has no meaningful traffic or links; if it does, the content may deserve to be kept.
5. Pattern-based rules where possible (regular expressions on the server), but validate each pattern against the inventory: patterns go wrong in edge cases.
6. Include parameters, capitalisation, trailing slashes and legacy versions (HTTP, www) that still receive visits.

Old URL                              → New URL                           Type
/services/local-seo.html             → /services/local-seo/              301
/blog/2023/05/hreflang-guide/        → /resources/blog/hreflang/         301
/summer-promo-2021/                  → (no equivalent, no links)         410

Google recommends keeping redirects in place for as long as possible, and for at least a year. In practice, if you can, never remove them: external links and users' bookmarks will keep pointing at the old URLs for years.

Step 3: protected staging and QA

The new site should be built and tested on a staging environment that Google cannot index. The most reliable option is HTTP authentication or IP restriction; you can add noindex as a second barrier. Blocking with robots.txt alone is not enough: it prevents crawling, but a blocked URL can still be indexed if it receives links.

This is where the most classic migration error is born: the staging noindex or Disallow: / travels with the code to production. Put it in bold on the launch checklist, with the name of whoever removes it and whoever checks it.

On staging, validate the following against the inventory:

• Content: pages with traffic keep their main copy, titles, headings and structured data, or improve them deliberately.
• Metadata: title, meta description, canonical (pointing to the production domain, not staging), hreflang, robots directives.
• Internal linking: links point to the final new URLs without going through redirects.
• Rendering: the main content is in the HTML or renders correctly; test with the URL Inspection tool as soon as you can.
• Performance: the new site is not slower than the old one; check Core Web Vitals in lab tests.
• Analytics: GA4 tags and conversions are installed and work with the consent banner.
• Redirects: the map is loaded and tested (you can crawl the list of old URLs against staging if the environment allows).

Step 4: the launch-day checklist

Choose a quiet commercial period, never right before a long weekend or your high season, with the technical team available for the following days.

1. Full backup of the old site and an export of its final crawl.
2. Deployment, and removal of staging protection, noindex and robots.txt blocks.
3. Redirects switched on; immediate test of a sample of priority URLs, then the complete list with a crawler in list mode.
4. Check robots.txt and an XML sitemap with the new URLs (200 status and canonical only), and submit it in Search Console.
5. For domain changes: verify both properties in Search Console and use the Change of Address tool. Keep the old property too, so you can follow its data.
6. Check HTTPS, certificates and canonical versions (with and without www).
7. Inspect key URLs in Search Console and request indexing for the most important ones.
8. Review real-time analytics: visits and conversions are being recorded.
9. Update the links you control: Google Business Profile, social profiles, Google Ads campaigns, email signatures, directories.

Step 5: post-launch monitoring

The first few weeks are critical. A sensible schedule:

When	What to check
First 24–72 hours	404 and 5xx errors in logs and crawls, failing redirects, pages with noindex, conversions in analytics.
First week	Crawl stats and the indexing report in Search Console, coverage of the new sitemap, old URLs still appearing in results.
Weeks 2–8	Clicks and impressions compared with the previous period (and the same period last year if there is seasonality), by page group; queries that have dropped; important external links pointing to 404s.
Months 3–6	Stabilisation, improvement opportunities, clean-up of any redirect chains that have crept in.

Always compare by page group (services, categories, product pages, blog), not just the total. A drop in the total can hide the fact that one section has lost almost all its traffic because of a badly written redirect pattern.

If traffic does fall beyond the expected fluctuation, triage in order: first, can Google crawl and index the new pages (robots, noindex, canonicals)? Second, do the old URLs redirect correctly and in a single hop? Third, has the content or internal linking of the affected page group changed? Only once those three are ruled out does it make sense to look for external causes, such as an algorithm update that coincided with the launch.

Typical failures and how to spot them

• Staging noindex or robots.txt in production. A crawl detects it within hours; it takes weeks to show in traffic, by which time the damage is done.
• Redirects to the homepage or generic categories. They show up as soft 404 in Search Console.
• Trimmed content. The redesign removes the "long" copy that was precisely what ranked. Compare length and headings on your highest-traffic pages.
• Canonicals pointing to staging or the old site. Visible in the crawl and in URL Inspection.
• Internal links to old URLs that go through redirects or, worse, end in a 404.
• Lost structured data (products, FAQs, breadcrumbs) when templates change.
• Changes to faceted navigation that create thousands of new crawlable URLs and dilute crawl budget, a typical risk for online shops.
• Broken analytics exactly when you most need to measure.
• Language versions left behind: hreflang pointing to old URLs, or versions launched weeks later. We cover this in multilingual SEO and hreflang.

Timelines, roles and when to get help

The SEO workstream of a migration should begin when the new architecture is being defined, not the week before launch. As a rough guide, for a medium-sized corporate site, the inventory and redirect map take several weeks of work coordinated with the development team; for large sites or shops with thousands of products, longer. Agree from the outset:

• SEO lead: inventory, map, QA criteria and monitoring.
• Technical lead: implementing redirects, environments, deployment.
• Content lead: making sure no valuable copy is lost and new content meets the minimum standard.
• Who decides whether launch is postponed if QA does not pass.

If your team has never run a migration, or organic search drives a significant share of your sales, it is worth bringing in specialist support at least for the inventory, the map and the pre-launch review. Many of the technical checks in this article also appear in our SEO checklist.

Conclusion

Migrating without losing SEO is above all a matter of method: know what you have, decide where each thing goes, test it before Google sees it and watch it afterwards. Serious failures are almost always avoidable and almost always detectable with a timely crawl. If you are planning a new website, talk to us before you fix the launch date: reviewing the plan at the start costs far less than recovering traffic later. Start with an audit or get in touch.