A CMS migration becomes a URL migration when existing public addresses change. The new theme may look correct while old articles, saved links, image references, and campaign destinations quietly stop working. Protecting those entry points requires a record of what exists and an explicit decision about where each address belongs.

Separate content movement from URL movement at the start. If the new CMS can preserve a useful public address, it may not need a redirect at all. The CMS and HTML URL guide explains that relationship. This checklist helps turn a proposed change into a reviewable mapping and a launch process with clear evidence.

State what is changing

Write a short migration scope that identifies changes to the hostname, protocol, paths, page content, and publishing system. Avoid treating all five as a single invisible switch. A move from /article.php?id=42 to /guides/url-planning/ changes a public address even when the underlying article stays the same.

Distinguish necessary changes from optional cleanup. Renaming a well-used path just to match a new CMS default adds another mapping to maintain. If the old address is understandable and can be preserved, consider keeping it. Reserve structural changes for a clear information or operational benefit.

Document which changes can be deployed together and which can be separated. A smaller release is easier to diagnose when its effects are distinct. Also identify the rollback owner and the last point at which reverting remains straightforward, particularly if editors continue publishing during the move.

Inventory more than the current navigation

The visible menu is not the complete site. Build the inventory from the CMS export, current sitemap, an internal crawl, and available records of incoming requests. Each source can reveal addresses the others miss. Historical campaign pages may still matter even after they disappear from the navigation.

Include article pages, topic archives, pagination, feeds, downloadable files, and images where their public locations may change. Record meaningful query-based routes as well. A CMS may use a query to select content, while a campaign query merely labels an otherwise identical page; those cases need different treatment.

Add enough context to make review possible: current title, content type, owner, proposed outcome, and any known dependency. Mark the source of each inventory entry. That helps explain why a path with no current CMS record still appears in the migration plan.

Assign an outcome to every known address

Use a mapping with a few explicit outcomes: preserve, move, merge, or remove. The mapping should express the editorial relationship first and the implementation second. A collection of regular expressions is difficult to review when nobody has agreed which content is actually replacing which.

old_path,new_path,outcome,owner
/article.php?id=42,/guides/url-planning/,move,editorial
/guides/link-basics/,/guides/link-basics/,preserve,editorial
/downloads/retired-sheet.pdf,,remove,documentation

When multiple old articles are merged, read the consolidated page and confirm that it covers the important material people expected from each source. Similar words in the title are not enough. Avoid sending unrelated removed pages to a generic home page simply to make every old request end with a successful response.

A missing resource can return 404; a deliberately and permanently removed resource can return 410. Give the visitor helpful navigation with that response. The content of an error page and its HTTP status should agree. A decorative “not found” heading inside a 200 response does not communicate the same condition.

Prepare the destination before moving traffic

For each moved page, verify that the target exists and contains the expected material. Check its main heading, body, images, downloads, and internal links. A redirect to a thin placeholder is not a completed content migration.

Inspect rendered output as well as CMS records. Template fields may be populated correctly while an image path is assembled with the old hostname or a category link points to a retired route. Test representative content types, including unusually long titles, embedded code, and articles with several assets.

Keep preview access separate from production indexing settings. A noindex rule asks supporting search engines not to index a resource; it does not restrict who can read it. A crawler must be able to retrieve the resource to discover that rule. Document which preview restrictions should disappear at launch and which private areas must remain protected.

Align canonical URLs and discovery files

A page’s canonical annotation communicates a preferred address for duplicate or closely similar content. During migration, verify that the new page does not still recommend the retired location. Also review whether the CMS, theme, and an extension are each generating competing canonical elements.

<link rel="canonical"
      href="https://example.org/guides/url-planning/">

Use the intended final addresses in the current sitemap and update internal navigation to reach them directly. Sitemaps use absolute URLs, so a hostname change needs more than a path replacement. Inspect feed item links, social sharing metadata, and any structured data that contains page or image URLs.

The SEO URL guide gives the publishing context for these signals. The practical goal is consistency: the page, site navigation, and discovery files should describe the same public location.

Implement redirects in the serving layer

When a page has permanently moved, configure the appropriate permanent redirect through the host, server, or application. Ordinary static HTML cannot produce an HTTP redirect status by itself. Confirm which serving layer owns the rule so it is not duplicated across several systems.

Point old routes directly at their final replacements, and check rule ordering. A broad path rule can intercept an exception before the more specific mapping has a chance to run. Test query handling, trailing slashes, letter case, and supported hostname variants against the written plan.

Use the shortlinks and redirects guide to review status semantics and destination behavior. Maintain the mapping as a readable artifact alongside the configuration, so future changes can be evaluated against the intended relationship rather than inferred from the server rules.

Make launch verification specific

Prepare expected results before launch. For a moved route, record the first response status, expected location, and final content check. For a preserved route, record the expected successful page. For a removed route, record the intended unavailable-resource response.

  • Request old addresses without initially following redirects and inspect their responses.
  • Follow each mapped destination and verify that it resolves to the expected content.
  • Check that unknown paths do not accidentally match an unrelated fallback rule.
  • Inspect canonical annotations and production indexing directives.
  • Open migrated images, files, and feed links directly.
  • Review the sitemap and navigation from the deployed site.

Automate mechanical comparisons when the inventory is large, but retain human review for content equivalence. A script can confirm a successful response and exact location; it cannot determine whether a new guide answers the question promised by an old campaign.

Account for edits made during the move

Agree on how late editorial changes reach the new system. If the first export happens on Monday and the launch is on Thursday, an article published on Tuesday needs an explicit path into the final release. Otherwise, a technically correct migration can still omit recent work.

Use a short publishing pause when practical, or record and replay the intervening changes. Include asset replacements and corrected slugs, not just new articles. Before launch, reconcile that change list against the destination inventory. After launch, tell editors which system is authoritative so a correction is not accidentally made only in the retired CMS. This handoff protects the content work as well as its public addresses.

Monitor the move with a recorded baseline

Save the launch time, mapping version, and initial verification results. Compare later errors against that baseline. Group issues by route type so a broken archive pattern is distinguishable from a single misspelled destination.

Google’s site-move documentation recommends monitoring old and new URLs and retaining redirects for as long as possible, generally at least one year. It also explains that search visibility can fluctuate while moved content is recrawled and processed. A migration does not come with a fixed recovery date.

Prioritize reproducible failures: broken replacements, loops, inaccessible assets, and unintended indexing restrictions. Keep observations separate from assumptions about search changes. When a technical issue is found, record the correction and repeat the check that exposed it.

Close the project without losing the map

A migration is ready for handoff when known entry points behave as planned, destinations are complete, discovery files are coherent, and someone owns the remaining monitoring. Preserve the final inventory, redirect mapping, and verification notes for the next publishing change.

CMS software will change again. A maintained record of public addresses makes that next move easier because it preserves the decisions behind the links people already use.