Paywalls and SEO

How to keep paywalled and registration-gated content indexable without cloaking — flexible sampling, isAccessibleForFree/cssSelector markup, the JavaScript-paywall trap, and metering strategy.

First published: Jul 3, 2026 · Last updated: Jul 18, 2026 · Advanced
demand #5 in News & Discover SEO#285 in Technical SEO#381 on the site
AIAuthored byAI v2

A paywall doesn't inherently hurt SEO — Google has no bias against gated content, and the biggest paywalled publishers rank fine. What hurts is Google not being able to see enough content to understand the page. The supported fix is flexible sampling: let Googlebot crawl the full article, then declare the gated part with structured data (isAccessibleForFree plus a cssSelector). That's an explicit, sanctioned exception to cloaking — cloaking is about intent to deceive; this is a declared mechanism. Use metering (start around 6–10 free articles/month) or lead-in, gate server-side (not with JavaScript that just hides content in the DOM), give login pages unique copy, and never use robots.txt to hide private URLs.

TL;DR — Paywalls don’t inherently hurt rankings; Google being unable to see your content does. The supported model is flexible sampling — metering or lead-in — declared with structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. (isAccessibleForFree: false plus a hasPart/cssSelector marking the gated section, class selectors only). That declaration is what makes serving GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. the full article not cloaking: cloaking requires intent to manipulate and mislead, and Google’s spam policy explicitly carves paywalls out of that definition. Gate server-side (the 2025 doc update and Mueller’s screen-reader caution both target the same JS-hiding mistake), give login pages unique copy, never robots.txt private URLs, and use noarchive to stop a cached copy leaking the full text. Registration walls use the same markup as paid ones.

What actually causes ranking problems (it isn’t the gate)

Paywall eligibility depends on crawlable content and accurate markup; the presence of a paywall alone is not documented as a penalty. Evidence for this claim Official or primary documentation supporting the adjacent article claim, with scope limited to the source's published description. Scope: No ranking guarantee or undisclosed system mechanics are inferred beyond the cited source. Confidence: high · Verified: Google: Paywalled content structured data Sampling choices remain publisher decisions with user and business tradeoffs. Evidence for this claim Official or primary documentation supporting the adjacent article claim, with scope limited to the source's published description. Scope: No ranking guarantee or undisclosed system mechanics are inferred beyond the cited source. Confidence: high · Verified: Google: Flexible sampling

Google has no penalty for paywalled content, and this article’s parent hub says as much: gated content is fine as long as Google can read it through the supported approach. The failure mode is upstream of ranking — it’s comprehension. If GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. only ever sees a teaser, that teaser is all it can indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. and rank you for. Every technique below exists to solve one problem: let the engine read the whole thing, while unauthenticated humans still hit the gate.

Two boundaries worth stating plainly, since it’s easy to overreach in either direction. First, this markup is a tool for content you want indexed under a declared gate — not a mechanism for exposing content you don’t want indexed at all. Genuinely private account/admin URLs are a different case (see the decision tree below): those get noindex or an authentication redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., not isAccessibleForFree. Second, valid markup and full crawl access are not a ranking guarantee. Google’s structured-data guidelines say directly that “Google does not guarantee that features that consume structured data will show up in search results” — the markup is the declaration that keeps you out of the cloaking bucket, not a promise of indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., ranking, traffic, or a rich result.

Historically this is where the biggest cautionary tale comes from. When the Wall Street Journal pulled out of Google’s old First Click Free program in 2017, it reported a ~44% drop in Google search traffic — not because paywalls are penalized, but because Google could no longer see the articles at all. (More on First Click Free below; it is history, not current policy.)

Flexible sampling: metering and lead-in

The current, active model is flexible sampling, laid out in Google’s Flexible Sampling guidelines. Google describes two sampling types: “metering, which provides users with a quota of articles to consume before requiring users to subscribe or log in, after which paywalls will start appearing; and lead-in, which offers a portion of an article’s content without it being shown in full.”

The numbers that matter, all from Google’s own doc:

  • Prefer monthly over daily metering. Google: “In general, we think that monthly, rather than daily metering provides more flexibility and a safer environment for testing.” A one-unit change is far less jarring at 10 monthly samples than at 3 daily ones.
  • Start around 6–10 free articles/month. “As a starting point for your explorations, we encourage you to provide 10 articles per month… for most daily news publishers, we expect the value to fall between 6 and 10 articles per user per month.”
  • Watch the exposure ceiling. “Our analysis shows that general user satisfaction starts to degrade significantly when paywalls are shown more than 10% of the time (which generally means that about 3% of the audience has been exposed to the paywall).”
  • Lead-in is a good practice. Showing the first few sentences above the paywall lets users “experience the value of the content.”

None of these numbers is a mandate. Google says directly: “There is no single value for optimal sampling across different businesses” — the 6–10/month figure is a starting point Google gives specifically for daily news publishers, and even that comes with “we leave the exact number to the discretion of individual publishers, who are best positioned to understand the particular demands of their businesses.” Treat it as a tested starting range, not a rule to copy verbatim.

The under-appreciated point: metering is not purely a monetization dial. Google opens the doc noting that “even minor changes to the current sampling levels could degrade user experience and, as user access is restricted, unintentionally impact article ranking in Google Search.” Tightening the meter can quietly cost you rankings.

Why this isn’t cloaking — the reasoning, not just the rule

This is the load-bearing part of the whole topic, and most guides assert the conclusion (“paywalls aren’t cloaking if you use structured data”) without showing why. Here’s the actual reasoning, straight from Google’s spam policies.

Start with the definition. Cloaking is “the practice of presenting different content to users and search engines with the intent to manipulate search rankings and mislead users.” The load is on that clause — intent to manipulate and mislead. A paywall isn’t trying to trick anyone; it’s monetizing content, and it’s declaring the difference in treatment through markup.

Then the explicit carve-out, in the same policy: “If you operate a paywall or a content-gating mechanism, we don’t consider this to be cloaking if Google can see the full content of what’s behind the paywall just like any person who has access to the gated material and if you follow our Flexible Sampling general guidance.”

So the exception has two conditions: (1) Google sees the same full content a paid subscriber would, and (2) you follow flexible sampling — which in practice means the structured data below. Google’s flexible-sampling doc reinforces the same logic: “Enclose paywalled content with structured data in order to help Google differentiate paywalled content from the practice of cloaking, where the content served to Googlebot is different from the content served to users.” The structured data is the declaration that turns “different content for botsA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index.” from deception into a disclosed, sanctioned mechanism.

Implementing the structured data

The markup lives in Google’s Subscription and paywalled content doc. Two properties do the work:

  • isAccessibleForFree (Boolean, required) — whether the content is free or gated. Google’s own property reference marks this the required one; set it on the top-level CreativeWork/NewsArticle node and on each gated section.
  • hasPart (recommended, not required) — an array of WebPageElement objects, one per gated section, each with its own isAccessibleForFree: false and a cssSelector pointing at the class you wrapped the gated HTML in. This is how you tell Google which part of the piece is gated when it’s a section rather than the whole thing; it’s the recommended way to get section-level precision, not a second required property alongside the top-level flag.

A minimal NewsArticle looks like this:

{
  "@context": "https://schema.org",
  "@type": "NewsArticle",
  "isAccessibleForFree": false,
  "hasPart": {
    "@type": "WebPageElement",
    "isAccessibleForFree": false,
    "cssSelector": ".paywall"
  }
}

Three implementation details people trip on:

  • Class selectors only. The cssSelector “references the class name that you set in the HTML.” Use .paywall — not an ID (#paywall), not a descendant or attribute selector.
  • Multiple gated sections use an array of hasPart objects, each with its own class-based selector. Don’t nest the gated sections inside each other.
  • It’s not just for news. The markup is supported on any CreativeWork subtype — Article, NewsArticle, Blog, Comment, Course, HowTo, Message, Review, WebPage. The broader structured data guidance treats isAccessibleForFree as a general CreativeWork property, not a news-only one.
  • Correct markup doesn’t guarantee a result. Even fully valid, correctly-nested markup only makes Google eligible to understand your gating — it isn’t a ranking or rich-result guarantee. Treat the markup as the mechanism that keeps you out of the cloaking bucket, not a promise of any specific outcome.

Registration walls use the identical markup. Google doesn’t distinguish “pay to access” from “register to access” at the schema level. John Mueller said as much on Search Off the Record: the mechanism “could be maybe you require a login, maybe you require a payment, maybe after a certain number of iterations you’re like, ‘Oh, this is enough free content.’ Now you have to pay for it… It can just be something like a login or some other mechanism that basically limits the visibility of the content.” If you gate it, mark it — paid or not. He even flags A/B pricing tests as a valid reason: “if you have something like different thresholds where you say some people get to view five pages for free and others have the whole content available for free because you’re doing A/B testing… then you’d want to use a paywall structured data.”

The JavaScript-paywall trap

Here’s the single most common real-world mistake, and it’s distinct from “forgetting the structured data.” A lot of paywall solutions ship the full article in the HTML the server sends, then use JavaScript to hide it until subscription status is confirmed. Google explicitly warned against this in a 2025 addition to its JavaScript troubleshooting doc: “Some JavaScript paywall solutions include the full content in the server response, then use JavaScript to hide it until subscription status is confirmed. This isn’t a reliable way to limit access to the content. Make sure your paywall only provides the full content once the subscription status is confirmed.”

Why it’s bad on three fronts:

  1. It’s trivially bypassable. Disable JavaScript and the “hidden” article is right there in the source. You’re not actually gating anything.
  2. It muddies the cloaking exception. If the full text is sitting in the DOM for everyone, Google can’t cleanly tell which content was meant to be gated — which is the whole thing the structured-data declaration is supposed to make clear.
  3. It’s an accessibilityWeb accessibility means designing sites so people with disabilities can use them, per the W3C's WCAG guidelines. It overlaps with SEO in specific, checkable ways — alt text, heading structure, descriptive link text, captions, and page speed all serve both audiences — but Google has said accessibility itself is not a ranking factor, and most WCAG success criteria (keyboard focus order, ARIA live regions, form labels) have no SEO effect at all. problem. Mueller raised exactly this on Search Off the Record: “when a user looks at your page, you don’t load the content into the HTML, but rather you make sure that it’s really not loaded into the page’s DOM so that, if a browser has something like… a screen reader, that the screen reader doesn’t go off and read all of this text that you’re trying to hide… make sure you don’t load it into the browser and use JavaScript to turn it on, but rather that it’s really only served to the user when you want to make it available.” The 2025 doc update and Mueller’s caution are the same mistake seen from two angles.

The fix is server-side gating: confirm subscription/login status on the server, and only include the full article in the response for authenticated users. Then layer isAccessibleForFree/cssSelector on top so Googlebot — which is allowed to see the full text under flexible sampling — still gets everything, while unauthenticated humans genuinely don’t. This is also where paywalls intersect with mobile-first indexingGoogle's practice of using the mobile version of a page's content — crawled by Googlebot smartphone — for indexing and ranking. It is not a separate index and not a ranking boost.: Google crawls and evaluates the mobile version, so the full gated content has to be present in the mobile server response too, not just desktop.

Login pages and registration gates: the quieter pitfalls

Two distinct problems show up around login/registration, both from the same Search Off the Record episode.

Generic login pages get folded into duplicates. Mueller: “if you have a very generic login page, we will see all of these URLs that show that login page, that redirect to that login page, as being duplicates… We’ll fold them together as duplicates, and we’ll focus on indexing the login page… If someone is searching for your service… the only thing… they find in search is like, ‘Here’s how to log in,’ that might be a kind of a weird experience for them.” The fix is to give login pages unique contextual copy per service, so they’re not all identical.

Don’t robots.txt private URLs. This one contradicts a common intuition. Mueller: “whether all of this should just be blocked by robots.txtA Google Search Console Page Indexing status: the URL was excluded from indexing because your robots.txt disallows crawling it. Usually intentional and benign — robots.txt blocks crawling, not indexing., which is another common strategy… The problem, I think, with doing that is the URLs could become indexable so we wouldn’t see the contents of the login page… if it’s private content, serve it with a noindexNoindex is a directive that tells search engines to keep a page out of their index, so it won't appear in search results. It works only on pages a crawler can actually fetch — a page blocked in robots.txt can never be noindexed. or redirect it to a login page somewhere. Don’t use robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere..” A robots-blocked URL can still be indexed as a bare, contentless URL — often worse than a clean noindex. (This is genuinely-private content, which is a different case from paywalled-but-should-be-indexed; don’t confuse the two.)

Testing and the “leaky” worry

Test with the Rich ResultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show. Test. Google added paywalled-content support to the Rich Results Test in October 2023, so it validates isAccessibleForFree/cssSelector on a live URL, testing as Googlebot desktop or smartphone. As Mueller put it back in a 2020 office-hours, “you would use the rich results test, like any other kind of structured data… the tricky part with some of these paywall implementations is that Googlebot, of course, needs to be able to see the full content.”

The self-audit trick: open an incognito window (logged out of everything), search for your own brand or service, and see what shows. Mueller’s advice — “If the top result is something like a login page and there’s no information on this page at all otherwise, then probably that’s something that you can improve.”

Is showing Googlebot the full article “leaky”? No. Danny Sullivan, Google’s Search Liaison, addressed the recurring worry that this exposes paid content: “Our system is looking to be shown the full content, if a publisher wants to do that. If they do, we understand more about it. If we understand more, then we might be able to show it for more queries where it’s relevant,” and “Since only we are seeing this, there’s nothing ‘leaky’ as you are suggesting.” The real leak vector, he noted, is the cached copy — solved with noarchive, a separate control from the paywall markup itself. Sullivan’s remarks are relayed via Search Engine Roundtable’s coverage; treat them as reported rather than a first-party transcript.

Bing’s approach

Bing’s subscription and paywall guidance (Fabrice Canel, May 2022) is structurally similar but not schema-centric. Its three points: (1) let BingbotBingbot is Microsoft Bing's primary web crawler — the bot that discovers, fetches, and renders pages to build the Bing index. That index also powers Yahoo, DuckDuckGo, Ecosia, and Microsoft Copilot, so Bingbot's reach is far wider than Bing's own search-market share. crawl the full gated content, (2) use noarchive/nocache (or the X-Robots-Tag: noarchive header) so cached copies don’t leak, and (3) verify the crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. is genuinely Bingbot by checking the requesting IP against Bing’s published ranges — not by trusting the user-agent string, which anyone can spoof. There’s no published Bing equivalent to isAccessibleForFree/cssSelector; Bing’s model is crawl-access-plus-cache-control, where Google’s is markup-centric. Don’t assume feature parity.

First Click Free — history, not policy

You’ll still see blog posts and forum answers describing First Click Free as if it’s current. It isn’t. Google retired it in October 2017, replacing it with flexible sampling. Richard Gingras, then Google’s VP of News: “First, Flexible Sampling will replace First Click Free. Publishers are in the best position to determine what level of free sampling works best for them.” First Click Free had required participating publishers to let Google-referred visitors read a set number of articles a day (commonly three) even past their own paywall. Flexible sampling handed that decision back to publishers. If you see FCF cited as something you can opt into today, that guidance is eight-plus years stale.

Where this sits in news SEO

Paywall handling is one piece of the broader News & Discover SEO picture — alongside news sitemapsA news sitemap is a sitemap (a standalone file or a section of an existing sitemap) that uses Google's news: XML namespace to tell Google about your recent articles — only those published in the last two days. It speeds discovery of breaking content; it isn't a ranking factor and isn't required for Google News eligibility., Google News/Top Stories eligibility, Discover, and syndication (canonical vs. noindexNoindex is a directive that tells search engines to keep a page out of their index, so it won't appear in search results. It works only on pages a crawler can actually fetch — a page blocked in robots.txt can never be noindexed.). If you’re a publisher, get your paywall markup and your syndication policy sorted before either one quietly costs you indexation or attribution.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.