Replatforming a website without losing the traffic you already have
Migrations do not lose traffic because the new site is worse. They lose traffic because URLs changed with no redirects, a staging directive shipped to production, or the pages that earned the rankings were quietly shortened. All of that is preventable with an inventory built before anyone touches design. Here is the sequence we follow.
What actually causes the drop
The damage is nearly always mechanical, and it is nearly always one of a short list. Search engines have an index full of URLs that used to return content. If those URLs now return a 404, redirect to the homepage in bulk, or serve a page with a fraction of the original content, the rankings attached to them have nowhere to go.
The second category is accidental self-blocking. A staging site is protected with a robots directive or a noindex tag, that configuration is promoted with the rest of the build, and nobody notices for a week because the site looks perfect to humans. It is the single most common serious migration incident, and the cheapest to prevent with one check.
- URL changes with no redirect, or every old URL redirected to the homepage
- noindex tags or a disallow-all robots.txt carried over from staging
- Titles, meta descriptions and headings regenerated by the new platform and losing their targeting
- Pages consolidated or shortened during a content "cleanup" that removed what actually ranked
- Internal links pointing at old URLs, so every click passes through a redirect
- Images, PDFs and category pages forgotten because the inventory only covered HTML pages
The inventory you build before touching anything
Start by crawling the current site in full and exporting every URL that returns a 200, including images, PDFs and paginated listings. Then export your Search Console data for the last twelve months: top pages by clicks and impressions, and the queries that reach them. That list defines which pages are not allowed to change without a deliberate decision.
Add an analytics baseline — sessions, conversions and enquiry volume for the same period, split by device and by landing page. Without a baseline you cannot tell a migration problem from normal seasonality later, and you will end up arguing about it from memory. Finally, note current titles, meta descriptions, canonical tags and, on multilingual sites, the hreflang relationships.
- Full crawl of the live site: every 200 URL, not just the pages in the menu
- Search Console export: top pages and queries over twelve months
- Analytics baseline: sessions and conversions by landing page and device
- Current titles, descriptions, canonicals and hreflang pairs
- A redirect map, old URL to new URL, one to one wherever an equivalent page exists
Launch week: the checks that matter
The redirect map is the deliverable that carries the migration. Map each old URL to the closest equivalent page with a 301, not a 302, and not a blanket rule to the homepage. Where no equivalent exists, decide deliberately: redirect to the nearest relevant parent, or let it return 410 if the content is genuinely gone. Then test the map against the crawl, not against a sample.
On launch day, verify in this order: robots.txt is permissive, no stray noindex tags, the XML sitemap lists new URLs only, canonicals are self-referential, and analytics plus conversion tracking still fire. Submit the new sitemap, keep the old one available briefly so redirects get discovered, and re-crawl your own site to find internal links still pointing at old paths.
What normal looks like, and what we will not promise
Some movement in the first weeks is expected while search engines recrawl and reassign. What matters is the direction of the trend and whether your priority pages hold their positions. Recovery timing depends on site size, crawl frequency and how much genuinely changed — anyone quoting you a fixed number of days is guessing.
We will not promise that rankings are untouched by a migration, because that depends partly on decisions outside anyone's control. What we will do is keep the mechanical causes off the table: a complete redirect map, no self-blocking, preserved metadata and preserved content depth on the pages that earn your traffic. If a page must change substantially, we say so before launch, not after.
Frequently asked questions
Will I lose rankings if I redesign my site?
Not inherently. If URLs stay the same, content depth is preserved and the site is not accidentally blocked, a redesign is usually neutral to positive. Losses come from changing addresses and content at the same time without a plan.
How long should redirects stay in place?
Keep them permanently if the platform allows it. At minimum, keep them well past the point where old URLs stop receiving traffic — external links and bookmarks outlive search indexes, and a redirect costs almost nothing to maintain.
Should I clean up my URL structure while I migrate?
Only if the current structure is a real problem. Every change adds redirect risk. If you do restructure, do it once, in the same migration, with a complete map — not gradually over months, which creates redirect chains.
Is it safer to change platform and design separately?
Usually yes, if you can afford two phases. Separating them means that when traffic moves, you know which change caused it. Doing both at once is workable with a solid inventory, but diagnosis afterwards is harder.
What changes for a multilingual site?
More surface area. Every language version needs its own redirect map, and hreflang relationships must be rebuilt to point at the new URLs on both sides. A one-sided hreflang tag is ignored, so partially migrated language sets are a common failure point.
Planning a replatform or a redesign and worried about the traffic you already have? Send us your current site and where you are heading — we will map the risk before any code is written and quote the migration work honestly.