A migration goes wrong quietly. The new site launches on a Friday, looks better than the old one, and everyone celebrates. By Monday, organic traffic has fallen by half, the phone is quieter, and the rankings that took three years to build are gone. The cause is almost never the new design. It is the hundreds of small connections between the old site and Google that were severed during the move and never reconnected.
Site migrations lose rankings for the same reasons everywhere, in Atlanta or anywhere else. There is no metro where Google’s crawler behaves differently, and the search ecosystem does not punish a Buckhead business faster than a business in a small town. What punishes mistakes is the migration itself, and the protocol below prevents the loss regardless of where the business sits. The value is in the phasing, not in any regional exception.
Why Migrations Lose Rankings
Every indexed page carries accumulated value: the links pointing to it, the history of users engaging with it, the relevance it built for specific searches. The value has an address. When a migration changes URLs, changes platforms, or restructures the site, those values do not automatically follow. A page that ranked for “emergency plumber Atlanta” at one address becomes, to Google, a missing page at that address and a brand new page at the new one, with all the accumulated trust stripped away.
The mechanism that preserves the value is the redirect. A permanent redirect from the old URL to the new one tells Google that the page moved and instructs it to carry most of the accumulated authority forward. Map every old URL to its new equivalent with permanent redirects and the trust survives. Launch new URLs while the old ones return errors and that trust is thrown away. That single omission causes most of the catastrophic traffic drops people attribute to bad luck.
Phase One: Pre-Migration, the Six-Week Preparation
The work that prevents a nightmare happens weeks before launch. Most businesses skip it. The old site is still working and the pressure to move feels low, so the preparation gets deferred until there is no time left for it.
Preparation starts with a complete inventory of the current site: every indexed URL, pulled from the CMS, the XML sitemap, Search Console, and a full crawl. A 400-page site can hide 60 forgotten URLs that still hold rankings, which is why the inventory has to be exhaustive rather than approximate. Each URL is then mapped to its destination on the new site, producing the redirect map that becomes the spine of the migration. Pages that drive traffic and hold rankings get particular attention, because losing a redirect on a high-value page is far costlier than on a forgotten one. Alongside the map, a baseline is recorded: current rankings, traffic, and indexed page count, so that any post-launch loss can be measured rather than guessed.
The new site is built and tested on a staging environment that is blocked from search engines, where redirects, internal links, metadata, and structured data can be verified before anything goes live. Six weeks gives room to find the broken pieces while they are still harmless.
Phase Two: Launch Day, the 72-Hour Execution Window
Launch tests everything. The first seventy-two hours decide whether the preparation pays off or unravels.
The redirects go live with the new site, and they are tested immediately against the map, because a redirect that exists in a spreadsheet but fails in production protects nothing. The XML sitemap is updated to the new URLs and submitted in Search Console, which invites Google to recrawl quickly rather than discovering the changes slowly. Internal links across the new site point to the new URLs directly, since relying on redirects for internal navigation wastes crawl efficiency and slows reindexing.
Within this window, a full crawl of the new site confirms that pages resolve, redirects fire, and nothing returns an unexpected error. Search Console is watched closely for spikes in crawl errors or coverage problems, which are the earliest signals that something in the map failed. Catching a broken redirect on day 1 is a 5-minute fix. Discovering it 3 weeks later, after Google has dropped the pages, is a recovery project.
Phase Three: Recovery, the 30-Day Trust Restoration
After launch, rankings almost always fluctuate. This is normal, not alarming. Google is recrawling, reprocessing redirects, and re-evaluating the moved pages, and positions can wobble for several weeks before settling.
Panic does the damage. The instinct to start changing things during the wobble often hurts more than the temporary dip itself. The thirty days after launch are for monitoring and correction, not redesign. Search Console reveals which pages Google has recrawled, which redirects it has processed, and which URLs are throwing errors that need fixing. Rankings and traffic are compared against the pre-launch baseline to confirm recovery is underway. Any old URLs that surface without a redirect get one. By day 30, a clean migration has returned to its prior positions or close to them, and the temporary loss has reversed.
Common Migration Traps
A few failures recur often enough to name. They cluster like this:
- No complete redirect map. The most destructive trap, leaving high-value pages stranded with no path to their new home.
- Temporary redirects instead of permanent ones. Signals to Google that the move is provisional, which can dilute the authority transfer.
- Forgotten internal links. The new site ends up pointing at its own old URLs, wasting crawl budget and slowing reindexing.
- A crawl block carried over from staging. A single setting left in place can deindex the entire site overnight.
- Changing design, URLs, and platform at once. Everything moves together, so when a problem appears it is nearly impossible to isolate which change caused it.
What a Clean Migration Looks Like
A well-executed migration is anticlimactic. That is the goal. The new site launches, every old URL redirects to its new home, the sitemap is submitted, internal links are updated, and Search Console stays quiet. Rankings dip slightly in the first 1 or 2 weeks as Google reprocesses, then return. Traffic holds, recovers, and often improves once the better-structured site is fully understood. No emergency, no lost quarter, no rebuilding of authority that took years to accumulate. The difference between a nightmare and a non-event is entirely the preparation that happened before anyone saw the new design.
Frequently Asked Questions
Will I lose rankings when I migrate my site?
A small, temporary fluctuation is normal as Google reprocesses the moved pages. A large, lasting loss is not normal and almost always traces to a redirect failure, a crawling block, or a missing redirect map rather than to the migration itself.
How long before rankings recover after a migration?
For a clean migration with proper redirects, positions typically stabilize within a few weeks, often inside thirty days. A longer or deeper loss usually points to an unresolved technical problem that needs diagnosis.
Do I need to keep the same URLs?
Keeping URL structure where possible reduces risk, but it is not required. What matters is that every old URL permanently redirects to a relevant new one. Changing URLs is safe when the redirect map is complete and correct.
What is the most common cause of a failed migration?
An incomplete or missing redirect map. When old URLs return errors instead of redirecting, the accumulated authority of those pages is lost, which produces the steep traffic drops most associated with migration failures.
Can I change my design and platform at the same time?
It is possible but riskier, because simultaneous changes make problems hard to isolate. Separating the changes, or at minimum preserving the redirect map and URL logic through the move, makes any issue far easier to diagnose and fix.