security.txt is a standardized plain-text file, defined in RFC 9116, that tells security researchers how to report vulnerabilities to your organization. It lives at /.well-known/security.txt and lists a contact method, an expiry date, and optional fields like an encryption key, a disclosure policy, and acknowledgements page. Having one shortens the path between a researcher finding a flaw and your team hearing about it, which can mean the difference between a responsible disclosure and a public leak.

The canonical location is /.well-known/security.txt at the root of your domain, served over HTTPS. The older top-level path /security.txt is tolerated as a fallback, so this checker tries the well-known path first and then falls back to the root. For maximum compatibility you can place the file at the well-known location and optionally keep the root path as a redirect, but the well-known directory is the spec-compliant home.

Two fields are mandatory: Contact, which is a way to reach your security team such as a mailto, https, or tel URI, and Expires, a single date-time after which the file should be considered stale. Encryption, Policy, Acknowledgments, Preferred-Languages, Canonical, and Hiring are all optional but recommended. The checker confirms Contact and Expires are present and well-formed, and notes which optional fields you could add.

Expires forces you to keep the file current. A security.txt that promises a contact address you abandoned years ago is worse than none, so RFC 9116 requires an explicit expiry date — typically less than a year out — after which researchers should not trust the file. This checker validates that Expires exists, parses as a date, and is in the future, flagging files that have already expired so you can refresh them.

Not directly — it is not a ranking factor. But it is part of a healthy technical and security posture, and it signals to researchers and partners that you take security seriously. Sites that maintain strong security hygiene tend to avoid the trust-damaging incidents and downtime that can hurt rankings indirectly. Treat security.txt as a low-effort professionalism and risk-reduction win rather than an SEO tactic.

If neither the well-known path nor the root fallback returns a file, the checker generates a ready-to-use RFC 9116 template pre-filled with the required Contact and Expires fields plus common optional fields. You copy it, replace the placeholder contact and policy URLs with your real ones, set a sensible expiry date, and save it as /.well-known/security.txt served over HTTPS. That is all it takes to comply.

RFC 9116 allows but does not require a PGP signature, referenced via a clear-signed file and an Encryption field pointing to your public key. Signing proves the file genuinely comes from you and has not been tampered with, which matters for high-trust organizations. For most sites an unsigned file with a valid Contact and Expires is perfectly acceptable, and you can add a signature later as your program matures.