How to Fix Mixed Content in WordPress After Enabling SSL

You installed the SSL certificate, the address bar shows the padlock, and then a visitor reports a warning that the connection is not fully secure. The page loads, but a few images, scripts or stylesheets still come from plain http:// addresses. Browsers call this mixed content, and they block or warn about it, which hurts trust and can break a checkout or a form. This guide finds every insecure address, fixes the ones inside WordPress’s content, and checks that the padlock stays solid.

On SiteHarbour’s SSL certificates and on every WordPress plan, the certificate is the easy part. The mixed content is almost always old addresses that WordPress stored in the database before the switch to HTTPS.

Step 1: Find the insecure addresses#

Open the page in a browser, then open the developer console. Mixed content appears as a warning that names each insecure address, such as Mixed Content: The page was loaded over HTTPS, but requested an insecure image. Write down the addresses. Repeat the check on the home page, a post, a category page and any page with a form, because each one can load different assets.

A quick scan from a terminal finds the same problem in the database. Connect over SSH to the WordPress folder and count the stored addresses with WP-CLI:

sudo -u www-data wp --path=/var/www/example search-replace 'http://example.com' 'https://example.com' --dry-run --all-tables

Expected: a report of how many rows and replacements would change, table by table. Nothing is saved with --dry-run. Use your own domain in place of example.com, and check the report before you run it for real.

Step 2: Set the site address to HTTPS#

In the dashboard, open Settings > General. Check that both the WordPress Address and the Site Address begin with https://. If either is still HTTP, change it and save. WordPress then builds new links with HTTPS. Old links in the content still need the next step.

Step 3: Replace the stored addresses#

Run the same search and replace without the dry-run flag, and with the exact address pair you checked. WP-CLI updates serialized data safely, which a plain text replace in a database tool can corrupt:

sudo -u www-data wp --path=/var/www/example search-replace 'http://example.com' 'https://example.com' --all-tables

Expected: a count for each table, then a success line. Clear the page cache afterwards, because a cached page still holds the old addresses until it expires. If you use the LiteSpeed Cache plugin, purge all, as described in how to speed up WordPress with LiteSpeed Cache.

Keep the backup in hand before this step. A search and replace changes many rows, and the restore steps are in how to back up and restore a cPanel account.

Step 4: Fix the assets that are hard-coded#

Some addresses are not in the database at all. They sit in a theme file, a plugin’s stylesheet, or a script that writes a link into the page. Search the theme and plugin folders for the insecure address:

grep -rl "http://example.com" ~/public_html/wp-content/themes ~/public_html/wp-content/plugins

Expected: a list of files. Change each address to HTTPS, or to a protocol-relative form if the file is served from the same site. For a file that belongs to a plugin, check first whether an update fixes it, because a local edit is lost on the next update.

Images that come from another site are a different case. If the other site does not offer HTTPS, you cannot load it securely. Download the image to your own media library, or remove it.

Step 5: Check the result#

Reload each page you tested in Step 1 and check the console again. The mixed content warnings should be gone. Then check the page source for any remaining http:// reference inside a script or a link:

curl -s https://example.com/ | grep -o 'http://[^"]*' | sort -u

Expected: no output, or only addresses to other sites that you know do not need to change. A standard XML namespace such as http://www.w3.org/2000/svg is not a request, and it is fine to leave.

Step 6: Keep the redirect and the certificate in step#

An HTTP address that redirects to HTTPS is the right behaviour, so do not remove that redirect while you fix the content. Make sure the certificate covers both the bare domain and the www address if you use both. If the site is behind a proxy or a CDN, check that the proxy also serves HTTPS to visitors, or the browser sees a mixture again.

Common mistakes#

• Using a text editor on the database. Serialized data holds lengths, and a plain replace breaks them. Use WP-CLI.
• Skipping the dry run. The report shows how many rows change before anything is saved.
• Forgetting the cache. The old page is served until the cache clears.
• Fixing a theme file that an update will overwrite. Prefer a plugin or a child theme, or check the update.
• Ignoring one page. Test a form, a checkout and a category page, because they load different assets.

Frequently asked questions#

Does the padlock show a warning if only one image is insecure?#

Yes. Browsers warn about any insecure request on the page, however small.

Can I fix this with a plugin instead?#

Some plugins rewrite addresses on output. They hide the problem, but the stored addresses remain. The search and replace is the lasting fix.

Why does the mixed content come back after a restore?#

A restored database can hold the old addresses from the backup. Run the search and replace again after each restore.

Do I need the www version?#

Only if the site serves it. Pick one canonical address, and run the search and replace for that pair.

Mixed content is old HTTP addresses left behind after a switch to HTTPS. Find them in the console, set the site address to HTTPS, replace the stored addresses with WP-CLI after a dry run, then fix any hard-coded files and purge the cache. For the HTTPS setup on a Linux server, read how to set up free SSL on Nginx with Certbot.