Should I scan before or after launch?

Before. Catch public gaps while you still have time to fix them without customers watching.

Which domain should I scan?

The production hostname customers will use. Not localhost, not a staging URL, not an old preview link.

Is an outside-in scan enough before launch?

It is the right first pass. It catches the public gaps buyers and attackers can already see. Deeper testing comes later if you need it.

How long does the scan take?

About 60 seconds. Fix the top failures, then rescan to confirm the score moved.

Website security scan checklist before launch

Why run a security scan before launch?

Your site can work perfectly in staging and still look bad from the outside. Missing security headers, weak TLS, broken email auth, and exposed services are common on first launches.

Buyers and security-conscious users check public signals before they sign up. A low score on a quick external scan is easier to fix before launch than after a customer asks about it.

What is on the website security scan checklist?

Scan your production domain, not localhost or staging.
Check TLS and certificate health on the live hostname.
Review security headers on deployed responses.
Verify DNS records for dangling or misconfigured entries.
Check email authentication (SPF, DKIM, DMARC) for the domain you send mail from.
Look for public exposure signals that should not be internet-facing.
Rescan after fixes to confirm the score moved.

RedScore runs the outside-in pass in about 60 seconds. No credentials, no repo upload, no invasive testing. See the website security scanner page for what each category covers.

How do I run the checklist?

Go to /lookup and enter your production domain. Read the category grades and fix-first summary. Work through the failures in order.

For specific checks, use the matching tool pages as secondary context: SSL checker, DNS checker, DMARC checker, and port scanner.

What should I fix first?

Start with the failures that are easiest to fix and most visible to outsiders:

TLS and certificate problems.
Missing security headers (HSTS, CSP, X-Frame-Options).
Weak or missing email authentication.
DNS records pointing to dead services.
Anything flagged as publicly exposed.

Fix the top items, deploy, wait for DNS to propagate, then rescan from /lookup.

What is this checklist not?

It is not a source-code review. It is not an authenticated app test. It is not a pentest.

It is the public posture check that catches embarrassing gaps before your first customer, investor, or security questionnaire arrives. Book deeper testing later if your product handles sensitive data or you need active exploitation testing.