Verification guide

How to Check if a Website Is Secure

People ask this question for two different reasons: they want to know whether a site they are about to trust with card details looks legitimate, or they own a site and want to know whether its own configuration holds up. This guide answers both, starting from what any visitor can check in a browser.

The honest framing matters. External checks tell you whether specific protections are present and configured sensibly. They cannot tell you whether the business behind a site handles your data well, or whether its servers were compromised yesterday.

Run an external check on your website

Start with the address bar, not the padlock alone

Confirm the address begins with https:// and that the domain is spelled exactly as you expect. The padlock icon means traffic is encrypted between your browser and that server — nothing more. A fraudulent site can obtain a valid certificate in minutes, so a padlock is a minimum bar rather than a mark of trustworthiness.

Look carefully for lookalike domains: an extra hyphen, a swapped letter, or a familiar brand name sitting on an unfamiliar suffix. Typosquatting is one of the cheapest attacks there is, and browsers will happily show a padlock on a convincing fake.

Inspect the certificate itself

Click the padlock and view the certificate. Check that the name on it matches the site you are visiting, that it has not expired, and that it was issued by a certificate authority your browser trusts. If the browser warns about a name mismatch or an untrusted issuer, treat that as a stop signal rather than something to click through.

If you own the site, also check how the certificate is renewed. Most outages caused by certificates are simply missed renewals, and automated renewal removes that whole class of problem.

Check how HTTPS behaves, not just that it exists

Visit the plain http:// version of your own site and confirm you are redirected to HTTPS. Then check whether Strict-Transport-Security is present, which tells browsers to refuse plain-HTTP connections in future. A site that serves both protocols indefinitely leaves visitors on whichever one a link happens to use.

Also look for mixed content — pages served over HTTPS that load images, scripts or stylesheets over HTTP. Browsers block or downgrade some of this, and the rest weakens the protection you thought you had.

Look at the security headers a site returns

Response headers are publicly visible and quick to review. Content-Security-Policy limits where scripts may load from, X-Content-Type-Options stops content-type guessing, and X-Frame-Options or frame-ancestors controls who may embed your pages. Their absence is not proof of a vulnerability, but their presence shows someone has considered browser-side attacks.

Headers are configuration, so they drift. A hosting change, a new CDN or a plugin update can silently drop one, which is why re-checking periodically is more useful than checking once.

Check DNS and email records for the domain

For a domain you own, review the public DNS records: where the site points, which nameservers are authoritative, and whether stale records still resolve to services you no longer run. Then check SPF, DKIM and DMARC, because a domain without email authentication is easier to impersonate in invoice fraud.

These records are open to the internet by design, which is exactly why an outside check is meaningful — anyone assessing your business can already read them.

Know what these checks cannot prove

An external review does not log in to your systems, read your application code, or test business logic the way a human tester would. ScoutLab's Free Scan, Deep Scan and Monitoring assess externally visible website and domain signals. They do not perform malware or blacklist detection, they are not a manual penetration test, they do not provide compliance certification, and no scan can guarantee a website is secure.

Used properly, external checks give you an evidence-based list of things to fix or investigate. Anything beyond that — code review, authenticated testing, incident response — needs a person with access.

Check your website's external security signals

The Free Scan reviews publicly visible website and domain signals and returns findings to investigate. It does not detect malware or blacklisting, does not replace a manual penetration test, and does not guarantee security.

Run the free website security check

Continue with ScoutLab

Website vulnerability assessmentA deeper external assessment of your website's publicly visible attack surface.

Website security monitoringScheduled external checks so configuration drift and new exposure are noticed.

Keep reading

Website security for small businessThe hub guide covering the foundations behind every check on this page.

Website security checklistWork through the practical checks in order and record who owns each one.

Small business website securityOwnership, HTTPS, DNS, headers, updates and backups for a business website.

Frequently asked questions

Does a padlock icon mean a website is safe?

No. The padlock only means the connection is encrypted. A fraudulent website can obtain a valid certificate easily, so you still need to check the domain name carefully and consider whether the business itself is legitimate.

Can I tell if a website has been hacked just by looking at it?

Usually not. Compromises are often deliberately quiet. External checks can reveal weak configuration and exposed services, but confirming a compromise requires access to server logs, files and accounts.

How often should I check my own website's security signals?

Check after any hosting, DNS, platform or supplier change, and on a regular schedule otherwise. Configuration drifts over time, so a single point-in-time check goes stale quickly.

Security references

Website security is layered. External checks can surface useful public signals, but secure development, patching, access control, backups and appropriate testing remain separate responsibilities.