Custom website development: HTTPS is configured, but the client's mobile browser still says not secure—what is usually wrong?

Opening conclusion: After custom website development is delivered, a browser warning saying “not secure” is usually not something a single SSL certificate purchase can fully solve. Based on 2026 project delivery experience, the warning corresponds to at least three layers: the certificate layer (not installed, expired, domain mismatch, incomplete certificate chain), the content layer (the page still references http images, scripts, fonts, or iframes), and the renewal layer (automatic renewal did not take effect, or no one manages expiry). Locate the layer first, then decide whether to add a certificate, change resources, or switch renewal method. In the typical range, this saves more rework than directly buying extra certificates.

What the browser means by “not secure”

The “not secure” label in the address bar is the result, not the cause. It means the current page is not connected through HTTPS, or part of the page still loads over http. HTTPS relies on an SSL/TLS certificate for encryption and identity verification. The certificate is issued by a trusted certificate authority and is bound to a specific domain during its validity period. When visitors see the padlock icon, it only means the browser accepts the basic identity of this connection; when http resources are mixed into the page, the padlock may disappear or become a gray exclamation mark.

Do not check only the homepage. If any step—login page, form page, admin entry, payment redirect page—uses http, the browser may show a warning. A common 2026 practice is: first look at the padlock icon in the address bar, then press F12 to open the developer tools Console and Network, filter for Mixed Content and http links, and narrow the issue down to specific pages and specific resources.

• Certificate layer issues: The certificate is not installed, has expired, is bound only to www while visitors use the bare domain, or lacks intermediate certificates in the chain.
• Content layer issues: Images, CSS, JS, fonts, videos, or iframes on the page still use http addresses.
• Renewal layer issues: The certificate is not automatically renewed before expiry, or after renewal it is not reloaded onto the server.

Certificate, mixed content, renewal: three-layer troubleshooting order and cost comparison

Splitting troubleshooting into three layers makes sense because the people and costs involved differ. The certificate layer is generally handled by operations or the website builder; the content layer often goes back to page code and asset links; the renewal layer involves account ownership and reminder mechanisms. Check the certificate layer first to quickly rule out “no encryption at all”; then check the content layer to solve “encrypted but the page still warns”; finally check the renewal layer to avoid the same issue appearing again a few months after launch.

1. Certificate layer check: Confirm the certificate is installed, within its validity period, domain-matched, and has a complete chain. The pass standard is that the address bar shows a padlock icon, and when clicked, the certificate information matches the visited domain.
2. Content layer check: Use developer tools to filter Mixed Content and check images, scripts, styles, fonts, and iframes page by page. The pass standard is no mixed content warnings in Console and no http resources in Network.
3. Renewal layer check: Confirm whether auto-renewal is enabled, whether there is a reminder before expiry, and whether a manual reload is required after renewal. The pass standard is receiving an alert at least 30 days before expiry and having a clear responsible person.

On cost, certificate layer troubleshooting is commonly a few minutes to ten-plus minutes, while handling installation or chain completion is commonly tens of minutes to a few hours; content layer page-by-page cleanup is commonly tens of minutes to half a day, and may reach a day when there are many pages and external images; if auto-renewal fails, handling it on the expiry day may cost a morning of emergency work plus brief visitor inaccessibility. These are experience ranges, depending on site scale and number of resources. Free DV certificates are commonly CNY 0 to a few hundred per year; paid OV certificates are commonly a few hundred to several thousand CNY per year, subject to the provider's current rules.

Applicable and non-applicable boundaries: which sites must have it, and which can wait

If a website includes login, registration, inquiry forms, payment, member center, admin management, or external APIs, HTTPS should basically be a must-do before launch, because these pages transmit accounts, passwords, contact information, or transaction information. By 2026, even purely presentational corporate websites generally default to HTTPS, mainly not for encryption but to avoid the “not secure” browser warning affecting visitors' first impression. Conversely, a fully isolated internal test environment or a temporary demo page seen by only a few internal people can wait, but it is still advisable to complete HTTPS before formal external use.

The boundary should be clear: HTTPS cannot replace server security hardening, cannot replace login permission control, and cannot solve a page being injected with malware. It solves transport link encryption and basic identity verification. If a website is compromised or tampered with, installing a certificate will not make the page clean again.

• Suitable for priority HTTPS: Sites with forms, login, payment, membership, admin, or third-party API integration.
• Recommended to add at the same time: Purely presentational sites, brand official websites, and campaign pages, to avoid browser warnings affecting clicks and conversion.
• Can wait: Temporary environments that are fully internal, not externally accessible, and do not transmit sensitive information.
• Cannot be solved by certificates: Server vulnerabilities, weak passwords, malware injection, content tampering, and similar issues.

Delivery reality: one certificate expiry and dozens of http resources causing rework

A common project situation: the client's budget is tight, so they choose hosting without auto-renewal, and the assets still keep many external image links. Testing during development is all normal. After launch, one day the certificate expires, the browser blocks directly, visitors think the website has been hacked, and the team urgently renews and then goes back to clean dozens of http image links, spending an extra half day to a day on rework. This kind of cost is usually not caused by technical difficulty, but because renewal responsibility and resource standards were not clearly written into the delivery checklist.

To reduce this kind of rework, verify three things at delivery: who owns the certificate account, whether auto-renewal is effective, and whether any http resources remain sitewide. To judge whether a site's HTTPS is properly done, check four criteria: no warning in the address bar, no mixed content in Console, certificate domain consistent with the actual visited domain, and an executable reminder mechanism before expiry.

• Bound to www only: Visitors entering the bare domain may still get an error. A common practice is to resolve both and cover both in the certificate.
• Auto-renewal silently fails: If there is no alert, no one knows until the expiry day.
• CDN and origin certificate mismatch: The edge certificate is normal but the origin certificate expired, which can also cause intermittent warnings.
• Third-party embedded content: If maps, videos, or analytics scripts use http, they can also trigger mixed content warnings.

FAQ

For custom website development, should the development company buy the SSL certificate or should I buy it myself?

Both are common. Buying it yourself has the advantage of keeping the account and renewal in your hands; at delivery, have the developer complete installation and debugging. If the developer purchases it on your behalf, write certificate ownership and renewal responsibility into the delivery checklist.

Will browsers treat free SSL certificates differently from paid ones?

Mainstream browsers show a padlock for sites with a valid certificate chain. The differences are mainly validation level, validity length, and after-sales support; sites with payment or login are better advised to use a plan with renewal reminders.

After the site launches, it says “not secure,” but the certificate is clearly within its validity period. Why?

It is most likely that the page still references http images, scripts, or fonts, creating mixed content; it may also be that the certificate is bound only to www while the visitor is using the domain without www.

The website only has a few presentational pages. Is it okay not to install HTTPS?

Technically it can open, but in 2026 browsers mark http pages as “not secure,” and form submissions also show risk prompts. For a presentational site, a basic DV certificate is not expensive, so it is usually recommended.

If the website has forms, login, or payment, check the certificate layer and mixed content before launch; for a purely static presentational site, it is also recommended to at least configure a DV certificate with auto-renewal and write renewal responsibility into the delivery checklist. The prices and periods in this article are experience ranges; refer to the provider's rules and the actual environment. Following enterprise project delivery habits, we usually check certificates, resource links, and renewal reminders before launch, and then arrange acceptance.