Content Migration Checklist: Preserve URLs and Meaning

Decide what is moving and what is changing

A migration can change hosting, the content management system, URL paths, domain, templates or the information itself. List these dimensions before planning the work. A hosting move with stable URLs needs different safeguards from merging two libraries under new paths. Avoid adding a wholesale rewrite merely because every page is already being touched. If several dimensions must change together, preserve enough baseline evidence to diagnose failures. The migration plan should say which differences are intentional, which are incidental and which would count as a defect. Otherwise a lost paragraph can be mistaken for an editorial choice.

Google's site-move guidance recommends preparing the new site, mapping URLs and monitoring the move. Use that broad sequence, but build your own inventory from the systems involved. Include article routes, category pages, images, downloads and other resources with meaningful inbound links. A sitemap alone may omit older but still useful resources. Combine the content system export with navigation, server records and known campaign links where available. The content inventory guide explains how to establish a dependable starting list before deciding what should survive.

Map each old resource to an honest outcome

Give every inventoried URL an outcome: retained at the same address, moved to a relevant replacement, merged into a suitable guide or removed without replacement. Include the reason and intended destination. A spreadsheet of old and new paths is useful only if the destinations preserve the expected meaning. Sending every retired article to the homepage may avoid visible error pages, but it gives readers no explanation of where their information went. Evaluate a redirect by the task the original page served. A replacement should provide a credible continuation of that task, not simply exist on the new domain.

Consider an illustrative library with separate guides for changing an account email and resetting a password. Combining them into an account settings guide might be sensible if both procedures remain easy to find. Redirecting a deleted security policy to that guide would be misleading because the policy served a different purpose. The content consolidation guide covers the editorial decision. In migration planning, record the specific section or information that makes a merged destination appropriate. Where no equivalent exists, use a truthful removal response rather than manufacturing a relationship solely to avoid an empty cell in the mapping file.

Preserve the substance that templates can hide

Compare the migrated article body with the source before comparing visual polish. Check tables, notes, exceptions, image captions, downloadable resources and source links. Rich text importers can silently drop nested lists or convert a table into unreadable text. A page can retain its title and most paragraphs while losing the one condition that makes its recommendation accurate. Use representative content containing each complex element, then automate broader checks where feasible. Do not rely only on total word counts: equal counts can conceal duplicated paragraphs or the replacement of a meaningful section with a repeated template description.

Preserve dates according to their meaning. The date a record entered the new CMS is not automatically its original publication date or a substantive update date. Check author identities and structured data against the visible article. If the old system stored a byline separately from the body, a migration can accidentally attach the default author to everything. The author bio guide covers honest attribution; this checklist asks whether the new system retained it accurately. Review images and diagrams with their text alternatives so the migrated content remains understandable through the same accessible representations as before.

Rebuild URL signals as one coherent set

Implement redirects from moved routes to their final destinations and test the complete chain. Avoid creating a route through several historical versions when the final address is already known. Update internal links to the intended current URL rather than using redirects as permanent internal navigation. Canonical tags, sitemap entries and navigation should describe the same public structure. The canonical URL guide explains how to choose the preferred address. Migration verification then compares that choice across all the places where the new system expresses it, including inherited SEO fields and application-level defaults.

Review staging restrictions before launch. A preview environment may intentionally require authentication or prevent indexing, but those settings can remain in a shared production template. Inspect response headers, HTML directives and robots rules at the live hostname. Keep private or deliberately excluded resources restricted according to plan. The robots and noindex guide explains why different controls cannot be treated as interchangeable switches. Also check alternate language relationships if the library has regional versions. A migrated English page should not accidentally declare a retired staging URL as its French counterpart because an old field was copied unchanged.

Plan the cutover around recoverable decisions

Prepare the destination and run migration rehearsals before directing public traffic to it. Freeze or reconcile content changes during the final transfer so late edits do not disappear. Specify which system is authoritative at each stage and who can approve the cutover. A rollback plan needs more than the old deployment identifier: it must consider content written after launch, redirect configuration and any changed data structures. If returning to the old system would discard newly published material, plan how that material will be preserved. Recovery should restore a coherent state rather than merely a familiar visual design.

Before launch, test a sample chosen for risk: high-use pages, deeply nested paths, unusual characters, downloads, merged articles and deliberately removed resources. After launch, request those same public URLs directly. HTTP status behaviour provides a technical basis for distinguishing success, moves and failures. Compare actual responses with the mapping file and inspect rendered content at the destination. The technical release checks provide the broader production gate. Build success alone does not establish that external hosting rules, environment settings and legacy URL handling match the intended move.

Monitor concrete failures before interpreting trends

Watch for requests to missing old URLs, unexpected redirect destinations and unavailable assets. Prioritise patterns that reveal a mapping omission or shared rule error. Keep measurement configuration consistent where possible, and annotate the migration date so analysts can distinguish a data collection change from a user behaviour change. If the domain changes, verify that the old and new properties remain observable through the relevant tools. Search results may fluctuate during reprocessing, but a visible trend does not identify its cause. Diagnose route and content failures directly before attributing a change to the migration's strategic value.

Continue checking the mapping after the initial launch window. An overlooked PDF or old campaign link may surface later. Retain responsibility for the old address infrastructure for as long as the move requires, with clear ownership for redirects and renewal decisions. Move unresolved editorial opportunities into the backlog rather than repeatedly reopening the technical cutover. A migration is complete when the intended resources, relationships and operational handover are verified, not when every future search metric has stabilised. Preserve the final map and decisions so the next team can understand why a route moves, remains or correctly reports that its content is gone.

Sources and further reading

• Google: site movesMigration guidance covers URL mapping, redirects, testing and monitoring old and new URLs.
• Google: HTTP status codesHTTP responses communicate successful retrieval, redirects and failures to crawlers.