Migrate your site without losing your rankings
We benchmark what you rank for today, map every legacy URL to its destination, and verify the whole thing on staging before you touch DNS.
Migrations fail in predictable ways
Almost nobody loses traffic in a migration because of something exotic. They lose it because of five things, and all five are preventable on a schedule that is known weeks in advance.
- Redirects that were never mapped. Someone exports the top 500 URLs, ships redirects for those, and the long tail — which is most of the traffic — 404s silently.
- Chains and loops. Legacy URL redirects to an interim URL redirects to the final one. It works for users and dilutes everything for crawlers.
- Staging directives shipped to production. A
noindexor a blockingrobots.txtthat was correct on staging and catastrophic on launch. - Silently dropped pages. Content that existed on the old CMS and was never migrated, because the content inventory and the URL inventory were different spreadsheets.
- No benchmark. Traffic falls, and nobody can prove whether it fell because of the migration or because of the season, because nothing was frozen beforehand.
What we do, in order
Before. Full crawl of the existing site, ranking and traffic benchmark frozen and dated, complete URL inventory, redirect map built to the last URL, and a staging audit against the same checklist we will use on launch day.
During. We monitor the switch live. If indexation or error rates cross a threshold we agreed in advance, the rollback trigger fires — that decision is made before launch, not argued about at 2am.
After. Thirty days of tracking against the frozen benchmark, with weekly reporting on retention by page. If something is lost, we know within days which URLs and why, while it is still cheap to reverse.
Fixed scope, fixed price
A migration has an end date, so this engagement has one too. It is not a retainer and it does not roll into one unless you decide separately that you want ongoing SEO support afterwards.
Questions we get asked
When should I bring you in? +
Before the redirect map is written — ideally as soon as the migration is scheduled. Post-launch is recovery work, and it costs several times more than prevention.
What if we have already launched and lost traffic? +
Then this is the wrong entry point. Start with a traffic drop audit so we can separate migration damage from everything else, and we will fold the findings into a recovery scope.
Do you write the redirects or does our team? +
We produce the map — legacy URL to destination, one hop, no chains — and your team implements it. We then verify every row after it goes live rather than trusting the spreadsheet.
Which migrations does this cover? +
Replatforms, domain changes, HTTP to HTTPS, subdomain to subfolder, site consolidations after an acquisition, and large-scale URL restructures. The risk profile is similar across all of them.
Read before you hire
Tell us your launch date
If it is more than three weeks out, we can run the full process. If it is sooner, tell us anyway — a compressed pre-launch check still beats a post-launch recovery.
Book a migration slot →