Mixed-Content Warnings and Redirect Chains: Auditing SSL Beyond Expiry Dates
Most conversations about SSL stop at expiry dates. A certificate is valid, the padlock appears, and the team assumes the job is done. In practice, many of the problems visitors actually notice have little to do with whether a certificate is current. Browsers warn about pages that load some resources over plain HTTP, visitors get bounced through a chain of redirects that never settles, and old subdomains still point at a server that no longer serves a valid certificate. This article takes a different angle from a standard expiry audit. It focuses on the parts of HTTPS hygiene that surface as broken pages, slow loads, and confused users, and it offers questions to ask so your team can catch them on a schedule rather than during a support ticket.
Why a valid certificate does not guarantee a clean HTTPS experience
A certificate proves that a server presented a trusted identity for a specific hostname. It says nothing about what the page requests after it loads. A page served over HTTPS can still pull a script, image, or font from an HTTP URL, and modern browsers will block or warn about that mixed content. The result is a site that looks secure in the address bar but shows warnings in the console, breaks an embedded widget, or triggers a security notice on checkout.
Redirects create a second category of trouble. A visitor who types the bare domain may hit HTTP, then get redirected to HTTPS, then to the www variant, then to a trailing-slash version, and finally reach the page. Each hop adds latency and a chance for failure. Some sites accidentally create loops when two rules disagree, such as one forcing HTTPS while another forces a hostname that resolves to a different configuration. None of these problems involve an expired certificate, which is why a date-based check misses them.
Questions to ask about your current setup
Before changing anything, write down answers to a few plain questions. Which hostnames does the site actually use, including subdomains for mail, media, staging, and forms? Which of those hostnames are meant to serve HTTPS, and which ones were set up years ago and forgotten? Where does the canonical version of each page live, and does every other variant redirect to it in a single step? Which third-party embeds, analytics tags, and fonts does each page request, and do all of them load over HTTPS?
Ask who is responsible for renewal and where renewal notifications go. A certificate that renews automatically on the server may still fail if the hostname it covers no longer exists, or if a contact address has gone to a former employee. These questions take less than an hour to answer for a small site and often reveal more risk than the expiry date does.
A practical audit routine for small teams
Start with a crawl of your own site. Use a standard crawler or a browser's developer tools to load each key page and record every request that uses an HTTP scheme, every redirect status code, and the total number of hops from the entry URL to the final page. Flag any page with more than one redirect, any HTTP resource on an HTTPS page, and any redirect that returns to a URL already visited in the same chain.
Next, compare the crawl against a list of intended hostnames. Anything that resolves but is not on the list deserves a decision: retire it, redirect it to the canonical host, or document why it exists. Check that each intended hostname presents a certificate that covers it, using a view of the certificate details rather than trusting a green padlock alone. Finally, review the browser console on a few representative pages, since mixed-content and insecure-form warnings often appear there first.
Repeat this audit after major changes such as a new theme, a new plugin, a migration, or a change to a third-party service. A quarterly cadence is reasonable for most small sites, with an extra pass before peak traffic periods.
A short checklist you can keep
Keep a single document that lists every hostname, its purpose, its owner, and the date its certificate was last confirmed. Record the canonical URL for each important page and confirm that all variants reach it in one redirect. Note every external resource a page loads and confirm it uses HTTPS. Keep a list of contacts who receive certificate and domain notices, and confirm that list is current each quarter.
When you evaluate a hosting provider or plan, use the same questions. Ask what the platform documents about HTTPS setup, how redirects are configured, and where certificate status is visible. Only rely on the answers the provider states in writing, and verify the rest yourself with the audit steps above. A clean HTTPS experience comes from ongoing attention to the whole chain of requests, not from a single date on a certificate.