How we analyse your site
The analysis is passive: we only read what any browser or email server sees. We don't get into the site, we don't try to exploit flaws and we don't ask for passwords.
What we check
Each check is based on a public standard or an open database. The report shows what we saw, why it matters and what to do.
Secure connection
| Check | What we read | Reference |
|---|---|---|
| Secure connection (HTTPS) | The page response over https:// and the certificate presented | RFC 2818 |
| Redirect from http:// to https:// | Whether the unencrypted address redirects to the encrypted one | RFC 9110 |
| HSTS | The Strict-Transport-Security header and its duration | RFC 6797 |
| Certificate validity | The expiry date and issuer, confirmed in the public certificate log | RFC 6962 · crt.sh |
Browser protection
| Check | What we read | Reference |
|---|---|---|
| Content policy (CSP) | The Content-Security-Policy header | W3C CSP Level 3 |
| Clickjacking protection | X-Frame-Options ou frame-ancestors | RFC 7034 |
| X-Content-Type-Options e Referrer-Policy | The recommended protection headers | OWASP Secure Headers |
| Cookie protection | The Secure, HttpOnly and SameSite options on the page's cookies | RFC 6265 |
| Mixed content and forms | Scripts, styles or forms using http:// on an https:// page | W3C Mixed Content |
Domain email
| Check | What we read | Reference |
|---|---|---|
| SPF | The public TXT record that says who may send email for the domain | RFC 7208 |
| DKIM | The public signing keys in the most common selectors | RFC 6376 |
| DMARC | The _dmarc policy and what it tells Gmail and Outlook to do with fake emails | RFC 7489 |
| MTA-STS | The policy that requires email to be received over an encrypted connection | RFC 8461 |
Software
| Check | What we read | Reference |
|---|---|---|
| Visible versions | Server, PHP or WordPress versions announced in the headers and HTML | OWASP WSTG-INFO-02 |
| WordPress and plugins | The public version, compared with the current version | api.wordpress.org |
| Known vulnerabilities | Flaws published for those versions of WordPress and the plugins | CVE · WPVulnerability |
| JavaScript libraries | Versions of jQuery, Bootstrap and others with known flaws | CVE |
| Server software | PHP or server versions that no longer get security updates | Official end of support |
Threats
| Check | What we read | Reference |
|---|---|---|
| Malicious code | Signs on the home page: miners, obfuscated code, hidden iframes and spam links | HTML analysis |
| Blacklists | Whether the site is flagged as dangerous | Google Web Risk |
Local SEO
| Check | What we read | Reference |
|---|---|---|
| Page readable by Google | Whether the main content is in the HTML | Google Search Central |
| Link to your Google Maps listing | A link from the page to the business listing | Google Business Profile |
| Local business data | The LocalBusiness block with name, address, phone and opening hours | Schema.org |
| Title, description, contact details and opening hours | What Google shows in results and on Maps | Google Search Central |
How we work out the score
Each check has a weight according to its severity: critical, important or improvement. The score is the percentage of points earned. A check we couldn't carry out doesn't count against you.
What we don't do
- We don't run penetration tests or try to exploit flaws.
- We don't get into the site or ask for passwords or access.
- We don't analyse the server's code, only what is public.
- We don't guarantee positions on Google. Nobody can.
- We don't replace a full security audit.
Laws and good practice
The checks cover the technical measures that the GDPR (Article 32) and the NIS2 directive require of businesses. In the GDPR and NIS2 checklist you can see what your site already meets.
Transparency
For anyone who finds a flaw in SinalPT, we publish a responsible disclosure policy and a security.txt.
See a sample report, made for a fictional website.
Free, no sign-up and no passwords needed.