Blog
The risk sits in your addresses, not your technology.
How to run a migration without losing rankings, with attention to redirects, markup and load times.
The biggest risk in a migration sits in your addresses, not in your technology.
A new CMS, different hosting or a new theme costs you no rankings by itself, as long as your addresses, your markup and your load times move with it.
That only goes wrong when a page that sat at the same address for years suddenly lives elsewhere, with nothing connecting the two.
That last part is manual work and the one part of a migration you cannot fix afterwards.
For many Drupal sites, that is exactly what's happening now.
Drupal 10 reaches end of life on 9 December 2026 and 10.6.0 is the last minor release, Drupal 7 has been out of support since 5 January 2025 and Drupal 12 arrives in the week of 7 December 2026.
Anyone migrating this winter is doing it under time pressure, and the redirect plan is usually the first thing to suffer.
The URL inventory comes before everything else
You start with a list of every address that exists today, not the pages you want to keep.
The addresses that bring in traffic are rarely the ones in your menu: a 2019 press release with twenty inbound links carries more weight than your new services page.
Five sources together give you the full picture.
| Source | What it gives you |
|---|---|
| XML sitemap | What your site thinks it publishes, usually only the pages you want indexed |
| Full crawl | Everything linked internally, including pagination, facets, feeds and PDFs |
| Search Console, Pages and Performance reports | What Google actually knows (Pages report, around three months of history) and which addresses generate clicks (Performance report, sixteen months back) |
| Server logs | Addresses still being requested but no longer linked anywhere |
| Backlink data | External links to pages you had forgotten about yourself |
For each address you record status code, canonical, indexability, inbound links and twelve months of traffic.
Don't forget the non-HTML addresses: images, PDFs, feeds and language variants have one too.
Export your indexing data yourself before the migration, because that history is gone afterwards.
This list is your baseline.
The redirect plan: one 301 per old address
Every old address gets exactly one 301 to the closest matching new address.
A 301 tells search engines and AI crawlers that the move is permanent and that the accumulated signals should transfer with it.
A 302 says it's temporary: Google follows it, but doesn't use it as a signal that the new address should become canonical, so for now the old address stays canonical.
Leave that 302 in place long enough and Google usually treats it as permanent anyway, but that costs weeks you don't lose with a 301.
The mapping is a table with three columns: old address, new address and why.
That third column looks unnecessary until someone later asks why three pages were merged into one.
If there's no reasonable equivalent, a 410 is more honest than a redirect to something the visitor wasn't looking for.
In Drupal, the Redirect module handles this and the Migrate API carries over existing path aliases.
At large volumes, the rules belong at web server or CDN level, outside PHP.
What not to do
Four mistakes do most of the damage and all four cost nothing to avoid.
- Redirecting everything to the homepage. Google treats a mass redirect like that as a soft 404, so you lose exactly the signals you thought you were keeping.
- Building redirect chains. Every hop costs time and at some point the chain simply stops working.
Keep it to one hop and update your internal links to the final destination. - Carrying the staging environment over. A robots.txt that blocks everything, a noindex in the meta tags or a canonical pointing to your staging domain: the three classic reasons a site drops out of the index after launch.
- Thinking about redirects only after launch. Then you miss exactly the addresses you didn't know existed, because they aren't in the new CMS.
Checking after launch: status codes, canonicals, sitemap, structured data
On launch day you check four things.
Crawl your full old address list and check that every address lands on a 200 with one hop.
Check that every canonical points to itself, on the right domain and protocol.
The sitemap contains only addresses that return 200, no redirects and no noindex, and your robots.txt points to the right file.
Structured data is the fourth check and the one most often skipped.
Your schema.org markup sits in your theme or in your Metatag configuration, so with a new theme that markup is new and untested.
Watch the properties that hold an address themselves: @id, url, logo and sameAs surprisingly often still point to the old domain after a move.
Validate your key page types with the Rich Results Test and the Schema Markup Validator.
AI visibility needs the same work, but stricter
AI assistants read the same pages as Google, except you don't get a second chance.
On most informational search terms in my field I see an AI Overview above the regular results.
A broken reference doesn't cost you a ranking there, it costs you the mention entirely.
Three things you check separately.
Your schema.org markup needs to be correct at address level, including the sameAs references to external profiles.
An llms.txt is a list of addresses, so after a migration it's out of date by definition.
And check whether your robots.txt still allows the AI crawlers through, because that's exactly the rule that changes by accident.
To be honest about llms.txt: it's a proposal, not a standard, and nobody is obliged to read it.
I keep it up to date because it's half an hour's work.
What you measure to know it went well
Four metrics tell you whether the migration succeeded, and none of the four answer that on day one.
| What | Where | When |
|---|---|---|
| Status codes of the old address list | Crawler | Day 1, day 7, day 30 |
| Number of indexed pages | Search Console, Pages report | Weekly, for eight weeks |
| Clicks and impressions per address | Search Console, Performance report | Per URL, against the same period last year |
| LCP, INP and CLS | Search Console, Core Web Vitals | Only after a month, the field data runs on a 28 day window |
Expect a temporary dip, even with a clean migration: search engines have to request every old address again, follow the redirect and re-evaluate the new address.
What isn't normal is a dip that hasn't recovered after eight weeks.
Keep your redirects in place for at least a year, and ideally permanently.
When most of this work falls away
If your URL structure doesn't change, most of this article falls away from your project.
An upgrade from Drupal 10 to Drupal 11 within the same site keeps your node IDs and path aliases, so there's nothing to reconnect.
A crawl before and after is enough then.
The distinction between an upgrade and a real migration decides whether this is an afternoon or weeks of work.
With a platform switch such as a move from WordPress to Drupal, almost every path changes, and then this article applies from the first step to the last.
How I approach a migration
I build the inventory and the redirect plan before the first line of migration code, and deliver them as a file you can check yourself.
The technical work, the launch checks and the measurements afterwards follow from there.
More on that on Drupal migration and upgrade and technical SEO and frontend performance.
My rate is 75 to 95 euros per hour or 650 to 800 euros per day, excluding VAT, lower for long engagements and returning clients.
What a migration costs depends mainly on your number of addresses and your custom code, not on your Drupal version.
Still running a Drupal 7 site, start there. Tell me about your situation and I'll give you an honest picture of what's needed within 24 hours.
Frequently asked questions
How do you copy a website?
Copying and migrating are two different things.
A copy is a full export of files and database, to test on a second environment.
A migration moves content over to a new structure, and then your addresses usually do change.
Never put a copy on an indexable environment, since a second findable version is more damaging than none.
Can I build a website using an existing domain name?
Yes, and that's the recommended route.
Your domain carries your findability, so a new site on your existing domain doesn't start from zero.
What you do need to sort out are the addresses underneath it: every old path gets a 301 to its new path.
With a different domain, a change of address in Search Console comes on top of that.
What do I do with an old page that has no new equivalent?
Then a 410 is more honest than a 301 to something the visitor wasn't looking for.
Sending everything to the homepage is the worst option, since Google treats a mass redirect like that as a soft 404, and then you lose exactly the signals you thought you were preserving.
Note in your mapping why you chose a 410, so you don't have to make that call again later.
How long should I keep my 301 redirects in place?
At least a year, and there's no good reason to remove them after that.
Search engines need time to re-request every old address, and external links to old addresses often keep existing for years.
What you do clean up are chains, since after a second migration they need to be flattened to a single hop.
Do I always lose visitors during a migration?
Temporarily, usually yes; structurally, not if the redirect plan is right.
Search engines have to re-request every old address, follow the 301, and re-evaluate the new address, and that takes weeks.
A drop that's still there after eight weeks almost always comes from missing redirects, a noindex left over from the test environment, or an incorrect canonical.
How do I check after launch that my redirects are correct?
Crawl your full list of old addresses and check that each one ends up on a 200 with a single hop, not two or three.
Repeat that same crawl on day 7 and day 30.
Also check that every canonical points to itself on the correct domain and protocol, and that your sitemap only contains addresses that return 200.
A question about this topic?
Briefly describe your situation, and I'll let you know what's going on and what it would cost. No sales pitch.
