The Content Migration Playbook: Move Thousands of Pages and Protect Your Search Traffic

This playbook is for anyone about to move a site: a new CMS, a new URL structure, a new domain or a merger of several sites. It gives you six phases (inventory, decisions, redirect mapping, build and validation, cutover, monitoring), Google's own rules for each step, and the checklists and templates to run it. Follow it and the migration becomes a planned project with gates, not a launch-day gamble.

Migrations rarely fail on launch day. They fail weeks earlier, when a URL was left out of the inventory, a decision was deferred or a redirect was mapped by pattern instead of by topic. The traffic loss is the late symptom. Every phase below exists to catch one of those failures while it is still cheap to fix.

Name the migration type first

"Migration" covers very different projects. The phases are the same for all of them, but the Google-specific steps and the risk are not.

A rebrand or large rewrite often rides along with one of these. When it does, treat the content changes as a separate risk: if rankings move after launch, you want to know whether the URLs or the words caused it. Where you can, change one thing at a time.

Why migrations lose traffic

• Incomplete inventory.The team moved the pages it knew about. Old landing pages, PDFs and parameter URLs it didn't know about returned 404s.
• Redirect chains and wrong targets. Old URLs point to older URLs, or to a page about something else.
• No audit before the move. Hundreds of pages that should have been merged or retired were carried into the new architecture.
• Sample testing. Redirects were checked on a sample; the legacy URL pattern used only by old product pages broke.
• Launch-day leftovers. The staging noindex or robots.txt block shipped to production.
• No monitoring plan. Problems surfaced weeks later, after the team had moved on.

Phase 1: Inventory every URL

The goal is a complete list of every URL your site serves or has served recently, with enough data to decide what happens to each. A CMS export plus one crawl is not complete. Pull from six sources and deduplicate:

• CMS export: every published page, post, taxonomy term and custom content type.
• A full crawl: follows links, sitemap entries and pagination, and catches auto-generated pages the CMS hides.
• XML sitemaps: including auto-generated ones for tags, categories and archives.
• Search Console: every page with impressions in the Performance report. The interface exports only 1,000 rows, so use the API (up to 50,000 rows per day per site per search type) or the bulk export for large sites. Data goes back about 16 months.
• Server logs: URLs requested in the last 6 to 12 months, including PDFs, campaign URLs and old redirects that no other source shows.
• Analytics: every page with views in the last 12 months, as a cross-check.

The inventory template

One row per URL. These columns are enough to drive every later decision:

If you already keep a live content inventory, this phase takes days. If you don't, building it is the project before the project.

The URLs teams forget

• Paginated archives such as /blog/page/2, which often have links and impressions.
• Tag and archive pages generated by the CMS and never audited.
• Parameter URLs such as ?page=2 or ?filter=. Decide deliberately which need to survive.
• PDFs and other files, often linked from other sites and a classic source of post-launch 404s.
• Old campaign and microsite pages still linked from emails, partners and ads.
• Redirects from earlier migrations.They are invisible day to day and become chains if you don't fold them into the new map.

Document odd URL patterns now (mixed trailing slashes, uppercase paths, inconsistent parameters) with a Site architecture review, before they become redirect bugs.

Phase 2: Decide what moves, changes or goes

A migration is the cheapest moment you will ever have to clean up a library: every page is being touched anyway and stakeholders expect change. Give every URL one decision before mapping starts: keep, rewrite, consolidate, redirect or retire.

Rules of thumb for the decision

These thresholds are starting points from practice, not Google rules; adjust them to your site's size. For the full framework, see the guide on when to merge, prune or leave content.

Don't defer the decisions

"Migrate everything as-is and prune next quarter" almost never happens. Once launch ships, the urgency is gone and the new site carries the old problems. The decisions phase is slow and involves arguments. That is the right cost to pay, and it is far smaller during the migration than after it.

Phase 3: Map redirects

This is where small errors become large traffic losses. Google's guidance is specific, so build the map on it:

• Use permanent, server-side redirects. Google recommends HTTP permanent redirects such as 301 or 308 for a site move. Google treats a permanent redirect as a strong signal that the target should be canonical and shows the target in results. A temporary redirect (302, 303, 307) is a weak signal, and Google shows the source page instead. JavaScript redirects are a last resort, because Google may not see them if rendering fails.
• Redirect straight to the final URL. Googlebot follows up to 10 redirect hops, but Google advises keeping chains short, ideally no more than 3 and fewer than 5 hops. In practice, aim for one: flatten redirects from earlier migrations into the new map.
• Map one to one wherever you can. Merging several old pages into one new page is fine. Sending many old URLs to one unrelated destination, such as the new homepage, is not: Google warns it can confuse users and may be treated as a soft 404.
• Let truly retired pages return 404 or 410.Google treats all 4xx codes except 429 the same way: the URL drops out of the index. Choose 410 if you want to say "gone on purpose" to people and other tools; for Google, either works.
• Handle variants consistently. HTTP to HTTPS, www or not, trailing slash or not, and letter case should all resolve in one hop to the single final URL.
• Keep redirects for at least a year. Google says to keep them as long as possible, generally at least one year, and to consider keeping them indefinitely for users.

The redirect map template

Have someone who didn't build the map review it. A second pair of eyes at this stage is the cheapest quality check in the whole project.

Map by topic, not by string

The most common mapping mistake is a pattern rule doing work that needs judgement. A rule that sends /blog/* to /resources/* works only if no slug changed. In the example above, /blog/content-audit-guide became /resources/auditing-content; the pattern rule would send it to a URL that doesn't exist. Map every URL you care about explicitly. Keep pattern rules as a fallback for low-value groups you have consciously decided to map loosely, such as old tag pages.

Before you change or remove a high-value URL, check what depends on it: which pages link to it, what queries it ranks for and how many clicks are at stake. An update impact analysis answers exactly that, and it catches mappings that look right by URL but serve a different intent.

dash.morrison.app/lumenpay.com/chat

Illustration

lumenpay.com/Migration impact: guides

What do you want to know about lumenpay.com?

Ask about your website content...

Search ConsoleAhrefs

Claude Sonnet 5.5

Update internal links to final URLs

Redirects handle external links and the existing index. Your own links should point straight at the new URLs, and Google recommends updating them as soon as the move starts. Remember there are two kinds: links in body copy, which content teams own, and links in navigation, footers and templates, which developers own. Audit both. An internal link audit before launch lists what to change; one after launch confirms nothing still points at an old URL. The internal linking guide covers the wider system.

Phase 4: Build and validate

While engineering builds, the content team's job is validation: does the new site match the decisions and map from the earlier phases?

Staging rules

• Keep staging out of Google with password protection, and match production's server, CDN and redirect handling as closely as you can. Redirects that work on staging and fail on the production CDN are a classic launch bug.
• Prepare the production robots.txt in advance, and keep a list of every URL where a development noindex must be removed at launch. Google calls both out in its site move guidance.
• Keep the Search Console verification file or meta tag in the new templates, so verification survives the move.

Validate the whole redirect map

Every row, not a sample. Script it against staging, then again against production at launch:

1. Each old URL returns the expected status (301, 308, 404 or 410).
2. Each redirect lands on the expected new URL in one hop.
3. Each target returns 200, is indexable (no noindex) and has a self-referencing canonical.
4. Titles, main content and structured data on the target are present.
5. A manual spot check per content type (blog, product, category, legacy, PDF) catches what the script can't.

Any mismatch blocks launch. Use your own crawler or script for this: Search Console's URL Inspection API allows 2,000 inspections per day per property, which is right for spot checks on key pages and too few for validating a large map.

Validate content fidelity

If content is rewritten or passes through new templates, compare old and new versions. Rule of thumb: review 10% of pages across all content types, and every page in your top 50 by clicks. Look for lost sections, broken tables, missing images, changed headings and facts that no longer match the rest of the site; a cross-page consistency check helps with the last one.

Phase 5: Cut over

Google recommends moving all URLs at once for small and medium sites. For large sites, moving one section at a time is acceptable and makes problems easier to spot and fix. Either way, the sequence is the same.

Phasing a large site

• Start with a section that has fewer external links and clean URLs.
• Monitor for a week or two. If it settles, move the next one.
• Move the commercially critical sections once the setup has proved itself.

A problem found in the first phase costs a little traffic in one section. The same problem in a big-bang launch hits the whole site.

The non-content checklist

• Search Console: verify all variants of both old and new sites. For a domain move, you must own both properties with the same Google account and run Change of Address from a domain-level property. Google forwards signals for 180 days after you start.
• Analytics: tags on every template, key events firing on the new forms and thank-you pages.
• Google Ads:update final URLs to the new pages instead of relying on redirects. For a domain change, an ad whose final URL redirects to a different domain can be disapproved under Google Ads' destination requirements.
• Email: automated and transactional templates, and links in scheduled campaigns.
• Partners and top linkers: ask the most important referring sites to update their links. Redirects cover you, but a direct link is cleaner.
• Structured data:rebuilt on the new templates and checked with Google's Rich Results Test.

Phase 6: Monitor, recover and close

Google says a small or medium site can take a few weeks for most pages to move in its index, larger sites longer, and that rankings may fluctuate while it recrawls. The migration is done when traffic and conversions are back on their pre-migration trend, not when the site is live.

First 72 hours

• Server logs: every 404 is a URL missing from the map; every 5xx is a rendering bug. Fix both the same day.
• Search Console Page indexing report:watch for "Redirect error" (chains too long, loops, bad URLs), unexpected "Not found (404)" and new soft 404s. Old URLs appearing as "Page with redirect" is expected.
• Top pages: inspect your top 20 new URLs with URL Inspection and confirm Google can fetch and index them.
• Conversion paths: a broken form on a top page costs money even while search looks fine.

Weeks 1 to 4

• In the Sitemaps report, the old sitemap's indexed count should fall towards zero and the new one's should rise. Google says you can remove the old sitemap once the new one is in use.
• In the Performance report, new URLs should pick up the impressions and clicks the old ones lose. Compare with the same weeks last year to account for seasonality.
• Re-run the internal link audit to catch links that slipped through, and compare redirect hits in your logs with the map.

Weeks 4 to 8

• Indexed pages approach the old baseline, minus deliberate retirements.
• Top pages are back at or above their old positions. Pages still lagging become refresh candidates, not migration bugs.
• Close with a short post-mortem: what went smoothly, what nearly broke, and what to keep for next time.

If traffic drops

Don't panic-revert: undoing a migration is a second migration. Diagnose first:

1. Where is the drop?Site-wide drops point to launch blockers (robots.txt, noindex, canonicals). Drops in one section point to that section's redirects or templates.
2. What do the affected URLs actually return? Check the live response and the final URL, not what the map says.
3. Has Google recrawled them? URL Inspection shows the last crawl. Recovery often lags recrawling.
4. Did anything else change? A Google core update or a big content rewrite in the same weeks changes the diagnosis.

If a drop persists beyond eight weeks with clean redirects, treat the affected pages as a refresh project; the content refresh playbook covers how to prioritize and diagnose them.

Where Morrison helps

Morrison is not a redirect server or a technical crawler, but it covers several content-side steps of this playbook:

• Inventory. The site index crawls from your sitemap, by following links, or from a list of URLs you provide. Every URL carries its HTTP status, its redirect target if it redirects, its metadata, the links in its copy and its last 90 days of Search Console clicks and impressions. Group pages into segments and export any view to CSV.
• Decisions and dependencies. Ask Chat which pages link to a URL in their copy, what it ranks for and how much traffic is at stake before you change it. Chat answers from the whole site index and reads whatever pages the decision needs; to pull the data for every URL in a section, run a workflowthat pulls each URL's queries and clicks from Search Console, up to 500 pages a run, and writes one result per URL into the grid. The URL export's internal links show which pages link where.
• After launch.Status is checked on every crawl, so after your next recrawl, filter for anything that isn't a 200 to see redirects with their targets and every new 404. Within one domain, redirect targets are crawled too, so Morrison reads the page you actually serve. Search Console URL inspection and sitemaps are available in Chat for spot checks.

Two limits to plan around: Morrison reads the main content of each page only, so links in navigation and footers need a technical crawler; and it records each URL's status and redirect target rather than testing a whole redirect map hop by hop, so the validation script in Phase 4 still matters. The content migration planning use case shows the Morrison side in more detail.

Key takeaways

• Name the migration type. It decides whether you need the Change of Address tool, and how much risk you carry.
• Inventory from six sources. CMS, crawl, sitemaps, Search Console, logs and analytics. Missing URLs are the most avoidable loss.
• Decide before you map. Every URL gets keep, rewrite, consolidate, redirect or retire.
• 301 or 308, one hop, to a relevant page. No homepage dumping; let truly retired pages return 404 or 410.
• Validate every row. Status, target, one hop, indexable target, on staging and again at launch.
• Ship without the staging leftovers. Production robots.txt and noindex removal are part of the release.
• Keep redirects at least a year and monitor actively for four to eight weeks.
• Write the post-mortem. The next migration comes sooner than you think.