Moving WordPress to HTTPS without leaving mixed content behind
Installing an SSL certificate isn’t enough to make a WordPress site fully work over HTTPS. Hardcoded http:// URLs in content and stored in the site’s options keep loading unsecured resources, which the browser flags or blocks as mixed content.
What the certificate alone doesn’t fix
The certificate encrypts the connection between browser and server, but it doesn’t change anything in the database. Two core settings, siteurl and home in the wp_options table, define the site’s reference address: if they stay on http://, WordPress keeps generating some of its links without the secure protocol. On top of that, there are http:// URLs hardcoded in post content (images inserted with their full address, internal links) and ones stored in serialised theme or widget settings, which follow the same serialisation mechanism as a host or domain change — I cover that mechanism in depth on the dedicated hosting migration page; the logic here is identical.
Mixed content occurs precisely when a page served over https:// tries to load a resource still on http:// (an image, a script, a stylesheet): the browser blocks the resource or shows a warning in the address bar, which visually breaks the page or triggers a security alert for the visitor.
On a WooCommerce shop, moving to HTTPS isn’t only a matter of visual trust: some payment gateways require an encrypted connection to work at all and simply block the checkout until the certificate is active, which makes this job a priority on a live shop rather than a plain brochure site. Once mixed content is fixed, I add the HSTS header (Strict-Transport-Security) so browsers always prefer the encrypted connection on that domain, reducing the risk of an accidental fallback to HTTP.
How I move a site to HTTPS cleanly
-
Installing the certificate
I set up the SSL/TLS certificate with the host or via a service like Let’s Encrypt, and check it covers every subdomain in use.
-
Forcing the http to https redirect
I configure the redirect at server level (.htaccess on Apache, a server block on Nginx) so no page remains reachable over http://, including API and webhook endpoints used by payment extensions.
-
Updating siteurl, home and the content
I fix these two options along with every http:// URL stored in content and serialised data, using the right tool — the same one used for a host or domain change.
-
Hunting down remaining mixed content
I open the browser console on the main pages to spot resources still called over http:// (often external images or a forgotten third-party script) and fix them one by one.
-
Updating Search Console
I add the https:// property in Search Console, which is treated as a separate address from the http:// version, to keep tracking indexing correctly.
Going further
-
General guide: moving a site to HTTPS
The general method, valid for any CMS, with less WordPress-specific detail.
-
Migrating hosting without downtime
The full detail of the serialisation mechanism referred to on this page.
-
Changing domain name without losing your rankings
Another URL change that follows the same correction and verification logic.
-
Understanding PHP serialisation
The full definition of the mechanism that makes a plain SQL replace dangerous.
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.