Preventing SEO Loss During a Website Migration: Guide
When a new site goes live, rankings usually drop because of forgotten redirects, not weak design. A URL mapping and migration checklist.
rabbitclip teamPublished: 5 min read
Short answer
The most common reason rankings drop after a site relaunch is that old URLs never get redirected to the new ones. Google expects a proper 301 redirect whenever a URL changes, so the signal an old page had built up carries over to the new address; skip that step and the search engine starts evaluating the page from scratch (Google Search Central, Site moves with URL changes).
This loss is usually not the design team's fault; it is a project planning gap. The new design gets approved, development starts, but nobody ever pulls the old site's full URL list, and on launch night no one is holding the mapping between old and new addresses.
Below are the three stages of a migration: preparation, launch night, and the checks that follow.
Preparation: the old site gets fully mapped out
Before the switch, every crawlable (indexed) URL on the old site gets pulled together, from the coverage report in Search Console, the sitemap, and a crawl tool if needed. If an e-signature service's site carries hundreds of help articles, each one of those needs to go on that list individually.
Each old URL then gets mapped to its equivalent on the new site. If a page has no exact match in the new structure, it redirects to the closest page on the same topic; with no match at all, sending it to a relevant category page tends to work better than sending it to the homepage.
Why a 301 redirect is not the same as a 302
A 301 redirect says 'this page has moved permanently', and the search engine carries the old page's signal over to the new address. A 302 says 'this page is temporarily somewhere else', and no signal transfer is expected. Using a 302 for a permanent site change is a common mistake that blocks that transfer (Google Search Central).
Redirect chains are worth checking too; if old address A redirects not to the new address but to another old address first, and only then to the new one, that chain costs both speed and signal. The goal is for every old address to reach the new one in a single hop.
The sitemap and robots file get updated
Once the new site is live, the sitemap (sitemap.xml) needs to carry the new URLs and get submitted to the search engine through Search Console; an old sitemap still pointing at old addresses confuses the crawl.
The robots.txt file needs checking too; a rule added during development to keep search engines from crawling the site, if it survives the switch to production, can leave the new site completely invisible in search. It is a common but easily preventable mistake in migrations.
The launch night checklist
There are items worth checking at the moment of launch and just after; most take a few minutes, but skipping them can cost weeks of lost rankings.
- Confirm robots.txt no longer blocks crawling
- Generate the new sitemap and submit it to Search Console
- Test redirects for every old URL, including at least the twenty lowest-traffic pages
- Check that structured data (schema) still exists on the new pages
- Watch the coverage report in Search Console over the days after launch
After the switch: how many weeks to watch
It can take Google a few weeks to fully process the new URLs; some temporary fluctuation in rankings during that window is normal. The actual warning sign is not fluctuation, it is a specific page still showing indexed under its old address weeks later; that points to a break somewhere in the redirect chain.
Protecting internal links and backlinks
Internal links, one page linking to another within the site, are the ones most often forgotten during a migration; even with old URLs redirected, if the copy on a page still points at old links, a visitor passes through a redirect chain, and that costs speed on every click.
Backlinks, links from other sites pointing at yours, cannot be edited directly, but if the redirect is set up properly, the signal those links carry still transfers to the new address; a complete 301 setup matters just as much for external links as it does for internal ones.
Protecting analytics and conversion tracking during migration
Analytics code and conversion tracking tags, form submissions, search tracking, are another item that gets forgotten when moving to a new site; if these tags go missing, traffic and conversion data has a blind spot for a while after launch.
If an e-signature service's form-submission tracking code works on the old site but never gets rebuilt on the new one, nobody can say how many people actually filled in the form after launch; that is why the list of tracking tags should get pulled together alongside the URL list before the switch.
On the first day after launch, every live form and button is worth testing by hand once; seeing that test entry show up in the analytics panel confirms the tracking code is actually working.
However good the design of a new site is, missing redirects and URL mapping still cost the search visibility already built up. rabbitclip runs the old URL list, the redirect plan and post-launch monitoring as their own line item on every migration project; if you already have a relaunch plan, we can check it against this list together.
FAQ
Does a 301 redirect hurt rankings?
No, not if it is set up correctly; the real risk is no redirect at all, or using a temporary one like a 302.
Does every old page need an exact match on the new site?
No, a page with no exact equivalent can redirect to the closest page on the same topic.
How long until rankings settle after a migration?
Usually a few weeks; it varies with site size and how much actually changed.
Why does the robots.txt check matter so much?
A crawl block added during development, if it carries over to production, can leave the new site invisible in search entirely.
Should internal links get fixed before migration?
Ideally yes; at the very least, every internal link should be updated to the new addresses right after launch.
