WordPress multisite starts as a convenience: one install, many sites for regions, brands, products or events. Years later it is often a network nobody fully understands, with dozens of themes and plugins, overlapping content and subsites nobody owns. Consolidating into one site is less a technical migration than a pruning exercise. This playbook covers both. For single-site moves, start with our guide to migrating from WordPress.
How does a WordPress multisite migration to a single site work?
You migrate a WordPress multisite network by inventorying every subsite, pruning content with clear rules, designing one structure and content model, rebuilding on the new platform, and redirecting each subsite into it. The pruning step decides the size and cost of everything after it.
Inventory the network
List every subsite with its domain or path, owner, theme, plugins, page count, last update and traffic. Include archived and private subsites.
Pull performance data
Export Search Console clicks, backlinks and conversions per URL for every subsite. Many networks have separate properties per subsite, so collect them all.
Apply pruning rules
Tag every URL keep, merge, redirect or remove using the rules below. Get owners to sign off per subsite.
Design the new structure
Decide how former subsites live in one site: subfolders, collections, filters or separate sections. Define one content model with shared templates.
Rebuild and import
Build templates, then import only the kept and merged content. Rewrite merged pages so they read as one.
Redirect each subsite
Map every old URL, including subdomain-level rules, to its new home, and remove redirect chains.
Launch in waves
Move subsites in groups rather than all at once, so you can monitor and fix each wave before the next.
If a subsite runs WPML or Polylang, follow our guide to moving translated WordPress sites for that part.
Which multisite content should you migrate at all?
Migrate content that earns search traffic, has backlinks, drives leads or is needed for legal and customer reasons. Merge content that duplicates other subsites. Redirect or remove everything else. In most networks, the remove pile is bigger than teams expect.
Pruning rule | Decision | Example |
|---|---|---|
Has clicks or backlinks, still accurate | Keep | A product page that still ranks |
Same topic on several subsites | Merge into one page | Three regional copies of the same feature page |
Outdated but has links | Update or redirect to the closest page | An old event page with press links |
No traffic, no links, no leads | Remove and redirect | A 2019 campaign microsite |
Legally required | Keep, even without traffic | Privacy policies, terms, disclosures |
Unique regional content | Keep in a regional section | Local pricing or office pages |
Orphaned subsite with no owner | Remove unless data says otherwise | A test site left public |
How do you consolidate many websites into one structure?
You consolidate many websites into one by choosing a single organizing principle, usually region, product or audience, and expressing it as subfolders in one domain. Each former subsite becomes a section that shares the same templates, navigation and content model.
- By region: /uk/, /de/ and so on, with shared templates and local content. Decide this before design, because it shapes navigation, templates and every redirect.
- By product or brand: /products/brand-a/ as a collection or section, with consistent page templates.
- By audience: /for-agencies/, /for-enterprise/, where subsites were built for segments.
- Shared resources: one blog, one resource library and one events listing, filtered by region or product instead of copied per subsite.
One content model is the main benefit. Instead of many themes each with their own fields, you have one set of collections, so a product launch or a brand change updates every section at once.
Hypothetical example: a 14-subsite network becomes one site
For example, suppose a company runs 14 multisite subsites: one per country office, three for product lines and several for old campaigns. The inventory shows the campaign subsites have almost no traffic, and the country sites duplicate the same product pages with small edits.
The pruning rules keep local office, pricing and legal pages, merge the duplicated product pages into one set with regional notes, and remove the campaign sites with redirects to the closest product page. The new site has one product section, one blog filtered by region, and country subfolders holding only local content.
Should a consolidated multisite go to Webflow or Next.js?
Go to Webflow when marketers will run the consolidated site and the total content fits within Webflow's CMS and localization limits. Go to Next.js when the network is large, shares complex templates, needs many locales or integrates with other systems, and you have developers to maintain it.
Factor | Webflow | Next.js with a headless CMS |
|---|---|---|
Who edits | Marketers, visually | Editors in a CMS, developers for templates |
Content volume | Within plan CMS item limits | Effectively unlimited |
Multiple regions | Webflow Localization, a paid add-on | Built into routing, plus CMS locales |
Shared templates | Components and CMS templates | Shared code components |
Integrations | Apps and embeds | Anything with an API |
Running cost | Platform plan plus seats | Hosting, CMS plan and developer time |
Our guides to WordPress to Webflow migration and WordPress to Next.js migration cover each path in detail. If the business already runs HubSpot, moving into HubSpot CMS is a third option worth comparing.
How do you redirect subsites and subdomains?
You redirect subsites by mapping every URL under each subsite to its new path in the consolidated site, then adding domain-level rules for subdomains so that any URL you missed lands on the right section instead of a 404.
- Subfolder subsites (example.com/uk/...) map URL by URL within the same domain.
- Subdomain subsites (uk.example.com) need DNS kept live and redirect rules at the DNS, CDN or host level, because the new platform won't receive those requests otherwise.
- Mapped domains (a separate brand domain) need the same: keep the domain registered and redirect it for the long term.
- Catch-all rules send any remaining URL on a retired subsite to the matching section, never to the homepage by default.
Keep GA4 measurement continuous through the move by planning one property structure for the new site. Our GA4 setup guide covers events and properties.
How do you stop the new site from sprawling again?
You stop sprawl with governance: named owners for each section, a fixed set of templates, rules for when a new page or section is allowed, and a scheduled pruning review. Multisite networks sprawl because creating a subsite is easy and deleting one never has an owner.
Pros
- One brand, one design system and one place to update shared content.
- Stronger domain signals from merged, non-duplicated pages.
- Lower maintenance than many themes and plugin stacks.
Cons
- Regional teams lose some independence and need a process to request changes.
- Consolidation takes time and stakeholder sign-off for every subsite.
- Redirects for retired domains must be kept up for the long term.
Schedule a pruning review twice a year using the same rules you used in the migration. One clean content model also makes any later move far easier. Our walkthrough of migrating off Webflow with Claude Code shows what a future platform move involves.
