How to Add security.txt to Squarespace

The short answer

There is no way to publish a valid security.txt on Squarespace.

Here is the evidence. Request /.well-known/security.txt on a Squarespace site and you do not get your site's 404 page. You get a JSON 404 from Squarespace platform infrastructure. That detail is the whole story: the path is being intercepted before your site's routing is consulted. Your site is never asked.

Which means a URL Mapping almost certainly cannot help. A URL Mapping operates inside your site's routing, and the request never gets that far. It is also moot in practice, because Squarespace slugs cannot contain dots or slashes, so you cannot even create a page at that address to map to.

What security.txt is meant to be

Worth understanding, because it explains why half-measures do not count.

security.txt is defined by RFC 9116. It is a plain text file telling security researchers how to report a vulnerability to you, so that someone who finds a problem can reach you instead of giving up or going public. The spec is specific:

→It MUST live at /.well-known/security.txt. Not at /security.txt, and not on a page you invent.
→It MUST be served over https.
→It MUST be served as Content-Type: text/plain; charset=utf-8. This is where CMS workarounds die.
→Contact: is mandatory. The spec says this field MUST always be present.
→Expires: is mandatory too, must appear exactly once, and is recommended to be less than a year out. It was added in RFC 9116 and is very commonly missing from files written against older advice.

A valid file, for reference

This is the minimum that satisfies the spec. Two lines. It is genuinely that small, which is part of why it is frustrating that Squarespace will not serve it.

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

Because Expires must be less than a year in the future, security.txt is not a set-and-forget file. It needs a diary entry. An expired security.txt is itself a finding, so if you do publish one somewhere, keep it current.

Why the workarounds do not work

You will find suggestions online. Here is why each one fails on Squarespace, so you do not spend a Saturday finding out yourself.

→Make a page and map the URL to it. The request to /.well-known/security.txt never reaches your site's routing, so there is nothing for a mapping to intercept. And slugs cannot contain dots or slashes, so the page cannot exist at that path anyway.
→Make a normal page at /security-txt and call it done. A Squarespace page is served as text/html. RFC 9116 requires text/plain. It fails the spec on content type alone, regardless of what is written on it.
→Put the file at /security.txt and redirect to /.well-known/. Backwards. The RFC sanctions a redirect FROM the legacy top-level /security.txt TO /.well-known/security.txt, not the other way around. Even a redirect that worked would not satisfy the spec.
→Code Injection. Code Injection adds markup to your page head. It cannot create a file at a path, and it certainly cannot set a content type.

What to do instead

Step back from the file for a moment. The point of security.txt is that a researcher who finds a hole in your site can tell you about it quickly. The file is the standard way to communicate that. It is not the only way.

So do the part that actually matters:

→Publish a security contact somewhere findable. A short page at /security with a monitored email address, or a clear line on your contact page. It will not pass an RFC 9116 check. It will still get you the email, which is the entire point.
→Make sure someone reads that mailbox. A reporting address nobody checks is worse than none, because it looks like a promise you are not keeping.
→Do not let this one distract you. A missing security.txt is a documentation gap. Missing email authentication is an attack surface. If your SPF and DMARC records are not sorted, fix those first. Both are fully within your control on Squarespace.
→If you genuinely need it, you need different hosting for that path. That means moving the site, or putting something in front of it. Both are large decisions to make for a two-line text file. For most Squarespace owners the honest answer is: accept this finding and move on.

How we treat this in a report

We flag a missing security.txt, but we are not going to pretend it is a hole in your site. It is a nice-to-have that Squarespace does not permit, and no amount of effort on your part will change that.

If you want the background in plain English, see our security.txt explainer. If you want to see which findings on your site you can act on, run a free check and start with those.

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

Can I add security.txt to a Squarespace site?

No. A request to /.well-known/security.txt returns a JSON 404 from Squarespace platform infrastructure, which means the path is intercepted before your site routing is consulted. Your site never sees the request, so there is nothing you can configure to answer it.

Will a URL Mapping work for /.well-known/security.txt?

Almost certainly not. URL Mappings work within your site's routing, and the request is intercepted before it reaches that layer. On top of that, Squarespace slugs cannot contain dots or slashes, so you cannot create a page at that path to map to in the first place.

Can I just make a page with the security.txt content on it?

You can, and it may still get you a useful report, but it does not satisfy RFC 9116. A Squarespace page is served as text/html and the spec requires text/plain; charset=utf-8 at the /.well-known/security.txt path. A scanner checking the standard will still record it as missing.

What has to be in a valid security.txt?

At minimum a Contact field and an Expires field. Both are mandatory under RFC 9116, and Expires must appear exactly once and is recommended to be less than a year in the future. Expires is the one most existing files are missing, because it was added in RFC 9116 and older guides predate it.

How much does a missing security.txt actually matter?

Honestly, not much for a small business site, and on Squarespace it is not your fault. It is a way for researchers to reach you, not a protection. Publish a security contact on a normal page so people can still find you, and spend your time on SPF, DMARC and SSL, which you fully control.