DNS, SSL, and HTTPS are the three things every visitor's browser checks before it renders a single pixel of the site — and they're also the three things that get the least attention at launch, because when they work, nothing visible happens. When one of them is misconfigured, the failure mode ranges from a scary browser warning to the site simply not resolving for half your visitors. This is the checklist to run before calling a launch done.
DNS checklist
- The domain resolves with the
wwwprefix and without it — pick one as canonical and make sure the other redirects to it, rather than serving duplicate content at both. - A and/or CNAME records point to the correct host, and propagation is confirmed globally using a propagation checker rather than just your own browser (your ISP or local DNS cache can show the new records before the rest of the world does).
- TTL (time-to-live) values were lowered before any DNS change and can be raised again afterward — a low TTL during the change window means mistakes propagate faster to fix, too.
- MX records (if email is hosted separately from the website) are untouched by the website DNS change — this is the single most common way a launch accidentally breaks a company's email overnight.
SSL certificate checklist
- The certificate is valid, not expired, and not self-signed — browsers block or heavily warn on self-signed certificates for public sites.
- The certificate covers the exact domain and subdomains in use (a certificate for
example.comdoesn't automatically coverwww.example.comunless it's issued as a wildcard or multi-domain certificate). - The intermediate certificate chain is installed completely — a missing intermediate certificate is the classic case where a site looks fine in Chrome but throws a trust error in Safari or on older devices.
- Auto-renewal is configured and confirmed (most modern certificates, including free ones like Let's Encrypt, renew every 60-90 days) — a certificate that isn't set to auto-renew is a guaranteed future outage.
HTTPS enforcement checklist
- Every HTTP URL (with and without
www) 301-redirects to the HTTPS version — not a 302, and not left to load over plain HTTP at all. - The HSTS (HTTP Strict Transport Security) header is set, telling browsers to only ever connect over HTTPS for this domain, even if a user manually types
http://. - No hardcoded
http://links exist in the HTML, CSS, or third-party embeds — these cause mixed-content warnings and, in stricter browsers, get silently blocked. - The redirect chain is a single hop: HTTP → HTTPS, not HTTP → HTTP www → HTTPS www through multiple redirects, which slows every single page load.
| Symptom | Likely Cause | Fix |
|---|---|---|
| "Not Secure" warning in the address bar | No SSL certificate, or HTTPS not enforced site-wide | Install a certificate and force HTTPS redirects on every route |
| Certificate error only in some browsers | Incomplete intermediate certificate chain | Reinstall the full certificate bundle, not just the leaf certificate |
| Mixed-content warning / broken padlock | An asset (image, script, embed) still loads over plain HTTP | Update every hardcoded http:// reference to https:// |
| Site works with www but not without (or vice versa) | Missing redirect between the www and non-www versions | Pick one as canonical, 301-redirect the other |
None of this is exotic work — it's a 15-minute check with the right tools. The reason it makes every pre-launch checklist anyway is that a DNS or SSL mistake doesn't show up as a bug report; it shows up as visitors who simply can't reach the site, silently, with no error logged anywhere on your end. This is also foundational to the rest of a launch checklist — a site that fails HTTPS enforcement will fail security header checks and can suppress conversion tracking, so it's worth confirming this layer before moving on to the rest of the infrastructure.
FAQ
How do I check if my SSL certificate is set up correctly?
Load the site in a browser and confirm the padlock icon shows no warnings, then check the certificate chain with a tool like SSL Labs' SSL Test — it flags an incomplete intermediate certificate chain, an expiring certificate, or a certificate that doesn't match the domain, all of which look fine in some browsers but fail in others.
- A certificate that looks fine in Chrome can still fail in Safari or on older Android devices if the intermediate chain is incomplete.
- Check the expiry date and auto-renewal status, not just current validity — a certificate that isn't set to auto-renew will eventually cause an outage.
Why does my site show mixed-content warnings after adding SSL?
Mixed-content warnings happen when a page loaded over HTTPS still requests an image, script, or stylesheet over plain HTTP — usually from a hardcoded http:// URL in the HTML, CSS, or a third-party embed. Fix it by changing every hardcoded asset URL to https:// or a protocol-relative path.
- Third-party embeds (old widget code, ad tags, analytics snippets) are the most common hidden source of mixed content.
- Browsers increasingly block mixed-content resources outright rather than just warning, so a fixed padlock issue can also fix a silently broken page element.