How to Install a Free SSL Certificate and Fix Mixed Content

Why HTTPS Is No Longer Optional

HTTPS encrypts the connection between your visitor’s browser and your server. Without it, anything typed or submitted on your site, including contact form messages and passwords, travels in a form that can be intercepted on a public network. Browsers now label plain HTTP sites as “Not secure” in the address bar, which is a visible warning to every visitor.

There is also a practical side. Payment processors, advertising networks and many analytics integrations expect HTTPS. Search engines treat it as a baseline signal. And email deliverability, contact forms and logins all behave better on a secure connection.

The good news is that certificates are free, installation is usually one click on modern hosting, and the only real work is fixing the “mixed content” warnings that appear when parts of an old site still load over an insecure connection. This guide covers both halves.

What a Certificate Is and Where the Free Ones Come From

An SSL or TLS certificate proves that the domain in the browser belongs to the server serving it. Three sources cover almost everyone:

Your host’s free automatic certificates. Most hosting control panels issue and renew free certificates automatically. Some hosts call this AutoSSL. This is the simplest option and needs no configuration.
A CDN such as Cloudflare. The CDN terminates the encrypted connection at its edge and provides its own certificate, usually on a free plan, while your server can stay as it is, though ideally it should also be secured.
A paid certificate. Useful for specific business or compliance requirements, extended validation, or wildcard coverage across many subdomains. Most blogs do not need this.

For a typical blog or small business site, the free automatic route is the right choice. Renewal happens automatically, and modern certificates are cryptographically equivalent to paid ones for normal use.

Step 1: Check Whether You Already Have HTTPS

Open your site with the https prefix written manually, for example https://yourdomain.com. Then check two things:

Does a padlock appear in the address bar?
Does the browser show any warning, such as “Not secure” or “Parts of this page are not secure”? A padlock with a warning triangle is a classic mixed content signal.

If the https version does not load at all, the certificate is missing or not installed correctly. If it loads but the padlock has a warning, your certificate works and the page is loading some insecure elements, which is the second half of this guide.

Step 2: Issue the Certificate

The automatic route

Log in to your hosting control panel and look for a section labelled SSL, SSL/TLS, or Security. Many hosts have an automatic option that issues and renews certificates without any input. Run it for your domain and any subdomains you want covered, then wait a few minutes for the certificate to be issued.

The DNS route

If your host supports DNS-based verification, you may be asked to add a text record at your domain registrar. Copy the value exactly, save it, and wait for DNS to update. This is often the most reliable method because it does not depend on your website being reachable during validation.

The CDN route

If you use a CDN, enable its SSL mode. Choose a mode that encrypts traffic all the way to your origin server rather than only between the visitor and the CDN. A mode that leaves the origin connection in plain text is better than nothing but not by much, and it can produce confusing warnings if your server later installs its own certificate.

Step 3: Force HTTPS and Update the Site Address

Installing a certificate is only half the job. If visitors can still reach the http version, you are maintaining two addresses for one site, which splits your traffic data and can confuse search engines. You need one canonical secure version.

Do these in order.

Take a backup. Any time you change site addresses, a backup is mandatory. If something goes wrong, restoring is instant.
Update the WordPress and site address in Settings, then General, to the https version of your domain. Make sure both fields use the same version, with or without www, whichever you have chosen as canonical.
Add a server-level redirect from http to https. On Apache hosting, this is typically a few lines in the .htaccess file that redirect all requests to the secure version. Many hosts, CDNs and security plugins offer a one-click “force HTTPS” option that adds this for you. If you can use that, prefer it, because hand-edited redirect rules are easy to get wrong.
Test every important URL. Open your homepage, a post, a category page, the contact page and the login page, all starting with http. Every one should land on the https version. Follow exactly one redirect, not a chain of two or three.

One caution: when redirecting, do not create a loop. Redirecting https back to http anywhere, or redirecting the www and non-www versions into each other in both directions, will break the site. Add one redirect, test, then stop.

Step 4: Identify Mixed Content

Mixed content means a secure page is loading some resources, usually images, scripts or stylesheets, over an insecure http address. The browser blocks the insecure item or shows a warning, and the padlock disappears or carries an alert icon.

Three ways to find the exact URLs:

Browser developer tools. Open the page, press F12, and look at the Console tab. Insecure resources are reported with their full URLs. This is the most reliable method because it shows you what is actually loading, including items injected by scripts.
A mixed content checker tool. Paste a page URL and the tool lists insecure resources in one report. Useful for checking many pages quickly.
Search Console. The HTTPS or security report sometimes flags pages with mixed content, though browser tools remain more precise.

Note which category each insecure URL falls into, because the fix differs by type.

Step 5: Fix Mixed Content at the Source

Fix the actual URLs rather than hiding the warnings. In order of how often they cause trouble:

Images inside post content. Old posts often contain hard-coded http image URLs. These need to be updated in the database, ideally with a search-and-replace tool.
Hard-coded links in the theme or a plugin. If a developer hard-coded an http address in a template file, the theme or plugin needs updating, or the file needs a careful edit.
Widgets and menus. Custom menu items and widget links sometimes keep the old protocol. Edit each one from the dashboard.
External scripts and fonts. Some third-party services, especially older ones, still hand out http URLs. Replace them with the https version of the same file, or remove them if they are no longer needed.
Cached pages. After fixing everything, clear your caching plugin and CDN cache. Otherwise visitors keep receiving the old page with the old insecure references.

Step 6: Update the Database Safely

On a site with years of content, searching and replacing URLs by hand is impossible. Use a dedicated search-and-replace tool designed for WordPress databases, which handles serialised data correctly.

A safe procedure looks like this:

Take a full backup and download it, not just store it on the server.
Run a search-and-replace only from the specific http address to the specific https address. Never run a blind replace of every “http” string on the site, because it will damage legitimate text.
Do the replace in small batches and spot-check pages as you go.
Check forms, image galleries and embedded media afterwards, since these are the places where serialised data problems surface first.

If a plugin offers a “fix mixed content” toggle as a shortcut, understand what it does before using it. It rewrites insecure resources at page load. That removes browser warnings immediately but leaves the underlying URLs unfixed, so it is a temporary measure at best. If you use it, still plan a proper cleanup.

Step 7: Verify the Result

Work through this verification list after every change.

Open your homepage in an incognito window and confirm a clean padlock with no warning.
Open the Console tab on three different pages and confirm no insecure resource messages.
Test a page with an image gallery, a page with a form and a page with embedded media.
Check that http URLs redirect to https with a single hop.
Recheck after 24 hours, because caching layers can serve old versions for a while.

Certificates, Renewals and HSTS

Free certificates often renew automatically, but the renewal is not guaranteed if your configuration changed. Diarise a check every few months, or enable a monitoring service that alerts you before expiry. An expired certificate produces a full-page browser warning that stops most visitors instantly.

HTTP Strict Transport Security is an optional header that tells browsers to always use HTTPS for your domain. It is powerful and improves security, but it is also unforgiving: if you enable it with a long expiry and later need to serve plain HTTP, visitors who already received the header may be locked out. Enable it only after HTTPS is fully working, including every subdomain, and start with a short duration.

Common Errors and What They Mean

Message	Meaning	Action
Your connection is not private	Certificate missing, expired or for the wrong hostname	Reissue the certificate and confirm it covers the exact domain in use
Not secure, no warning details	Page served over http	Add the http-to-https redirect
Padlock with warning triangle	Mixed content	Find insecure resources in the console and fix them
Redirect loop	Conflicting redirect rules	Remove duplicates; keep one redirect to the canonical version
Certificate valid but admin panel insecure	Site address fields not updated	Set both WordPress address and site address to https

Moving to HTTPS When a CDN Is Already in Place

Sites that installed a CDN before adding a certificate need extra care, because there are now two encrypted connections to consider: visitor to CDN, and CDN to your origin server.

Enable HTTPS at the origin first, so your server can serve a secure connection on its own.
In the CDN dashboard, set the SSL mode to a full or strict option that encrypts traffic to the origin, not a flexible mode that leaves the origin connection plain.
Force HTTPS in the CDN edge or through a page rule, and keep the origin-level redirect as a second layer.
Purge the CDN cache completely after the change. Cached http resource URLs will keep producing warnings until the cache is cleared.
Re-test with browser tools from a different network to bypass any local cache that could give a misleading result.

Frequently Asked Questions

Is a free certificate as good as a paid one?

For encryption, yes. The main differences with paid certificates are support, warranties and extra features such as wildcard coverage or extended validation displays. For a normal blog, a free automatic certificate is entirely sufficient.

Do I need a separate certificate for each subdomain?

Depends on the provider. Many issue a wildcard or multi-domain certificate that covers several hostnames. Check which domains your certificate actually covers, since a mismatch causes a browser warning.

Will switching to HTTPS hurt my rankings?

No, provided you redirect properly and update internal links. Leaving both versions live and reachable, which creates duplicate content, is the real risk.

Can I turn off mixed content by editing CSS?

No. CSS can hide a broken image but cannot change the protocol of a loaded resource. The URL itself has to be corrected.

My padlock disappeared after installing a CDN. Why?

Usually because the CDN is serving some assets over http, or because the SSL mode is set to flexible while your origin is also trying to redirect. Align the CDN’s SSL mode with your server configuration.

Final Thoughts

Moving to HTTPS is a two-part job: install a certificate so the connection is encrypted, then eliminate the insecure references so the browser stops complaining. The second part takes more time, especially on older sites, but it is a one-time cleanup. Do it carefully with a backup in hand, verify in an incognito window, and your visitors will see exactly what they expect: a secure site with a clean padlock.