You finally moved your site to HTTPS. The padlock shows up, you open a page to admire it, and then Chrome flags it: your page was loaded over HTTPS but requested an insecure script. Your stomach drops. Is the site hacked? Did the new certificate break something?
Relax. This warning is common after an HTTPS move. It’s a WordPress mixed content issue: your page uses HTTPS, but a resource still points to HTTP.
You don’t need to replace every HTTP link you can find. You only need the one request that failed, and you can usually fix it without touching your certificate.
TL;DR: This warning usually comes from one old HTTP link, not a broken certificate or a hacked site. Find the blocked URL in Chrome’s Console, trace it to its source, and switch it to HTTPS after backing up. Then clear your caches and test the features your visitors use.
Is your site hacked?
Almost certainly not. Chrome is protecting your visitors by refusing to run an insecure script on a secure page. It’s a safety check, not a sign of an attack. The blocked script can still cause real trouble, though:
- Menus and sliders stop responding
- Forms and buttons fail without any message
- Checkout or login can break completely
- Visitor trust drops when a “Not secure” label appears
A padlock and this warning can appear together. The padlock confirms the connection is encrypted, while the warning says one item inside the page still asks for HTTP. If you want a second opinion, you can scan WordPress for malware while you work through this.
📝 Note: Look at where the blocked URL points before you worry. An address on your own domain is almost always an old setting, while an unfamiliar outside domain deserves a closer look.
Find the one link that failed
The browser already knows which request failed, so let it show you. Open the affected page in Chrome, right-click, and choose Inspect. Then open the Console tab. Chrome lists each blocked request with its full address and whether it was a script or a stylesheet. If the blocked resource is a stylesheet and your layout looks broken, follow the checks for WordPress not loading CSS over HTTPS.
Copy that full URL, including the http:// part, the hostname, and the path. You’ll need it for every step that follows.
On a clean WordPress 6.9.4 test site, we loaded one script and one stylesheet over HTTP from an HTTPS page. Chrome blocked both and named each URL, so we switched both references to HTTPS, reloaded in a fresh tab, and the Console showed zero errors and zero warnings.
📝 Note: Backup your site before you edit anything. A full copy of your files and database gives you a clean way back if a change goes wrong.
Track down where the link lives
Once you have the URL, its hostname usually tells you where it came from. Work through these four sources in order:
- Your domain, across the whole site: Go to Settings > General and check that the WordPress Address and Site Address both use HTTPS. Also check wp-config.php for WP_HOME and WP_SITEURL, since those constants override what the dashboard shows.
- Your domain, on one page or post: The link is stored in the content. Edit that post, page, or widget, and swap the HTTP address for its HTTPS version.
- Your domain, in theme or plugin code: Look in header.php, footer.php, and functions.php under Appearance > Theme Editor. Make edits in a child theme so theme updates don’t wipe them out.
- An outside domain: Check the vendor’s website for an HTTPS address. Update it only if the vendor supports secure connections. If it doesn’t, you may need to replace that service.
📝 Note: A redirect from HTTP to HTTPS doesn’t count as a fix. Browsers can block the original HTTP request before the redirect ever helps, so change the source URL itself.
Fix it with the smallest change
Start with the narrowest fix that matches the source. Edit the content if the link lives in content, and edit the theme if it lives in the theme. Save bulk changes for when the same URL appears across the database, because those are harder to undo.
For many links at once, the SSL Insecure Content Fixer plugin offers five levels:
- Basic: Handles simple issues, and suits most sites
- Content: Fixes your main page content
- Widgets: Targets widget content
- Capture: Makes a deeper fix across the site
- Capture All: Fixes everything, so keep it as a last resort
Start with Basic, save, and test. Move up only if the warning remains, because each higher level reaches further into your site.
If you’d rather run a sitewide scan first, the free WhyNoPadlock tool crawls your pages and reports which ones trigger the warning. Really Simple Security, a plugin that can also convert your URLs to HTTPS automatically, helps when the problem spans the whole site. Before you install either, check its update history and WordPress compatibility, since an abandoned plugin can create a new problem while it fixes the old one.
If you’re unsure which tool suits your setup, compare WordPress SSL plugins by the HTTPS problem you need to solve.
📝 Note: A Content Security Policy with upgrade-insecure-requests can ask browsers to upgrade HTTP requests automatically. It’s a useful temporary safety net, but the old links are still in your code, so don’t stop there.
When the warning refuses to leave
If the warning sticks around after your fix, the cause is often an old copy rather than a missing change. Clear your caches in this order: your WordPress caching plugin, any CDN or proxy cache, and then your browser. Caches can hold the old page long after the source is corrected.
Reload the page in a fresh tab with DevTools open. If the same HTTP address still appears, another layer may be serving an old version. Check these three places first:
- Your page builder, which may store its own copy of the content
- Your asset optimizer, which may combine and cache old files
- Your tag manager, which can load outside scripts on its own
If an unfamiliar domain keeps showing up, stop making changes and bring in a qualified WordPress administrator or security specialist.
📝 Note: Clearing the cache before you locate the source can make the problem look solved when it isn’t. Find the URL first, then clear caches to confirm the result.
Check that it’s really gone
A clean Console is the first sign of success, but it isn’t the whole story. A blocked script can fail quietly while the page looks fine, so test the parts of the site your visitors use:
- Menus and buttons respond when clicked
- Forms submit and show a confirmation
- Embeds and fonts display correctly
- Checkout or login works, if your site has them
Finally, load the page through its public address, not a preview link. If the warning only showed up while you were logged in, log out and check again.
📝 Note: A silently broken button can cost you more than the warning did. Test the features that bring in visitors and money first.
Stop the warning coming back
Most repeat warnings come from new content, updates, or migrations that bring old links back. A few habits keep the problem from returning:
- Use HTTPS in every new link, and check new embeds in DevTools before launch
- Renew your SSL certificate early, since an expired one pushes visitors back toward HTTP
- Force HTTP to HTTPS in WordPress with a permanent redirect, so visitors using old HTTP addresses land on the secure version.
- Recheck after every update or migration, because those changes often reintroduce old links
HTTPS protects data in transit. For protection against malware, vulnerable plugins, and login attacks, follow these WordPress security practices.
📝 Note: One old link can break the secure connection for an entire page. A quick DevTools check after each change catches it before your visitors do.
FAQs
Does this warning mean my site has been hacked?
No, it usually means an old HTTP link is still in your code, content, or settings. Treat it as a security issue only if the domain is unfamiliar or the change appeared without your action.
How long does the fix take?
Most fixes take minutes once you know the source. Stored content and theme code take longer to check, and caching or third-party issues can add time.
Do I need a new SSL certificate?
Usually not. Your certificate can be valid while a page still loads one HTTP resource, so focus on the blocked URL. If your host confirms the certificate is missing or incorrectly installed, follow the steps to install an SSL certificate on WordPress.
Can a plugin fix this automatically?
Often, yes, for common WordPress links. It may miss outside resources or cached files, so check the Console and test the page afterward.
Who should fix it if I can’t access the code or database?
Ask whoever manages your hosting, CDN, or WordPress site to make the change. Send them the blocked URL, the page where it appears, and a screenshot of the Console message.
Conclusion
This warning is usually caused by one outdated HTTP link, not a broken SSL certificate or a hacked website. Find the blocked URL in Chrome’s Console, locate its source in your WordPress settings, content, theme, plugin, or third-party service, and replace it with HTTPS after backing up your site.
Then clear your caches and test important features such as menus, forms, logins, and checkout. If the warning remains or the domain looks unfamiliar, contact your hosting provider or a qualified WordPress security expert.
