isAccessibleForFree: The Complete Guide to Structured Data for Paywalled and Gated Content

Key Points

• isAccessibleForFree is a Schema.org property that tells Google which content on your page is gated. Getting it wrong can cost you substantial search traffic.
• The Wall Street Journal lost 44% of its search traffic after ending Google's First Click Free model without proper structured markup in place.
• The hasPart + cssSelector pattern is the correct implementation for paywalled and registration-gated content, and it works for metered models too.
• Correct markup prevents Google's anti-cloaking systems from flagging your site, protecting rankings and keeping you off penalty lists entirely.
• Validating with Google's Rich Results Test and monitoring the Subscribed Content report in Search Console are your two primary quality controls after deployment.

The Wall Street Journal ended Google's First Click Free model and lost 44% of its search traffic in the process. Not because of bad content. Not because of an algorithm update. Because they removed a key signal and replaced it with nothing. Google's anti-cloaking systems saw a mismatch between what Googlebot crawled and what users received, and traffic fell off a cliff.

That's what isAccessibleForFree is actually for. It's the structured data property that tells Google exactly where the line is between accessible and gated content, for paid paywalls, metered models, and registration walls alike. Get it right and Google understands your access model. Get it wrong and you're invisible in organic search before you ever see a warning email.

This guide covers the complete implementation: JSON-LD patterns for paywalled and registration-gated content, the hasPart + cssSelector structure, metered access configuration, anti-cloaking compliance, and validation workflow. It applies to news publishers, but also to gaming sites, education platforms, sports communities, and entertainment hubs running any form of content gating. For a broader look at how these tools connect to identity collection and ad revenue, the complete publisher's guide to Reader Revenue Manager, identity, and ad revenue is the right place to start.

Why This Markup Exists

Google's flexible sampling model was built specifically for publishers who gate content. It gives Googlebot permission to index full article text even when that content isn't visible to anonymous users, provided the publisher correctly signals the access model through structured data.

Without that signal, Googlebot sees a full article in the HTML source but a registration wall in the rendered page. From Google's perspective, that looks identical to keyword-stuffing a page with content users never see. The anti-cloaking system doesn't know you have a legitimate paywall; it just sees a mismatch between what the crawler receives and what users receive.

The WSJ situation illustrates the cost precisely. When The Wall Street Journal ended Google's First Click Free model without implementing correct structured markup to replace it, organic search traffic dropped 44%. That's not a gradual decline. That's a cliff.

isAccessibleForFree exists to prevent that cliff. It's the handshake between your access model and Google's indexing infrastructure, and it applies equally whether you're charging for access or simply requiring a free registration.

Registration Walls Need This Markup Too

Most articles on this topic write for paid subscription publishers. That framing misses a large chunk of publishers who need this markup just as much.

If you're running a registration wall. Where readers create a free account to access content. You have the same structured data requirement as a subscription paywall. Google doesn't distinguish between "pay to access" and "register to access" at the markup level. Both are access-restricted content. Both need isAccessibleForFree: false.

This matters especially for ad-supported publishers. Registration walls are increasingly the preferred identity capture mechanism for publishers monetizing through programmatic advertising rather than subscriptions. The registration wall generates first-party identifiers. Those identifiers flow into audience targeting. The CPM lift on cookie-less inventory from publisher provided identifiers depends on that pipeline working. The structured data is what keeps the content indexable so traffic keeps arriving to hit the wall in the first place.

Publishers running Google Reader Revenue Manager's Reader Registration feature need this markup on every article where the registration CTA fires. The RRM code and the structured data are separate systems that both need to be in place. RRM handles the user-facing wall; the JSON-LD handles the crawler-facing signal. If you haven't yet configured Google Reader Revenue Manager, that's the prerequisite before the structured data has anything to protect.

The Core JSON-LD Pattern

The structured data goes on every article page where content may be gated. That means every article in your archive, not just new posts, and every device variant if you serve separate mobile and desktop documents.

Here's the base pattern for a hard paywall:

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

The isAccessibleForFree: false on the top-level NewsArticle (or Article) object tells Google the content is not freely accessible. The hasPart block with its own isAccessibleForFree: false and the cssSelector identifies exactly which DOM element contains the gated content.

That cssSelector value needs to match the class or ID you actually use in your HTML to wrap the paywalled content. If your gated content sits inside a <div class="subscriber-content">, your selector is .subscriber-content. If it's inside <div id="premium-article-body">, it's #premium-article-body. The value is a standard CSS selector string.

Your HTML needs to match:

<article>
  <p>This introductory paragraph is visible to all users and indexable by Google.</p>
  <div class="paywall">
    <p>This content is behind the paywall. Googlebot can index it because the structured data correctly identifies it as gated.</p>
  </div>
</article>
 

The indexable preview text above the gated div is what users see before hitting the wall, and it's what surfaces in search snippets.

Essential Background Reading:

• Reader Revenue Manager: The Complete Publisher's Guide to Identity, Engagement, and Ad Revenue: The full framework connecting identity collection, engagement uplift, and ad revenue. Start here before implementing any gated content infrastructure.
• What Is Google Reader Revenue Manager? Definition and FAQs: Covers the Standard vs. Enterprise distinction, feature set, and who RRM is actually built for. Prerequisite reading before deploying RRM alongside structured data.
• Reader Registration Wall: How Publishers Turn Anonymous Traffic into Ad Revenue: Why registration walls beat newsletter prompts 16:1 and how the identity capture pipeline connects to programmatic revenue.
• Harnessing the Power of First-Party Data With a DMP: How first-party identifiers collected through registration walls connect to audience segmentation and CPM lift.

Correct Schema Type Selection

The @type value matters. Use the most specific type that accurately describes your content:

NewsArticle is the preferred type for news publishers because it's most directly associated with Google's Subscribed Content rich results. Publishers outside news, including gaming, education, sports, and entertainment. Should use Article or the most specific applicable type. The isAccessibleForFree property works across all of them.

Metered Access Configuration

Metered models work differently from hard paywalls. A metered model allows readers to access some articles for free before the wall activates, which means the isAccessibleForFree value changes depending on whether a specific user's meter has expired.

For metered implementations, the structured data must reflect the state for a general anonymous user, not a specific user who has remaining free articles. Set isAccessibleForFree: false in the structured data for all metered articles. Even though some users can read those articles freely, the content itself is part of a paid-access model. Google's flexible sampling guidelines accommodate this: Googlebot is treated as a user who has not consumed meter credits.

The metered structured data pattern:

{
  "@context": "https://schema.org",
  "@type": "NewsArticle",
  "headline": "Your Article Headline",
  "isAccessibleForFree": false,
  "hasPart": {
    "@type": "WebPageElement",
    "isAccessibleForFree": false,
    "cssSelector": ".metered-content"
  }
}

Google's flexible sampling guidance recommends a starting point of 10 free articles per user per month for most daily news publishers. User satisfaction degrades when paywalls activate more than 10% of the time. Treat that as a floor, not a ceiling. You can be more generous, but tightening below it risks both user experience and SEO performance.

Related Content:

• Google Subscription Linking Explained: What It Does, What It Doesn't, and How It Connects to Ad Revenue: Disentangles Subscription Linking from SEO myth and explains how personalized Discover surfaces interact with correctly indexed gated content.
• Does Google Subscription Linking Improve SEO? Guidance for Publishers: Direct answer to the question publishers keep asking, with a clear breakdown of what Subscription Linking actually affects in search.
• Publisher Provided Identifiers: How PPIDs Recover Cookie-Less Ad Revenue: The programmatic revenue mechanics that depend on the registration pipeline that structured data keeps running.
• Programmatic Monetization: The Complete Publisher's Guide to Maximizing Ad Revenue: Full-stack programmatic strategy for publishers, including how identified audiences command higher CPMs.
• PARMM Dimension 6: First-Party Data Strategy for Publishers. Identity, Privacy, and Revenue: How first-party data strategy fits into the broader publisher ad revenue management model.

Registration-Gated Content

Registration walls use the same structured data pattern as paywalls. The distinction between "pay to access" and "register to access" is irrelevant to the markup; both are access-restricted content from Google's perspective.

For registration-gated content:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Your Article Headline",
  "isAccessibleForFree": false,
  "hasPart": {
    "@type": "WebPageElement",
    "isAccessibleForFree": false,
    "cssSelector": ".registration-gate"
  }
}
 

One additional consideration for registration walls: the non-dismissible nature of many registration prompts means Googlebot will encounter the wall on every crawl. Correct structured data is what keeps this from triggering anti-cloaking flags. The markup is your declaration to Google that the restriction is intentional and disclosed.

Multiple Content Sections

Some publishers gate portions of an article while leaving others free. A sports site might give away the summary but gate the advanced statistics. An education publisher might leave the lesson intro accessible while gating the full curriculum content.

The hasPart property accepts an array, so you can mark up multiple sections:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Your Article Headline",
  "isAccessibleForFree": false,
  "hasPart": [
    {
      "@type": "WebPageElement",
      "isAccessibleForFree": true,
      "cssSelector": ".free-preview"
    },
    {
      "@type": "WebPageElement",
      "isAccessibleForFree": false,
      "cssSelector": ".subscriber-content"
    }
  ]
}
 

The free section gets isAccessibleForFree: true. The gated section gets false. Google uses both signals together to understand the content structure.

Be consistent. If .free-preview appears in the markup as freely accessible, the actual .free-preview div needs to be visible to all users without any JavaScript-driven hiding or registration prompts. Inconsistency between the markup and the rendered page is exactly what anti-cloaking detection looks for.

Anti-Cloaking Compliance

Google's anti-cloaking policy prohibits showing different content to Googlebot than to users. This creates real tension for paywalled publishers: your technical implementation needs to show Googlebot the full article text for indexing purposes, but you also need to hide that text from anonymous users on the front end.

The structured data resolves this tension. With isAccessibleForFree: false in place, Google understands that the discrepancy between what the crawler sees and what the user sees is intentional and declared, not deceptive.

The requirements for anti-cloaking compliance:

• Consistent HTML source: The full article content must be present in the HTML source that Googlebot receives. Don't server-side render a stripped version for crawlers.
• CSS or JavaScript hiding only: Gate the content visually using CSS or JavaScript that fires after the HTML is loaded. Googlebot receives the full HTML before the JavaScript paywall activates.
• Matching cssSelector: The selector in your structured data must match the element that actually wraps the gated content. A mismatch signals inconsistency.
• No user-agent detection: Never serve Googlebot a different HTML response than you serve to regular users. The correct approach is serving the full content in HTML for everyone, then using client-side code to show the wall.

The server-side approach that explicitly blocks content from Googlebot. Where the HTML itself contains no article text for crawler user agents. Will trigger anti-cloaking flags even with correct structured data in place. Structured data documents your access model; it doesn't override Google's requirement that crawlers receive the same HTML response as users.

Next Steps:

• How to Set Up Google Reader Revenue Manager: Step-by-step from Publisher Center configuration through code placement. The implementation that your structured data needs to accompany.
• Google Subscription Linking Implementation Guide: swg.js, PPIDs, and the Revenue Case for Building It Right: Full RRME architecture including PPID generation strategy and the Google Cloud project setup that unlocks programmatic lift.
• From Anonymous to Known: How Identified Readers Translate to Higher Ad Revenue: The revenue mechanics that activate once your structured data and registration infrastructure are correctly in place.
• Google Reader Revenue Manager Standard vs. Enterprise: Which Version Do You Actually Need?: Feature and engineering lift comparison to help you decide which RRM path fits your current infrastructure.
• Surveys as First-Party Data: Turning RRM Surveys Into an Audience Intelligence Engine: How to collect audience segmentation data through RRM surveys and activate it in Google Ad Manager.

Implementation Placement and AMP Considerations

Place the JSON-LD block in the <head> section of each article page. It can also appear in the <body>, but <head> placement is consistent with Google's examples and reduces the risk of rendering issues affecting schema parsing.

For publishers running both desktop and mobile canonical pages as separate HTML documents, the structured data must appear on both. If you serve the same HTML to all devices, one implementation covers both.

AMP is a separate issue. Google Reader Revenue Manager code snippets are not valid AMP, and the standard isAccessibleForFree implementation assumes a non-AMP page with JavaScript paywall activation. If you're running a hybrid AMP/non-AMP setup, implement the structured data on your canonical non-AMP pages. AMP has largely been phased out as a meaningful traffic driver, and maintaining AMP pages creates more complexity than it resolves.

Validation and Monitoring

Two tools. Use both.

Google's Rich Results Test (search.google.com/test/rich-results) validates your structured data and shows whether Google can parse the isAccessibleForFree markup correctly. Paste your article URL or the raw JSON-LD. Look for the "Subscribed content" result type. If the test returns errors or the subscribed content type doesn't appear, your markup has a problem.

The Subscribed Content report in Google Search Console tracks indexing health for your gated content at scale. Find it under Enhancements > Subscribed Content. The report surfaces:

• Valid pages: Correctly marked-up articles that Google has indexed
• Valid with warnings: Markup present but with potential issues to review
• Errors: Pages with invalid or missing markup where Google cannot determine the access model

Run a crawl of your full article archive after initial deployment. Any article published before you added the structured data needs to be recrawled before the Subscribed Content report will reflect current markup status. Request indexing for high-priority pages via URL Inspection in Search Console rather than waiting for the regular crawl cycle.

Check the report weekly for the first month after deployment, then monthly once the error count is near zero. New article templates, CMS updates, and theme changes can silently break the JSON-LD block, and the Subscribed Content report will surface those breaks before they affect rankings.

See It In Action:

• Gaming Publisher First-Party Data: Identity, Segmentation, and CPM Lift: How gaming publishers connect gated content and registration infrastructure to measurable CPM gains in programmatic auctions.
• Publishers Turn Community Data Into Revenue as Third-Party Limits Bite: Real publisher examples of first-party data strategies driving revenue as cookie-based targeting shrinks.
• Key Takeaways From the Jounce Media March 2025 Report: Industry-level data on the programmatic landscape shifts driving the case for first-party identity infrastructure.
• Best Publisher Ad Monetization Platform: Complete Evaluation Guide: How to evaluate monetization partners on their ability to activate first-party data alongside technical infrastructure like structured data and PPIDs.

Common Implementation Errors

Most implementations fail in predictable ways. These are the patterns worth auditing against:

• Missing structured data on older articles: The markup needs to be retroactively applied to your full article archive. Implementing it only on new content leaves your existing inventory unprotected.
• cssSelector mismatch: The selector in the JSON-LD doesn't match the class or ID in the HTML. This is the single most common implementation error, and it silently breaks the anti-cloaking compliance signal.
• Omitting hasPart entirely: Some implementations include isAccessibleForFree: false at the top level but skip the hasPart block. Google needs both to understand which specific element is gated.
• Setting isAccessibleForFree: true on gated content: This appears in implementations where a developer confuses the property direction. true means freely accessible to everyone. If the content is behind a wall, the value is false.
• Server-side content stripping: Delivering stripped HTML to Googlebot while serving full HTML to logged-in users is cloaking, regardless of structured data. The fix is client-side gating only.

Frequently Asked Questions

Does isAccessibleForFree improve SEO rankings, or does it just prevent penalties?

It's primarily a defensive signal, not an offensive one. Correct implementation prevents Google's anti-cloaking systems from penalizing your site and keeps your gated content eligible for indexing. It does not itself boost rankings. Its role is to maintain search visibility and avoid negative ranking effects, not produce uplift. Think of it as insurance: you notice its value when something goes wrong without it.

Do I need isAccessibleForFree for a registration wall, or only for a paid paywall?

Both. Google treats registration-gated and subscription-gated content the same way at the markup level. If users must take any action, pay, register, or verify an email. To access the content, set isAccessibleForFree: false and include the hasPart block. Skipping the markup on a registration wall exposes you to the same anti-cloaking risk as skipping it on a paid paywall.

What's the difference between isAccessibleForFree and hasPart? Do I need both?

Yes, you need both. isAccessibleForFree: false on the top-level schema object tells Google the overall article is not freely accessible. The hasPart block with its own isAccessibleForFree: false and a cssSelector tells Google exactly which DOM element contains the restricted content. Without hasPart, Google knows content is gated but can't identify which part of the page it applies to. Both properties working together is what enables full-article indexing with correct access model signaling.

Should the value be a boolean (false) or a string ("False")?

Use the boolean false, not the string "False". Schema.org defines isAccessibleForFree as a Boolean type. While some parsers are lenient, the correct form per the Schema.org specification and Google's structured data documentation is the JSON boolean false, without quotes.

Does isAccessibleForFree affect Google Discover eligibility?

Not directly. The markup itself doesn't block or enable Discover surfacing. What it does affect is whether your gated content stays correctly indexed, and indexed content is what Discover pulls from. Publishers using Subscription Linking through Google Reader Revenue Manager Enterprise should note that linked subscribers see their content in a dedicated "From your subscriptions" Discover section regardless of this markup. For broad Discover eligibility, correct indexing is the prerequisite, and correct isAccessibleForFree implementation is what keeps gated content indexed. For a full breakdown of what Google Subscription Linking does and doesn't do for publishers, that's covered separately.

Does isAccessibleForFree work for non-news schema types like Article or BlogPosting?

Yes. Every competitor article on this topic focuses on NewsArticle, but the property applies across content types. Article, BlogPosting, ScholarlyArticle, and other subtypes of CreativeWork all support isAccessibleForFree. Gaming sites gating premium guides, education platforms gating curriculum content, and sports publishers gating advanced statistics all have the same implementation path: substitute the appropriate @type. For gaming publishers specifically, the first-party data and identity strategy for gaming publishers covers how gated content connects to CPM lift in that vertical.

Is it cloaking to let Googlebot see content that regular users can't?

No, provided you implement isAccessibleForFree: false correctly. Google's flexible sampling model explicitly permits Googlebot to index full article text even when anonymous users see a wall. The structured data is your declared signal that the discrepancy is intentional. What remains prohibited is user-agent detection: serving different HTML to Googlebot versus users. The correct approach is serving full content in HTML to everyone, then using client-side JavaScript or CSS to activate the wall for non-credentialed users.

How Playwire Approaches This

Publishers running on our RAMP platform have structured data and gated content handled as part of the technical infrastructure, not as an afterthought. When you're deploying registration walls or metered access models alongside a monetization stack, the structured data and the ad configuration need to coexist correctly. The registered-user cohort is also the highest-value programmatic audience, and you don't want either system creating problems for the other.

Our yield ops team and technical solutions engineers review site architecture holistically. That includes making sure isAccessibleForFree markup is correctly deployed and consistent with your access model, that the gated content is properly indexed, and that the identifiers generated through registration flow correctly into first-party data and ad targeting infrastructure.

The broader picture: a registration wall that works correctly generates the first-party identifiers that drive CPM lift on cookie-less inventory. The structured data keeps that content indexable, which keeps traffic coming in to hit the wall. Each piece depends on the others being correct. Getting the schema markup right is the foundation that makes the rest of the stack worth building.

If you want to understand how identified readers translate to higher ad revenue once the structured data and registration infrastructure are in place, that's the natural next step after implementation. Running gated content and want a technical review of your structured data implementation alongside your monetization setup? Reach out to our team.