Replatform and Site Migration SEO Plan, Written Early

A replatform loses organic traffic for one of three reasons: the redirect map was written after the new information architecture was frozen, the URL inventory came from a crawl of the old site rather than from what search actually knew about it, or nobody agreed in advance on the number that would trigger a rollback. Everything in this engagement is aimed at those three. When I need to start: Before the new URL structure is signed off, which in practice means eight to twelve weeks ahead of cutover. If you are three weeks out and no map exists, I will still take the work, and you should understand you are buying damage control rather than a migration plan. I would rather say that on the first call than in the post-mortem. Building the inventory: Five sources, not one. Ninety days of Search Console URLs by bulk export. Twelve months of edge or origin logs for anything Googlebot touched, including URLs that have not been linked for years. Every historical sitemap I can recover. Analytics landing pages ordered by revenue. And a backlink export, so the couple of hundred URLs carrying external links are treated as the assets they are. A crawl of the live site is the sixth and least interesting source, because it only knows what is currently linked. The map itself: One hop, 301, no chains, and no wildcard rule that quietly sends four thousand product URLs to a category page. Where a page has no successor I would rather route it to the closest real equivalent and mark the row as a judgement call than pretend a pattern held. You receive the map as a CSV with a reason column, and as the rule file your platform actually consumes: nginx, a Cloudflare Worker, or a platform redirect import. Hebrew URLs get a decision rather than a default. If your paths are percent-encoded Hebrew and they carry links and history, they keep the Hebrew. Changing platform and URL language in the same release means that when traffic moves you cannot tell which change moved it, and you pay that diagnostic cost for months. Cutover: A runbook with a named owner and a time on every line. Staging behind authentication rather than robots.txt, and an explicit line for removing the noindex, which is the single most common way a migration goes wrong and the easiest to prevent. TTLs lowered two days ahead. On the day I sample the map continuously, watch status codes and rendered head tags rather than rankings, and read logs hourly for the first forty-eight hours. The rollback threshold is written down in week one, while everyone is calm. After: Four weeks of monitoring against the pre-launch baseline, split by template, because an aggregate traffic line tells you something broke and never what. Search Console lags, so the first meaningful read comes from logs and the second from indexation by segment. Not included: The migration itself. I do not build the new site, write the theme or move the data. Content consolidation decisions belong to whoever owns the catalogue; I price each one in search terms and they decide. Paid media, which will also be affected, and whose team should be told in week one rather than on launch morning. Not for you if: The launch date is fixed by a campaign and cannot move by a week whatever the evidence shows. There is no staging environment that mirrors production. Or the plan is to change domain, platform, architecture and content in one release, which I decline unless there is a reason strong enough to accept that nothing afterwards will be diagnosable.