How to Audit URLs Before a CMS Migration

Map every live URL to its new destination before launch to prevent broken links and lost traffic.

To audit URLs before a CMS migration, crawl the live site to build a full list of addresses, then map each address to its planned destination or redirect. A CMS migration moves pages, files, and media into new publishing software, which often changes URL patterns. The audit prevents broken links, lost forms, and missing downloads after launch. It also gives developers, editors, and marketers a shared checklist for testing.

Table of Contents

Build a Complete URL Inventory

Start with a crawler that follows internal links and records status codes, page titles, and content types. Add data from the CMS sitemap, analytics landing pages, and server logs to catch orphan pages the crawler misses. Include non-page URLs such as PDFs, images, feeds, and paginated archives.

In WordPress or Drupal, also export taxonomy pages, author pages, attachment pages, and search-result URLs that may be indexed. Clean the list by removing duplicates, staging domains, and query-string variants that show the same content. The result is one master sheet with the live URL, type, traffic level, and inbound links.

Which URLs Deserve Priority?

Focus first on pages with visits, signups, purchases, or many inbound links. These include the home page, main service pages, popular posts, contact pages, and key landing pages used in ads.

Apply the same review to files and media. Keep product manuals, price sheets, and forms that customers still use, and archive obsolete brochures and old campaign assets.

  • Keep and migrate pages that still earn traffic or conversions.
  • Consolidate near-duplicate pages into one stronger destination.
  • Remove thin, outdated, or unpublished drafts with no visits or links.
  • Flag legal, privacy, and accessibility statements that must remain reachable.

How Do You Map Old URLs to New Ones?

Create a mapping table with three columns: old URL, new URL, and action. Use "keep" for unchanged addresses, "redirect" for moved pages, and "remove" for deleted pages that should return a 410 Gone status. Match redirects one-to-one whenever possible. Send an old wedding-photography pricing page to the new pricing page, not to the home page.

Group similar changes with pattern rules, such as moving `/blog/2023/title` to `/insights/title`, then check each rule against real examples. Review URL structure changes carefully. New trailing slashes, uppercase letters, changed date paths, and different pagination formats all create separate addresses. Record the intended canonical address for each page to prevent duplicates.

Build the redirect map in a staging environment and test it with a fresh crawl. Every old URL should return the intended destination with a single permanent redirect, without chains or loops. Check internal links, menus, forms, scripts, and feeds for hard-coded old addresses.

Update image paths, document links, canonical tags, pagination links, and hreflang entries, then confirm that XML sitemaps list only new canonical URLs. Test edge cases that often break during platform changes. Submit forms, complete checkout steps, play embedded video, download key PDFs, and load filtered listings. Fix mixed-content warnings and missing assets before approval.

What Should You Monitor After Launch?

Recrawl the new site immediately after launch and compare results against the master inventory. Look for 404 errors, redirect chains, soft 404 pages, duplicate titles, and blocked resources in server logs and crawl reports.

Keep the old redirect file in place for several months while external sites update their links. Monitor contact-form submissions, ad landing pages, and download counts for sudden drops that signal a missed mapping or broken script.

Frequently Asked Questions

How far in advance should the URL audit start?

Start when content freeze is planned, usually several weeks before development ends, so mapping and testing finish before launch.

Should query parameters be included in the audit?

Include parameters that change content, such as product filters and sorting, and exclude session IDs and tracking codes that create duplicates.

What causes most post-migration broken links?

Hard-coded links in content, menus, widgets, PDFs, and scripts cause most failures because they still point to retired paths.


You Might Also Like