Enforcing HTTPS site-wide: from installed certificate to full enforcement

An installed SSL certificate alone means the site can run over HTTPS - but if visitors who arrive via http:// are not redirected to https://, part of the traffic still flows unencrypted. Real HTTPS enforcement requires three steps: the WordPress site URL, a server-level redirect, and rewriting internal links in the database.

Why this matters

When the site is reachable over both HTTP and HTTPS, several harms compound: Security - passwords, session cookies and personal data sent over HTTP are readable on any intermediate network (public Wi-Fi, ISP, corporate proxy). An attacker at an airport hotspot can read the cookie of an admin signing in over HTTP and hijack the session. SEO - Google treats the same content at http:// and https:// as two different URLs. That fragments PageRank, creates duplicate content, and can hurt rankings. Google has also preferred HTTPS sites in the ranking algorithm since 2014. User experience - modern browsers (Chrome, Firefox, Safari) flag HTTP sites as 'Not Secure' with a prominent warning icon. On mobile, some browsers even render a full-page warning before loading. Bounce rates on sites marked 'Not Secure' rise by 15-25%.

How to detect

The audit issues an HTTP request to http://example.com and checks for a 301 or 302 response to https://. A 200 (content delivered over HTTP) means the check fails. Manually:

curl -I http://example.com

should return 'HTTP/1.1 301 Moved Permanently' and 'Location: https://example.com/'. Also: open the site over http:// in a browser - the URL should auto-rewrite to https://.

How to fix

1. Settings > General: confirm WordPress Address and Site Address both start with https://.
2. Add a 301 redirect at the server. Apache in .htaccess:

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

3. Nginx:

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

4. Rewrite internal links saved with http:// in the database. Easy way: install Better Search Replace. Set search='http://example.com', replace='https://example.com', tick all tables, run as dry run first.
5. If the volume looks reasonable (thousands, not millions), uncheck dry run and run for real.
6. Alternative: WP-CLI

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

7. Browse in a private window. Open DevTools (F12) > Console - 'Mixed Content' warnings should be gone.
8. If any remain, they live in theme or plugin files. Grep the codebase for 'http://' strings that should be 'https://'.

Common mistakes

Do not rely on WP_HOME and WP_SITEURL in wp-config.php without a server-level redirect - visitors who arrive directly at http://example.com/some/page still get content over HTTP. Do not run a plain MySQL search-replace (sed or UPDATE) - it does not handle serialized data, and serialized options will break. Do not keep 'Really Simple SSL' as a permanent solution - it is fine as a quick fix but adds overhead; once the database is fixed, remove it. Do not include the guid column in search-replace - that breaks RSS feeds.

Verifying the fix

curl -I http://example.com should return 301 to https. 'Why No Padlock?' (whynopadlock.com) scans for mixed content. SSL Labs (ssllabs.com/ssltest/) grades the configuration. Browse 5-10 different pages, including the admin area, to verify no resources are still loaded over http.