The Content Migration Playbook: How to Move Thousands of Pages Without Losing Traffic

There is a specific kind of quiet that falls over a content team in the week after a migration goes live. Everyone is watching the dashboards. Traffic is flat, then dips, then flattens again. Someone notices a 404 in Search Console. A product marketer messages the group chat to say a landing page URL from a paid campaign is broken. The engineering lead pulls up the redirect log and starts clicking through entries. The CEO asks why the numbers are down and whether this is "the migration."

This is the scene every content team dreads, and most content teams experience at least once. Migrations – moving content to a new CMS, restructuring URLs, consolidating domains, rebranding, changing site architecture – are one of the highest-stakes projects a content team will ever run. They combine the technical complexity of an engineering project, the editorial complexity of a content overhaul, and the operational complexity of coordinating dozens of stakeholders. The cost of getting them wrong is measured in permanent ranking losses, broken conversion paths, and the kind of organic traffic craters that take quarters to climb out of.

The good news is that migrations do not have to go this way. The teams that migrate thousands of pages without material traffic loss do not have better luck or more technical ability. They follow a much more disciplined process – one that treats the migration as a multi-phase project with named gates, explicit inventories, and validation at every step. Most migration disasters come from shortcuts on one or two of those phases. Traffic and rankings are the quiet consequence of an invisible process failure that happened weeks before launch.

This guide walks through the full playbook: how to inventory what you have, how to decide what moves, how to map redirects, how to sequence a cutover without breaking everything at once, and how to monitor in the weeks after launch. It is written for content leaders and SEO owners who want to walk into their next migration with a defensible plan and walk out with their rankings intact.

What actually counts as a content migration

"Migration" gets used loosely to mean any large change to a website. Before you plan one, it is useful to be precise about which kind you are running, because the playbook differs materially between them.

The five common migration types

• Platform migration. Moving content from one CMS to another (WordPress to Contentful, Contentful to a headless setup, custom to Sanity). URLs may or may not change. The content moves wholesale, but the structure mostly stays the same.
• URL restructure. Keeping the same CMS but reorganizing the URL structure. Moving from /blog/post-slug to /resources/post-slug, or from flat URLs to a category hierarchy. The content is the same; the paths change.
• Domain change. Moving the site from one domain to another, usually because of a rebrand, acquisition, or consolidation of multiple domains into one. Every URL on the site changes by definition.
• Site consolidation. Merging multiple properties into one. This is the most complex migration because you combine the risks of URL restructuring, domain changes, and content deduplication all at once.
• Rebrand-driven content migration. Not always a URL change, but a systematic content rewrite across large parts of the site. The URLs stay, the pages change underneath. Often paired with one of the above.

The specific playbook varies, but the phases are the same: inventory, decisions, mapping, build, cutover, validation. The risk profile changes across types – a URL restructure is less risky than a domain change, which is less risky than a site consolidation – but the discipline required does not.

Why migrations fail

In the post-mortems of every traffic-destroying migration, you find the same patterns:

• Incomplete URL inventory.The team migrated the pages they knew about. Thousands of pages they didn't discover – old landing pages, orphaned blog posts, parameter URLs, PDFs, image pages – got 404s instead of redirects.
• Broken redirect chains. Old URLs redirect to other old URLs that redirect to other old URLs. Each hop increases the chance the chain breaks somewhere and sheds link equity.
• No content audit before the move. The team migrated whatever existed, including hundreds of pages they would have consolidated, redirected, or retired if they had paused to audit first. Post-migration, they are stuck with a new architecture full of old problems.
• Testing skipped or rushed.The migration was validated on a sample of pages rather than comprehensively. Edge cases – the one old URL structure used only on legacy product pages, the paginated archive URLs, the UTM-tagged campaign landing pages – were missed.
• Cutover happened in one shot. Rather than rolling out in phases with rollback points, the whole site moved at once. When problems appeared, the team had no easy way to isolate or reverse.
• No monitoring plan after launch.The team assumed "if it went live, it worked." Actual problems showed up weeks later as rankings decayed, but by then the urgency had passed and the team had moved on to other work.

Every failure mode in that list has a specific phase of the playbook designed to prevent it. The playbook is the discipline of not skipping those phases when the deadline is pressing.

Phase 1: Inventory everything

A migration you don't know about is a migration that fails. The inventory phase is the least glamorous and most critical part of the project. The goal is simple: produce an exhaustive list of every URL currently served from your site, with enough metadata to make decisions about each one.

What "exhaustive" actually means

Most teams build their inventory from one or two sources – usually the CMS export and a crawl – and call it complete. That inventory misses dozens to hundreds of URLs that Google knows about but your crawl doesn't. An exhaustive inventory pulls URLs from at least these six sources and deduplicates across them:

• CMS export. Every page, post, taxonomy term, and custom content type currently published.
• Full-site crawl. A comprehensive crawl that follows internal links, sitemap entries, and pagination. This catches auto-generated pages the CMS export might miss.
• XML sitemaps. All sitemaps including any auto-generated ones for categories, tags, or archives.
• Google Search Console.Every URL with impressions or clicks in the last 12 months, including URLs Google indexes that don't appear in your own tools. This is where a lot of surprise URLs surface.
• Server logs. All URLs that have received traffic in the last 6-12 months, including URLs not in any of the above. This catches campaign URLs, PDF downloads, redirect entries, and parameter-based URLs.
• Analytics. Every URL with pageviews in the last 12-24 months. Cross-check against the other sources to surface discrepancies.

For each URL in the combined inventory, attach the metadata you need for the later phases:

• URL, page title, and meta description
• Content type (blog post, product page, landing page, category, legacy, PDF)
• Last modified date
• Organic impressions and clicks (last 12 months)
• Number of referring domains and backlinks
• Number of internal links pointing to this URL
• Any conversions or revenue attributed to this URL

This is where a robust content inventory practice pays for itself many times over. If your team already maintains a live inventory with this metadata, Phase 1 of a migration is a week, not a month. If you don't, building the inventory is the project before the project.

Discover the URLs you'd otherwise miss

Certain categories of URLs are disproportionately likely to be missed by standard inventory methods, and they are disproportionately likely to cause problems post-migration if forgotten:

• Paginated URLs. /blog/page/2, /category/page/5, and similar. These often have backlinks and impressions that disappear silently in migration.
• Tag and archive pages. Auto-generated by the CMS, sometimes never audited. Often have more indexed URLs than the team realizes.
• Parameter URLs. ?utm_source=..., ?page=2,?filter=.... May or may not need to survive migration depending on what they do, but they need to be consciously decided about, not forgotten.
• PDF downloads and other non-HTML resources. Often ignored in content migrations, often linked from external sites, often the source of sudden 404s after cutover.
• Old campaign and microsite URLs. Landing pages from campaigns run two years ago, still receiving some traffic, still linked from old email campaigns and paid ads buried in search caches.
• Legacy URL structures. If the site has been through a previous migration, there may be URLs still redirecting from the structure before that. These chains are invisible during normal operation but become critical to preserve.

Getting the inventory right is also where an URL structure audit pays off. Surprising URL patterns – mixed trailing slashes, inconsistent parameter usage, redirects that already exist from past migrations – need to be documented now, before they cause issues later.

Phase 2: Decide what moves, what changes, and what dies

Every migration is also an opportunity to clean up years of accumulated content. Teams that treat migrations as "move everything as-is" end up porting their old problems into the new architecture. Teams that treat migrations as an opportunity for editorial and structural decisions emerge with a cleaner site than they started with.

Before you build any redirect maps, run every URL in the inventory through an explicit decision: keep, consolidate, redirect, retire, or rewrite.

The case for pruning, not just moving

Most large content libraries have a long tail of pages that no longer drive traffic, conversions, or strategic value. Migrating those pages unchanged costs you in three ways. You spend engineering time on content that doesn't earn it. You pollute your new site's topical focus with thin content. And you carry forward maintenance debt that a clean break could have resolved.

Migrations are the single best time to prune. The team is already opening every page for migration anyway. The URL is already going to change (or be considered). Stakeholders are already expecting disruption. The cost of deciding "this page does not move forward" is dramatically lower during a migration than at any other point in the content lifecycle.

For the decision framework on what to keep, consolidate, or prune, see our detailed guide on content consolidation. For the migration-specific version, the rule of thumb is: if a page has fewer than 5 organic clicks a month, no backlinks, and no internal links pointing to it, it is a candidate for retirement or consolidation into a parent topic – not one-to-one migration.

Don't let "move now, decide later" happen

The most common migration failure mode in the decisions phase is deferring decisions. "We'll migrate everything as-is and prune in the next quarter." This almost never happens. Once the migration ships, the urgency evaporates, and the new site carries the old problems indefinitely.

Force the decisions upfront. Every URL gets a decision before the mapping phase starts. The decisions phase is hard, slow, and involves arguments with stakeholders. That is the correct cost. Deferring it just moves the cost from "part of the migration project" to "permanent drag on the new site."

Phase 3: Map redirects meticulously

With the inventory done and decisions made, redirect mapping is next. This is the phase where small errors become large traffic losses. Google's guidance on site moves with URL changes is clear about what matters: 1:1 redirects, permanent (301) where the move is permanent, to the most equivalent page on the new site.

The rules of good redirect mapping

• One-to-one wherever possible. Each old URL should redirect to the single most equivalent new URL. Avoid many-to-one redirects (dozens of old URLs pointing to the homepage) except as a last resort for URLs that genuinely have no topical equivalent.
• Permanent (301) redirects. If the old URL is never coming back, use a 301. Temporary (302) redirects are for actually temporary changes; Google treats them very differently for link equity preservation.
• No redirect chains. Every old URL should redirect directly to its final destination, not to another old URL that then redirects. If your site has legacy redirects from previous migrations, flatten them during this migration.
• Preserve protocol and subdomain rules. http:// to https:// and non-www to www (or vice versa) redirects should be enforced consistently across the redirect map.
• Handle trailing slashes deliberately.If your new site uses trailing slashes and your old site didn't (or vice versa), every URL needs explicit handling.
• 410 Gone for genuinely retired pages. A page that has no valid destination and no remaining equity should return 410, not redirect to the homepage. Telling Google the page is intentionally gone is cleaner than creating a soft-404 user experience.

Build the redirect map as a spreadsheet (or a structured data source) with columns for old URL, new URL, decision type, and notes. Review it. Then have someone else review it. A senior SEO or content lead who didn't build the map spotting issues at this stage saves enormous amounts of post-launch cleanup.

Map by topical relevance, not by string similarity

The single most common redirect mapping mistake is mapping by URL pattern rather than by content. When URLs change substantially, the old /blog/content-audit-guide might have a natural equivalent at /resources/auditing-content– even though the slugs do not match. A redirect rule that just maps /blog/* to /resources/* will misroute URLs that changed slugs during the migration.

For substantial migrations, the mapping should be done at the page level, not the pattern level. Pattern rules are a fallback for URLs where you deliberately accept a loose mapping (old tag pages, for example). Explicit mappings are for everything you care about preserving.

This is where having a content inventory with topical tagging and a clear view of which new URL corresponds to which old topic pays off. An update impact analysis run over each proposed redirect can surface cases where the mapping looks right by URL pattern but the pages actually cover different intent.

Preserve internal links, not just redirects

Redirects handle external links and existing indexing. They do not fix internal links within your own site. Every internal link pointing to an old URL should be updated to point directly to the new URL. Letting internal links rely on redirect chains permanently is bad for crawl efficiency, user experience (each redirect adds latency), and link equity flow.

This is where an internal link audit run before and after migration is invaluable. Before migration, it tells you which pages contain links that will need updating. After migration, it verifies that every internal link lands on its final destination rather than passing through a redirect. Our detailed guide on internal linking strategy at scale covers the broader system this fits into.

Phase 4: Build and validate the new site

Building the new site is, in migration terms, the engineering phase. The content team's job during build is validation: making sure the new site, as it comes together, matches the decisions, redirects, and content state defined in the earlier phases. Getting pulled into content execution during this phase without a validation framework is how things slip through.

Mirror the production environment in staging

The staging environment should be as close to production as possible: same server configuration, same CDN setup, same redirect handling, same robots directives (though staging itself should be noindexed and password-protected). Differences between staging and production are where migration bugs hide – a redirect that works on staging but not on the production CDN configuration is the classic case.

Validate the redirect map before launch

Every entry in the redirect map should be tested against the staging environment. For large maps, this cannot be done manually on every URL, but it can be automated:

• Script a check that fetches each old URL on staging and verifies it returns a 301 to the expected new URL.
• Verify no redirect chains (each redirect returns the final 200 response after one hop).
• Spot-check a stratified sample by content type (blog, product, category, legacy, PDF) manually to catch issues the script might not flag.
• Verify pages that should return 410 do so, rather than redirecting or 404-ing.

This validation should happen on the full redirect map, not a subset. Every URL in the inventory gets checked. Any discrepancy between expected and actual behavior is a blocking issue for launch.

Validate content fidelity

For migrations that involve rewrites, the content team also has to validate content fidelity: is the new version of each page faithful to the intent of the old version, correctly updated where updates were planned, and consistent with the brand voice and governance standards? This is where the cross-page consistency and brand voice work from your existing governance program applies.

A useful check: pick 10% of pages across content types, compare the old and new versions, and flag any unintended changes. In large-scale migrations with rewrites, content gets inadvertently altered more often than teams expect – especially when content passes through formatting or template changes.

Phase 5: Cutover without a single point of failure

The cutover is the moment the new site becomes the live site. For small migrations, this is a single deployment. For larger ones, it is a phased rollout designed to contain risk.

Phased cutovers for large sites

For very large sites, a single big-bang cutover is unnecessarily risky. Where possible, phase by content type or section:

• Launch the new architecture with the least-risky content first (for example, a recently-built resource section that has fewer backlinks and clearer URLs).
• Monitor for a week. If everything looks good, migrate the next section.
• Save the most commercially critical content (product pages, top organic pages, top conversion paths) for a later phase, when the infrastructure has been tested.

Phased cutovers are harder to coordinate, but they isolate risk. A problem surfaced in the first phase costs a little traffic. The same problem surfaced in a big-bang migration can cost quarters.

Don't forget the non-content pieces

Migrations have a surprising number of dependencies beyond the content itself. A working cutover plan includes:

• Analytics. Updated tracking on every new URL, with cross-checks that conversion events still fire.
• Paid campaigns. Every ad landing page URL updated, or the redirect map confirmed to handle ad traffic without penalty (Google Ads is particularly unforgiving of 302s on landing pages).
• Email campaigns. Automated and transactional email templates updated; links in scheduled campaigns checked.
• Partner and backlinked URLs. Where possible, reach out to the most important external linkers to request link updates. Redirects cover you, but direct links are cleaner.
• Search Console setup. The new domain (or site variant) verified; old and new properties both accessible for comparison.
• Schema and structured data.Preserved or rebuilt on the new site; validated with Google's Rich Results Test.

Phase 6: Monitor, recover, and reconcile

The migration is not done when it launches. It is done when the new site's rankings, traffic, and conversions have stabilized at or above their pre-migration trajectory. For most migrations, that's a 4-8 week window of active monitoring.

The first 72 hours

In the first three days, watch:

• Search Console coverage reports. New URLs should start appearing as indexed within 24-72 hours; old URLs should be marked as redirects. Unexpected 404s are the single clearest early warning signal.
• Server logs for 404 and 500 responses.Every 404 is a URL that should have been in the redirect map and wasn't. Every 500 is a page rendering bug. Both need same-day attention.
• Top-page rankings. Rankings for the top 50-100 URLs, monitored daily. Small fluctuations are normal. Sustained drops of more than a few positions on multiple top pages warrant investigation.
• Conversion rates on critical paths. Especially on commercial pages. A broken CTA or form on a top-converting page can cost real money even while SEO looks healthy.

Weeks one through four

As the site settles, shift from hourly to daily to weekly monitoring:

• Compare traffic patterns week-over-week with the equivalent pre-migration periods (adjusted for seasonality) to identify any sustained decline.
• Work through the Search Console coverage report systematically – every "Not indexed" URL has a reason, and most reasons are fixable if caught early.
• Run a targeted internal link audit to catch links still pointing at old URLs that slipped through the bulk update.
• Compare redirect map usage against server logs to identify redirects that are firing unexpectedly or not firing at all.

Weeks four through eight

By week four, most issues should be identified and either fixed or on the fix queue. Weeks four through eight are about confirming recovery and closing the project:

• Total indexed pages should be approaching the pre-migration baseline (adjusting for any pages deliberately retired).
• Rankings on top pages should be at or above pre-migration positions; any still-lagging pages become refresh candidates, not migration bugs.
• Traffic should be within expected seasonal variance of the pre-migration trajectory.
• Close the project with a post-mortem: what went smoothly, what almost went wrong, what process improvements are worth carrying into the next migration.

When things go wrong

Some percentage of migrations do cause traffic loss despite best efforts. The response to a traffic drop is not to panic-revert (that creates a second migration on top of the first, which typically makes things worse). It is to diagnose:

• Is the drop site-wide or concentrated in specific sections or page types? Concentrated drops almost always trace to a specific redirect or content issue in that area.
• Are the affected URLs returning the right status codes and content? Check the actual response, not what you expect.
• Has Google re-crawled enough of the new site to reflect the change? Recovery sometimes lags index refresh.
• Is the drop correlated with a core algorithm update that happened to coincide with the migration? This is rare but possible, and it changes the diagnosis.

For drops that persist beyond eight weeks, the post-migration recovery becomes a content refresh project. The framework in our content refresh playbook applies: prioritize by business impact, diagnose why specific pages lost rankings, and refresh the content rather than assuming the migration itself is the sole cause.

Where content intelligence changes the migration equation

Everything described above can be done manually. It is also, at the scale most teams operate at, the reason migrations take months and come with surprise traffic losses.

A content intelligence platform changes several specific parts of the playbook. The inventory is maintained continuously, not built from scratch for every migration. Cross-page consistency and redirect-mapping decisions can be run as AI workflows that read the old and new content and suggest the topically correct mapping rather than a string-matched guess. Pre-launch validation can include semantic checks – does the new page actually cover the same topic as the old one – not just status-code checks.

Most valuable, post-launch monitoring can surface the specific kind of problem that migrations create: pages whose rankings are declining because the new content subtly shifted intent, pages that were redirected to technically-correct but topically-wrong targets, and internal links still pointing at old URLs three weeks after cutover. These are the problems that kill migrations silently, and they are the problems that become visible when your content library is queryable.

Morrison is built for this kind of work. The platform crawls and indexes your content, ties each page to its Search Console data, and runs workflows across the library – so that tasks like redirect-mapping validation, internal link updates, or pre-launch consistency checks happen as queries, not as quarter-long manual projects. Our dedicated use-case page for content migration planning covers the specific workflows in more detail.

Key takeaways

Content migrations are not a recurring event for most teams. They happen once every few years, and the cost of getting them wrong compounds for quarters. Treating them as routine engineering work is how they turn into crises. Treating them as multi-phase projects with named gates is how they ship quietly and stay stable.

• Name the migration type first. Platform migrations, URL restructures, domain changes, consolidations, and rebrands each have different risk profiles. The playbook phases are the same; the tolerances are not.
• Inventory everything from six sources, not one. CMS, crawl, sitemaps, Search Console, server logs, and analytics. Missing URLs are the #1 cause of avoidable traffic loss.
• Force decisions before mapping. Every URL gets a keep/consolidate/redirect/retire/rewrite decision before the redirect map is built. Deferred decisions become permanent problems.
• Map by topic, not by pattern. Pattern rules are fallbacks. Explicit mappings are what preserve ranking and intent.
• Flatten redirect chains. Every old URL redirects directly to its final destination. Chains leak equity and multiply failure points.
• Validate the full redirect map before launch. Not a sample. Every URL tested against staging, with automated scripts and manual spot-checks.
• Cut over in phases when size allows. Phased rollouts isolate risk. Big-bang launches amplify it.
• Monitor actively for 4-8 weeks. The migration is done when rankings and traffic stabilize, not when the site goes live. Build the monitoring plan before cutover and hold the team to it.
• Update internal links to final URLs, not redirects. Redirects are for external traffic. Internal links should always point to live URLs.
• Post-mortem every migration. The next one will happen sooner than you think, and the lessons compound across projects only if you capture them.

The cost of a disciplined migration is real: weeks of planning, arguments about what to retire, validation work that feels excessive. The cost of an undisciplined migration is larger and less forgiving: traffic that doesn't fully come back, rankings that settle lower than they started, and a new architecture that already carries the same problems as the old one. The playbook is how you trade the second cost for the first – intentionally, visibly, and on schedule.