Disclosure: To maintain independence and full honesty, this guide on multisite subdomain versus subfolder setups includes affiliate links to the tools we endorse, and if yo
The subdomain-vs-subfolder decision has to be made before you run the multisite install script — switching structures afterward means re-mapping every site’s URLs, which is painful enough that most agencies just live with a wrong first choice. Here’s what actually determines the right answer.
Subdomain multisite gives every site a URL like client1.agencydomain.com. Subfolder gives you agencydomain.com/client1. Both run on the same WordPress core install and share the same database (with prefixed tables per site), but the URL structure changes what’s required to run it and how each site is treated by search engines and browsers.
Subdomain multisite needs a wildcard DNS record (*.agencydomain.com) pointed at your server before WordPress will let you choose that mode during setup. Most managed WordPress hosts (WP Engine, Kinsta, Cloudways) support adding this in their DNS panel, but if you’re on a smaller shared host, check whether wildcard subdomains are supported before you commit to this structure — some budget hosts don’t allow it at all, which forces subfolder by default.
Subfolder mode has no DNS requirement beyond the domain already resolving, which is part of why it’s the default recommendation for agencies who want the simplest possible setup.
Search engines generally treat subdomains as more separate from the root domain than subfolders — this matters if you’re trying to build the network’s collective domain authority for a single client-facing brand. A subfolder structure consolidates authority signals toward the root domain more reliably. If each client site is meant to feel and rank as its own independent brand anyway (typical for an agency hosting genuinely separate client businesses), this distinction matters less, since you’re not trying to pool authority across sites in the first place.
Cookies are also scoped differently: subfolder sites on the same root domain can share cookies unless you explicitly isolate them, which occasionally causes login-state bugs across sites that subdomain setups don’t have, since each subdomain gets its own cookie scope by default.
In practice, most agencies use multisite as a management shell, then map each site to the client’s real custom domain (client-actualdomain.com) using WordPress’s built-in domain mapping (available since WP 4.5) or a mapping plugin. Once a custom domain is mapped, the subdomain-vs-subfolder choice becomes largely invisible to the client and their visitors — it only affects your internal admin URLs and how the network installer initially provisioned things.
| Subdomain | Subfolder | |
|---|---|---|
| DNS setup | Wildcard record required | None beyond root domain |
| Works on shared/budget hosting | Often not supported | Usually fine |
| SEO authority pooling | Weaker cross-site signal | Stronger cross-site signal |
| Cookie isolation between sites | Automatic | Requires care |
| Best fit | Truly separate client brands | One brand, multiple sections/regions |
Confirm wildcard DNS support with your host first — this alone eliminates subdomain as an option on some budget plans. Then decide whether these are genuinely separate client businesses (favor subdomain, since it isolates cleanly and each will get its own mapped domain anyway) or sections of one brand, like a multi-location business or a franchise network (favor subfolder, since you likely want the SEO consolidation).
[AFFILIATE CTA: Cloudways]
Once the network structure is set, adding a new client site is genuinely fast — that’s the payoff for the upfront DNS and structure decisions. From Network Admin, “Add New Site” creates the site instantly with its own tables and uploads folder, without a fresh WordPress install or server provisioning. The steps that still need doing manually: mapping the client’s real domain (via Network Admin’s site settings or a mapping plugin), setting the correct site-level SEO and analytics IDs so client sites don’t inherit a template’s placeholder tracking code, and confirming the theme and network-activated plugins are actually appropriate for that client rather than just defaulting to whatever the last site used.
Keep a short onboarding checklist per new site: domain mapped and SSL issued, correct theme applied, client-specific plugins activated, placeholder content replaced, and a test pass on both the subdomain/subfolder URL and the mapped domain before handing credentials to the client. Skipping the placeholder-content check is a common miss — a new site provisioned from a template can go live with a previous client’s demo text still in a widget or footer.
WordPress does not offer a clean built-in way to convert an existing subdomain network to subfolder or vice versa. It’s possible via manual database URL updates and a plugin like WP Migrate DB or Better Search Replace, but it’s genuinely risky for a live network with real client sites on it — back up the full database and files first, and test the migration on a staging copy before touching production.
Can I mix subdomain and subfolder sites in one network?
No — WordPress multisite locks the structure for the whole network at setup. If you need both, that generally means running two separate multisite installs.
Does subfolder multisite hurt individual client SEO?
Not once a custom domain is mapped — the client’s visitors and Google see their own domain, not the underlying subfolder path.
Which does WordPress.com’s own multi-site network use?
Subdomain, by default, for new sites created under wordpress.com — a useful reference point but not binding for a self-hosted install.
Related reading: When Multisite Is the Wrong Choice · Migrating From Single Sites to Multisite · Multisite Plugin Management