HTTPS Before Launch: Certificates, Redirects and Mixed Content
The padlock is only the visible part of HTTPS. A clean production setup also needs valid certificates, consistent redirects and secure subresources. Domain changes are a common time for these pieces to drift apart.
Validate the certificate
Load the final production hostname over HTTPS and confirm the browser trusts the certificate. It should cover the hostname users actually visit and should not be expired or self-signed. Managed hosts such as Vercel can automate certificates after DNS and domain ownership are configured correctly.
Redirect HTTP consistently
Visitors and old links may still use http://. Redirect those requests to the preferred HTTPS URL. Avoid redirect chains where possible. If you also support both www and apex hostnames, choose one canonical form and redirect the other deliberately.
Find mixed content
A secure HTML page can reference an insecure image, script, stylesheet or API endpoint. Browsers may block active mixed content or downgrade the experience. Search the rendered page and developer console for http:// resource requests and update them to secure endpoints where supported.
Align canonical and social URLs
Canonical tags, Open Graph URLs, sitemap entries and internal navigation should all use the production HTTPS hostname. A certificate can be correct while metadata still points to an old staging host, creating confusing discovery signals.
Retest after DNS changes
Domain setup can appear correct from one network while DNS changes are still propagating elsewhere. After connecting a custom domain, test from more than one network, verify redirects and wait for certificate provisioning to complete before submitting the site to external crawlers or advertising review systems.
Automated checks can confirm whether a public signal exists and looks technically reasonable. They cannot replace human review of content, accessibility, security, business logic or legal requirements.
Check a website