Menu
πŸ”’
Technical SEO Β· Security

An SSL Certificate Doesn't
Fix the URLs You Hardcoded Years Ago

The padlock in the address bar says the server can serve HTTPS. It says nothing about the image tag from 2019 still pointing at http://, or the third-party widget that never bothered to support it. TechySEO finds every leftover HTTP reference still loading on your HTTPS pages, plus the insecure form actions and missing redirects that don't show up just from glancing at the browser bar.

The Certificate Was the Easy Part

HTTPS has been a confirmed, if minor, Google ranking signal for years, and getting the certificate installed is genuinely the easy step. The harder part is everywhere the old HTTP version of your site left fingerprints: an image tag with an absolute http:// URL baked into a CMS field, a script reference in a template nobody's touched since the migration, a third-party embed pointing at a provider's old endpoint. Browsers block or flag that mixed content, which means broken styling, JavaScript that silently fails, or images that just don't load, on a site that otherwise looks fully secured.

This is especially common on sites that migrated to HTTPS a while ago and assumed the job was done once the certificate went live. Months or years later, hundreds of these references can still be sitting there, generating "Not Secure" warnings on pages nobody's checked since the migration wrapped up.

Finding these requires actually reading every page's resources, not just confirming the server responds over HTTPS. A scan that stops at the certificate misses everything that actually causes the warning.

⚠️
Mixed Content Browsers Actually Block
Scripts and stylesheets loaded over HTTP on an HTTPS page get blocked outright, not just flagged, which breaks functionality visibly.
πŸ”“
A Form Submitting Over Plain HTTP
Whatever a user types into that form is exposed in transit. This is a real security issue first, an SEO issue second.
πŸ”„
An HTTP Version That Never Redirects
Two live versions of the same page splitting signals between them, instead of one clean HTTPS version receiving everything.
πŸ“‘
Third-Party Embeds Still on HTTP
A widget or font provider that never updated their own endpoint quietly reintroduces mixed content on an otherwise clean page.

Every Place an Old HTTP Reference Can Still Be Hiding

From links that are just untidy to resources browsers actively block.

πŸ”—
HTTP Links on HTTPS Pages
Not mixed content by itself, but a hygiene problem and a common source of unnecessary redirect hops once clicked.
βœ…
Confirms What's Already Clean
A baseline of pages correctly using HTTPS throughout, so the issues list isn't the only thing you see.
⚠️
Active Mixed Content
Scripts or stylesheets loaded over HTTP on an HTTPS page, the kind browsers block outright rather than just warning about.
πŸ“‘
HTTP Resources From Third Parties
Scripts, fonts, iframes, and API calls from external providers still on HTTP, with the affected pages listed so you know exactly where to follow up if the provider needs contacting.
πŸ“
Insecure Form Actions
A form on an HTTPS page submitting to an HTTP endpoint. Flagged at the highest severity, since this one exposes real user data, not just a rendering glitch.
πŸ”„
HTTP-to-HTTPS Redirect Verification
Confirms the HTTP version of every key page actually 301s to HTTPS, rather than serving duplicate content on both.

How the Mixed Content Audit Runs

1
Every Resource Reference Gets Read
Script src, link href, img src, form action, iframe src, anchor href, all of it, with the protocol recorded for each one on every crawled page.
2
Active vs. Passive Gets Classified Separately
Scripts and stylesheets that browsers block outright get marked critical. Images and similar passive resources, which just generate a warning, get a high severity instead of the top tier.
3
Every HTTP URL Gets Checked for a Real Redirect
Not just assumed. A request actually goes out to confirm a 301 to HTTPS exists, rather than a soft 200 that quietly serves the old version.
4
Each Issue Comes With What to Do Next
Update the hardcoded URL, reach out to the third-party provider, or fix the server's redirect rule, whichever actually applies to that specific issue.

Security Analysis for Every Stage

HTTPS Migrations
Confirming the Migration Actually Finished
A migration "completing" usually means the certificate went live and the obvious pages got checked. The hardcoded references in templates, old CMS fields, and third-party embeds are what's left, and they're worth finding before you start building links to the new HTTPS URLs.
eCommerce
Keeping the Checkout Page Genuinely Clean
One mixed content warning on a payment page is enough to make a buyer hesitate at the exact moment you need them not to. Watching that specific page continuously catches a plugin or template update that quietly reintroduces an HTTP resource.
Enterprise
Finding the Subdomain Nobody Finished Migrating
A regional site or microsite on its own subdomain is exactly the kind of property that gets HTTPS half-implemented and then forgotten. Seeing all of them together makes it obvious which one is actually behind.

Security Analysis β€” FAQs

Someone told me to fix mixed content with a protocol-relative URL (//). Is that actually safe?
It's a real fix, but it's not magic. A protocol-relative URL just inherits whatever scheme the current page is using, so on an HTTPS page it requests the resource over HTTPS too. The catch is that this only works if the destination actually supports HTTPS. Point a protocol-relative URL at a resource that's only ever served HTTP, and it fails outright instead of falling back gracefully. Confirm the target supports HTTPS first, then it's a clean fix. Skip that check and you've traded one broken resource for another.
What's actually the difference between active and passive mixed content?
Active mixed content, scripts, stylesheets, iframes, gets blocked by the browser outright, which breaks page functionality visibly. Passive mixed content, mostly images, loads with a warning rather than a hard block, though browsers have been getting stricter about this over time too. Both get flagged, but active mixed content is the one that actually breaks something on the page.
I have a valid SSL certificate. Why does mixed content still show up?
A certificate makes your server capable of serving HTTPS. It does nothing to the absolute http:// URLs already sitting in your HTML, your database content, or a third-party embed's own code. Those keep generating mixed content until someone actually goes and updates each reference, certificate or not.
Does HTTPS actually move rankings?
It's been a confirmed ranking signal since 2014, but a lightweight one, not something that overcomes a real content or authority gap. The more practical effect is on user trust: a security warning bounces visitors before they ever read the page, and that behavioral signal matters more day to day than the direct ranking boost does.
Is this a full security scanner?
No, and it's not trying to be. This covers the security issues that actually affect SEO and user trust: mixed content, HTTPS configuration, insecure form actions. It doesn't scan for XSS, SQL injection, or application-level vulnerabilities. For that, pair this with a dedicated security scanner like OWASP ZAP.

Find the HTTP References Your Certificate Didn't Fix

Get the actual list: every leftover HTTP resource, insecure form action, and missing redirect, not just a flag that something's wrong.

No credit card required Β· Free 7-day trial Β· Cancel anytime