More fixes

WordPress site says "Not Secure"

Visitors see "Not Secure" next to your address, a padlock with a line through it, or a full red page saying "Your connection is not private". Customers leave at that page, and contact and checkout forms look unsafe. There are four usual causes, and one look at the certificate tells you which. Below is a rebuilt example (not a real client), that look, and the fix for each answer.

First: look at what the browser is complaining about

1. Read the address. If it starts with http:// (no "s"), the page was not loaded securely at all. Type the same address with https:// in front and see what happens: a working page means you only need a redirect; a red warning page means the certificate is the problem.
2. On the red warning page, read the small code under the message. NET::ERR_CERT_DATE_INVALID means the certificate expired. NET::ERR_CERT_COMMON_NAME_INVALID means it was issued for a different name (often example.com but not www.example.com, or the hosting company's own name). ERR_CERT_AUTHORITY_INVALID means a self-made or unfinished certificate.
3. If the page loads on https but the padlock is missing or crossed out, click the icon left of the address and read "Connection is secure" or not, then press F12 and open the Console tab. Lines starting "Mixed Content" each name an image, script or font the page still loads over http://.
4. Check from a second device on mobile data. If only one computer sees the warning, its clock or its antivirus is the cause, not your site.

The causes, most common first

1. The certificate expired and did not renew. Most hosts give a free certificate (Let's Encrypt, "AutoSSL", "Free SSL") that renews itself every 60 to 90 days. Renewal fails quietly when the domain no longer points at that host (a DNS change, a moved www record, Cloudflare in front), and three months later the site goes red. In the host panel, find SSL/TLS Status or AutoSSL and run it again; it says which name failed and why. Fix the DNS record it names, then run it once more.
2. The certificate does not cover the name visitors use. It was issued for example.com and people type www.example.com, or the reverse, or the domain was added to the hosting later. Reissue it with both names ticked. If the warning names your host's server (server123.host.example), the domain has no certificate of its own yet.
3. The site never moved to https. The certificate may even be there, but WordPress still sends everyone to http://. Only after https:// loads cleanly, change both addresses under Settings, General (WordPress Address and Site Address) to https://, then add a permanent (301) redirect from http to https in the host panel or .htaccess. Do it in that order: switching WordPress to https before the certificate works can lock you out of the admin.
4. Mixed content: the page is https, some of its parts are not. WordPress stores full addresses inside posts, widgets and theme settings, so images and scripts added before the move still say http://. Browsers block or flag them and the padlock goes. Fix it with a database search-and-replace from http://example.com to https://example.com (Better Search Replace or wp search-replace), a backup and a dry run first. Then check the theme options, page builder settings and any hard-coded script (chat widget, map, old analytics) for http://. A plugin like Really Simple SSL rewrites these on the fly, which hides the problem rather than removing it.
5. Cloudflare and the host disagree. With Cloudflare's SSL mode on "Flexible", Cloudflare talks to your server over plain http, which can loop forever once WordPress insists on https. Error 526 means "Full (strict)" is on but the server's own certificate is invalid. Give the server a valid certificate, then use "Full (strict)".

The http-to-https redirect, by where the site is hosted

Once the certificate works, send every http:// visitor to https://, so nobody who types the bare address lands on the "Not Secure" copy.

• Apache / cPanel hosting (GoDaddy, Bluehost, HostGator and similar): turn on the free SSL in cPanel, then put this at the top of .htaccess, above the WordPress block:

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

• Nginx:

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

• Cloudflare: SSL/TLS, Edge Certificates, "Always Use HTTPS" (with SSL mode "Full (strict)", see cause 5).
• Wix, Squarespace, Shopify: HTTPS is a switch in the domain or SSL settings; turn it on and the platform redirects for you. The certificate and the mixed-content causes above still apply to pages you edited by hand.

What you see, what it means, what it needs

What not to do

• Do not tell customers to click "Advanced" and "Proceed anyway". Most will not, and the ones who do learn to ignore a warning that one day will be real.
• Do not change the WordPress Address to https before https actually loads. If you are already locked out, the two addresses can be set back in wp-config.php (WP_HOME and WP_SITEURL) or in the database.
• Do not run a search-and-replace without a backup and a dry run. One wrong replace across the whole database is harder to undo than a missing padlock.
• For a small business site, a paid certificate is rarely needed: the free one shows the same padlock. What matters is that it renews.

Once the warning code has told you which cause it is, the fix is usually under an hour. If you would rather hand it over, or the padlock still will not appear, that is what the box below is for. Related: "redirected you too many times", images not showing after a move and a login page that keeps refreshing (both can follow a switch to https).