Gated Content on a Static Site
No Backend, No HubSpot

This whole blog is static files on a CDN, with no server of its own. But one day I wanted something a static site is not supposed to do: trade in-depth content for a reader's email: the full worker code behind a technical post, opened for people who care enough to leave an email.

Every guide said the same thing first: go get a tool. HubSpot, Mailchimp, a WordPress plugin, or at least a backend to track who unlocked. For a static site deliberately built with no server, that looked like a dead end. It turned out to be doable, with pieces the site already had, and one trap that nearly left the whole gate open without me noticing.

Part 1Why gated content usually needs a backend

The heart of gated content is that something has to remember who unlocked. State that must be remembered needs somewhere to live: which is why the tools all tie back to a server or a database. HubSpot/Mailchimp keep that state in their systems; a WordPress plugin leans on WordPress's backend.

A static site has no state and nothing to remember. Every request serves the same file to everyone. So the real question is not "how do I build a gate" but where do I borrow the memory from, without standing up a whole server.

The answer sits in a layer people forget is there. If your site is behind Cloudflare, every request passes through Cloudflare's edge before it reaches the real file. You can drop a little code at that layer (a Cloudflare Worker) to decide, first, whether this request should see the real thing. That is the memory we need: no backend of our own.

Part 2Doing it on static: public teaser + gated payload

Three pieces, with clear division of labor:

1. The teaser is public HTML. The front of the article is fully readable by everyone and every crawler. This is the SEO/GEO surface: never gate it, or Google sees nothing.
2. The gated content is stored separately, not in the teaser page. This matters most: the real payload must not ship inside the teaser's HTML at all. Hide it with CSS or blur and it still sits in page source: anyone who opens devtools reads it. That is not gating.
3. The Worker is the gate. The gated content has exactly one way in: through the Worker, which first checks whether the request carries a valid unlock cookie. Has one: serve the real thing. No cookie: bounce back to the email form.

The reader's flow: read the teaser free up to the cut, hit a box asking for an email to read on, enter it: the Worker records the email in Cloudflare's key-value store (KV) and issues a signed cookie back. From then on, requests for the gated content succeed: the Worker sees a valid cookie and serves the payload.

What makes it safe is that the cookie is server-signed, not a plain value you can forge: tamper with it and the signature fails. And the content never appears in the public page; its only exit is through the gate. Those two together are the whole soft paywall Substack uses, except here you own it on static.

For the emails you collect, don't store just the address. Store which post it came from, whether they consented to updates, and when, from day one. Later you can export a clean list to a newsletter tool, and see which post converts better.

Part 3The origin trap: a gate that nearly leaked

Reviewing the gate code before shipping (handing it to a second model to hunt for holes, not the one that wrote it) surfaced a gate that opened without unlocking: even though the Worker was correct line by line.

The flaw was in a spot easy to miss. The Worker is only the front door, but the real file lives at the origin. If the gated content is stored as a public static file on the origin, anyone who knows the origin address fetches it directly, straight past the Worker. Front door bolted, back door wide open. We named it the origin hole.

A second hole is similar: the gate route usually matches on the literal path, but if someone percent-encodes characters in the path (turning method into an encoded form that decodes later), the literal match misses and the request falls through to the generic proxy, which decodes it afterward: reaching the real content another way.

The lesson in one line: a good gate guards the front door and the back door. Two things to close:

• Protect the origin from direct access: don't store gated content as a public file, or require a token only the Worker can present.
• Always decode and canonicalize the path before matching the route; never compare against the raw, still-encoded path.

It was caught before shipping only because a different model reviewed it. The model that writes code tends to trust it's already covered; one that didn't write it finds the detours faster. We wrote that up separately.

Part 4Using it on your own site

If your site is already on Cloudflare (or you can move DNS there), the whole shape is:

1. Write the gated content first. Don't build an empty gate with nothing behind it. Finish the real payload, then wrap the gate around it.
2. Cut teaser from payload cleanly. The front proves value (public, crawlable); the back is the real thing traded for an email. Store them in different places.
3. The Worker checks the unlock cookie. Valid cookie serves the payload; none bounces to the form. Record email + source + consent + time in KV, and issue a signed cookie.
4. Close the back door. Protect the origin from direct hits and decode the path before matching: then attack it yourself by hitting the origin directly and with an encoded path, to prove it's shut.
5. Don't pop the form on load. Let people read the teaser, then gate at the cut or on scroll. Popping immediately drives bounces and hurts SEO.

The whole principle is in this post; you can build it now. The full Worker code: signed-cookie issuance, origin protection, and the KV schema: I keep as a members' method page, not to withhold, but because a gate copy-pasted without understanding how the back door closes is a gate that leaks. The principle has to come before the code.

This gate is not theory: it runs on this blog, guards the method content of several posts, and real emails have come through it. The same design works for a lead magnet, a course preview, or a report you want an email before delivering: with no marketing tool to pay for.