Josiah Cole

Mixed content means a page loaded over HTTPS is pulling in some files (images, scripts, stylesheets, fonts, iframes) over plain HTTP. On a WordPress site it almost always happens after a move to HTTPS, because old http:// URLs are still saved in the database. The fix is a careful search and replace, plus a quick look at your theme and any hardcoded embeds.

Last updated: October 28, 2026.

Disclosure: some links in this post are affiliate links, marked as sponsored. If you sign up through them I may earn a commission at no extra cost to you. I only recommend hosts I have used.

What mixed content looks like

Depending on what is loading over HTTP, you might see:

• No padlock, or a “Not secure” label, even though the address starts with https
• Images that don’t appear
• A broken layout, because a stylesheet was blocked
• Sliders, forms, or embeds that stop working, because a script or iframe was blocked

Modern browsers handle the two kinds of mixed content differently. Images, audio, and video are upgraded to HTTPS automatically, and blocked if the HTTPS version doesn’t exist. Scripts, stylesheets, and iframes loaded over HTTP are blocked outright, and that is what breaks pages.

Step 1: Find every insecure URL

Open the page in Chrome, press F12, and click the Console tab. Each problem shows up as a line like this:

Mixed Content: The page at 'https://example.com/' was loaded over HTTPS,
but requested an insecure resource 'http://example.com/wp-content/uploads/photo.jpg'.

That tells you exactly which file is the problem. Check a few different page types (home page, a post, a page, your contact form), because a widget or a single post can be the only offender.

To find every stored copy at once, search the database with WP-CLI:

wp db search 'http://example.com' --all-tables

Step 2: Set both site URLs to https

In Settings > General, make sure WordPress Address and Site Address both start with https:// and match the www or non-www version your site actually uses. If changing these locks you out with a redirect loop, see How to Fix ERR_TOO_MANY_REDIRECTS in WordPress.

Step 3: Search and replace old URLs in the database

This fixes most mixed content in one pass. Back up first. Then do a dry run, which reports what would change without changing anything:

wp db export before-https.sql

wp search-replace 'http://example.com' 'https://example.com' --all-tables --skip-columns=guid --dry-run

# looks right? run it for real
wp search-replace 'http://example.com' 'https://example.com' --all-tables --skip-columns=guid

A few notes from doing this on a lot of sites:

• Run it again for http://www.example.com if your site ever used www.
• WP-CLI’s search-replace handles serialized data correctly. A raw SQL UPDATE ... REPLACE() query does not, and can break widgets and theme settings.
• Skip the guid column. WordPress uses it as a permanent ID, not a link, and the official advice is to leave it alone.
• No WP-CLI? The Better Search Replace plugin does the same job from wp-admin, including a dry run.

Try it on a staging copy first if your host gives you one. Here is how staging works on Pressable.

Step 4: Check the theme, widgets, and custom CSS

If the console still shows warnings after the search and replace, the URL is probably not in the database. Places to look:

• Theme files: search your theme for http://. Background images in style.css are a common one.
• Page builders that cache CSS to files. Elementor, for example, has a Regenerate CSS option under Elementor > Tools. Run it after the replace.
• Hardcoded script or font tags added by a plugin or in a header/footer code snippet
• Third-party embeds. If an old widget or iframe only works over HTTP, swap it for an HTTPS version or remove it.

Step 5 (stopgap): Tell browsers to upgrade requests

The upgrade-insecure-requests directive tells the browser to request every http:// resource on the page over HTTPS instead. You can send it as a header from your server or CDN:

Content-Security-Policy: upgrade-insecure-requests

SSL plugins like Really Simple SSL can add it for you too. It only works if the file actually exists on HTTPS, and it hides the problem rather than fixing it, so I treat it as a stopgap while the database cleanup gets done.

Step 6: Purge caches and test again

Page caches, CDNs, and minify plugins can keep serving the old HTML with the old URLs. Purge everything, then reload the page in a private window and check the console again. A clean console and a padlock means you are done.

Where http:// URLs hide, and how to fix each

Where it lives	Example	Fix
Post and page content	Images inserted before the HTTPS switch	wp search-replace or Better Search Replace
Widgets and theme settings	Logo URL, footer HTML	search-replace (handles serialized data)
Theme files	Background image in style.css	Edit the file, use https or a relative path
Page builder CSS files	Cached CSS with old URLs	Regenerate CSS in the builder’s tools
Third-party embeds	Old widget or iframe on http	Use the HTTPS embed code or remove it

FAQ

What is mixed content in WordPress?

Mixed content is when a page served over HTTPS loads some files, such as images, scripts, or stylesheets, over plain HTTP. It usually comes from old http:// URLs left in the database after a switch to HTTPS.

How do I find mixed content on my site?

Open the page in Chrome, press F12, and check the Console tab. Each insecure file is listed with its full URL. WP-CLI’s wp db search command finds every stored copy in the database.

Do I need the Really Simple SSL plugin to fix mixed content?

No. A one-time search and replace of http:// URLs in the database fixes most cases without a plugin. An SSL plugin can help as a stopgap while you clean up.

Why does my site still say Not secure after fixing mixed content?

Check for cached pages, a form that submits to an http:// address, hardcoded URLs in theme files, or an expired SSL certificate.

Should I replace http with https in the guid column?

No. WordPress uses the guid as a permanent identifier, not a link, so skip it with –skip-columns=guid.

Related posts

• How to Fix ERR_TOO_MANY_REDIRECTS in WordPress
• How to Point Your Domain to WP Engine (DNS Records and SSL)
• How to Add a Domain to Pressable and Set the Primary Domain
• Pressable Staging Sites: How to Create One and Push It Live
• How to Speed Up WordPress: Fixes That Start With Your Host
• WordPress Security Best Practices

ERR_TOO_MANY_REDIRECTS means your browser got bounced between URLs until it gave up. Chrome and Firefox both stop after 20 redirects. On a WordPress site the cause is almost always two settings that disagree about the “real” address of the site: http or https, www or no www. Fix the disagreement and the loop goes away.

Last updated: October 28, 2026.

Disclosure: some links in this post are affiliate links, marked as sponsored. If you sign up through them I may earn a commission at no extra cost to you. I only recommend hosts I have used.

The same error shows up under different names depending on the browser:

• Chrome and Edge: This page isn’t working. example.com redirected you too many times. ERR_TOO_MANY_REDIRECTS
• Firefox: The page isn’t redirecting properly
• Safari: Safari can’t open the page because too many redirects occurred

I have run into this on client sites more times than I can count, usually right after someone “just turned on HTTPS” or put the site behind Cloudflare. Here is the order I check things in, fastest first.

What causes a WordPress redirect loop

Cause	Typical sign	Fix
Stale cookies or cache	Loop only happens for you, or only when logged in	Clear cookies for the domain, purge caches
WordPress Address and Site Address disagree	Started right after editing Settings > General	Set both to the same https URL
Cloudflare SSL mode set to Flexible	Site is behind Cloudflare and the host forces HTTPS	Switch SSL/TLS mode to Full (strict)
Two HTTPS or www redirects fighting	Started after adding a plugin, an .htaccess rule, or a host redirect	Keep one redirect, remove the rest
HTTPS not detected behind a proxy	Only wp-admin loops, often after FORCE_SSL_ADMIN	Add the X-Forwarded-Proto check to wp-config.php
A plugin redirecting on its own	Redirect, language, membership, or security plugin recently changed	Deactivate plugins, then turn them back on one by one

Step 1: Rule out your own browser

Open the site in a private window or on your phone over cellular. If it loads there, the problem is a cookie or cached redirect on your machine. Clear cookies for that one domain (not your whole browser) and try again.

If you can use a terminal, curl shows you the whole chain, which is the fastest way to see where the loop is:

curl -sIL https://example.com | grep -iE '^(HTTP|location)'

You will see a list of status codes and Location headers. A loop usually looks like the same two URLs taking turns, for example http to https and back again, or www to non-www and back again. That pattern tells you which two settings are fighting.

Step 2: Check the WordPress Address and Site Address

WordPress stores two URLs: siteurl (WordPress Address) and home (Site Address). On most sites they should be identical, including https and www. If one says http://example.com and your host forces https://www.example.com, you get a loop.

You usually can’t reach wp-admin while the loop is happening, so check them with WP-CLI:

wp option get home
wp option get siteurl

# set both to the address you actually want
wp option update home 'https://www.example.com'
wp option update siteurl 'https://www.example.com'

No WP-CLI? Add these two lines to wp-config.php above the line that says “That’s all, stop editing”. They override the database values:

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

You can also edit the siteurl and home rows in the wp_options table with phpMyAdmin. If you’re on WP Engine, here is how to get into phpMyAdmin there.

Step 3: Fix Cloudflare’s SSL mode

This is the most common cause I see. With Cloudflare’s Flexible SSL mode, visitors connect to Cloudflare over HTTPS, but Cloudflare connects to your server over plain HTTP. Your server or WordPress sees an HTTP request and redirects to HTTPS. Cloudflare passes that redirect back to the browser, the browser asks again over HTTPS, Cloudflare fetches over HTTP again, and around it goes.

The fix: in the Cloudflare dashboard go to SSL/TLS and set the encryption mode to Full (strict). That makes Cloudflare talk to your server over HTTPS, which works as long as your host has a valid certificate installed. Every managed WordPress host I use issues one for free.

While you’re in Cloudflare, look for duplicate redirects in Redirect Rules or old Page Rules, and check whether Always Use HTTPS is on. That setting is fine on its own, but it adds one more redirect to the pile if your host or a plugin is already doing the same job.

Step 4: Remove duplicate HTTPS and www redirects

A redirect to HTTPS should happen in exactly one place. Common places it hides:

• Your host’s dashboard (many managed hosts force HTTPS at the platform level)
• An SSL plugin such as Really Simple SSL
• Rules in .htaccess on Apache servers
• A redirect plugin like Redirection, or your host’s redirect tool
• Cloudflare or another CDN

Pick one, usually the host or CDN since it runs before WordPress loads, and turn off the others. Do the same for www versus non-www. If your host runs NGINX without Apache, .htaccess is ignored completely, so rules there won’t be the cause, but they won’t fix anything either. Pressable is one of those hosts, and it handles redirects with a custom-redirects.php file instead. For Apache sites, my .htaccess file for WordPress shows a clean HTTPS rule.

Step 5: Make WordPress see HTTPS behind a proxy

If the front end works but /wp-admin/ loops, WordPress probably doesn’t know the request came in over HTTPS. That happens behind load balancers and some proxies that end the HTTPS connection before it reaches PHP. WordPress checks is_ssl(), gets false, and redirects the admin to HTTPS again.

Add this to wp-config.php, above the “stop editing” line:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
    $_SERVER['HTTPS'] = 'on';
}

Managed WordPress hosts normally handle this for you, so on those platforms this is rarely the fix. It matters most on self-managed servers and container setups.

Step 6: Turn off plugins without wp-admin

If the URLs and SSL settings are right and the loop is still there, a plugin is the next suspect. Save a list of active plugins first so you can put things back the way they were:

wp plugin list --status=active --field=name > active-plugins.txt
wp plugin deactivate --all

If the site loads, reactivate plugins one at a time and reload after each one until the loop comes back. No WP-CLI? Rename wp-content/plugins to plugins-off over SFTP, which disables every plugin, then rename it back and activate them individually from wp-admin.

Step 7: Purge every cache

A redirect can get cached at several layers: your host’s page cache, a CDN, a caching plugin, and the browser itself. After you fix the real cause, purge all of them, then test in a private window. On WP Engine that means the cache button in the User Portal or WP Admin, covered in How to Clear the WP Engine Cache.

FAQ

Is ERR_TOO_MANY_REDIRECTS a problem with my computer or the website?

Usually the website. Test in a private window or on another device. If it loads there, clear cookies for that domain on your machine. If it fails everywhere, the site’s settings need fixing.

Will clearing cookies fix ERR_TOO_MANY_REDIRECTS?

Only when the loop is caused by a stale cookie or a cached redirect in your browser. If the loop happens on every device, the cause is on the server or CDN.

How many redirects does Chrome allow before showing the error?

Chrome and Firefox both give up after 20 redirects in a row.

Why does only wp-admin have a redirect loop?

Usually WordPress can’t tell the request arrived over HTTPS, which is common behind a proxy or load balancer. Setting $_SERVER[‘HTTPS’] from the X-Forwarded-Proto header in wp-config.php fixes it.

Can a redirect loop hurt SEO?

Yes, if it lasts. Search engines can’t crawl pages they can’t reach, so fix it quickly and then check Google Search Console for crawl errors.

Related posts

• How to Fix Mixed Content Warnings in WordPress
• How to Point Your Domain to WP Engine (DNS Records and SSL)
• How to Add a Domain to Pressable and Set the Primary Domain
• Pressable Redirects: How to Set Up 301s with custom-redirects.php
• The Almost Perfect .htaccess File for WordPress
• How to Clear the WP Engine Cache