You usually notice the problem the same way: a client opens a ticket because checkout feels flaky, the admin screen throws a browser warning, or a domain that was “fixed months ago” is suddenly back on HTTP. In an agency portfolio, WordPress SSL certificate work rarely fails at the moment of installation. It fails later, when nobody watches renewal dates, a plugin rewrites a URL, or a host setting and a redirect rule start fighting each other.
That's why SSL on WordPress needs to be treated as an operational system, not a checkbox. The broader internet has moved there already, with 299 million certificates in the global ecosystem by 2025 and 87.6% of websites using a valid SSL certificate in 2024, up from 18.5% six years earlier, according to reporting on SSL adoption trends. WordPress has not finished the same transition, with WordPress-specific scans still showing a substantial share of sites without valid encryption. SSL adoption statistics and ecosystem reporting and WordPress SSL scanning data make the point clearly.
The practical takeaway is simple. Getting a certificate installed is only the first step. Keeping HTTPS stable across renewals, redirects, mixed content, and host changes is the work.
Table of Contents
- Why SSL Is Now a Lifecycle Problem, Not a One-Time Fix
- Three Realistic Ways to Get a WordPress SSL Certificate
- Installing the Certificate at the Hosting Layer
- Forcing HTTPS Without Creating Redirect Loops
- Finding and Killing Mixed Content for Good
- Renewals, Expirations, and How Incidents Actually Surface
- Portfolio-Scale SSL Monitoring and Triage
Why SSL Is Now a Lifecycle Problem, Not a One-Time Fix
An agency inherits a 20-site portfolio and the SSL picture is almost never clean. A few client sites are healthy, some are already expired, and a few still sit on HTTP because the original install happened in a hurry and nobody came back to verify the certificate, the redirects, or the renewal path. That is the actual operating environment for most WordPress teams, not the tidy “enable HTTPS” story that setup guides prefer.
A large share of WordPress sites still run without valid encryption, so SSL status is a useful risk signal rather than background hygiene. One scan of WordPress sites found a sizable portion still lacking valid SSL, and other industry checks point in the same direction. Plenty of WordPress properties still do not have dependable encryption. WordPress SSL installation and scan data
Treat SSL as an uptime dependency
The trap is assuming SSL ends once the padlock appears. In practice, the certificate sits on a renewal clock, WordPress stores URL settings in more than one place, and themes or plugins can keep old http:// references alive long after the certificate itself is valid. Google Chrome's ongoing treatment of HTTP as not secure makes the maintenance side matter more than the initial purchase or provisioning. WordPress HTTPS and SSL guidance
Practical rule: if you're managing more than one WordPress site, SSL health belongs in the same recurring review as uptime and plugin status.
The better mental model is lifecycle, not setup. That means checking expiry dates, confirming redirects still land cleanly, watching for mixed content after plugin updates, and re-validating the certificate chain after host-side changes. Once you work that way, SSL stops being a one-time security task and becomes a routine control you can measure across the whole portfolio.
Three Realistic Ways to Get a WordPress SSL Certificate
Most WordPress sites get SSL through one of three paths, and the right choice depends on who controls the host, how many sites you manage, and how much manual renewal you can tolerate. I've seen all three work. I've also seen all three fail when the wrong team owned the process.
Host-provided certificates
Managed WordPress hosts increasingly bundle certificate provisioning into the dashboard. That is the easiest route for site owners who do not want to touch server settings, because renewal is usually handled inside the hosting platform and tied to its own configuration. The trade-off is control. If the site moves later, certificate behavior changes with the host, so you need to know whether the platform can export, reissue, or recreate the certificate cleanly.
Let's Encrypt automation
Let's Encrypt fits sites where automation matters and the host can complete the challenge flow reliably. It is free, it renews without much attention when the setup is correct, and it works well across many sites as long as the validation method stays stable. The failure mode is operational. DNS edits, challenge-path changes, or permission limits can interrupt renewal even when the first issuance went through without trouble.
Commercial certificates
Paid commercial certificates still make sense in specific situations, especially ecommerce, wildcard coverage for multiple subdomains, or environments that need a commercial trust chain or a particular compliance posture. They do not remove the need for careful installation, and they do not solve redirect problems or mixed content on their own. They do give you a different support and procurement model, which some agency clients still prefer.
Practical rule: choose the certificate path based on renewal behavior, not just first install convenience.
The hosting-managed path is the least hands-on, Let's Encrypt is usually the most efficient choice for agencies that can automate, and commercial CAs fit edge cases where the business case justifies the extra overhead. If a site may move hosts soon, favor a setup that is easy to reissue and verify rather than one that becomes difficult to explain during a migration. For a broader view of how certificate choice fits into the rest of the stack, see this WordPress hosting guide.
The installation mechanics vary by host, but the decision criteria stay the same. A host that auto-renews is often a better operational choice than a certificate someone has to remember to paste into a panel every quarter.
Installing the Certificate at the Hosting Layer
The right sequence matters more than most tutorials admit. A reliable rollout starts on the server side, with certificate generation or import, then the full certificate chain, then WordPress URL updates, then redirect enforcement. Skip one of those pieces and you'll get a site that looks fine in one browser and broken in another.
At the host, the first job is to generate or obtain a CSR, then install the leaf certificate with the private key and CA bundle or intermediate chain. That chain detail is not optional. When the intermediate certificates are missing, some browsers and APIs can refuse trust even though the main cert appears installed. WordPress SSL installation guidance
For cPanel-based hosting, the usual path is the SSL management area where the certificate, key, and bundle are pasted together. Managed WordPress dashboards often hide the low-level inputs and present a one-click toggle, which is convenient until the host's provisioning logic fails. Cloudflare is different again because the edge certificate can be active before the origin is correctly aligned, so you have to think about where TLS is terminating.
A good install also includes WordPress itself. The WordPress Address and Site Address both need to resolve to https://, or WordPress may keep generating insecure links internally. If you're documenting the stack for a client or another engineer, the complete WordPress hosting guide is a useful companion reference for understanding where these settings sit in the bigger hosting picture.
Verify the chain, not just the padlock
A browser padlock is not enough. Check that the certificate chain validates cleanly, then confirm the host isn't serving a stale intermediate or an incomplete bundle. That's where many “it works on my machine” SSL fixes fall apart.
If the leaf cert is present but the chain is incomplete, the installation isn't finished.
That's the mindset that saves time. Install at the hosting layer first, confirm chain integrity second, then let WordPress advertise the secure URLs after the server is already trustworthy.
Forcing HTTPS Without Creating Redirect Loops
Once the certificate is live, the next failure mode is a redirect war. WordPress, the host, a security plugin, or Cloudflare can each try to force HTTPS, and when two layers do it at the same time, you get loops instead of a clean redirect. That's usually when support tickets start mentioning ERR_TOO_MANY_REDIRECTS.
Pick one redirect authority
On Apache, HTTPS enforcement usually lives in .htaccess. On Nginx, it belongs in the server block. On Cloudflare, the edge setting can handle the redirect before the request reaches WordPress. The important part is to let one layer own the behavior and keep the others quiet.
If the host already forces HTTPS, don't add another plugin-level redirect unless you have a specific reason. If Cloudflare is handling the redirect at the edge, double-check that the origin server isn't also performing the same rule in a way that confuses the request path. Even experienced developers get caught here, because each layer looks correct in isolation.
Practical rule: one HTTPS redirect policy per stack, not three.
The other common trap is a wp-config or database mismatch between the home and site URL values and the actual canonical domain. If WordPress still thinks the canonical site is HTTP while the server is forcing HTTPS, the redirects can bounce back and forth. Fix the canonical setting first, then apply the redirect rule once.
The shortest diagnosis path
Start with the browser, then the host, then the WordPress URL values. If the browser sees a loop, look for duplicate rules. If the host seems clean but WordPress still won't settle, inspect the site URL configuration and any plugin that touches redirects. In mixed stacks, the bug is usually not the certificate itself. It's the interaction between layers.
A clean HTTPS rollout should feel boring. If the site keeps redirecting twice, the stack is overconfigured, not secure.
Finding and Killing Mixed Content for Good
Mixed content is the reason many sites show a warning even after the SSL certificate is valid. A page can load over HTTPS and still pull images, scripts, fonts, embeds, or CSS from HTTP sources. The result is a browser warning that undermines trust even though the certificate itself is fine.
The fastest way to find it is browser DevTools. Load the page, inspect the console and network panel, and look for requests that still point to http://. External scanners help too, especially the Why No Padlock tool, because it reveals assets that don't stand out in casual testing. After that, check the database for hardcoded references in post content, widgets, and theme options.
Audit the usual suspects first
A useful audit sequence looks like this:
- Post content: old image embeds and manually inserted links often keep stale URLs.
- Widget areas: text widgets and builder blocks can store hardcoded asset paths.
- Theme options: logo, hero image, and background fields are common holdouts.
- Plugin settings: some plugins store absolute URLs and never rewrite them on their own.
The fix usually starts with search and replace in the database, followed by a pass through plugin and theme settings. Then I check whether any plugin or theme is still outputting insecure assets from its own templates. That's where a lot of “I already ran the migration” confusion comes from.
Use the last-mile plugin carefully
For edge cases like feeds, admin AJAX, or older content that's stubborn about rewriting, a content-fixing plugin can help, including tools in the SSL Insecure Content Fixer category. I treat those as last-mile tools, not the primary fix. If a plugin is masking insecure output from a theme that should be corrected properly, the warning will come back later.
| Common Mixed Content Sources in WordPress | Likelihood | First Audit Step | Typical Fix |
|---|---|---|---|
| Uploaded images in posts | High | Search post content for HTTP references | Replace stored URLs and regenerate links if needed |
| Theme asset paths | High | Inspect theme options and templates | Update theme settings or edit hardcoded asset URLs |
| Builder module fields | Medium | Review page builder content blocks | Run search and replace, then re-save the page |
| Old plugin output | Medium | Check page source and network requests | Update plugin settings or replace the plugin behavior |
| Feeds and admin endpoints | Low | Test edge cases after core cleanup | Use a targeted SSL content fixer only if needed |
The key habit is to keep scanning after updates. A plugin can reintroduce mixed content long after the first SSL rollout, especially when a client edits content without knowing the old URLs are still embedded in the database.
Renewals, Expirations, and How Incidents Actually Surface
The cleanest renewal stories are the ones nobody notices because automation worked. The messy ones start with a site that was fine yesterday and is failing today because a DNS change, ACME challenge issue, or host-side misconfiguration broke renewal. Once the certificate expires, the symptoms show up fast in places the client cares about.
A weekend failure pattern
A familiar case is a Let's Encrypt renewal that stops working after a DNS or challenge change. The site keeps running until expiry, then checkout errors appear, webhooks stop landing, and admins can't trust what they're seeing in wp-admin because the browser starts treating the site as unsafe. It's not the certificate alone that hurts, it's the chain reaction across sales, login, and integrations.
The first warning usually isn't a dramatic outage. It's a browser notice, a failed API callback, or a cron task that no longer passes an HTTPS check. For a client, that feels random. For an operator, it's a renewal incident that should have been visible earlier.
Monitor the things that fail first
The signals worth watching are the boring ones:
- Expiry windows: don't wait for the deadline, track it early.
- Renewal failure alerts: send notices through more than one channel.
- Integration errors: monitor webhook and API rejections tied to TLS.
- Admin access issues: treat wp-admin warnings as incident signals, not isolated browser noise.
The useful mental model is that certificate expiry is a production event, not a calendar reminder. That's especially true for agencies with many sites on different hosts, because one platform can renew cleanly while another stops handling challenges.
The WordPress maintenance guidance is a good reminder that SSL belongs in the wider maintenance cycle, not in a separate bucket. A 30-day pre-expiry checklist is often enough to catch most avoidable issues, but only if somebody owns it. That ownership is what separates routine renewal from weekend firefighting.
Portfolio-Scale SSL Monitoring and Triage
A healthy SSL posture across 10 to 50 sites looks like a system, not a pile of one-off fixes. Every site should have a known expiry window, a known redirect path, and a known owner for renewal failure response. If those three things aren't visible, SSL health is already drifting.
The portfolio view matters because SSL problems rarely arrive alone. A site with broken redirects may also have stale plugins or PHP issues, and a site with mixed content often needs a content audit after a theme update. SSL is one signal in a broader risk picture, not the whole picture.
What to review each month
A simple monthly review should include a central expiration dashboard, automated alerts before expiry, a protocol audit for current TLS behavior, and an incident playbook for renewal failures. If you already run broader uptime checks, fold SSL into that routine instead of creating a separate ritual. The WordPress uptime monitoring guidance fits well here because uptime and certificate health tend to surface together when a site slips.
For teams that want one risk view across multiple WordPress installs, WP Triage is one option to surface SSL health alongside other site risk signals, so you can see which sites need attention first and which issues are urgent. That matters more than raw certificate counts, because the job is deciding what to fix first.
A portfolio is only as secure as the site whose certificate expires quietly on a Friday afternoon.
The practical standard is clear. Track expiry, confirm redirects, scan for mixed content after changes, and keep an incident path for renewals that fail. If you can answer those four questions for every site, SSL stops being a recurring surprise and becomes a managed part of WordPress operations.
If your team is juggling expired certs, redirect problems, and mixed-content cleanup across multiple WordPress sites, bring those sites into one triage workflow instead of chasing each alert separately. WP Triage helps you see SSL health alongside the other maintenance risks that decide what should get fixed first, so you can catch renewal gaps before clients do.