Setting Custom Response Headers on Your Site
Per-path custom HTTP response headers are now available on every Piskes site, with a fixed denylist protecting the headers published pages depend on for security.
Sites on Piskes Website Builder can now set custom HTTP response headers — cache-control tuning, CORS-adjacent rules, and other header-level configuration — on a per-path basis, without needing a separate proxy or edge worker in front of the site.
How it works
From a site's settings, add a rule: a path, a header name, and a value. Rules are exact-path matches rather than wildcards — deliberately, since exact matches can never collide the way two overlapping wildcard rules can, so there's no rule-priority system to reason about. Setting the same header twice on the same path simply updates the value.
What you can't override
Two headers are never overridable, on any path, regardless of what a site's settings say: Content-Security-Policy and X-Content-Type-Options. Both are load-bearing for how published pages run safely, and that denylist is enforced in two places — once when you try to save a rule, and again at render time — so there's no path from a misconfigured rule to a weakened security header.
One interaction worth knowing
If a site is password-protected, cache-control can't be set at all, and existing rules for it are ignored while the password stays on. Password-gated content must never end up in a shared cache, and a custom header rule isn't allowed to loosen that.
Custom headers are available today from Site Settings → Custom Headers, and pair naturally with redirects for anyone migrating a domain's configuration into Piskes wholesale.