Site migration and 301 redirects without losing SEO
How to move a site without losing half its organic traffic: the URL inventory, a one-to-one redirect map, the 301 decision, launch-day order and the first 72 hours.
On Tuesday morning the marketing lead at an industrial parts distributor opens the weekly report. The new site went live late Saturday. Sunday and Monday looked slightly soft, and everyone put it down to the weekend. Tuesday, organic sessions are half of the previous week and the search console has flagged four thousand addresses as not found. Nobody had actually been careless: products used to live under one URL pattern, the rebuilt site moved them to another, and the redirect map had been prepared for category pages only. Four thousand product pages that had taken three years to earn their rankings lost their addresses over a single weekend.
The search side of a migration has little to do with whether the new design is liked. It has everything to do with the rule connecting old addresses to new ones. What follows separates the distinct projects hiding inside the word migration, breaks traffic loss into three causes, then covers the inventory to pull beforehand, how a URL mapping table is built, the choice between 301, 302 and canonical, the order of operations on launch day, what to watch in the first three days, when a dip is normal, and the work that begins after everyone thinks the migration is over.
How many separate projects hide inside the word migration?
At least six: changing the domain, moving to https, replacing the platform, changing the URL structure, redesigning templates and content, and relocating the server. Their risk profiles have nothing in common. A server move usually passes unnoticed. A domain change is a single, manageable risk. Changing the URL structure redefines the identity of every page on the site, and that is where the real loss comes from.
Teams tend to compress all six into one weekend, because the agency contract is a single line item and the development team's next free window is three months out. The bill for that arrives when something goes wrong and nobody can name the cause: traffic dropped, but was it a broken redirect, shorter product copy, or a slower server?
The standard advice is to change one thing at a time. For a small team that is usually unusable: three migrations mean three risky windows and three rounds of testing. The version that works is different — change the design, the platform and the server together, and leave the addresses alone. Preserving the URL structure is the cheapest insurance a migration offers, and in most platform selection decisions it is technically possible. It gets skipped because nobody insists, not because anyone refuses.
Why traffic falls: three separate causes
The first is severed link equity. Years of external links, internal links and bookmarks point at old addresses; with no redirect, that value drains away rather than moving. The second is recrawl lag. A search engine does not discover new addresses overnight — it visits the old ones, sees the redirect, and queues the new page. On a large catalog that queue takes weeks to clear.
The third cause is the one teams overlook: the template change itself. To make the design feel airier, product copy went from three paragraphs to one, category descriptions were dropped, sidebar links were tidied away. Even with perfect redirects, thinner pages rank lower. The three causes show different symptoms and are diagnosed from different places; we cover the mechanics in our article on crawling and indexing.
Diagnose in this order: index status first, redirect accuracy second, content last. Teams that start from the other end spend weeks rewriting copy when the problem may sit in a single misconfigured rule.
What inventory do you pull before you move?
The quality of a migration is set less by launch day than by the lists gathered two weeks earlier. They cannot be reconstructed after the fact: once the old site is gone, producing a complete list of its addresses gets much harder. The six records below are the raw material of the mapping table.
- The full address list: Crawl the old site end to end into one table of address, status code and canonical value; pages unreachable from the menu but still sitting in the index surface exactly here.
- Pages that earn search traffic: Pull every address that received clicks in the past twelve months from search console data; this list sets priority, because this is where loss is felt.
- Pages that attract external links: Identify which old addresses are linked from elsewhere; even at low traffic they carry authority built up over years and can never be skipped.
- Pages that generate conversions: Flag the entry addresses of visitors who submit forms, add to cart or pick up the phone; a mistake on these pages hits revenue directly.
- Template inventory: List the distinct templates — product, category, article, landing — and the markup each carries; new templates get checked against it.
- Measurement setup: Write down which tag fires where and which goals exist; if measurement breaks, you cannot tell whether traffic fell or tracking stopped.
How is the URL mapping table built?
The table itself is trivial: old address, new address. The decision behind each row is not. The rule is that every old address points to the one new address where its content genuinely continues. Bulk pattern rules work only where the pattern is preserved exactly; once the category structure changes, manual mapping is unavoidable and becomes the longest line item in the project.
| Situation | Correct call | If skipped |
|---|---|---|
| Page with a direct equivalent | 301, mapped page by page | Rankings restart from zero on the new address |
| Two pages merged into one | 301 both to the new page | The gain from merging disappears |
| No equivalent, but has traffic and links | 301 to the nearest parent category | External link value drains away |
| No equivalent, no traffic, no links | Close it with a 410 | A redirect to home is read as a soft error |
| Filter and parameter addresses | Canonical to the new filter address | Thousands of duplicates eat crawl capacity |
The last two rows are where the arguments happen. Sending every orphaned page to the homepage is easy and wrong: the engine reads it as a closed door rather than a move, and the visitor who wanted a specific part lands on a storefront. Honestly closing a page that no longer exists beats a redirect that pretends. A migration is also the natural moment to fold two weak pages into one strong one, a logic we cover in our piece on pages competing against each other.
301, 302 or canonical?
A 301 says permanent: forget the old address, carry its value forward. A 302 says temporary, so the old address stays in the index because the engine assumes you are coming back. Using 302 in a migration is the most common reason for the question, asked two months later, of why old addresses still show. A canonical is not a redirect at all — both pages stay open, and you only name which is authoritative.
The choice comes down to one question: when someone lands on the old address, do you want them to see the old page? If no, use 301. If yes, but you want one version in search results, use canonical. Outside a temporary maintenance page, 302 has no place in a migration.
Break the chains and the loops
After a few migrations stacked over the years, one address redirects to a second, which redirects to a third. Every hop adds latency and ambiguity, and long chains may be abandoned before the end. Flatten them when you build the new map: old addresses should point straight at the final destination. The same goes for internal links — menus, buttons and in-text links should carry the final address rather than lean on a redirect.
Loops are nastier: A points to B, B points back to A, and the page never opens. This usually comes from two rules colliding, one defined at the server level and one inside the application. Keeping redirect rules in a single place removes half of these collisions before they happen.
How long should redirects stay up?
At least a year, and indefinitely if you can. Search engines learn the new address within months, but external links, old emails, PDF catalogs and forum posts point at the old one for far longer. The day a redirect is removed, all of those references break. If the rule count weighs on the server, convert single lines into pattern rules — do not delete them.
What is the order of operations on launch day?
Order matters, because most accidents come from steps swapping places. First, the crawl blocks used on staging are removed. That sounds dull, and it is the most expensive failure in the category: the file keeping search engines out of the test site is copied to production untouched, and the site stays unindexed for weeks. The first post-launch check is confirming that the homepage and three random inner pages are open to crawling.
Then redirect rules go live, a random sample of old addresses is tested by hand, the new sitemap is submitted, and the old sitemap is deliberately left reachable a while longer. That last one surprises people: it makes the crawler revisit old addresses on purpose and pick up the redirects sooner. Verify the same day that structured data markup survived the redesign; it lives inside the old template and vanishes silently when that template is rewritten.
The first three days: what do you watch?
Watching traffic on day one is misleading. What matters is the server log: which addresses the crawler requests and what status code it gets back. A bot hitting old addresses and receiving a 301 means the process works. A 404 means a hole in the map, and that cannot wait a week.
The second check is measurement itself. If tags never made it into the new templates, the drop on the dashboard may not be real — and double-counted events hide a genuine loss just as easily. Interpret no number before confirming that your analytics setup collects the same events under the same names as before.
For the first two weeks after a migration you watch index status, not traffic; a team watching traffic reaches panic early and the real problem late.
When is a dip normal, and when is it an alarm?
On a mid-sized site whose URL structure changed, two to six weeks of turbulence is expected. Rankings move a few positions, some pages vanish temporarily, then settle. Reading the report daily during that window and acting on it makes the migration's effect impossible to measure.
The alarm is not the traffic curve; it is three concrete symptoms. Indexed page count drops and does not recover. The logs still show the crawler receiving 404s. The new versions of pages that lost traffic do not appear in search results at all. If none of the three are present, waiting is the right call. If any of them is, waiting only makes the loss bigger.
The work that starts where the migration appears to end
The new site is live, redirects hold, the index has recovered. All of that was about not losing. Winning is a separate job, and a migration opens a one-time window for it: templates have just been touched and the technical debt is fresh in everyone's mind. Measuring page speed now and comparing page experience signals against the old site makes differences visible while they are still explainable.
The second opportunity is editorial. The migration put in one table, for the first time, which pages bring traffic and which have sat idle for years. That table is expensive to rebuild once discarded; keep it as the starting list for your content refresh plan.
Common mistakes and the rollback plan
Three mistakes account for most of the damage: mapping at category level and forgetting product pages, deleting the old sitemap on launch day, and carrying the staging crawl block into production. A fourth is discussed less — scheduling the migration into the busiest sales weeks of the year, which both amplifies the loss and makes cause impossible to separate from season.
Write the rollback plan down too. Keep the old site reachable for at least two weeks, keep a database backup at hand, and hold redirect rules in one file so they can be switched off in a single move. A rollback is itself a migration; done without a plan it does more damage than the original mistake.
The hardest part of a move to preserve is the memory of which page brought which customer. When search and paid visitors land in one customer record, the history of the relationship survives a change of address. Rocketly keeps form submissions, campaign sources and customer history together — create a free account and see whether post-migration traffic really turns into sales.