Blog

WordPress mixed content warnings appear when your secure page requests an image, script, iframe, or another resource over plain HTTP. Your SSL certificate protects the HTTPS connection, but it doesn’t update every saved URL inside your affiliate pages.

An old banner or tracking pixel can still cause trouble after you’ve installed SSL, and a browser may show a “Not Secure” warning or remove the padlock if the page loads an insecure resource. You can fix the source of the problem without rebuilding your site. Find the exact insecure request, then work through the settings below.

Why Affiliate Pages Trigger WordPress Mixed Content

Affiliate pages load external resources from several places. Your images might come from WordPress, your comparison widget from a plugin, and your advertising banner from an affiliate network.

Mixed content happens when an HTTPS page requests a resource over HTTP. That includes scripts, stylesheets, fonts, iframes, images, tracking pixels, and AJAX requests. An insecure form action also creates a security problem when visitors submit their details.

Affiliate Links and Embeds Behave Differently

A normal outbound affiliate link doesn’t load the merchant’s page while someone reads your review. An embedded banner, script, iframe, or tracking pixel makes a request as the page loads.

So, an HTTP destination in an ordinary clickable link generally isn’t the same problem as an HTTP image inside that link. Inspect the resource the browser identifies before changing your tracking links.

Installing SSL Leaves Saved URLs Behind

Your certificate doesn’t rewrite old posts, page-builder layouts, widgets, or copied affiliate code. Those can still contain absolute HTTP URLs.

Browsers may upgrade some insecure image requests automatically while blocking scripts and other unsafe resources. A page that looks fine can still have a broken widget or missing tracking request.

Step 1. Find the Exact HTTP Resource

Don’t start by switching plugins off. First, find the URL that’s causing the warning. That gives you something useful to fix.

Use Chrome DevTools

Open the affected page, right-click, and select Inspect. In the Console tab, look for a mixed-content warning that names an insecure resource.

Next, open the Network tab and reload the page. Inspect the affected request, then copy its full HTTP URL under Headers. Check the Initiator to identify the script or document that requested it.

Chrome’s DevTools security panel also has a Non-secure origins section with a shortcut to the affected Network requests. Why No Padlock can help identify insecure requests too, but verify the results in your browser tools.

Match the Request to Its Source

A WordPress uploads path points toward an image reference. A plugin directory suggests plugin-generated output. An unfamiliar tracking domain suggests an affiliate embed or marketing tag.

For an Elementor image or background, open the page in its page builder and select the matching element. Check its image control or background setting for the old absolute URL. Replace it with the secure media-library selection, update the page, and regenerate builder files where available.

For Spectra, inspect the matching block’s image or background settings. The saved reference can remain even when the original file has disappeared.

Step 2. Fix WordPress Settings and Stored URLs

Now you know what the browser is requesting. Fix your own site’s addresses before making wider replacements.

Set the Correct HTTPS Addresses

Go to Settings > General. Both WordPress Address and Site Address should use HTTPS and the correct primary domain, including your chosen www or non-www version.

The paths can differ when WordPress core lives in a separate directory. Don’t remove a valid directory just to make the fields identical. The WordPress General Settings documentation explains that distinction.

Also inspect menus, widgets, reusable content, and builder templates. Changing the main address doesn’t rewrite those saved links.

Replace Database URLs Safely

Take a full backup of your database and files first. Include your affiliate redirect settings. My WordPress backup and recovery plan covers keeping a usable recovery copy.

Use Better Search Replace or WP-CLI search-replace, starting with a dry run. Search for your complete HTTP site address and replace it with the matching HTTPS address. Keep the hostname aligned with your primary domain.

Review the affected tables before applying changes. Avoid replacing every occurrence of HTTP across the database, since that can alter third-party tracking destinations.

WordPress stores some settings as serialized data, which includes string lengths. Ordinary SQL replacement can leave those lengths incorrect. The WP-CLI search-replace command handles serialized data and supports --dry-run without saving changes.

Use staging for larger repairs, and keep the backup until your live tests pass.

Step 3. Repair Themes, Plugins, and Affiliate Embeds

If the request survives the settings and database fixes, inspect the code producing it. Keep this focused on the URL you found.

Find Hardcoded Theme and Plugin URLs

Through SFTP or your host’s File Manager, search theme files such as header.php, footer.php, and functions.php for the insecure hostname.

A hardcoded HTTP reference can override otherwise correct settings. Theme scripts and styles should use wp_enqueue_script() and wp_enqueue_style() with HTTPS sources. Protocol-relative sources inherit the page’s scheme, though explicit HTTPS is clearer.

Make custom theme changes in a child theme. Avoid editing third-party plugin files directly, because updates can overwrite your repair. Use its settings or supported customization method instead.

If a plugin is responsible, troubleshoot WordPress plugin conflicts on staging rather than disabling live redirect tools. If HTTPS enforcement causes a redirect loop, check for competing rules in .htaccess, your host, CDN, and plugins. Confirm that proxy scheme detection is correct. Review HSTS only after your hostnames and HTTPS configuration work reliably.

Update Embeds Without Breaking Tracking

For affiliate banners, pixels, and iframes, use the network’s current HTTPS embed code. Don’t assume changing the scheme works for every external endpoint.

Preserve affiliate IDs, sub-IDs, click IDs, and other required parameters. Signed tracking URLs may also depend on their original structure.

Really Simple SSL’s mixed-content fixer can rewrite insecure references during page output without repairing the stored database values. I recommend treating that as temporary relief while you fix the source.

SSL Insecure Content Fixer is another troubleshooting option. Neither installing a plugin nor removing a warning proves your affiliate tracking works.

Step 4. Fix CDN URLs and HTTPS Redirect Conflicts

A CDN adds another place where an old scheme can survive. Compare the insecure request’s hostname with your origin hostname and CDN hostname.

If page source contains the HTTP reference, inspect WordPress or the tool generating that markup. If a stylesheet initiates it, inspect that stylesheet’s contents and builder-generated files. A cached file can reference an image that no longer exists on your server.

For Breeze users, the Cloudways mixed-content procedure uses a protocol-relative CDN URL. Set the CDN address to begin with //, replacing an existing HTTP prefix rather than putting slashes before it. Save the change, then purge the relevant caches.

Now look at HTTPS enforcement. Host settings, CDN rules, .htaccess, and plugins can duplicate or conflict with one another. Choose one primary redirect mechanism and make sure WordPress recognizes the original request as HTTPS.

Behind a reverse proxy, incorrect scheme detection can cause repeated redirects. Cloudflare Flexible mode can also conflict with an origin that forces HTTPS. Full (strict), with a valid origin certificate, avoids that particular HTTP-to-origin mismatch.

An HTTPS redirect doesn’t rewrite the HTTP resource embedded inside your page. Repair that reference too.

Before retesting, clear cache at each relevant layer: WordPress, host, CDN, builder, and browser. Then test the page in a fresh browser window.

Test the full affiliate journey, including branded redirects and required tracking parameters. If the HTTP request returns, compare its URL and Initiator in your browser’s developer tools to find what still loads it.

Step 5. Clear Caches and Test the Affiliate Journey

Once you’ve fixed the source, test what visitors receive. Your dashboard view alone isn’t enough.

Purge Every Relevant Cache

Clear WordPress page caching, optimization-plugin caches, host or server caches, CDN caches, and builder-generated CSS or files. Then clear your browser’s cached files.

In Chrome on Windows, Ctrl+Shift+Delete opens browsing-data controls. Start a fresh incognito window afterward, open the repaired page, and inspect Console and Network again.

If the same request returns, compare its URL and Initiator with your original notes. An unchanged request can point to another saved template, external script, or cache layer.

Follow Your Important Affiliate Paths

Start with your busiest reviews and paid-traffic landing pages. Click the main button, comparison-table links, and important text links on desktop and mobile.

If you use Pretty Links or ThirstyAffiliates, test the branded redirect and merchant handoff. Look for loops, wrong offers, and lost parameters at the tracking hops where they’re required. My broken affiliate link audit guide gives you a repeatable process.

Where consent controls apply, test rejection and acceptance separately. A pixel intentionally blocked before consent shouldn’t be mistaken for mixed content.

Use Google Tag Manager Preview for tag diagnostics and inspect permitted test clicks in your tracker or network. Don’t create unauthorized purchases or false conversions. A recorded outbound click doesn’t prove a commission.

Key Takeaways for Affiliate Site Owners

• Find the exact insecure request before changing settings or tracking code.
• Repair stored URLs with serialization-aware tools, a backup, and a dry run.
• Test the visitor’s complete path after clearing caches, including redirects and required tracking parameters.

A clean-looking page is only part of the result. Your buttons, embeds, and tracking need to work too.

Frequently Asked Questions About WordPress Mixed Content

Can I Fix WordPress Mixed Content Without a Plugin?

Yes. Update your WordPress addresses, repair saved content, and replace hardcoded HTTP references in the source that generates them. WP-CLI can handle database replacements without a WordPress repair plugin.

For third-party resources, use a working HTTPS endpoint or remove the insecure embed. HTTPS enforcement alone won’t repair an external script that only supports HTTP.

What If the WordPress Mixed Content Warning Returns After Clearing Cache?

Look for another source producing the same URL. Global builder templates, shared widgets, generated stylesheets, and affiliate scripts can reintroduce it.

Also distinguish malformed addresses from mixed content. An address beginning with httpss:// is a saved typo or copied-code error. Correct the setting or embed containing it. Installing another SSL certificate won’t repair that spelling.

Keep the Secure Page and Tracking Working Together

The quickest useful fix of a WordPress mixed content warning starts with the exact HTTP request. Repair its source, clear the relevant caches, and repeat the same browser test.

Then follow your affiliate links and confirm the required IDs survive their tracking hops. That’s the result you want: a secure page with a working affiliate journey, ready for your traffic.