HTTPS is enabled—so why does the browser still call the site insecure?

The certificate was installed and the home page showed a padlock. Hours later, some payment confirmations failed and an internal page displayed a security warning. The site looked like HTTPS, but images, an API request and the payment callback still used HTTP.

Treat migration as three connected layers: certificate and server, resources inside the page, and external signals such as canonicals, sitemaps and internal links. Passing one layer does not prove the others are healthy.

Identify the class of failure first

Check expiry, hostname and certificate chain, then inspect browser Console and Network for HTTP resources. Renewing a certificate cannot fix mixed content; the resource URL must change.

In WordPress, site settings, old content, generated CSS and CDN caches can each retain the previous URL. A blind database replacement can damage serialised values.

Choose one final destination

HTTP, HTTPS, www and non-www variants should reach the chosen host in one hop. Chains waste time and complicate canonical interpretation.

Internal links, sitemap entries and canonical tags should already use HTTPS. Redirects catch old arrivals; they do not replace a clean internal architecture.

Test sensitive paths separately

Login, forms, uploads, APIs, webhooks and payment returns may follow special rules. After enforcing HTTPS, test these paths with logs and a real browser—not only the home page.

Enable HSTS only after every included subdomain has reliable HTTPS. A premature HSTS policy is not easy to undo for returning browsers.

Final checks

• Certificate, hostname and chain are valid.
• Key pages make no HTTP requests.
• Every host variant reaches the destination in one hop.
• Canonical and sitemap URLs use HTTPS.
• Login, API and payment flows pass after the change.

Official reference: Google guidance for URL moves