No HTTPS: Why It Fails Even When You "Have Nothing to Protect"

A site served over HTTP rather than HTTPS does not just receive the "Not Secure" badge in Chrome and Safari — it is exposed to traffic sniffing, MITM injection, ad insertion by some ISPs (yes, this still happens), and lower search rankings. Google has long stated that HTTPS is a ranking signal, and several Search Console features simply do not work for HTTP-only properties.

Why this matters

Even if your site is a static blog with no forms, HTTP still leaks information: any visitor on shared Wi-Fi or a corporate network can see which pages were read, which violates privacy expectations; some carriers (especially mobile) inject advertising into HTTP pages — your visitors see content you did not create; and every request to wp-login.php that was not redirected to HTTPS exposes the admin password in clear text. Commercially, sandbox APIs from PayPal, Stripe, and Google Workspace refuse to integrate with non-HTTPS origins, so checkout flows and SSO simply will not work.

How to detect

Open the site in Chrome. If the address bar shows "Not secure" or a broken lock icon, the site is on HTTP. Verify with curl -I http://example.com — if it returns 200 instead of a redirect to HTTPS, there is no SSL enforcement. External tool: https://www.ssllabs.com/ssltest/ — it grades SSL configuration (target an A or A+).

How to fix

Step 1 — install a certificate. Most hosts support Let's Encrypt for free. In cPanel: SSL/TLS Status > Run AutoSSL. In Plesk: Domains > example.com > SSL/TLS Certificates. On a managed VPS: certbot --apache.

Step 2 — change site URLs. Settings > General, switch both fields from http:// to https://.

Step 3 — update the database:

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

Step 4 — 301 redirect:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$server_name$request_uri;
}

Step 5 — resolve mixed content. Open the site in DevTools > Console; every "Mixed Content" warning points to an image, CSS, or JS still loaded over HTTP. Fix in source or add the response header Content-Security-Policy: upgrade-insecure-requests to upgrade them automatically.

Common mistakes

Mistake one: installing SSL without running search-replace. Images, menu links, and inline content links remain http://, producing Mixed Content on every page. Mistake two: skipping --skip-columns=guid. The guid field in wp_posts is meant as a stable unique identifier, not a fetch URL — rewriting it can break RSS readers that cache against guid. Mistake three: relying on Really Simple SSL alone. It is a quick fix but adds PHP overhead on every request. After a clean search-replace, you can usually remove it.

Verifying the fix

Browse the site in Chrome — the lock must be intact, with no "Not secure" or "Mixed Content" indicators. Run curl -I http://example.com — it should return HTTP/1.1 301 Moved Permanently with a Location: https://... header. Run SSL Labs and aim for A or A+. In Search Console, add the HTTPS variant as a new property and confirm indexing continues normally.