A rebuild is the fastest way to lose traffic you already owned.

Four things carry the value of an existing site: the URLs, the content on them, the internal link structure, and the signals pointing in from elsewhere. A rebuild usually replaces the first three at once and assumes the fourth follows along.

It follows only if every old URL resolves to the closest new equivalent, in one hop, permanently. Not to the homepage. The single most common migration failure is a blanket redirect to the root, which tells a search engine that forty pages of accumulated relevance are now one page about nothing.

This site's own migration is a worked example. Twenty two legacy WordPress URLs still resolve: service pages to services, portfolio and project taxonomies to work, author and category archives to their closest section, and the dated blog path to the piece that replaced it. Each resolves in a single hop. Each also has an explicit trailing-slash variant, because every URL the old CMS published ended in a slash, and a redirect that only matches the slash-free form silently misses the version Google actually has.

Capture before you change anything. Export the full URL list, the pages with inbound links, the queries currently producing impressions, and a performance baseline. After the cutover this information is gone, and without it you cannot prove whether a drop is real or seasonal.

Map second. Every old URL gets a destination written down before a line of the new site is built. Mapping after the build is what produces the blanket redirect, because by then nobody wants to spend two days on it.

Stage third, and keep staging out of the index. A noindex tag on a staging environment is correct. The same tag surviving the cutover is one of the most expensive one-line mistakes available, and it is invisible unless someone checks the live response.

Cut over, then verify the same day. Not the URL you remember, the whole list. A redirect table is a claim until something has walked it.

Compare like for like before panicking. Traffic falls after most launches for reasons that have nothing to do with the migration: seasonality, a paid campaign ending in the same week, a tracking change that altered what counts as a session.

The signal that a migration is the cause is specific. Impressions fall for queries that used to land on pages whose URLs changed, while queries pointing at unchanged URLs hold. If everything fell evenly, the cause is usually measurement, not migration.

Check the index directly rather than inferring from a traffic chart. A page that is still indexed and ranking will show impressions. A page that was dropped shows nothing at all, and that difference tells you whether to fix redirects or fix analytics.

Redirect chains. An old URL points at a second URL which points at a third. Each hop costs, and chains longer than two are frequently abandoned. The fix is to point every legacy URL at its final destination, not at the intermediate one that happened to exist at the time.

Ordering. Specific rules have to be evaluated before catch-alls, or a broad pattern swallows the one page that deserved a precise destination.

Content that quietly shrank. A rebuild often rewrites long pages into short ones because the new design looks better with less text. That is a content change wearing a design change's clothing, and it moves rankings on its own.

Declaring victory at launch. The index takes weeks. A migration is not finished on cutover day, it is finished when the crawl has caught up and the numbers have been checked against the pre-launch baseline.