Sensitive content
If a link page sends visitors to an adult subscription platform, big shows an age check before the page itself. The visitor sees a plain screen — Sensitive content, one sentence, and two buttons — and your page loads once they confirm they're of legal age.
You don't turn this on. It follows from your links.
It applies to short links too — see Short links are checked as well below.
What triggers it
A page is age-checked when anything on it that a visitor can actually tap leads to:
- OnlyFans (
onlyfans.com, and any subdomain) - Fansly (
fansly.com, and any subdomain)
That covers all three places a destination can live: a link button, the website entry in a socials row, and an image block you've made tappable.
Some things deliberately don't trigger it:
| Not triggered by | Why |
|---|---|
| A hidden block | Nobody can reach it, so there's nothing to check an age for. |
| A link block that isn't rendering | Same reason — if the button isn't on the page, its destination doesn't count. |
| Another site that mentions those platforms | Only the destination host is read. A blog post about OnlyFans hosted somewhere else is an ordinary link. |
| A domain that merely contains the name | notonlyfans.com is a different site and is treated as one. |
| Someone else's link shortener | A bit.ly link, your own domain, or another link-in-bio service is opaque to us — see What it can't see. |
| Your bio text or a header block | Neither carries a destination. |
Shortening the link first doesn't avoid it. If you point a button at one of your own big short links, we follow that link to see where it lands. itsjustbig.com/l/abc → onlyfans.com age-checks the page exactly as the direct link would, and so does a chain of your own short links, up to three deep. A tagged link counts as the link it was copied from, so pasting the one you copied for a channel behaves the same way.
What the visitor sees
The age check replaces your page. It doesn't sit on top of it, and it isn't a banner you can scroll past: your avatar and your blocks aren't sent to the browser at all until someone confirms.
The share card is the deliberate exception. When your page is posted somewhere that unfurls a preview, that preview still carries your name and bio — a link that says whose page it is, so the person who taps it knows who they're confirming for.
- I am 18 or older — your page loads, and they aren't asked again on your page while their browser stays open.
- I am under 18 — the page says it can't be shown, with a link back to big
Both answers are per page and last one browsing session. Confirming on your page doesn't unlock anyone else's — the next age-checked page they open asks again — and closing the browser clears every answer, so a returning visitor is asked afresh.
That's the narrow reading on purpose. An answer is about the page in front of someone: confirming for one creator isn't a request to be let into creators they've never heard of. And a longer memory would turn a tap into durable state on a stranger's device — much of this traffic is a phone's in-app browser, sometimes a shared or borrowed one — where a page acknowledged weeks ago would open with no check at all for whoever is holding it now.
The check isn't themed. It's big's screen, in big's colours, whatever background and buttons you've picked — the same reasoning behind the footer row in What big. adds to your page.
Nothing about the answer is stored on our side: no account, no contact record, no entry in your stats. It's one cookie in the visitor's own browser.
What it does to your numbers
Page views only count visitors who got through the check. Somebody who lands on the age screen and leaves isn't a view of your page, because they never saw it — see Page views.
Clicks on your blocks are unaffected: they're counted at the /l/ redirect, and only somebody looking at your page can tap one.
Where it shows up while you're editing
The editor tells you, under the phone preview: Visitors confirm they are 18 or older before this page opens. The preview itself stays ungated — it's your page, and you shouldn't have to tap through an age check to reach your own blocks.
Outside the dashboard, a page reports it as sensitiveContent — on the API, on both MCP servers, and in big link-page:view. It's read-only everywhere: there's no field to set and no override, because the links are the setting.
sensitiveContent: false is the weaker answer, and so is a silent editor. Both read the link targets on the block itself; neither follows one of your own /l short links the way the live page does. So a page whose only adult destination sits behind a short link you made reports false, shows no banner under the preview — and is still age-checked when a visitor opens it. true is authoritative; false means "no adult host on a block", never "no age check".
Turning it off
Remove or repoint the links that trigger it. There's no toggle, and that's deliberate: a switch would be a second answer to the question that could disagree with your actual links — and the disagreement that matters is a page marked safe that isn't.
Short links are checked as well
A /l/ short link that lands on OnlyFans or Fansly shows the same check before it redirects — whether you made it yourself under Links → Short links, or it was minted for a link-page button. It applies wherever the link was opened from: a DM, a bio, a QR code, a post caption.
Nothing about the click is counted or attributed until the visitor confirms. Campaign tags survive the detour, so a confirmed click is attributed exactly as it would have been.
A page and its own buttons count as one check. Confirm on someone's link page and their buttons open without asking again; confirm on one of their buttons and their page opens the same way. A standalone short link — one that isn't a page's button — is its own check.
What it can't see
The check reads the destination. That is knowable when the link points at the platform, and when it points at one of our short links, which we can follow.
It is not knowable when the link points somewhere else that redirects: a bit.ly link, your own domain, another link-in-bio service. We don't fetch those to find out — making our servers follow arbitrary links that anyone can type is its own risk, and it wouldn't settle the question anyway, since anything we could follow could be hidden one hop further along.
So the honest statement is narrow: big's own shortener can't be used to get around the check. Deliberately routing around it with a third-party redirector is possible, and it's a terms problem rather than a technical one — pages and links that break the terms get reported and acted on.