Site Migration Checklist 2026: The Three Things That Now Break Without Any Warning

The standard migration checklist is thirty years old in spirit and it still works. Map every URL, redirect with 301s, keep the redirects, update internal links, resubmit sitemaps, watch Search Console. Nothing on that list has become wrong. The problem is that it was written for a web where every failure eventually showed up as a ranking drop, and that is no longer true.

Three things now break during migrations without producing an error, an alert, or a visible change in rankings. Each of them can run for weeks before anyone notices, and two of them cannot be seen in any tool a typical team already has open.

First, the statistics that are not going in this article

Search for migration risk and you will find confident percentages: some fixed share of migrations lose some fixed share of traffic. Those figures circulate in agency blog posts, get repeated in slide decks, and are used to justify budgets.

We are not citing them, because when you follow them back they do not terminate anywhere. They cite each other, or an unnamed internal dataset, or a study that no longer exists at the URL given. There is no published methodology, no sample definition, and no way to know whether a “migration” in the sample meant a domain change, a redesign, a platform move or all three at once.

The honest position is that nobody has published a credible, reproducible figure for the average traffic loss from a site migration, and any number presented as one should be treated as marketing. The useful analysis is mechanism-based: here is what breaks, here is why, here is how you detect it. That is the rest of this piece.

Silent failure one: structured data, and disappearing from AI answers

Structured data is the most commonly lost asset in a migration, because it usually lives in a theme, a plugin or a template layer that is being replaced. The new site launches, the pages look identical, and the Product, FAQ, Organization, Article and Breadcrumb markup simply is not emitted any more.

Historically this cost you a rich result: stars vanished from the listing, click-through rate fell a little, someone noticed within a month. In 2026 the more expensive consequence is different. Generated answers draw on machine-readable page content, and a page that no longer declares what it is, what it costs and whether it is in stock is a weaker candidate for being used and cited. Google’s own introduction to structured data frames it as helping search understand page content, and that understanding feeds more surfaces every year.

Here is what makes it silent. You do not lose a ranking position when this breaks. The blue link stays exactly where it was. What you lose is presence in answers that never generated a session in the first place, so there is no traffic line to fall. The metric that would have shown it does not exist in most analytics setups.

How to detect it: take twenty URLs across every template type, run them through a structured data validator on the old site and on staging, and compare the emitted types field by field, not page by page. Do this before launch, not after. The Search Console enhancement reports will eventually tell you, but they lag by weeks and they only report on types Google already knew you had.

Silent failure two: the product feed and the agentic channels

This one is new enough that most checklists have no line for it, and it is specific to anyone selling something.

Product data now leaves your site through a second pipe that has nothing to do with crawling. Feeds are pushed to merchant platforms and to agent-facing commerce protocols: Google’s Universal Commerce Protocol and the Agentic Commerce Protocol maintained by OpenAI and Stripe both work from a structured product feed with required attributes covering identity, price, availability, images and eligibility flags.

A migration breaks feeds in ways that are easy to miss. Product URLs change, so every item in the feed points at a redirect or a 404. Internal product IDs are regenerated by the new platform, so the feed’s identifiers no longer match what the channel has on file. The feed endpoint itself moves or requires new credentials. Availability and price fields get mapped from different database columns and quietly come back wrong.

The reason this is silent is structural: the failure surfaces on someone else’s platform, not on yours. Your site is up. Your checkout works. Your analytics show nothing unusual, because the traffic that stops arriving was never counted as a channel you were tracking closely. Items are simply disqualified upstream, and the notification, if there is one, lands in a merchant account nobody in the migration team has open.

How to detect it: treat the feed as a deliverable with its own acceptance test. Before switchover, generate the new feed and diff it against the current one on item count, identifier stability, URL resolution without redirect, price, and availability. After switchover, check the disapproval and error counts in each merchant destination on day one and day three, not at the end of the month.

Silent failure three: CrUX history is tied to the origin

The third one cannot be prevented, only planned for, and it catches teams that did everything else correctly.

Chrome UX Report data is aggregated by origin. Per the CrUX API documentation, the dataset is a 28-day rolling average, updated daily, and when the identifier is an origin all data for all pages on that origin is aggregated together. Change the domain and you are a new origin. The accumulated field data does not follow you.

The practical consequences are worth spelling out, because they arrive in a specific order. On day one after a domain change, the new origin has little or no data. It takes up to twenty-eight days before the rolling window is full of post-migration traffic, and the origin only appears at all once it clears the popularity threshold. During that period Core Web Vitals reporting for your site is either missing or built on a partial window, and any comparison you make between the old and new sites is a comparison between a full window and a partial one.

This is not a penalty and it does not mean performance got worse. It means your field measurement goes dark exactly when you most need it, which is why performance regressions introduced by a migration are so often found in the second month rather than the first. The mitigation is to run your own real-user measurement collection through the migration so you have a continuous series that does not restart, and to capture a full pre-migration CrUX baseline before the switch so you have something to compare against later.

The three failures side by side

What to expect on timing, stated carefully

There is a widely repeated claim that rankings stabilise in four to twelve weeks after a correctly mapped migration, usually attributed to a Google representative. We looked for the primary source and could not find one. What Google does document, in its guidance on site moves with URL changes, is that a small to medium site can take a few weeks for most pages to move in the index, that larger sites take longer, that temporary ranking fluctuation during a move is normal and settles over time, and that redirects should be kept for at least a year.

So the four to twelve week range is best treated as observed practice rather than an official statement: it matches what we see, it is consistent with what Google documents, and it is not a quotation. The distinction matters when a client asks you to commit to a recovery date.

What genuinely changes the timeline is scale and mapping quality. A one-to-one map on a site of a few hundred pages resolves quickly. A migration that also consolidates categories, merges two sites or changes URL structure is a different exercise, because the search engine has to reassess relevance rather than just follow a redirect. Our guide to domain migration without losing traffic covers the mapping mechanics, and the wider question of whether to move at all is in rebuild from scratch or improve what you have.

Additions to the standard checklist

• Structured data parity test on staging, by template type, with a field-level comparison rather than a pass or fail badge.
• Feed acceptance test covering item count, identifier stability, URL resolution, price and availability, run before switchover and again on day one.
• Merchant and agent channel review on days one and three, because the errors appear there and nowhere else.
• Your own field performance collection running before, during and after, so the CrUX gap does not become a blind spot.
• A pre-migration CrUX snapshot exported and stored, since the origin’s history is not retrievable later.
• A frozen baseline of impressions, clicks and conversions by template, so that a later argument about whether something got worse can be settled with data rather than memory.

If something does go wrong after launch, resist the urge to change several things at once. The diagnostic order for a post-migration decline is different from an ordinary one, and we set out the sequence in how to find the cause of a traffic drop. The most common finding, by a wide margin, is a mapping error affecting one template rather than a site-wide catastrophe.

The short version

Redirect mapping is still the core of a migration and it is no longer sufficient. Structured data can vanish with the old templates and cost you presence in generated answers without moving a single ranking. A product feed can break entirely on the merchant side while your site behaves perfectly. And CrUX field data is bound to the origin on a 28-day rolling window, so a domain change blanks your performance history at the exact moment you need it. None of the three raises an error, which is why they belong on the checklist explicitly rather than in someone’s head.

On the timing question, be precise: Google documents a few weeks for most pages on a small to medium site, longer for large ones, with temporary fluctuation that settles. Anything more specific than that is observed practice, not policy, and the traffic-loss percentages in circulation have no traceable source at all.

We plan migrations around these checks as a matter of course when we run a website migration, including the pre-launch parity tests and the baseline capture. The Curatos Agency case shows what the structure looks like when the rebuild and the move are handled as one project rather than two, and our write-up on redesigning without losing traffic and rankings covers the overlap in detail.