Keep response headers with your static-site build
Ivan Roslov2 min readRevised September 7, 2026. Product details reflect this revision.
Suppose your static site should prevent other sites from embedding its pages in a frame. You need the server to send an appropriate response header. Editing the page's HTML alone does not set that server response.
On a Lessly static site, you can put response-header rules in a _headers file in the build output. The rules travel with the files you deploy, so the site's content and header configuration can be reviewed together.
Put the rule in the published output
For a build that publishes dist, the deployed file is dist/_headers. Your build needs to copy it there; leaving it elsewhere in the source repository is not enough.
A rule for every path looks like this:
/*
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
The first line selects paths. The indented lines name the headers and their values. In this example, X-Frame-Options: DENY tells supporting browsers not to display the page inside a frame. X-Content-Type-Options: nosniff tells them to respect the declared content type rather than guessing another one.
These are example policies, not a complete security configuration. If your product needs to be embedded elsewhere, a rule that denies framing would conflict with that use.
Review the rule with the change it affects
Keeping the file in the build makes the configuration part of the release. A reviewer can see both a page change and any response-header change in the same pull request.
Lessly publishes a static deployment atomically: visitors receive the previous version or the new version, rather than a mixture. The static-site guide describes the build output and the supported _headers format.
The file supports rules for individual paths as well as a whole site. Start with the paths that need the policy. Do not assume that a file copied from another host has the intended effect without checking the deployed response.
Check what the server sends
After deployment, request the headers from a page the rule should affect. Replace the example hostname with your site's hostname:
curl -sI https://your-site.example/
Look for the header names and values you configured. Then check a page outside the rule's scope if you expect it to behave differently.
A valid header can still be wrong for the product. Test the relevant browser behavior too: in the framing example, verify that pages meant to be embedded still work under the policy you chose.
The benefit of putting headers in the build is that you can review and deploy them with the site. The final check remains the response your visitors receive.
Related posts
Building Lessly in the open
Follow along, and get early access to the private beta.