Case file PAYWALL / 2026-07-27 · Classification Internal · Prepared for Operator · Subject Boletín Bien
Exposure & Decision Briefing

The paywall,
the read limit,
and who slips past.

Three questions on the table: are readers bypassing the daily limit, should a free account become mandatory to read at all, and is now the moment or something to hold until scale. Here is what the code actually does, and what to do about it.

Core finding

The wall holds against casual bypass.
The article walks out the front door anyway.

The daily limit is decided on the server, so a lone VPN or a lone incognito window does not reset it. But the full article body is shipped inside the paywall response and merely blurred with CSS, so anyone who opens “view source” reads the whole thing. That is the real hole, and it is a code fix, not a business-model change.

Free allowance
1read per gazette, per Madrid day (down from 3 on 2026-06-19)
Limit enforced
Serverbackend returns HTTP 402, not a client-side check
The real leak
Full bodythe entire article ships in the 402, CSS-masked only
Paying readers
1as of 2026-07-26 — the wall is a list lever, not yet revenue
§ 01

Can people bypass the daily limit?

Q: “…via VPN or private browsing?”

How the counter actually identifies you

Every read is recorded server-side and counted against both a long-lived bb_visitor cookie and your network address, coarsened to a /24 block. The check is an OR: you are over the limit if either the cookie or the network prefix already read today. That single detail decides which “tricks” work.

Because it is an OR-match, changing only one identifier is not enough. A VPN swaps your network but keeps the cookie. Incognito drops the cookie but keeps your network. Either alone still matches the other half, so the wall stays up.

Bypass vector matrixWhat actually defeats the wall
Blocked Effortful Wide open
01
VPN only new IP · same cookie
Blocked
The bb_visitor cookie still matches today’s read, so the count holds.
02
Private browsing only new cookie · same IP
Blocked
Fresh cookie, but your network /24 already counts against you.
03
VPN + private browsing both identifiers change
Effortful
Now both halves reset, so the counter clears — but it takes deliberate steps on every single read.
04
New device / mobile data clean cookie + clean network
Effortful
Same as row 03 by other means. Realistic for a determined reader, not for the crowd.
05
View source / DevTools no reset needed
Wide open
The full article text is already in the page. There is no counter to beat and no wall to reset.
The hole that matters

It isn’t the counter. It’s the payload.

When the limit is hit, the backend still puts the complete, untruncated article body into the 402 response (article_body), and the reader page only clips it to max-h-[8em] with a gradient mask. The text is fully present in the delivered HTML — reachable by view-source, by deleting one CSS class, or by turning styles off.

The fix is small and server-side: stop sending the full body once the quota is spent. Send a short excerpt instead. This plugs the actual leak without touching pricing, accounts, or the funnel — and it is the highest-value thing on this page.

So, is the crowd VPN-hopping?

Almost certainly not.

Single-vector tricks don’t work, and the double-vector reset is too fiddly to do per article. If reads aren’t converting, suspect the body-leak or plain low intent long before mass evasion.

One more gap

A free login doesn’t unlock reads.

Only a paid member of that specific gazette skips the wall. A signed-in free account is still metered — worth knowing before you make accounts the gate.

§ 02

Should a free account be required to read?

Q: “…1 read/day only with an account, none without?”

What a hard account-gate really trades

Today the primary channel is Google organic, landing on a browse-first audience that meets the product for the first time on a single article. A registration wall before any value is delivered is the highest-friction move available: it asks strangers to sign up before they have read one useful line. At this stage that suppresses the exact top-of-funnel the whole business depends on.

With one paying reader, the wall is not yet a revenue instrument. Its real jobs right now are (1) not devaluing the paid tier by leaking content, and (2) building a relationship. An account-gate is a list-building lever, not a revenue lever — and it only pays off once there’s enough traffic to convert into a list worth having.

Dimension
A · Account required0 anonymous reads
B · Keep 1 free readstatus quo
C · Soft nudgerecommended direction
Email / list capture
Strong — but only on what survives the wall
None from the read itself
Grows without blocking the first read
Google organic reach
Hurts most — first-touch bounce, SEO risk
Fully preserved
Preserved — nudge comes after value
Path to first payment
Warmer leads, far fewer of them
Wide top, no mid-funnel step
Adds a mid-funnel rung before paid
Content-leak resistance
Irrelevant until the body-leak is fixed
Same leak
Same — fix §01 first, regardless
Fit for this stage
Premature at ~1 payer
Safe, but static
Captures upside, keeps reach
Recommendation

Don’t make accounts the gate — not yet.

Keep the anonymous first read, fix the body-leak, and add a soft account nudge (register free to lift the daily cap or save articles). You get list growth without spending the organic reach you can’t yet replace. Reserve the hard gate for a later, measured test.

§ 03

Do it now, or wait for 1k DAU?

Q: “…start now or hold until 1k DAU?”

Two reasons the hard gate should wait

You can’t measure it yet. A registration wall is a bet that captured emails outweigh lost readers. Proving that needs an A/B test with enough traffic for a real signal — at low DAU you’d be guessing, and guessing on your only growth channel.

Timing cuts the wrong way. Gating now throttles the top-of-funnel precisely when growing it is the priority. The move that scales with you is to plug the leak now, nudge softly now, and hold the hard gate until you have both the volume to test it and the traffic to afford being wrong.

Phase 0 · this week
Fix the leak

Stop shipping the full body in the 402

Return a short excerpt once the quota is spent, instead of the whole article behind a CSS mask. This is the one change with real payoff and zero funnel risk — do it independently of any account decision.

Effort: hours · Funnel risk: none
Phase 1 · now → weeks
Soft nudge

Free account lifts the cap, doesn’t block the door

Offer a reason to register (a higher daily allowance, saved articles, the daily email) after the reader has had value. Grows the list while the anonymous first read keeps organic reach intact.

Effort: moderate · Funnel risk: low
Phase 2 · ~1k DAU
Test the gate

A/B the hard registration wall on a slice

Split a fraction of traffic and measure both list growth and organic retention / bounce. Roll it out only if the net is positive. Until the traffic exists, this test can’t give a trustworthy answer.

Effort: moderate · Gate: statistical power
Verdict

Act now on the leak.
Wait on the hard gate.

The bypass worry is mostly a false alarm — but the payload leak is real and cheap to close. Make accounts the gate only after a measured test at scale, not before you have the traffic to run one.

Disposition HOLD · PATCH