A WordPress site consolidation checklist is what keeps a multi-site merge from turning into an improvised recovery effort. Most consolidation projects don’t fail because of a broken redirect or a bad migration script. They fail before a single line of config gets written, because nobody wrote down who actually owns access to each site, or which product genuinely needs to stay independent. By the time someone notices, several sites are already mid-migration and the team is improvising instead of following a plan.
Why Consolidations Fail at the Planning Stage, Not the Execution Stage
Redirect rules, database scripts, and DNS changes get most of the attention because they’re the visible, technical part of a consolidation. But the decisions that actually determine whether a project goes smoothly happen earlier: what gets merged, what stays separate, who has access right now, and in what order things move. Skip this stage and you end up making those calls mid-migration, under time pressure, one site at a time.
A written pre-migration checklist forces those decisions to happen once, on purpose, before anyone touches a live site.
Step 1: Inventory Every Site Before You Decide Anything
Before you can plan a consolidation, you need an honest list of what actually exists. For every site involved, record:
- Domain and current hosting environment
- CMS version, theme, and plugin versions in use
- Traffic volume and its main sources
- Revenue or conversion activity, if the site sells anything
- Who actually has working access to it today, not who is supposed to
Once you know how many sites are actually in scope, pull every URL each one is really serving, not what you assume is live. A simple URL export tool run against each site gives you that full list in minutes, and it becomes the raw material every later step in a consolidation depends on, from redirect mapping to content audits.
Traffic and revenue numbers matter here for a reason beyond curiosity: they tell you which sites can tolerate a mistake and which ones can’t. A low-traffic site with no active sales gives you room to experiment with your process before you touch anything customer-facing. A site with live orders coming in every day should be the last thing you migrate, once the process has already been proven elsewhere.
Step 2: Decide What Actually Merges
Not every site belongs in the consolidation. A product with its own established brand, its own backlink profile, and its own paying customers can be a legitimate exception, not a failure to commit to the plan. Trying to fold a strong standalone brand into a generic hub site usually costs more in lost recognition and broken links than it saves in hosting or maintenance.
Make this call explicitly, in writing, for every site on your inventory. “We’re keeping this one separate because X” is a decision. Silence on the question is not.
Step 3: Map Access Before You Touch Anything
A consolidation touches DNS, hosting, and database credentials across every site involved. Confirm, for each one, who can currently:
- Change DNS records at the registrar
- Log into the hosting control panel
- Access the database directly
- Make changes on the live WordPress install itself
If any of these sites run on a shared multisite network, verify who currently holds super-admin access and how long those sessions actually last, rather than assuming everyone who needs it still has it. A session that times out mid-migration is a bad moment to discover nobody wrote down the recovery credentials.
Write all of this down in one shared document, not scattered across whoever happens to remember a password. The goal is that anyone on the team could pick up the migration mid-way through and know exactly where to log in, without having to track down the one person who set up a given site three years ago.
Step 4: Build a Phased Timeline, Not a Single Cutover Date
Treating a consolidation as one big cutover night is how small mistakes turn into full outages. Sequence the work instead:
- Move and verify content first, on the new site, before anything old goes away
- Put redirects in place second, once the new content is confirmed live and correct
- Migrate transactional data – customers, orders, licenses – last, once everything else is stable
WordPress.org’s own guidance on moving a WordPress site is written for a single install, not a multi-site consolidation, but its core principle still holds here: never point DNS at the new environment until everything on it has been verified end to end.
Step 5: Lock In Your Canonical Domain and Naming Conventions First
Decide the final domain, URL structure, and naming pattern for shared assets before anyone starts moving files. Changing a naming convention halfway through means redoing work that’s already finished, on sites that are already partially migrated. This is a five-minute decision if you make it up front, and a multi-day cleanup job if you make it after the fact.
How Long the Planning Stage Should Actually Take
For a handful of sites, this checklist is a few days of work: pulling inventories, confirming access, and writing down decisions that mostly confirm what you already suspected. For a dozen or more sites, especially ones you didn’t build yourself, expect one to two weeks – most of it spent tracking down access to accounts nobody has logged into recently.
Either way, resist the urge to compress this stage to make up time later. Every hour spent confirming access and scope up front is an hour you don’t spend firefighting a locked-out database mid-migration.
A Consolidation That Keeps Its Flagships Independent
For example, imagine consolidating eight single-product sites into one central hub. Six of them are small, low-traffic products with overlapping audiences – obvious candidates to merge under one brand. The other two are established products with their own domains, their own backlink history, and active paying customers who already know those brand names. Keeping those two on their own domains while merging the rest isn’t a partial consolidation. It’s the plan working correctly, because the checklist forced that distinction to be made on purpose in step two, instead of by default under deadline pressure.
The Pitfall: Starting Technical Work Before Access Is Confirmed
The most common way a consolidation stalls is someone starting the technical work – writing redirect rules, drafting a migration script – before ownership and access are confirmed for every site involved. Halfway through, it turns out nobody actually has database credentials for one of the sites, or the person who registered a domain years ago is no longer reachable. Now the technical work stops, sometimes for days, while access gets sorted out on sites that are already mid-change. Confirming access is a cheap, boring step. Skipping it is expensive.
Your WordPress Site Consolidation Checklist
Before you write a single redirect rule or migration script, confirm you have all of the following in writing:
- A full inventory of every site: domain, versions, traffic, revenue, and current access
- An explicit merge-or-keep-independent decision for every site, with a reason
- Confirmed, working access to DNS, hosting, and databases for every site in scope
- A phased timeline: content, then redirects, then transactional data
- A locked-in canonical domain and naming convention, documented before any file moves
With that checklist complete, you’re ready for the next step: building a full content inventory and cross-checking it against every site’s sitemap before you redirect a single URL.