Fix WordPress Mixed Content After You Install SSL

The SSL certificate is on the site. Chrome still says Not Secure, or the padlock has a warning. That is mixed content, not a missing certificate. The page itself is HTTPS. Some image, script, stylesheet, or embed on that page is still loading over HTTP.

This is the cleanup we walk Connecticut shops, contractors, and clinics through after the host turns SSL on. Fix the two WordPress URLs. Redirect HTTP to HTTPS. Find the leftover http:// files. Replace them for good. Then clear cache so you are not staring at an old copy of the page.

What mixed content actually is

Mixed content means an HTTPS page is pulling at least one asset over plain HTTP. Browsers treat that as a hole in the lock. WordPress’s own HTTPS notes are blunt: a TLS certificate on the server is required, and HTTPS is strongly recommended for logins and visitors. The certificate is step one. The URLs inside the site are step two.

There are two flavors, and they fail differently:

• Passive mixed content: images, audio, video. Chrome often tries to auto-upgrade these to HTTPS if the same URL exists on HTTPS. If it does not, the file can fail to load or the padlock stays broken.
• Active mixed content: scripts, stylesheets, fonts, iframes, and AJAX calls. Modern browsers block these. Menus, sliders, forms, and checkout widgets go missing, and the console fills with “Mixed Content” errors.

MDN’s mixed content guide is the same story in more technical language: serve the page and every resource over HTTPS. Auto-upgrade is a safety net for some media. It is not a substitute for fixing the URLs WordPress is still printing.

Confirm WordPress itself is on https

WordPress stores two addresses under Settings > General:

• WordPress Address (URL) is where core files live (admin, includes, the REST API).
• Site Address (URL) is the public URL people type.

On a normal install they match, and both must start with https:// with no trailing slash. If one is still http://, WordPress will keep writing insecure links even though the certificate is valid.

Change them, save, then log in again at the HTTPS URL. If you cannot reach wp-admin after a bad edit, stop. Do not keep guessing in the dashboard. Put these two lines in wp-config.php above the “stop editing” comment, using your real domain:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

That hard-codes the values. You will not be able to edit them on the General screen while those lines stay in the file. That is the point when the dashboard is the problem.

Optional, once HTTPS works: define( 'FORCE_SSL_ADMIN', true ); in the same file forces logins and wp-admin over SSL. WordPress documents that constant. It does not fix leftover HTTP images in old posts.

Make HTTP redirect to HTTPS

Visitors still type http://. Old Google results and printed cards still use it. The server should 301 those requests to the HTTPS URL, same path, no extra hops.

Test it in a private window:

• Open http://yourdomain.com and confirm you land on https://yourdomain.com.
• Open an inner page the same way (http://yourdomain.com/contact/).
• Try both www and the apex if you use both. One hostname should win. The other should redirect to it, also on HTTPS.

If HTTP still serves the site, the padlock fight never ends. Ask the host to force HTTPS at the server. A plugin redirect is a backup, not the first choice. Two redirects stacked (server plus plugin) can loop.

Find the leftover http files

Guessing which image is wrong wastes an afternoon. The browser already knows.

• Open the homepage, a blog post with photos, a contact or booking page, and checkout if you have a store.
• Right-click, Inspect, Console tab. Reload.
• Look for lines that say Mixed Content and name an http:// URL.

Write those URLs down. Typical leftovers on small business sites:

• Images in old posts and page-builder sections, stored as full http:// links
• Logo, favicon, or background set in the customizer years ago
• A contact form, map, or booking iframe still pointed at HTTP
• A font or CSS file from a plugin that never got updated
• A CDN or cache plugin whose public URL is still HTTP

Logged-in and logged-out views can differ. Cache plugins often skip the admin bar. Always retest in a private window after you think you are done.

Fix the URLs for good

Take a backup you can restore before you rewrite the database. Files plus the database, from the same moment. We published that process in How to Back Up and Restore a WordPress Site.

There are two common fixes. They are not the same job.

On-the-fly rewrite plugins

SSL helper plugins can swap http:// to https:// as the page is sent. That is useful for a first pass, and it can restore the padlock the same afternoon. The old URLs are still sitting in the database. Turn the plugin off later and the warnings come back.

Use a rewrite plugin as a temporary net, not as the permanent record.

Replace the stored URLs

The lasting fix is a search-and-replace that understands WordPress serialized data (theme options, page builders, widgets). A raw SQL REPLACE() on wp_posts looks tidy and then quietly breaks those serialized strings.

If you use a search-replace plugin, run a dry run first. Replace only your domain:

• http://yourdomain.com to https://yourdomain.com
• http://www.yourdomain.com to the hostname you actually use (www or apex, not both leftover)

Do not run a blind replace of every http:// on the internet. Third-party URLs that have no HTTPS version will break, and you want to see those one at a time.

If you are comfortable with WP-CLI on the server, the same job is:

wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --all-tables --dry-run

Read the count. Then run it without --dry-run. Skip this if you have never used WP-CLI. The plugin path is enough.

Clear cache or you will think you failed

After the replace, purge every cache in the path: WordPress cache plugin, server cache, CDN, then your browser. Test again in a private window.

If the console still names an HTTP file that you already changed in the database, you are looking at a cached HTML page. Fix cache first. Then look at the theme or plugin file that hardcoded the old URL.

If pretty permalinks 404 after the URL change, open Settings > Permalinks and save once with no edits. That rewrites the rules.

Third-party widgets that still use http

Some map, chat, review, or booking embeds were copied years ago with an HTTP snippet. Chrome will block the script. The rest of the page can look fine.

Get a current embed from the vendor. If they still have no HTTPS URL, that widget cannot sit on an HTTPS page. Replace it or drop it. Do not leave it and hope the browser will upgrade a script. It will not.

What not to turn on yet

HSTS tells browsers “this host is HTTPS only, remember that.” Turn it on after the site is clean for a while: every hostname you care about (apex, www, maybe shop.) already redirects, and mixed content is gone. Enable it too early and a leftover HTTP subdomain becomes hard to recover from, because the browser will refuse HTTP on purpose.

Skip preload lists until you know you will not need HTTP anywhere on that domain.

A short checklist

• Certificate is valid for the hostname people actually type
• WordPress Address and Site Address both use https://
• HTTP 301s to HTTPS on the homepage and an inner page
• Console is clean on home, a post with images, forms, and checkout
• Database URLs replaced, not only rewritten on output
• Cache purged, private-window retest passed

If the padlock is still wrong after that, send support the exact console line (the blocked URL) plus whether it happens logged out. That is enough to tell a leftover post, a plugin file, or a CDN setting apart.

If you host with KDigital Hosting, open that from your client area. Managed WordPress hosting covers more of the SSL and cache side for you. On a standard WordPress hosting plan you still own the content URLs, which is why the console check matters.