Atlanta's Site Migration Nightmare: How to Change Platforms Without Losing Rankings

A platform change is least likely to cost rankings when three things hold: every old URL that matters points with a permanent redirect to its closest equivalent on the new site, nothing on the new site blocks Google from crawling or indexing it, and someone watches the move in Search Console until it settles. When a migration does lose rankings, those three are the first things to check.

Some movement is expected even when everything is done right. Google’s site move guide says to “expect temporary fluctuation in site ranking during the move,” and that “for medium-sized websites, it can take a few weeks or more for Google to gradually start showing the new URLs instead of the old ones (and for larger sites, even longer).” No fixed recovery date exists, which is why a migration plan is built around checks rather than a calendar.

What a platform change actually breaks

A new platform may not keep the old site’s addresses. Shops, booking systems, and content management systems can each generate URLs in their own pattern, so the page that ranked at one address now lives at another. Google sees a new address and an old one that no longer answers, unless something connects them. The failures to check for:

Missing or wrong redirects. Old URLs return errors, or many of them point at the home page.
Development settings left on. A robots.txt rule or noindex tag used to keep the unfinished site out of search goes live with it.
Old addresses inside the new site. Canonical tags, internal links, and the sitemap still reference the old URLs.
Deleted content answering with the wrong code. Pages you removed on purpose should say so.
Everything changed at once. New domain, new platform, and new design in a single weekend, so when traffic drops nobody can tell which change caused it.

Change one thing at a time

Google’s guide is direct about the last trap: “Plan your changes to your site one after the other, not everything at the same time.” Its example is a site that wants a new domain, a new content management system, and a new layout; the advice is to “do them one at a time.”

For a platform change, that means moving the content to the new platform with URLs and design as close to the old ones as the platform allows, confirming the move has settled, and only then redesigning. If the platform forces new URLs, keep the design change for later.

Before launch: the inventory and the redirect map

The redirect map is the core document of the move: a list of every old URL that matters and the new URL it should send visitors and Google to. Google suggests where to find the old URLs:

Your sitemaps, “because it’s likely your most important URLs have been submitted in Search Console that way.”
Server logs or analytics for “the URLs that get the most traffic.”
The Links report in Search Console for pages with internal and external links.
Your content management system, which can typically export a list of all content URLs.
Images, videos, scripts, and style files. Google notes these “need to be moved in the same way as all other content.”

Then decide each URL’s destination by hand for the pages that matter. Three rules from Google’s guide shape the decisions:

Closest equivalent, not the home page. “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site.” Google says that can be treated as a soft 404.
Merged content goes to the merged page. If several old pages became one new page, the old URLs can redirect to it.
Removed content says it is gone. Old URLs for content you are not moving should “return an HTTP 404 or 410 error response code on the new site.”

Record a baseline at the same time: Search Console clicks, impressions, and indexed pages, plus the queries and pages that bring the most traffic. Without it, you cannot tell a normal settling period from a real loss.

Prepare the new platform before it goes live

Build and test the new site where it cannot be indexed by accident, and prepare the switches you will flip at launch:

Robots.txt and noindex. Google notes that “some site owners block all crawling while in development” and advises preparing the final robots.txt and a list of URLs to remove noindex from when the move starts.
Canonical tags on the new site that point to the new URLs.
Internal links rewritten to the new URLs using your map, so the new site does not send visitors through its own redirects.
A new sitemap listing the new URLs, and a saved copy of the old one.
Search Console verified for the new site, and for the old one if the domain changes.

Launch: turn on the redirects and test them

Google recommends “server side permanent redirects” such as 301 and 308. If your platform manages redirects through a settings screen or plugin, check that it produces server-side permanent redirects rather than page-level scripts.

Avoid chains. Google can follow “up to 10 hops,” but advises “redirecting to the final destination directly.” A page that moved twice should redirect straight to its current address.
Test every important redirect after launch, not only in the spreadsheet. Google mentions the URL Inspection tool for individual URLs and command-line tools for large numbers.
Change of Address in Search Console is only for moves between domains or subdomains. Google says you do not need it for HTTP to HTTPS moves, www changes, or “moving paths within the same domain.”

Why the redirects must be permanent

Google’s redirects documentation explains the difference in terms of what appears in search results. Permanent redirects “show the new redirect target in search results.” Temporary redirects “show the source page in search results,” and for them “the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.”

On link value, the site move guide is plain: “Don’t worry about link credit. 301 and other permanent redirects don’t cause a loss in PageRank.” The reason to use permanent redirects is so Google treats the new URLs as the pages to show.

After launch: what to watch and for how long

Google lists the Search Console features that track a move:

Sitemaps. Submit both sitemaps. Over time, indexing for the old sitemap should fall toward zero while the new one rises. Google says redirect warnings on the old sitemap are normal.
Indexing reports. Indexed pages should shift from the old URLs to the new ones. Google advises you to “check regularly for any unexpected crawl errors.”
Search queries. New URLs should start appearing with impressions and clicks as they are indexed.
Server logs. Look for Googlebot’s crawling and for URLs that “unexpectedly return HTTP error status codes.”

Compare each against the baseline. A gradual handover from old URLs to new ones looks like a move settling. Old URLs dropping out with no new URLs taking their place suggests a redirect or indexing problem, and that is the time to check the map, not to redesign.

Two jobs continue after the first weeks. Ask sites that link to your old URLs to update their links, starting with the most important ones. And leave the redirects in place: Google’s guide says to keep them “for as long as possible, generally at least 1 year,” and from a visitor’s point of view “consider keeping redirects indefinitely.”

A pre-launch checklist

Every important old URL is in the map with a relevant destination.
No group of old URLs points at the home page without a reason.
Removed content returns 404 or 410.
Robots.txt and noindex are set for the live site, not the development one.
Canonical tags, internal links, and the sitemap use the new URLs.
Redirects are server-side, permanent, and single-hop.
Search Console is verified, the baseline is saved, and both sitemaps are ready to submit.
The design change waits until the platform move has settled.