A WordPress content audit before migration is the only thing standing between a clean site merge and content that quietly disappears the day you flip the switch. Redirects don’t fail loudly. A page that never made it into the redirect map doesn’t throw an error – it just 404s, or worse, resolves to the wrong content, and nobody notices until a customer or a drop in search traffic points it out weeks later.
Why Redirecting Without an Inventory Loses Content Silently
Most redirect failures during a consolidation aren’t bugs in the redirect logic. They’re gaps in the map the redirect logic was built from. If a page never made it onto your list of what needs to move, no rule you write will ever catch it, no matter how well-tested the rest of the map is.
A full content audit closes that gap before it becomes a redirect problem. It answers one question completely, for every site involved: what actually exists right now, and where is all of it going.
Step 1: Pull Every Sitemap Index and Sub-Sitemap, Not Just the Main One
Start with each site’s XML sitemap index, not a visual crawl of the navigation menu. Google’s own sitemap documentation is a useful reference here, because it lays out exactly how a sitemap index can reference multiple sub-sitemaps by content type – and that structure is exactly what you need to walk through completely.
Most WordPress SEO plugins publish a sitemap index at a predictable location, commonly /sitemap_index.xml or /sitemap.xml. Open that file directly in a browser rather than guessing – it lists every sub-sitemap the plugin has generated, by content type, with its own URL. That index is your starting checklist for the site, before you open a single sub-sitemap.
For each site, confirm you’ve accounted for every sub-sitemap type it actually generates:
- Posts
- Pages
- Any custom post types, such as downloads, products, or documentation
- Categories and tags, if they’re indexed and receiving traffic
If a site uses custom post types and taxonomies, those almost always get their own sub-sitemap, separate from the standard posts and pages sitemap. It’s easy to pull the main sitemap, see a familiar list of blog posts, and assume that’s the whole site – while an entire content type sits in a sub-sitemap nobody thought to check.
Step 2: Build One Master Spreadsheet Across Every Site
Once you have every URL from every sitemap, consolidate it into a single spreadsheet with at least these columns:
- Source URL
- Content type (post, page, product, download, etc.)
- Current status (live, orphaned, duplicate, thin)
- Proposed new URL on the consolidated site
A simple URL export tool can generate the raw source-URL list for each site quickly, so you’re not copying links out of a sitemap file by hand. One spreadsheet covering every site, not one per site, is what makes cross-referencing and gap-checking possible in the next steps.
A minimal version of that spreadsheet looks something like this:
| Source URL | Content Type | Status | Proposed New URL |
|---|---|---|---|
| oldsite-a.example.com/blog/post-title/ | Post | Live | newsite.example.com/blog/post-title/ |
| oldsite-b.example.com/resources/setup-guide/ | Page | Thin | Merge into newsite.example.com/resources/ |
| oldsite-a.example.com/downloads/legacy-tool/ | Download (CPT) | Orphaned | Not migrated |
The exact columns matter less than having every row filled in for every URL before you move on – a blank “Proposed New URL” cell is exactly the kind of gap this audit exists to catch.
Step 3: Flag Orphaned, Duplicate, and Thin Content Before It Migrates
Not everything on the old sites deserves a spot on the new one. As you work through the spreadsheet, mark:
- Orphaned pages with no internal links pointing to them anywhere on the site
- Duplicate content that exists in near-identical form across two or more of the sites being merged
- Thin pages with little to no real content, left over from earlier setup or testing
Migrating this kind of content by default, just because it exists, carries the same problems into the new site that you’re trying to leave behind. Decide deliberately what gets merged, redirected to a better equivalent page, or left out entirely.
For content you decide to leave out, distinguish between two different outcomes in the spreadsheet: a redirect to a genuinely relevant page elsewhere on the new site, or a deliberate drop with no equivalent at all. The second still needs a decision on record, even if that decision is to let the URL return a not-found response rather than force a misleading redirect to an unrelated page.
Step 4: Calculate a Real Content-Parity Percentage
Before you trust the map, quantify it. Divide the number of source URLs with a confirmed destination by the total number of source URLs across every site. Anything under 100% means there are pages you haven’t made a decision about yet, not pages you’ve decided to drop – those are two very different states, and the spreadsheet should make that distinction explicit rather than leaving gaps that look like oversights.
Re-run this calculation right before go-live, not just once at the start. Sites keep publishing content while a consolidation is being planned, and a spreadsheet built two weeks ago won’t reflect a handful of posts that went live since then. Treat the audit as current data, not a one-time snapshot.
The Sub-Sitemap Nobody Remembered
For example, imagine auditing a site that’s been live for several years, run by more than one person over that time. The main posts sitemap looks complete and familiar. But the sitemap index also references a separate sub-sitemap for a downloads custom post type, quietly holding dozens of documentation pages that were set up early on and then forgotten by everyone currently working on the site. Without pulling the full sitemap index, that entire content type would have been left out of the audit, and every one of those pages would have 404’d the day the old domain stopped resolving.
The Pitfall: Trusting a Visual Crawl Over the Actual Sitemap Data
Clicking through a site’s navigation and assuming that represents its full content is the single most common way pages get missed. Navigation menus are curated by design – they show what someone wanted visitors to find, not everything that’s actually indexed and receiving traffic. The XML sitemap reflects what search engines actually know about. Audit against that, not against what the main menu happens to link to.
This mistake is easy to make precisely because a visual crawl feels thorough. Clicking through every menu item and every linked page can take hours and still miss content that was never linked from navigation in the first place – an old landing page, a download only ever shared directly, a category page nobody bothered to add to a menu. The sitemap doesn’t have that blind spot, because it’s generated from what the site actually publishes, not from how it’s organized for visitors.
Your Content Audit Checklist
Before you draft a single redirect rule, confirm you have:
- Every sitemap index and sub-sitemap pulled for every site, including custom post types
- One master spreadsheet covering all sites, not one per site
- Orphaned, duplicate, and thin content explicitly flagged and decided on
- A calculated content-parity percentage, not an assumption that the map is complete
With a complete, verified inventory in hand, the next step is turning it into an actual URL redirect map – deciding which redirects are one-to-one, which need a fallback pattern, and how to document the exceptions on purpose.