SSL Monitoring for WordPress Agencies: The Failures That Generic Tools Miss

WordPress is the most common CMS in agency client portfolios. For agencies managing five, twenty, or fifty WordPress sites, SSL certificate management is not a single-platform problem — it is a fragmented one that spans shared hosting, managed WordPress platforms, CDNs, and client-controlled DNS zones.

WordPress introduces SSL failure modes that are specific to how it is hosted and configured. Generic monitoring tools — those built for single-site operators checking whether a certificate has expired — miss most of them.

The Let's Encrypt Auto-Renewal Problem

Let's Encrypt certificates expire every 90 days. They are designed to be renewed automatically — via a cron job, via the hosting platform's built-in ACME client, or via a WordPress plugin. In theory, auto-renewal means the certificate renews itself and the agency never has to think about it. In practice, renewal fails silently in ways that only become visible when the certificate expires.

On shared hosting, the cron job is often the failure point. Shared hosting environments — GoDaddy, Bluehost, HostGator, SiteGround's lower-tier plans — provision Let's Encrypt certificates through the cPanel interface. The renewal is triggered by a server-level cron job that the hosting provider controls. When the hosting account hits CPU or memory resource limits, the cron job may be throttled or skipped. The certificate reaches its 90-day expiry without renewing. The hosting panel still shows "Let's Encrypt: Active." The site begins throwing certificate errors.

The certificate can be issued but not deployed. Even when the ACME renewal completes successfully, the new certificate must be deployed to replace the old one. On some hosting configurations, this step is separate from the renewal and can fail independently. The renewal log shows success. The live site continues to serve the old, expiring certificate.

WordPress plugins that manage Let's Encrypt can break on core updates. Some agencies use WordPress plugins for certificate management rather than the hosting control panel. Plugin conflicts, WordPress core updates, and PHP version changes can disable the plugin without removing it — meaning the plugin appears active but has stopped running its renewal tasks.

WordPress Multisite and Subdomains

A WordPress multisite installation with subdomain routing means multiple certificates. www.client.com, shop.client.com, staging.client.com, events.client.com — each is a distinct hostname that may have its own certificate, or may rely on a wildcard certificate that was provisioned once and not subsequently monitored.

Most agencies monitor only the primary domain. They set up a check for client.com or www.client.com, confirm it is valid, and move on. The monitoring covers one certificate out of potentially four or five.

The subdomains that get missed tend to be the ones that are hardest to explain to a client. A staging subdomain with an expired certificate is typically discovered by a client developer sharing a preview link — and discovering it does not work because of a certificate error. An admin subdomain expiry may be discovered by the client trying to log in. These are not good moments.

Wildcard certificates, which cover all subdomains of a domain under a single certificate, reduce the problem — but introduce their own: wildcard certificates require DNS validation, which requires DNS control, which requires knowing who controls the DNS zone. Agencies managing clients across multiple DNS providers need a clear inventory of where each wildcard is managed and what the renewal process is.

DNS Drift After WordPress Migrations

Site migrations are high-risk periods for SSL certificates. When an agency migrates a WordPress site from one host to another, the sequence is roughly: stand up the new environment, import the database and files, test on a temporary URL, update DNS to point to the new host, wait for propagation, go live.

The SSL certificate must be provisioned on the new host before the DNS change, or immediately after. If the certificate provisioning fails — because the ACME validation runs before DNS has fully propagated, or because the new hosting account is not configured to issue certificates for the domain yet — the site goes live on new hosting with no valid certificate.

This failure mode is subtle because it is time-dependent. A monitoring check run before DNS propagation completes may still see the old host's valid certificate. A check run after may see the new host's invalid or missing certificate. The narrow window where the certificate status flips is often missed entirely unless the agency is monitoring actively through the migration.

A secondary DNS drift problem occurs when migrations are incomplete. Some agencies change the A record for www.client.com but leave the apex domain (client.com) pointing to the old host. The new host provisions a certificate for www.client.com. The apex domain continues to use the old host's certificate. When the old host certificate expires — which it will, since no one is managing it — half the traffic to the site begins receiving certificate errors.

WooCommerce and Payment Processor SSL Requirements

For WordPress agencies managing WooCommerce clients, SSL certificate failures carry additional consequences beyond browser warnings.

WooCommerce checkout pages require valid SSL on the checkout endpoint. If the site's certificate is expired or invalid, the checkout does not load for customers with strict browser settings. For customers who proceed past the warning, their browsers may block form submissions or payment processing calls.

Payment processors verify SSL status during webhook validation. Stripe, in particular, validates the SSL certificate on the webhook endpoint before delivering events. An expired certificate on the WooCommerce site breaks webhook delivery — meaning post-checkout events (order confirmations, fulfilment triggers, subscription renewals) stop reaching the store before the frontend appears fully broken to visitors.

This sequence — payment processing breaks before the storefront goes down — can be very difficult to diagnose if the monitoring is uptime-only. The site appears to be up. Stripe webhooks are failing. Orders are not being processed. The agency discovers the certificate issue via a client report of "something is wrong with orders" rather than a direct certificate alert.

What to Monitor on WordPress Client Sites

A complete SSL monitoring configuration for a WordPress agency client includes:

The primary domain, both apex and www variants
All active subdomains — staging, admin, app, API, any campaign microsites
The certificate chain, not just expiry — incomplete chain validation catches missing intermediate certificates that cause errors in some browsers
Renewal confirmation after each expected renewal window — verify the expiry date has advanced, not just that auto-renewal is configured
WooCommerce checkout endpoints specifically, if the client is running e-commerce

The practical starting point is a domain inventory. Most agencies do not have a complete list of all active subdomains for each client. Tools like crt.sh, which logs Certificate Transparency records, surface subdomains that have had certificates issued — a useful proxy for finding subdomains that exist and may need monitoring.

Merlonix provides per-client SSL monitoring for WordPress agency portfolios — covering all tracked subdomains, configurable alert thresholds, and account- manager routing. Client architecture is separated, so alerts for one client do not appear alongside alerts for another.