A "Not secure" warning on your website means the browser couldn't set up a private connection to it. It doesn't mean the site has been hacked. Start by checking five causes: no HTTPS or no redirect to it, a missing or expired certificate, a certificate that doesn't cover the exact address in the bar (www versus no www), insecure files loaded on an HTTPS page, or a site still configured to use http://. Several of them can be checked and fixed without changing host.
Google's Chrome help separates two warnings that look alike: "Not secure" means something is wrong with the privacy of the connection, while "Dangerous" means Safe Browsing has flagged the site as unsafe. The second one is a different problem; certificate fixes won't clear it.
Match what you see to the cause
| What you see | Likely cause | First check |
|---|---|---|
| "Not secure" next to an address starting with http:// | No HTTPS, or HTTPS works but nothing redirects to it | Type https:// in front of your domain and load it |
| A full-page certificate warning, for everyone | Certificate missing, expired, or not issued for this exact name | Look at the certificate's names and expiry date |
| The same warning on one device only | That device's date or time is wrong | Check the device clock |
| Padlock on the home page, missing or broken on some pages | Insecure images, scripts or fonts on those pages (mixed content) | Open the browser's developer console on that page |
| "Too many redirects" right after forcing HTTPS | A redirect loop, for example behind a CDN or proxy | Count how many places are doing the redirect |
| A red full-page warning about a dangerous or deceptive site | Safe Browsing flag, not a certificate issue | Treat it as a possible compromise |
Chrome's help lists a wrong date or time on the visitor's device as a cause of certificate errors, so rule that out before touching the site.
No HTTPS, or no redirect to it
Type https://yourdomain.com into the address bar yourself.
If the page loads with the padlock, the certificate works and visitors are arriving on the http:// version from old links, listings or printed material. You need a redirect from http:// to https://. Your host may have a switch for this in the control panel (Hostinger calls it Force HTTPS); otherwise it's a rule in the server configuration. Use one method, not several.
If https:// fails or shows a certificate warning, go to the next section.
Certificate missing or expired
Click the icon next to the address and open the certificate details. Two things matter: the dates it's valid between, and the names it was issued for.
If the certificate has expired, find out why it wasn't renewed. Free certificates are short-lived on purpose: Let's Encrypt's default certificates last 90 days and it recommends renewing every 60, so hosts that issue them renew them in the background. Check your host's conditions for that renewal; Hostinger's, for example, require the domain to still point to it. If you moved the DNS somewhere else, or put another service in front of the site, renewal can stop without anyone noticing until the certificate runs out.
Before buying a certificate, check whether your hosting plan already includes one. A paid certificate fixes nothing if the real problem is a redirect or mixed content.
The certificate doesn't list the exact name
A browser compares the name in the address bar with the names listed in the certificate. If none matches, it warns the user and stops the connection; the TLS standard, RFC 9525, describes exactly that behaviour. "Close enough" doesn't count:
example.comandwww.example.comare two different names. A certificate for one doesn't cover the other.- A wildcard certificate for
*.example.comcoverswww.example.comandshop.example.com, but notexample.comitself.
A redirect can't save you here. The browser checks the certificate before it ever sees a redirect, so if someone types www.example.com and the certificate only lists example.com, they get the warning. The fix is a certificate that lists every name people use, such as both the bare domain and www, plus any subdomain you link to. Ask your host to issue or reissue the certificate for both names, and make sure both names point to the host.
Padlock on some pages but not others: mixed content
If the home page has a padlock and a blog post doesn't, the post is probably loading something over http://: an image inserted years ago, an embedded video, a font or a script from another site.
According to MDN's guide to mixed content, browsers now handle these in two ways:
- Plain images, audio and video are switched to https:// automatically. If the file isn't available over HTTPS, it simply doesn't load, so you see a missing image.
- Scripts, stylesheets, iframes and fonts are blocked. The page may look unstyled, a booking widget may disappear, or a form may stop working.
To find the culprits, open the page, open the browser's developer tools, and look at the console: blocked and upgraded requests are listed there with their full http:// address. Then fix them where they come from: the post or page editor, theme settings, a page builder widget, or a hard-coded link in a footer. If hundreds of old posts are affected, take a backup and ask your host or developer to replace the links in bulk.
Redirect loops after forcing HTTPS
"Too many redirects" can mean two things are redirecting and disagreeing. Two setups that cause it:
- Several redirects stacked. The host's Force HTTPS switch, a rule in .htaccess and a WordPress plugin all try to do the same job. Keep one and remove the others.
- A CDN or proxy in front of the site. The visitor connects to the CDN over HTTPS, but the CDN talks to your server over plain HTTP. The server sees an HTTP request, redirects to HTTPS, and the cycle repeats. One fix is a setting in the CDN that makes it connect to your server over HTTPS. WordPress's own HTTPS documentation describes this loop behind reverse proxies and the server-side fix for it; that part is a job for whoever manages the server.
WordPress still thinks it lives at http://
WordPress stores two addresses under Settings, General: the WordPress Address (where the WordPress files live) and the Site Address (what visitors type). Both should start with https:// and have no slash at the end, according to WordPress's guide to changing the site URL. If they still say http://, WordPress keeps generating http:// links and you get mixed content or redirect trouble.
Change them in Settings, General only once https:// already loads correctly. The WordPress guide warns that a wrong value there can break the site and leave you with no easy way to correct it. If that happens, or you'd rather not risk it, add both values to wp-config.php instead:
define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );
Use your own address (if WordPress sits in a subfolder, WP_SITEURL includes it). The guide calls this hard-coding rather than the best fix, and the two fields in Settings stop being editable while the lines are there. It's still safer than editing the database, which you don't need to do for this.
Leave HSTS alone until HTTPS is stable
HSTS is a setting that tells browsers to use only HTTPS for your site, for as long as you specify, for example a year. Once a browser has seen it, MDN notes, visitors can no longer click past a certificate error. If your certificate then expires or misses the www name, people can't reach the site at all until it's fixed. Don't turn HSTS on until your certificate has renewed by itself at least once and covers every name you use. Skip the "preload" option too: MDN lists its requirements as a policy of at least a year that also covers every subdomain.
Before you change hosting, check these
Moving host only helps if the host was the problem. Check first:
- Your domain points where you think. The A record for both the bare domain and www should point to your current host. A certificate your host issues may depend on this; Hostinger's does.
- The certificate covers both names, and any subdomains you use.
- Expiry date and renewal. Is auto-renewal switched on in your hosting panel, and has it worked before?
- WordPress addresses use https://.
- Mixed content on the pages that show the problem.
A new host won't fix items 4 and 5; they travel with the site. If you do move, the hosting move guide includes turning on HTTPS at the new host and checking the padlock on each type of page.
A host that includes and renews the certificate
The least maintenance is a host that issues and renews the certificate for you. Hostinger, for example, includes SSL at no extra cost on its Web, Cloud and Agency hosting plans and renews it automatically, with a Force HTTPS switch in its control panel. The condition is the same one that breaks renewals elsewhere: the certificate is issued only once the domain points to Hostinger and DNS has updated, which can take 24 to 48 hours, and it keeps renewing only while the site is hosted there and the domain still points to it. An included certificate doesn't fix mixed content or wrong WordPress addresses; those are still yours to check.