WordPress multisite in subdomain mode promises a clean architecture: every new site gets its own subdomain, and the platform handles provisioning automatically. In practice, three layers—DNS wildcards, SSL certificate issuance, and web-server routing—each introduce failure points that most operators discover only after the first user tries to access a freshly created site and sees a browser error.
This guide walks through how wildcard subdomain provisioning actually works, where it breaks, and what to check when a new site won’t load.
DNS wildcard records: what they match and what they don’t
A wildcard DNS A record like *.example.com tells resolvers that any subdomain—alice.example.com, bob.example.com—should resolve to the same IP address as the multisite installation. You add this record once in your DNS provider’s control panel, pointing to your server’s public IP.
Wildcards match only one level deep. If you need nested subdomains like project.alice.example.com, the wildcard *.example.com won’t cover it; you’d need *.alice.example.com or another arrangement. Most multisite installations stick to single-level subdomains to avoid this complexity.
DNS propagation is usually fast—under an hour for most resolvers—but caching at the user’s ISP or device can mean stale lookups persist for the original TTL. Set a low TTL (300 or 600 seconds) on the wildcard record before launching new sites if you expect rapid iteration.
SSL wildcard certificates: issuance, renewal, and Let’s Encrypt limits
Once DNS resolves, the browser requests HTTPS. A wildcard certificate like *.example.com covers all first-level subdomains in a single cert. Let’s Encrypt supports wildcard issuance via DNS-01 challenge, which requires your host or control panel to programmatically update a _acme-challenge TXT record during validation (documented in the Let’s Encrypt challenge-types guide, checked November 2026).
Not every managed WordPress host automates DNS-01. If your host uses HTTP-01 validation instead, you’ll need to request individual certificates for each subdomain, which breaks the seamless provisioning model. Check your host’s multisite documentation before committing to subdomain mode.
Let’s Encrypt rate limits allow 50 certificates per registered domain per week (rate-limits page, checked November 2026). If you’re spinning up dozens of subsites in a short window and relying on individual HTTP-01 certs, you’ll hit the cap and new sites will serve warnings until the counter resets. Wildcard certs bypass this entirely, because one cert covers the whole namespace.
Web-server routing: how Nginx and Apache parse Host headers
After DNS and SSL succeed, the request reaches your web server. WordPress multisite relies on the Host header to identify which subsite the visitor wants. Nginx and Apache both support wildcard server blocks or virtual hosts, but the configuration syntax differs and misconfigurations silently fall back to the default site.
In Nginx, a server_name directive like *.example.com matches any subdomain. If you’re using a caching layer or CDN in front of Nginx, make sure the Host header passes through unmodified; some CDNs rewrite it to the origin hostname, which breaks multisite routing.
Apache’s ServerAlias directive accepts wildcards similarly. Both servers also respect the order of virtual-host definitions: if the wildcard block appears after a more specific block, requests may match the wrong site. Place the wildcard configuration last in your include order to ensure fallback behavior works as expected.
Auto-provisioning failures: what to check when a new site won’t load
When a user reports that a newly created subsite shows a certificate error, connection timeout, or default Apache page, work backwards through the stack:
- DNS: Use
dig alice.example.comor an online resolver tool to confirm the wildcard record resolves to the correct IP. If it doesn’t, check your DNS provider’s propagation status and TTL settings. - SSL: Check the certificate presented by the subdomain with
openssl s_client -connect alice.example.com:443 -servername alice.example.com. If it’s a self-signed cert or doesn’t include the subdomain in the SAN list, your wildcard cert didn’t issue or isn’t installed correctly. - Web server: Review access logs for the subdomain request. If the log entry shows a 200 but the browser sees an error, caching or a CDN is serving stale content. If the log shows a 404 or no entry appears, the server block isn’t matching; review your Nginx or Apache configuration syntax.
- WordPress: Confirm the subsite exists in the network admin dashboard and that its domain matches exactly what the user is requesting. Trailing slashes,
wwwprefixes, and protocol mismatches all cause routing failures.
When to avoid subdomain mode altogether
Subdomain multisite makes sense when you want clean namespace separation and don’t mind the DNS and SSL overhead. If your hosting environment doesn’t support wildcard DNS automation or you’re on a shared host without root access to install wildcard certificates, subdirectory mode (example.com/alice) is simpler and avoids all three provisioning layers.
Subdirectory mode also bypasses browser cookie-isolation issues: cookies set on example.com are visible to all subdirectory sites, which can simplify single sign-on but complicates multi-tenant privacy. Subdomain mode isolates cookies by default, because alice.example.com and bob.example.com are separate origins.
Running WordPress multisite? Reply with the weirdest provisioning failure you’ve debugged—we’ll feature operator war stories in an upcoming issue.