How to Migrate a Website Without Losing SEO Rankings
To migrate a website without losing rankings: inventory every indexed URL before anything changes, map each one to a single new destination with a 301 redirect, keep titles and substantive content intact on pages that already rank, crawl staging to confirm every redirect resolves in one hop, then monitor 404s and indexation for several weeks after cutover. Nearly all migration traffic loss traces back to one of three causes — a missing redirect, a redirect chain, or money pages that got thinner in the rebuild.
This guide covers the process in the order you actually have to do it. If you want the task-by-task version to work through, the website migration checklist is the companion artifact to this article.
What actually counts as a migration?
A migration is any change that alters the addresses search engines already have on file, or the platform serving them. In practice that means replatforming, moving to a new domain, merging several sites into one, moving from HTTP to HTTPS, changing URL structure, or restructuring an information architecture so pages move to new paths.
A visual reskin that leaves every URL exactly where it was is not a migration. The moment one indexed URL changes address, you are migrating, and the work below applies in proportion to how many URLs move. This distinction matters because plenty of projects sold as "just a refresh" quietly become migrations the day someone decides the navigation should be reorganised.
Step 1: Build the URL inventory first
One spreadsheet becomes the source of truth for the entire project. Pull URLs from four separate places, because no single source is complete:
- A full crawl of the current site — catches what is linked from navigation.
- The XML sitemap — catches what the CMS thinks exists.
- Search Console's indexed pages report — catches what Google actually holds, including pages nobody remembers publishing.
- Analytics for the last 12 months — catches orphaned pages that still earn traffic despite being linked from nowhere.
For every URL, record the current address, the page type or template, organic sessions and enquiries over 12 months, the number of referring domains, and current indexation status. Those last columns are what turn a flat list into a priority order. A mistake on a page with 40 referring domains and a steady enquiry history costs real money; a mistake on a 2019 announcement post does not.
Step 2: Map every old URL to exactly one new URL
Every row in the inventory needs one of three decisions: the address stays the same, it redirects to a specific new address, or it is deliberately retired. Write the destination explicitly for every redirect — "TBC" in a redirect map is how pages go missing.
Two mistakes cause most of the damage:
- Bulk redirects to the homepage. Redirecting a large group of retired pages to the homepage is treated as a soft 404, because the destination does not answer the query the original page answered. Redirect to the closest genuine equivalent instead.
- Redirect chains. An old URL pointing to another old URL that points somewhere else wastes crawl budget and loses signal at each hop. Every redirect should resolve to a live page in a single step, including redirects inherited from previous migrations.
Where a URL genuinely keeps its address, mark it as such rather than leaving the cell blank. A blank cell is indistinguishable from an unfinished decision when you are checking coverage the night before a cutover.
Step 3: Preserve what search engines already trust
The signals that took years to earn should survive the move deliberately, not by luck.
| Signal | What to do | Why it matters |
|---|---|---|
| Title tags and meta descriptions | Carry across for ranking pages rather than regenerating from a template | Templated rewrites often drop the exact phrasing the page ranked on |
| Body content on money pages | Keep substantive content and heading structure intact | A page that ranks on 900 words and loses 500 has materially changed |
| Structured data | Reproduce equivalent markup on the new templates | Losing Article, FAQPage or LocalBusiness markup removes rich result eligibility |
| Canonical tags | Update to the new URL pattern and verify no stale references remain | Stale canonicals quietly confuse indexing for months |
| Deliberate noindex rules | Carry across intentionally, and audit what should not carry across | Losing an intentional noindex indexes thin or private pages |
Content parity does not mean the new site must look the same. It means the page still answers the same question, for the same audience, with at least the same substance. Redesigning the presentation is fine. Quietly halving the copy because the new template has less room is what causes rankings to slide.
Step 4: Crawl staging before anyone launches anything
Run a full crawl of the staging build and diff it against the inventory. You are verifying that every mapped redirect resolves in one hop to a live page, that no page is missing a title or an H1, that internal links point at new URLs rather than relying on redirects to clean up after them, and that no page is orphaned from navigation.
Two staging-specific checks deserve their own line. First, confirm staging is blocked from indexing while it is publicly reachable. Second — and this is the one that actually hurts — confirm the block is removed at cutover. A site that launches with its staging noindex still attached disappears from search results entirely, and nothing on the page looks wrong.
Check template-level performance here too. Migration is when Core Web Vitals regressions get baked in across every page at once, and they are far cheaper to fix before launch than after.
Step 5: Cut over with a rollback plan
Choose a launch window when the people who can fix things are awake and available. Lower the DNS TTL well in advance so a rollback propagates quickly if you need one. Keep the previous site restorable — a rollback plan you never use costs a few hours of preparation; not having one costs days of downtime.
Immediately after switching: verify a sample of redirects against the live site, confirm key pages return 200, check that robots.txt is the production version rather than the staging one, and submit the new XML sitemap in Search Console. For sites with meaningful revenue, moving one template or section at a time contains the blast radius of any single mistake.
Step 6: Monitor for a defined window
Watch crawl errors, 404 reports, indexed page counts and rankings for high-value terms daily for the first two weeks, then weekly. Each symptom points somewhere specific:
- Rising 404s — a redirect was missed, or an internal link still points at a retired URL.
- Falling indexed count — check the sitemap, then internal linking, then robots rules, in that order.
- One template dropping while others hold — the problem is in that template, not the migration as a whole. Check its titles, headings and structured data.
Expect some movement. A well-executed migration commonly sees short-term volatility that settles as search engines reprocess the new structure. What you control is whether that volatility has a cause you introduced.
How Devoq runs migrations
Migrations at Devoq are scoped from the URL inventory outward, not from the design inward — the redirect map is a named deliverable rather than a launch-week scramble. A full website redesign with SEO-safe migration starts from $10,000 AUD ex GST, and complex migrations with larger content volumes, replatforming or heavy integrations typically run $25,000+ AUD ex GST. The free website cost calculator gives an indicative range before you ask for a quote. Scope is quoted after the inventory, because page count alone does not tell you how much redirect and parity work a site needs.
If the visibility work continues past launch, SEO & AEO services covers recovery and growth on the new structure. If you are still deciding whether the site needs a rebuild at all, when to redesign your business website is the more useful starting point.
Frequently asked questions
How long does it take to recover rankings after a migration?
Some volatility in the first few weeks is normal while search engines recrawl and reprocess the new structure. With complete redirects and content parity, recovery is usually measured in weeks to a few months depending on site size and how often the site is crawled. If traffic is still down well beyond that, the cause is almost always a specific technical fault rather than a waiting game.
Do we need to redirect every single old URL?
Every URL that is indexed, has referring domains, or has earned traffic in the last 12 months needs a decision. Genuinely obsolete pages with no links and no traffic can be retired with a 410. What causes damage is not deliberate retirement, it is pages that disappear by accident because nobody inventoried them.
Should we redirect old pages to the homepage?
No. Bulk-redirecting to the homepage is treated as a soft 404 because the destination does not satisfy the intent of the original page. Redirect to the closest equivalent page. If no equivalent exists, redirecting to a relevant category or parent is better than the homepage, and an honest 410 is better than a misleading redirect.
Can we migrate and redesign at the same time?
You can, and many businesses do, but it makes diagnosis harder. If rankings drop you will not know whether the cause was URL changes, content changes or template changes. On a site with significant organic traffic, migrating first on stable templates and redesigning afterwards makes each change diagnosable — at the cost of a longer programme.
What is the most common cause of traffic loss in a migration?
Missing redirects and thinner content on money pages, in that order. A close third is a staging noindex left in place at cutover, which removes the entire site from search results and is invisible until traffic collapses. All three are preventable with a pre-launch crawl.
Talk to Devoq about your migration — bring your URL list and current analytics access, and the first conversation can be about actual risk rather than guesswork.
