MERLONIX
Sign inStart free

SSL Monitoring for WordPress Multisite Networks: What Agencies Need to Watch

WordPress Multisite allows a single WordPress installation to run multiple sites from a shared codebase and database — one admin interface, one set of core files, multiple separate sites. Agencies use it for clients who need multiple related properties: regional sites for a franchise, separate storefronts for product lines, or language-specific sites for international audiences.

The SSL monitoring requirements for a Multisite network are different from monitoring a collection of independent WordPress sites. The shared hosting infrastructure, network-level configuration, and site-level DNS dependencies create failure modes that single-site SSL monitoring tools do not catch.

Subdomain vs. Subdirectory Networks

WordPress Multisite runs in one of two modes: subdomain-based or subdirectory-based.

In subdirectory mode — where each site is at a path on the primary domain like clientdomain.com/site2 — there is effectively a single SSL certificate for the root domain that covers all sites. SSL monitoring for subdirectory networks is similar to monitoring a single-domain installation.

In subdomain mode — where each site is at a subdomain like site2.clientdomain.com — each site has its own DNS record and typically its own SSL certificate requirement. A wildcard certificate (*.clientdomain.com) covers every subdomain, but wildcard certificates and subdomain-based SSL provisioning introduce their own monitoring requirements.

Most enterprise Multisite deployments on managed hosting platforms use subdomain mode. The rest of this guide focuses on subdomain-mode networks.

Failure Mode 1: Wildcard Certificates Don't Cover the Root Domain

A wildcard SSL certificate (*.clientdomain.com) covers site1.clientdomain.com, site2.clientdomain.com, and every other single-level subdomain — but it does not cover clientdomain.com itself. The root domain requires a separate SSL certificate.

For WordPress Multisite networks where the primary site sits on the root domain, the root domain SSL and the wildcard SSL are two separate certificates with independent expiry schedules. If the wildcard is renewed without renewing the root domain certificate, or vice versa, part of the network goes down while the rest remains accessible.

What to monitor: Track the root domain SSL and the wildcard SSL as separate monitored assets. A wildcard certificate expiry affects every site in the subdomain network simultaneously; a root domain certificate expiry affects only the primary site. Both need independent monitoring with 30-day expiry warnings.

Failure Mode 2: Managed Hosting SSL on Multisite Is Provisioned Per-Site, Not Network-Wide

WP Engine, Kinsta, Flywheel, and Pantheon each manage SSL differently for Multisite networks. On some platforms, SSL is provisioned at the site level — each subdomain in the Multisite network has SSL provisioned when the subdomain is added to the platform configuration. On others, a wildcard certificate is provisioned for the domain and covers all subdomains automatically.

The practical consequence: adding a new site to the Multisite network may or may not trigger automatic SSL provisioning on the managed host. Agencies that add a new network site, configure the DNS CNAME pointing at the managed host, and assume SSL will provision automatically may discover — after a client's new site goes live — that the managed host requires an explicit SSL provisioning step in the platform dashboard.

What to monitor: When adding a new site to the network, verify the SSL certificate is provisioned and valid before treating the site as live. Add each new subdomain to your monitoring configuration at the same time you create the site. Do not rely on managed hosting automatic provisioning without verification.

Failure Mode 3: A New Multisite Site Requires DNS Before SSL Can Provision

On managed hosting platforms that use DNS validation or HTTP validation for SSL provisioning, adding a new WordPress Multisite site requires the DNS CNAME to propagate to the managed host before SSL can be provisioned. The sequence is:

  1. Create the new site in WordPress Multisite
  2. Add the subdomain to the managed host's configuration
  3. Create the DNS CNAME record pointing the subdomain at the managed host
  4. Wait for DNS propagation (minutes to hours)
  5. Managed host provisions SSL (minutes to hours after propagation)

Steps 3 and 4 are client-side operations that the agency often cannot perform directly — the client controls their DNS at their registrar. Agencies that create the site and hand off the DNS task to the client frequently discover that the DNS change was delayed by days, leaving the new site accessible at the managed host's internal URL but not via the subdomain, and with no SSL certificate provisioned.

What to monitor: After any new Multisite site is created, immediately add the subdomain to monitoring with an alert for missing SSL rather than expiring SSL. A new site that has never had SSL provisioned will show no certificate at all — not an expiring one. Catching the provisioning gap quickly allows the agency to follow up with the client on the DNS change before the new site is expected to be publicly accessible.

Failure Mode 4: Domain Mapping for Custom Domains on Multisite Sites

Some WordPress Multisite configurations use custom domain mapping — each site in the network has a completely separate domain, not a subdomain of the primary installation domain. A franchise network might run site1.com, site2.com, and site3.com as separate custom domains, all on the same Multisite installation.

Each custom-mapped domain requires its own SSL certificate. On managed hosting platforms, each custom domain requires:

  • A CNAME or A record pointing at the managed host
  • SSL provisioned for each custom domain separately

When a franchise client's regional site transfers their domain to a new registrar, the CNAME pointing at the managed host may be lost during the transfer. The managed host cannot renew the SSL certificate for the custom domain if the DNS no longer points at its infrastructure — the same failure mode as any other SSL renewal that depends on DNS integrity.

What to monitor: Treat each custom-domain Multisite site as a separate monitored domain. CNAME integrity checks and SSL monitoring for each custom domain are independent — a domain transfer on one regional site does not affect others, but each one has the same DNS-dependent SSL renewal risk.

Failure Mode 5: Multisite Network Migrations Leave Orphaned DNS Records

Agencies migrating a WordPress Multisite network from one managed host to another — from WP Engine to Kinsta, from Flywheel to WP Engine, or from a shared host to a managed platform — update the DNS CNAME for every subdomain in the network. A 10-site network requires updating 10 CNAME records plus the root domain.

In practice, some subdomains are missed during the migration. Sites that are no longer actively used but still exist in the network may have their DNS CNAME pointing at the old managed host long after the network has migrated. When the old managed host eventually removes the DNS target or the agency closes the old account, those subdomains' CNAMEs become dangling records.

What to monitor: After any managed host migration, verify CNAME targets for every subdomain in the network, not just the primary domain. Run CNAME integrity checks for each subdomain against the new managed host's expected hostname. Subdomains pointing at the old host are candidates for removal from DNS — but they should be verified before deletion to confirm they are not still serving traffic.

Monitoring Configuration for Multisite Networks

For a WordPress Multisite network, a complete monitoring configuration includes:

  1. Root domain SSL — separate certificate, separate expiry schedule from the wildcard
  2. Wildcard SSL — covers all *.clientdomain.com subdomains simultaneously; single expiry date affects all sites at once
  3. Each active subdomain — CNAME target integrity check against the managed host; SSL verification (wildcard coverage is confirmed separately)
  4. Custom domain-mapped sites — full SSL and CNAME monitoring for each custom domain independently
  5. Domain registrar expiry — root domain and any custom-mapped domains; registration expiry takes down SSL renewal for the entire network

The single most important distinction from single-site SSL monitoring is tracking the wildcard certificate expiry separately from individual subdomain SSL status. A wildcard expiry is a simultaneous outage across every site in the network — the priority level for the alert should reflect that scope.