How to Add security.txt to WordPress

What security.txt is for

It is a plain text file that tells someone how to report a security problem to you. A researcher finds a flaw in your site, looks for /.well-known/security.txt, and finds an address to write to.

Without it, they either give up or post it publicly. Both are worse for you than an email. See security.txt if you want the background.

It is defined by RFC 9116, and the rules are strict but short. It must live at /.well-known/security.txt, be served over HTTPS, and be served as text/plain; charset=utf-8.

Why a plain file works on WordPress

People assume WordPress will intercept the URL and serve a 404 page, because WordPress routes almost everything through index.php. It does not, and the reason is in the rewrite rules WordPress ships with.

The rewrite only sends a request to index.php when it does not match a real file or directory. Those are the RewriteCond %{REQUEST_FILENAME} !-f and !-d lines in your .htaccess. Put a real file at that path and the condition fails, so the rewrite never fires and Apache just serves the file. nginx behaves the same way through try_files.

So the fix is genuinely as simple as uploading a file to the right place.

Do this

Over FTP, SFTP, or your host's file manager:

1.In your WordPress root, the folder holding wp-config.php, create a folder named .well-known. The leading dot matters. Some file managers hide dotfiles, so switch on "show hidden files" if you cannot see it afterwards.
2.Inside it, create security.txt.
3.Paste in the contents below, with your own address and a sensible expiry date.
4.Visit https://yourdomain.com/.well-known/security.txt in a browser. You should see plain text, not a WordPress 404 page.

Contact: mailto:[email protected]
Expires: 2027-01-01T00:00:00.000Z

That is a complete, valid file. Both fields are mandatory. Contact must always be present, and so must Expires, which may only appear once. Expires is the field most files get wrong, because it was introduced with RFC 9116 and older templates predate it.

The Expires field needs a diary entry

Expires is recommended to be less than a year in the future. That means this file is not something you set once and forget. An expired security.txt is itself a finding, and a scanner will report it, so a stale file can look worse than no file.

Set a reminder for a month before the date you chose. Renewing it is a thirty second job.

Never blanket-block /.well-known/

This is the most important paragraph on the page.

Some hardening guides and firewall plugins tell you to deny access to dot-directories, which sweeps up /.well-known/. Others suggest redirecting the whole path somewhere. Do not do either.

Let's Encrypt and cPanel AutoSSL validate your domain by fetching a file from /.well-known/acme-challenge/. Block or redirect that path and certificate renewal fails. It will not fail today, it will fail in ninety days, long after you have forgotten why, and your site will start showing security warnings to visitors. See our guide on SSL certificates on WordPress for how that renewal works.

If you already have a rule blocking dot-directories, make an exception for /.well-known/ before you go any further.

If the file is not being served correctly

Two things go wrong. Both are fixable.

Some servers block dot-directories by default. If you get a 403 rather than your file, that is what is happening. Your host can lift it for /.well-known/, and given that certificate renewal depends on the same path, they will understand why you are asking.

The content type is wrong. RFC 9116 requires text/plain; charset=utf-8. Most servers get this right for a .txt file, but if yours is serving something else, this Apache snippet fixes it.

<Files "security.txt">
  ForceType text/plain
</Files>

Only add this if the content type is actually wrong. Check first, in your browser developer tools under the Network tab, or with any header checking tool. Do not add config you do not need.

The plugin option

If you cannot reach the filesystem, there is a plugin route. Security.txt Manager on wordpress.org registers rewrite rules for the path. At the time of writing it was last updated in June 2026, tested to WordPress 7.0.1, with over 600 installs.

Be aware of what a rewrite approach depends on though. It only works if the request reaches WordPress. If your web server handles .well-known itself before PHP ever runs, the plugin never sees the request and the file never appears. That is the same reason a real file is more reliable: it does not depend on routing at all.

Whichever way you go, test the URL in a browser. Do not assume.

One more thing

Do not create it as a WordPress page. A page called "security-txt" gets served as HTML, which breaks the content-type requirement, and it cannot live at a path with a dot and a slash in it anyway. It has to be a file.

Once it is up, run a check to confirm it is reachable and valid. Then look at the rest of the fix-it matrix, because security.txt is one of the quicker wins on the list.

Check your work in seconds

Run your site through our free safety check to confirm the fix is live, and see what else a shopper would notice.

Run a free check

Frequently asked questions

Will WordPress intercept /.well-known/security.txt?

No, not if you put a real file there. The WordPress rewrite only routes to index.php when the request does not match an existing file or directory, which is what the RewriteCond !-f and !-d lines mean in your .htaccess. A real file matches, so the rewrite never fires and the server just serves it. nginx does the same thing through try_files.

Do I need a plugin for security.txt?

Only if you cannot access the filesystem. A file uploaded over FTP or your host's file manager works on stock WordPress with no plugin. Security.txt Manager on wordpress.org handles it via rewrite rules if you need that route, but a rewrite fails if your web server handles .well-known before WordPress does, so test the URL either way.

What is the minimum valid security.txt file?

Two lines: a Contact field and an Expires field. Both are mandatory under RFC 9116. Contact must always be present, and Expires must always be present and appear only once. Expires is the field most files miss, because it was added in RFC 9116 and older templates predate it.

Can I block /.well-known/ in my firewall or .htaccess?

No. Let's Encrypt and cPanel AutoSSL validate your domain by fetching a file from /.well-known/acme-challenge/. Blocking or redirecting that path breaks certificate renewal, and you will not find out until the renewal is due. If a hardening guide told you to deny dot-directories, add an exception for /.well-known/.

How often do I need to update it?

At least once a year. The Expires field is recommended to be less than a year in the future, and an expired file counts as a finding in its own right, so a stale one can look worse than none. Set a calendar reminder for a month before your chosen date.

Is this different for WooCommerce?

No. WooCommerce is WordPress, so the file goes in the same place and the same rewrite behaviour applies. If anything it matters more on a store, since a researcher finding a checkout flaw is someone you very much want to hear from privately.