Problem
Planning a migration? This is where traffic gets lost.
What you would say
“We are replatforming and I am worried about losing our organic traffic.”
- Urgency
- Time-sensitive — cheaper to fix early
- First useful answer
- The URL inventory and value scoring typically take under a week and immediately show how much traffic is currently unprotected.
- Investigation steps
- 8 steps, in a fixed order
Business impact
What this usually costs
- A large organic traffic loss in launch week is a well-known outcome of unmanaged migrations
- Months of recovery work costing more than the protection would have
- Revenue lost during the recovery window and never recovered
- Analytics discontinuity that makes the loss impossible to measure properly
- Loss of internal confidence in the new platform for reasons unrelated to the platform
Our approach
What we would investigate
Build the URL inventory
Crawl the old site, then add Search Console pages, GA4 landing pages, backlinked URLs and conversion pages. One list, every URL.
Score every URL by value
Traffic, conversions, revenue, backlinks and query value. This is what turns a redirect map from a guess into a protection plan.
Map old to new as rules
Rules wherever a pattern exists, explicit pairs where it does not. A rule can be tested against thousands of URLs; a spreadsheet cannot.
Specify what must carry across
Metadata, canonicals, structured data, internal links, sitemaps and robots — for both the staging and production environments.
Specify analytics continuity
Events, conversions, dataLayer and cross-domain behaviour on the new build, tested on staging before launch.
Test on staging
Crawl staging, run the redirect rules against the real scored URL set, verify rendering and markup, validate the tags.
Define launch-day pass/fail criteria
And rollback triggers. “Should we roll back?” should be answered by criteria agreed in advance, not by argument at 2am.
Monitor for 30 days
Day 1 critical QA, day 3 indexing and errors, day 7 traffic comparison, day 14 page-level comparison, day 30 retained-versus-lost report.
Differential diagnosis
Likely causes, and what proves each one
| # | Possible cause | Evidence that confirms or eliminates it |
|---|---|---|
| 01 | Redirect map built from a CMS export instead of value data | Coverage of the scored URL set by the proposed redirect map |
| 02 | Redirect chains, loops, or 302s where 301s belong | Redirect testing across the scored URL set on staging |
| 03 | Metadata, canonicals or structured data not carried across | Staging crawl compared field by field against the old site |
| 04 | Staging indexed, or production blocked by robots on launch | robots.txt and meta robots checks on both environments |
| 05 | Analytics and conversion tracking rebuilt and never validated | Real action traced through the new tag setup on staging |
| 06 | Internal links still pointing at old URLs after launch | Post-launch crawl of internal link targets |
The no-guessing rule
If the data does not support a conclusion, we write “we do not have enough evidence to confirm this” and tell you what we would need. A guess never becomes a recommendation.Outcome
What you end up with
- Pre-migration audit and a risk register you can take to the project meeting
- Value-scored URL inventory and a tested redirect specification
- Technical, content and analytics requirements for the new build
- A launch-day checklist with owners, pass/fail criteria and rollback triggers
- Launch QA execution and issue triage on the day
- 30-day monitoring with a retained-versus-lost report at day 30
No surprises
What happens if you get in touch
You send us your website and what is happening
One form, six fields. No call required to get started.
We review the situation
We look at your site and the public data before we reply, so the first conversation is useful.
We confirm whether we can help
If we are not the right fit, we say so — and where we can, we point you somewhere better.
We explain what we would investigate
Specifically: where we would look first and why, based on what we already saw.
You decide whether to move forward
No pressure and no follow-up sequence. You have the information; the decision is yours.
Questions
Questions about migration risk
Evidence and further reading
- Worked example
A migration redirect map that covered 96% of URLs and 41% of the revenue
The redirect map was built from a CMS export, so it covered almost every URL by count. Scored by traffic, conversions and backlinks, it missed most of what the old site actually earned.
- Insight · Migrations
Value-score your URLs before a migration, not after
Redirect coverage counted by URL is the default metric and it cannot detect the failure that actually costs you traffic. Coverage weighted by value can, and it takes about three days to make possible.
Services that fix this, and problems that travel with it
- ServiceWebsite Migration ProtectionMove CMS, domain, design or URL structure without losing the organic traffic and revenue you already have.
- ServiceTechnical SEO & Search GrowthMake sure search systems can crawl, render, index and understand the pages that carry your revenue.
- ServiceAnalytics & Revenue MeasurementMake the numbers trustworthy enough to make business decisions with — GA4, GTM, ads, consent and CRM.
- ProblemOrganic traffic droppedSomething changed. There is always a date, and the date narrows the cause.
- ProblemAnalytics cannot be trustedWhen the numbers are wrong, every decision made on them is a guess with a chart attached.