Site migration plan, launch review and the rollback call

A replatform loses its traffic in a narrow band of URLs, not evenly across the site. Across the last fourteen moves we ran, a median of 71 percent of pre-launch organic revenue arrived on under 3 percent of indexed URLs. That set is what we protect, and it is what decides whether a launch stands or is reversed. This engagement produces three artefacts: the URL map, the redirect specification your engineers ship, and a numbered list of thresholds, agreed before launch, that say when you roll back instead of arguing about it at two in the morning. What the engagement answers: Whether the new URL scheme can be reached from the old one without a human deciding case by case. Whether the pages carrying the revenue keep their internal links, their canonical, their hreflang cluster and their external links after the move. And whether the launch date you have already announced is the date the site is actually ready for. How the work runs: We take a baseline first: a full crawl in Screaming Frog, run against staging with the same auth your build has, twelve months of Search Console data pulled through the API into BigQuery, ninety days of CDN logs for Googlebot behaviour, and the external link inventory from Ahrefs so we know which old URLs carry equity worth moving. From that we build the map, with old URL, new URL, match confidence and revenue rank, as a sheet your team can argue with line by line. Anything we cannot map with confidence is flagged, not guessed at. The redirect specification is written for your stack rather than in the abstract: an nginx map file, a Cloudflare Worker, or middleware in Next.js, with rules ordered so that no chain exceeds one hop. We test it against staging with a harness that replays every URL in the protected set and asserts a single 301 landing on a 200. The rollback triggers: These are agreed in writing, with a named owner, before the code freeze, so nobody has to invent a threshold in the middle of an incident. The defaults we start from: Googlebot 5xx above 1 percent of crawl requests in any rolling two-hour window. Any URL in the protected set returning a chain longer than one hop, or a 404, after cutover. Organic sessions to the protected set down more than 15 percent against a four-week same-weekday baseline, sustained 72 hours. Search Console valid indexed count down more than 10 percent at day 14. We hold the old stack warm for 21 days. After that, a rollback usually costs more than fixing forward, and the plan says so in those words. When the answer is inconvenient: Three times in the past two years we have recommended postponing an announced launch. Twice the date moved. The third client launched anyway; we ran the rollback on day four and the recovery took eleven days rather than the quarter it was heading for. If the baseline says your redirect layer cannot be built in the window you have, that is the first paragraph of the report, with the evidence attached. Who does the work: One of the two partners leads every engagement and stays on it through cutover. We do not subcontract the URL map, and the person who wrote the thresholds is the person on the call when one of them fires. Not included: We do not write code into your repository. We specify, you ship, and we review the pull request. We do not write or rewrite content, do not touch paid media, and do not re-tag GA4 or GTM; we tell you what breaks and hand it to whoever owns it. No ranking guarantee is offered, at any tier, in any form. Not for you if: Your site is a few hundred pages moving to a hosted builder. A spreadsheet and a careful afternoon cover that. Your URL scheme is still under debate, in which case come back when it is settled, because the map is only worth building once. Or you need someone to sign a statement that traffic will not fall. It usually falls for a period. The plan is about how far, and for how long.