A B2B platform survived a domain migration with its rankings intact — and its logs to prove it

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

A B2B logistics-software platform sells through a funnel that runs on search: the marketing site, a public documentation set, and comparison pages that answer 'them-versus-us' questions. Around 2,300 URLs carried that pipeline when a rebrand forced every property onto a new domain at once. The company had migrated domains once before, in-house, and the result — a quarter of organic traffic gone for three months — still shaped every conversation about this one. Docs belonged to engineering, marketing owned the site, and the board wanted a plan it could hold people to.

What it was costing

A rebrand forced a domain move across 2,300 URLs, including the docs and comparison pages that carried most of the organic pipeline. The last migration the company ran had cost 40% of traffic for a quarter, so this one had a board-level eye on it.

What they could see

• The last migration cost roughly 40% of organic traffic for a quarter, and the incident had no post-mortem anyone could learn from.
• Documentation links redirected to the marketing homepage for weeks during the previous move before a customer reported it.
• Comparison pages carried most of the demo pipeline, and sales noticed dips after every site change with no explanation available.
• Nobody could say how Googlebot was behaving — rank charts moved days late and the crawl itself was invisible.

The constraints we worked inside

• The marketing site, docs, and app subdomain moved together — one window, three properties.
• Docs content was owned by engineering; redirects had to fit their release process.
• Rankings could not be A/B tested — the migration was going to happen either way, so the plan had to be right first time.

What had been tried before

The first migration was run in-house from a hand-built spreadsheet of redirect pairs, spot-checked by whoever had time.

There was no rehearsal and no crawl verification; parameter variants and old docs anchors were missed, and the 404s surfaced through customer complaints, not monitoring.

An enterprise rank-tracking subscription was bought to watch the fallout, with weekly dashboard reports.

Rank charts described the damage days after it happened; nothing observed the crawl itself, so the dashboards narrated a migration nobody could steer.

What we proposed

We proposed treating the migration as a rehearsed release, not an event: every URL pair generated from crawler exports, reviewed, and spot-crawled in staging — including the parameter and anchor permutations that usually get forgotten. Server-log analysis would run before and after cutover so Googlebot's transition was visible in hours, not inferred from rank charts days later. The old domain would keep serving redirects for 90 days while a weekly variance review compared entrances against a pre-migration baseline. Because rankings cannot be A/B tested, the whole plan was built to be right first time.

Just as important is what we ruled out, and why:

• Staggered cutover — marketing first, docs and app later — The rebrand date was fixed company-wide, and the app subdomain shared session infrastructure with docs; a split window risked breaking authenticated users mid-move.
• An overnight maintenance blackout on the docs subdomain — Customers' on-call engineers read those docs around the clock; a guaranteed support incident was a bad trade for a marginal simplification of the redirect work.

How the work ran

Delivered by the growth pod — technical SEO specialist + engineer over 8 weeks, with working increments reviewed with the client every week.

The stack, and the reasoning

Log-file analysis

Rank charts lag days; logs showed which URLs Googlebot requested and when, turning 2,300 URLs of guesswork into an hourly crawl record we could act on.

Screaming-class crawlers

Only a crawl of the old properties could enumerate every URL — including query-parameter and anchor variants — and then verify the pairs in staging before launch.

Search Console

Already verified across all three properties; coverage and crawl-stats reports were the free, authoritative place to watch for regressions during the 90-day stabilization window.

Rank tracking

The board needed a scoreboard it recognized; weekly positions against a pre-migration baseline gave a shared, if coarse, language for the variance reviews.

What went wrong

How we worked together

Cadence

A Tuesday 30-minute cutover-prep call with the engineering docs lead and the head of growth; during stabilization, a weekly variance review replaced it.

Client side

Engineering owned the docs redirects and their release slots; the head of growth owned the baseline and reporting; a board sponsor received the weekly summary.

Decisions

Disputes over which page inherits which were settled against the crawl data in the versioned redirect map itself — the pair list was the record — and anything still contested by the Tuesday call went to the head of growth.

They provided

Server-log access, a staging environment with the full redirect config, the pre-migration analytics baseline, and engineering release time we had to book explicitly.

What changed

The headline: organic entrance variance in the 90 days post-migration versus the pre-migration baseline (the prior migration had lost 40%) — −4% → −1%, read from Search Console + analytics, same-period YoY. A second check: unmapped 404s found by the post-launch crawl at 0.

The migration passed without the Monday-morning dread the last one left behind: variance reports ran to a single page the board could read in two minutes, and the stabilization window ended on schedule instead of stretching into blame. Engineering now treats redirects as a release-process input rather than a favor to marketing, and the log-analysis routine the pod built stayed in use long after the cutover.

The result was read from Search Console + analytics, same-period YoY against the pre-engagement baseline over the stated window, with a guardrail check on unmapped 404s found by the post-launch crawl. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• The complete redirect map, versioned in the company's own repository
• The log-analysis query pack with a runbook for post-change monitoring
• A baseline variance dashboard wired to the analytics property
• A stabilization checklist covering the 90-day window's weekly checks
• Documented Search Console routines for all three properties