What Is security.txt? Adding One to WordPress, and 35 Real Files Checked

This post contains affiliate links. If you buy something through one of them, Veravix may earn a commission at no extra cost to you.

A security.txt file is a short plain-text note at a fixed address on your site that tells security researchers how to report a vulnerability to you. It lives at /.well-known/security.txt, it is defined in RFC 9116, and it has exactly two required lines: a way to contact you and a date after which the file should no longer be trusted. Nothing in it changes how your site works, how it ranks or how it is protected. Its only job is to make sure a stranger who finds a hole in your site knows where to send the report.

I wanted to see what real sites do with it, not only what the guides say. On 12 November 2026 I requested the file from 71 sites, my own two and 69 well-known ones, mostly hosting companies, WordPress tools, SEO tools and online shops, and read every file I got back against the RFC. About half of the sites that answered publish one, and a surprising number of those files are stale, incomplete or not quite valid.

What the file contains, and what the RFC actually requires

RFC 9116 was published in April 2022 as an informational document, so it is a published convention and not an enforced rule. It says all fields are optional unless stated otherwise, and then states two exceptions: Contact must be present, and Expires must be present exactly once. Everything else is a convenience for the person reading it.

Field	What it holds	Required
Contact	An address as a URI: mailto:, tel: or an https:// page. Can appear more than once	Yes
Expires	A date and time in ISO 8601 form. The RFC recommends less than a year ahead	Yes
Policy	A link to your disclosure policy	No
Preferred-Languages	Languages you can read reports in	No
Canonical	The address this file is meant to be served from	No
Encryption	A link to a public key, never the key itself	No
Acknowledgments	A page that thanks past reporters	No
Hiring	A link to your security jobs	No

A complete minimal file for a small site looks like this:

Contact: mailto:security@example.com
Expires: 2027-06-30T23:59:00Z
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt

The location rules are strict. The file has to be reachable over HTTPS at /.well-known/security.txt, and it has to be served as text/plain in UTF-8. An older top-level /security.txt is allowed for legacy reasons, but if both exist the one under /.well-known/ wins.

What 35 real files looked like

Of the 71 sites, 65 gave a usable answer. Four hosting and tool sites (Bluehost, Cloudways, SiteGround and WPBeginner) answered my script with a 403 and two (Hismile and Intuit) would not connect, so I cannot say anything about them. Of the 65 that answered, 35 publish a file and 30 return a 404. Thirty-four of the 35 serve it at the standard path, and Wix serves it only at the old /security.txt address.

What I checked	Of the 35 files
Has a Contact line	34 (Dropbox has none)
Has an Expires line	24
Has both required fields	24
Links a disclosure Policy	28
Lists Preferred-Languages	21
Sets Canonical	18
Is wrapped in a PGP signature	7
Links an Encryption key	10

The sites without a file include GoDaddy, Namecheap, Elementor, WooCommerce, Semrush, Ahrefs and 14 of the online shops, among them Allbirds, Glossier and Gymshark. Veravix and Repairpicks were in my list and return a 404 as well. So the practical answer to “does everyone have one” is no, and the absence of a file is the normal state of a website, not a red flag.

Where real files go wrong

The expiry date is the weak point. Eleven of the 35 files have no Expires line at all, which breaks the one requirement that exists to stop stale files. Of the 24 that do set a date, one has already lapsed: Kinsta’s file expired on 18 October 2026, 25 days before I looked. Ten more set the date more than a year ahead, against the RFC’s recommendation. The BBC’s file runs to January 2038, Mozilla’s to September 2037 and HubSpot’s to 2034, which defeats the purpose of an expiry. The remaining 13 are within a year, and the nearest are php.net in 16 days and GitHub in 30. A file that expires is not a bug in itself. It is the format working as designed, and the owner has to renew it on a schedule.

The RFC is blunt about why. Its section on stale information says that not having a file may be better than having one with stale information, because a report sent to a dead address is a report that never arrives. An unmaintained file is the one mistake this format can make worse than doing nothing.

Some files use the wrong field names. Moz’s file says Expiration where the RFC says Expires, so a strict reader sees no expiry at all. Its date, 11 November 2026, had also passed when I ran the survey. Three files, from Moz, Slack and WordPress.com, spell Acknowledgements the British way, while the field is registered as Acknowledgments. Dropbox uses a Bug Bounty Contact line that is not a defined field, so it has no Contact at all by the RFC’s rules, and Wix and the New York Times add fields such as Article and Tips that no reader will know. Under the RFC a reader must ignore fields it does not recognise, so these do no harm, but they also do nothing.

A bare email address is not a valid Contact. The value has to be a URI, so an address needs mailto: in front of it. Moz’s file lists a plain email address, and Adobe’s lists one of its two contacts that way, next to a proper link.

The charset is often missing. All 34 files at the standard path were served as text/plain, but only 16 of them declared charset=utf-8. The other 18 sent the type with no charset. Most readers cope, but the RFC describes the UTF-8 charset as part of the expected response.

Six files are redirected, and three of those leave the domain entirely. PayPal sends the request to paypalobjects.com and WordPress.com to automattic.com. A third is an online shop, Native, whose file is a redirect to a file in Shopify’s content network. Intercom stays on its own domain but moves to an app subdomain, and HubSpot and Shopify redirect within their own sites. That works, and the RFC allows redirects, but it also tells researchers to inspect them, since a redirect can lead somewhere an attacker controls. If you can serve the file from your own domain, do.

Adding a security.txt file to a WordPress site

On a normal WordPress install the simplest route is a real file. Create a folder named .well-known in the site’s root directory, where wp-config.php lives, and put a file named security.txt inside it. Your host’s file manager or SFTP will do it, and the file manager in Hostinger’s hPanel works the same way as any other. Turn on the option to show hidden files first, because folders that start with a dot are hidden by default in several file managers.

On Apache and LiteSpeed hosting, which covers most shared WordPress plans, the standard WordPress rewrite rules only send a request to WordPress when no real file or folder matches it. A real file in /.well-known/ is therefore served directly, with the content type taken from the .txt extension. If your host runs nginx, the same result depends on the server configuration, so test it instead of assuming.

Testing takes one command. Run curl -sI https://yoursite.com/.well-known/security.txt and look for a 200 status, a content-type of text/plain and no redirect to a page that is not yours. Then open the address in a browser and make sure the text is what you wrote and not a web page. A themed page or an HTML error page is not a valid file, even if it loads.

If you do not want to touch files, the WordPress plugin directory lists a few small plugins for this. On 12 November 2026 the search for “security.txt” returned Security.txt Manager with about 700 active installs, Generate Security.txt with about 300 and Well-Known File Manager with about 200. A plugin adds one more piece of code to maintain for the sake of a four-line text file, so I would use the static file unless you have a reason not to.

Three choices that decide whether the file helps

• Use an address someone reads. A role address such as security@yourdomain.com, forwarded to a mailbox you actually check, beats a personal address that changes. Do not put a phone number or private address in the file, since the file is public.
• Set the date a few months ahead and write the renewal in a calendar. The php.net and GitHub files in my list run on short expiries, 16 and 30 days out when I looked, which is the opposite risk. A date about six to nine months out gives you room to forget once without letting the file go stale for long.
• Link a policy, even a short one. A single page that says what you want reported, where, and that you will not pursue people who report in good faith, is what the Policy field is for. Twenty-eight of the 35 real files have one.

Do you need one?

For a small blog or a store, a security.txt file is a courtesy and not a requirement. The RFC is about vulnerability disclosure and says nothing about search rankings or site protection, and I found no source that links the file to either. The cost is a few minutes and an annual reminder. The benefit is that a researcher who finds a problem has a documented place to send it instead of guessing at an address.

If you add one, the checks that matter are the ones my survey kept finding broken: a real Contact as a URI, an Expires date inside the next year, the right field names, and a calendar reminder to renew it. For the rest of a site’s first-line security, How to Check Your Website’s Security Headers covers the response headers a site should send, and How to Check Website Security Online walks through the other basics I measured on the same group of sites.

I read the whole of RFC 9116 on 12 November 2026 for the field rules and the sections on location, redirects and stale information. The numbers above come from my own requests to each site that day, run with a short script that records the response, follows redirects and parses each file. The six blocked or unreachable sites are not counted, and 69 of the sites are well-known names, not a random sample of the web. The other two are mine. My earlier basic security check counted 34 of 68 sites with a security.txt after a correction, which matches the 34 files at the standard path here.