When a website shows “Not Secure” in the browser, it can scare visitors and reduce trust in your business. A customer who opens your website and sees a warning may think the website is fake, broken or unsafe for entering information. For a business, school, church, NGO, blog or online shop, SSL and HTTPS are essential for trust and for protecting communication between the user and the website.
SSL stands for Secure Sockets Layer, although modern systems mostly use TLS. In simple terms, SSL/TLS encrypts the data moving between the browser and the server. This helps protect information such as login details, contact forms, payment data, cookies and other data exchanged between the user and the website.
HTTPS is the secure version of HTTP. A normal website may open as http://example.com, but a secure website should open as https://example.com. The “S” means secure. Most browsers show a lock icon when the certificate is valid. If SSL is missing, broken, expired or the page has mixed content, the browser may show “Not Secure.”
The first reason a website shows Not Secure is that there is no SSL certificate. If your hosting has not installed an SSL certificate, the website will only open through HTTP. The solution is to install an SSL certificate through your hosting panel, cPanel, Plesk, Cloudflare or provider. Many hosting providers offer free Let’s Encrypt SSL that can be installed with a few clicks.
The second reason is an expired SSL certificate. SSL certificates have an expiry date. When they expire, browsers warn that the connection is not secure. This can happen if auto-renew fails, DNS has problems, the domain does not point correctly or hosting cannot verify the domain. Make sure SSL auto-renew is enabled and the domain points to the correct server.
The third reason is a certificate mismatch. For example, the certificate may be issued for example.com, but the user opens www.example.com. If the certificate does not include www, the browser may show an error. Similarly, a certificate for only www.example.com may not cover example.com. It is best for the certificate to include both the root domain and the www version.
The fourth reason is incorrect DNS. SSL certificates often require the domain to point to the correct server. If DNS records are wrong, SSL may fail to issue or renew. Check A records, CNAME records, nameservers and whether the domain points to the hosting provider you are using.
For example, if your website is hosted on hosting A but DNS points to hosting B, the SSL from hosting A may fail because traffic is not going there. Before fixing SSL, make sure DNS is correct.
The fifth reason is the website opening through HTTP instead of HTTPS. You may have a valid SSL certificate, but the site still opens through http:// because there is no redirect. A redirect sends users from HTTP to HTTPS automatically. Without it, someone typing the domain without https may enter the insecure version.
The solution is to force HTTPS redirect. In cPanel, you may use Force HTTPS Redirect. In Apache, you can use .htaccess. In Nginx, you can configure a redirect server block. In Django or other frameworks, you can use secure redirect settings, but the proxy and server configuration must be correct.
The sixth reason is mixed content. Mixed content happens when the main page loads through HTTPS but images, CSS, JavaScript, fonts or other files load through HTTP. The browser may show Not Secure or block some files. This can break design, icons, scripts or the lock icon.
For example, the website may open as https://example.com, but CSS loads from http://example.com/static/style.css or an image loads from http://example.com/media/logo.png. This is mixed content. The solution is to change all internal links to HTTPS or relative URLs.
In HTML, instead of writing a full HTTP link such as http://example.com/image.jpg, use /image.jpg if the file is on the same website. For external resources such as fonts, scripts or images, make sure they come from an HTTPS source.
The seventh reason is confused canonical and redirect setup. A website may have four versions:
http://example.com
http://www.example.com
https://example.com
https://www.example.com
For SEO and security, you should choose one main version. For example, choose either https://www.example.com or https://example.com. Then redirect all other versions to that main version. Without this structure, you may have duplicate content, cookie issues, login issues and SEO confusion.
The eighth reason is poor www and non-www configuration. Some websites use www, others do not. Both are acceptable, but you must choose one. If you use non-www, redirect www.example.com to example.com. If you use www, redirect example.com to www.example.com.
The ninth reason is wrong Cloudflare SSL mode. If you use Cloudflare, there are SSL modes such as Off, Flexible, Full and Full Strict. A common mistake is using Flexible without understanding it. Flexible may make the browser connect to Cloudflare through HTTPS, while Cloudflare connects to your server through HTTP. This can cause redirect loops or incomplete security.
For better security, use Full Strict when your origin server has a valid SSL certificate. Full Strict ensures that both browser-to-Cloudflare and Cloudflare-to-server connections are secure. But the origin server must have a valid certificate.
The tenth reason is redirect loop. A redirect loop happens when the browser is sent from one URL to another and back again repeatedly. For example, the server says go to HTTPS, Cloudflare sends back to HTTP, or the application redirects differently from the proxy. The browser may show an error such as “too many redirects.”
To fix redirect loops, check Cloudflare SSL mode, server redirects, .htaccess, Nginx configuration, Django SECURE_SSL_REDIRECT, WordPress settings and site URL. Do not stack many redirects without understanding how they work.
The eleventh reason is WordPress site URL being HTTP. If WordPress Address and Site Address are set to http://, the website may continue loading resources through HTTP even when SSL exists. Go to Settings, General, then change WordPress Address and Site Address to HTTPS. Before changing, make sure SSL works properly.
The twelfth reason is Django or another framework not being configured for HTTPS. If Django is behind Nginx, Apache or a proxy, proxy headers must be correct. Otherwise, Django may think the request is HTTP even when the browser uses HTTPS. This can affect redirects, secure cookies and absolute URLs.
In Django, settings such as SECURE_SSL_REDIRECT, SESSION_COOKIE_SECURE, CSRF_COOKIE_SECURE and SECURE_PROXY_SSL_HEADER can be important in production. But if used incorrectly without correct server configuration, they can create redirect loops or login issues.
The thirteenth reason is static and media links using HTTP. In many websites, CSS, JavaScript and images come from static or media paths. If your templates hardcode full HTTP URLs, HTTPS may not be complete. Change static and media URLs to relative links or HTTPS.
The fourteenth reason is insecure external scripts. If you add scripts from third-party services such as ads, analytics, chat widgets, fonts or payment widgets, make sure the script URL starts with HTTPS. One HTTP script can break the lock icon or be blocked by the browser.
The fifteenth reason is old hardcoded links in the database. A large website may have old content with HTTP image or page links in the database. For example, blog posts may contain HTTP image URLs. You may need careful search and replace to change http://yourdomain.com to https://yourdomain.com. Always make a backup before bulk replacement.
The sixteenth reason is CDN settings. If you use a CDN, make sure the CDN also has an SSL certificate and serves files through HTTPS. If the CDN serves CSS or images through HTTP, mixed content can happen. Also make sure the CDN URL uses the correct domain and matching certificate.
The seventeenth reason is browser cache. Sometimes you fix the issue but the browser still shows a warning because of cache. Try hard refresh, incognito mode, another browser or another device. You can also clear cache. But do not assume cache is the only cause; verify that the certificate and redirects are correct.
The eighteenth reason is HSTS. HSTS is a security header that tells the browser to use HTTPS only for a domain for a certain time. This is good for security, but if enabled before SSL is correct, it can lock you into broken HTTPS. Use HSTS only after SSL, redirects and subdomains are properly configured.
The nineteenth reason is subdomains. An SSL certificate for the root domain does not always protect all subdomains. example.com and blog.example.com are different. If you have subdomains such as shop, mail, app, portal or blog, make sure each has an SSL certificate or use a wildcard certificate where appropriate.
The twentieth reason is confusing website SSL and mail SSL. Website SSL is not always the same as mail server SSL. Email may use different certificates for SMTP, IMAP or webmail. If webmail shows a warning, the issue may be the mail hostname certificate. Use the correct mail server hostname provided by your provider.
The twenty-first reason is certificate chain issues. SSL certificates need intermediate certificates so browsers can verify the chain. If the chain is incomplete, some browsers or devices may show warnings. Most hosting providers handle this automatically, but if you manage your own server, you must install the full chain certificate.
The twenty-second reason is wrong server or device time. Certificates depend on date and time. If the server or user device has the wrong date, SSL may appear not yet valid or expired. If the issue appears on only one device, check that device’s date and time.
The twenty-third reason is using a self-signed certificate. A self-signed certificate can be used in development or internal systems, but public browsers will not trust it. For a public website, use a certificate from a trusted certificate authority such as Let’s Encrypt or another recognized provider.
The twenty-fourth reason is SSL on an IP address. SSL certificates are usually issued for domains, not IP addresses. If you open a website using an IP such as https://123.123.123.123, the browser may show a warning because the certificate belongs to a domain. Use the domain instead of the IP.
The twenty-fifth reason is reverse proxy settings. If the website is behind a load balancer, Cloudflare, Nginx proxy or application proxy, HTTPS headers must be passed correctly. If the app does not know the original request was HTTPS, it may generate HTTP links or incorrect redirects.
The twenty-sixth reason is insecure cookies. For login systems, cookies should use the Secure flag when the website runs on HTTPS. This helps ensure cookies are not sent through HTTP. SameSite and HttpOnly settings are also important for security. This is more advanced for developers, but important for websites with login.
The twenty-seventh reason is payment pages. If a website receives payments or sensitive information, HTTPS is required. Many payment gateways will not allow integration without HTTPS. Users should never enter card details, passwords or personal information on a page that says Not Secure.
The twenty-eighth reason is SEO impact. Search engines prefer secure websites with correct redirects. If your website has both HTTP and HTTPS versions without canonical setup, duplicate content may occur. Make sure the sitemap uses HTTPS URLs, canonical tags point to the correct version, and Google Search Console uses the correct property.
The twenty-ninth reason is testing. After installing SSL, test your website on different devices, browsers and URLs. Try http://domain, http://www, https://domain, and https://www. All should end at one secure version. Also test different pages such as homepage, blog, contact, login, checkout, images and admin.
The thirtieth reason is having a renewal plan. Do not wait until the certificate expires. Make sure auto-renew works. If you manage your own server, ensure the renewal cron job works. If you use hosting, make sure the domain points correctly so Let’s Encrypt can renew. If the certificate is close to expiry, fix it early.
In general, “Not Secure” can be caused by missing SSL, expired certificates, DNS problems, missing HTTP redirects, mixed content, wrong Cloudflare mode, www/non-www confusion or app settings. Do not fix blindly. Start with the certificate, then DNS, redirects, mixed content and browser testing.
Remember: a secure website should always open through HTTPS, have a valid certificate, redirect HTTP to HTTPS, avoid mixed content and use one main domain version. This protects users, builds trust and makes your website look more professional.