I recently ran into a frustrating but enlightening issue while working with a WordPress staging environment on a subdomain. Despite setting everything up according to best practices, I encountered broken styles, insecure content warnings, and malware-like behavior in the browser. What began as a straightforward deployment turned into a deep learning experience about HTTPS, mixed content, and the all-important HSTS header.
TL;DR
When setting up a WordPress staging site on a subdomain, my SSL certificate wasn’t properly inherited or applied. This resulted in browsers throwing mixed content warnings and partial page rendering. I resolved it by forcing HTTPS using HSTS headers at the wildcard domain level (*.domain.com). Since making that change, not only did the staging site work flawlessly, but my entire site’s HTTPS integrity has remained solid and secure.
The Problem Begins: Setting Up the Staging Environment
In preparation for a major redesign, I created a staging environment at staging.domain.com. This clone of the production WordPress instance was meant to let my developers test themes, plugins, and layouts without affecting users. My production site already had a solid SSL certificate from Let’s Encrypt, but immediately after loading the staging URL, I noticed issues:
- Stylesheets and images weren’t loading correctly.
- Chrome console output was full of “Mixed Content: The page at XYZ was loaded over HTTPS, but requested an insecure resource…” errors.
- Some JavaScript failed to execute, breaking interactive features like sliders and dropdown menus.
At first, this looked like a typical mixed content problem. After all, I’d cloned the site, including its database and configuration, so the hardcoded links pointing to HTTP URLs made sense. But things weren’t adding up.
Digging Deeper: SSL Misconfiguration
Although domain.com was protected via SSL and loaded fine over HTTPS, it turned out that staging.domain.com did not receive that same protection by default. My hosting provider initially hadn’t issued a wildcard SSL certificate—just a single-domain SSL.
In practice, this meant that while HTTPS “loaded,” it wasn’t trusted, leading to a mix of encrypted and unencrypted assets—and subsequent browser complaints.
Initial Attempts to Fix Mixed Content Errors
It’s worth noting that WordPress stores full URLs in the database—including the protocol. So even though I had forced HTTPS in my wp-config.php and enforced HTTPS using a redirect rule in the .htaccess file, HTML output from WordPress and some embedded scripts still referenced http://staging.domain.com.
Here’s what I tried before landing on a more robust solution:
- Search-and-replace in the database: I used WP-CLI’s search-replace command to update all HTTP references to HTTPS. This cleared up some of the obvious internal links but not all embedded files and plugin-generated content.
- Installed the “Really Simple SSL” plugin: This helped dynamically rewrite resource URLs but added more abstraction, which sometimes broke with complex themes.
- Updated my CDN configuration: I triple-checked my Cloudflare settings to make sure the staging subdomain was proxied and had “Always Use HTTPS” toggled on.
These steps helped partially, but the issue was still recurring. And worse, every time I forgot to check a checkbox or a plugin failed to rewrite something, the site partially broke.
The Breakthrough: Using HSTS for HTTPS Integrity
Then I realized what was missing: a strong, top-down directive to the browser that says, “All subdomains must use HTTPS, no exceptions.”
The solution came in the form of HTTP Strict Transport Security (HSTS), a security feature that instructs compliant browsers to never make insecure (HTTP) requests—even if the user types them manually. More importantly, it allowed me to do this for all subdomains using a single wildcard policy.
Here’s the exact header I added to my origin server’s configuration:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
This tells the browser to trust HTTPS connections for this domain and every subdomain for one full year. includeSubDomains was the key difference—it ensured that staging.domain.com would inherit the HTTPS-only rules without further interference.
Precautions Before Enabling HSTS
It’s worth emphasizing that HSTS is not reversible while active. If you misconfigure it and bind a broken staging subdomain to HSTS, users will be stuck with bad HTTPS connections for the entire max-age duration. So before flipping the switch:
- Test SSL using SSL Labs to ensure every subdomain serves a valid certificate.
- Double-check redirects from HTTP to HTTPS using curl or browser dev tools.
- Avoid using preload at first unless you really understand the implications—it will be submitted to a browser-maintained list you can’t control.
Once I confirmed that both production and staging were serving valid SSL certificates and redirected properly, I deployed the HSTS header at the root domain. All subdomains, including staging, started working flawlessly.
Lessons Learned and Final Thoughts
Here’s what this incident taught me—and hopefully helps you avoid:
- Never assume subdomains automatically inherit HTTPS or SSL behavior from the root domain.
- Mixed content isn’t just a visual problem—it breaks functionality and seriously undermines user trust.
- Fixing the problem at the browser level using strong security headers like HSTS is often more effective and future-proof.
Of course, HSTS isn’t a silver bullet. It only works if configured correctly and combined with solid SSL provisioning across all your subdomains. Don’t neglect wildcard SSL certificates—get them right from the beginning.
Wrap-Up: The Importance of Thinking Holistically
What started as a simple staging setup turned into a masterclass in secure web architecture. Web developers and DevOps engineers alike should think about security beyond just enabling HTTPS. Without the right policies, headers, and SSL coverage, browsers will expose weaknesses you thought were behind you.
Since implementing HTTPS and HSTS across all subdomains, I haven’t encountered a single mixed content error. If you’re operating a WordPress site with multiple environments, take the time to get this right. Your future self—and your users—will thank you.
