Free Subscription and Paywall Schema Generator

Fill in the facts visible on your page, copy the Subscription and Paywall JSON-LD, and validate it before you publish. The guide, examples, and FAQs are below the tool. Generate this schema with AI

Type to filter 121 supported schema types.

Schema workflow

Use only facts a visitor can verify on the page, then validate the JSON-LD before publishing.

Check if readers can access the full content without a subscription.

Required

  • Visible Subscription and Paywall content
  • Canonical page URL
  • Clear page owner/publisher
  • Fields that match the visible page

Recommended

  • A representative image when the schema supports it
  • SameAs or related links when visible
  • Validation before publishing

Avoid

  • Adding properties that are not visible
  • Copying example URLs into production
  • Skipping Google and Schema.org validation

Schema stacks

Use Subscription and Paywall schema in a stack

Complete JSON-LD bundles that combine Subscription and Paywall with the other types a real page needs. Browse all stacks

  • Live Coverage Stack

    LiveBlogPosting pages with breadcrumb, speakable selectors, and paywall/access signals when applicable.

  • Publisher Schema Stack

    NewsArticle + Breadcrumb + Speakable + SubscriptionAndPaywall signals for publisher pages that need clarity, eligibility, and access control.

Next step

Validate, repair, and publish clean structured data.

Check the generated JSON-LD against the visible page, then run both SwiftSchema and external validators before publishing.

Subscription & Paywall Schema Generator — Be Honest About Gated Content

Use isAccessibleForFree and WebPageElement selectors to show exactly which sections require a subscription. Protect premium content while staying eligible for Google news features.

Try the Paywall Generator

Why paywall markup gets ignored

  • Teaser copy mentions a paywall, but the schema never sets `isAccessibleForFree`, so Google assumes the page is fully open and may penalize the experience.
  • Developers wrap premium sections with dynamic IDs or hashed CSS classes, so selectors break during every redesign.
  • Metered models (e.g., 3 free articles) aren’t documented anywhere, confusing both readers and reviewers.
  • Editorial teams worry paywall schema will hurt rankings, so they skip it altogether instead of treating it as transparency.

How SwiftSchema simplifies gated content disclosure

Our generator ensures every Article or NewsArticle entry explicitly states whether it is accessible for free and which DOM nodes represent the premium portion.

Guided prompts help you capture gating strategy (hard paywall, metered, registration wall) and align it with your UX so structured data never contradicts the on-page experience.

Documentation fields remind you to coordinate with subscription engineering teams, making sure selectors persist even if you refactor components or switch paywall vendors.

How it works

  1. 01

    Select Subscription & Paywall in the generator.

  2. 02

    Identify the page entity (Article/NewsArticle/WebPage) and set `isAccessibleForFree` to true or false based on the default experience.

  3. 03

    Add a `hasPart` WebPageElement for each gated section, including `isAccessibleForFree: false` plus a CSS selector that points to the paywalled container.

  4. 04

    Document teaser vs. gated copy inside the CMS so editors know what remains visible.

  5. 05

    Export JSON‑LD, attach it to the article template, and test via Rich Results or URL Inspection anytime the paywall script changes.

Ready to build the markup?

Disclose gated sections. Validate. Ship.

Generate Paywall JSON‑LD

What is Subscription & Paywall structured data?

Subscription and paywall markup communicates to Google which parts of a page require payment or sign-in. It relies on two pieces: the page-level isAccessibleForFree flag (typically on an Article) and a nested hasPart WebPageElement that marks the container with isAccessibleForFree: false. By pointing to the actual DOM nodes that hide behind the paywall, you reassure Google that your implementation complies with their policies for flexible sampling, First Click Free alternatives, or subscriber-only experiences.

Eligibility & status

Paywall markup is a limited enhancement, but Google expects publishers with gated content to use it. Eligibility requires that your markup accurately describes the user experience; if you claim an article is free but block it with a paywall, you could receive manual actions. The page should already have valid Article/NewsArticle schema, clear authorship, and consistent metadata. Selectors must resolve in the rendered DOM for anonymous users (even if the content hides behind a lightbox). Keep paywall scripts accessible so Googlebot can interpret the structure without executing login-only APIs.

Why paywall markup matters

  • Trust & compliance: Google’s news surfaces rely on clear disclosure to avoid surprising readers.
  • Policy protection: Transparent markup helps avoid manual actions tied to cloaking or misleading sampling implementations.
  • Team coordination: Schema acts as living documentation linking editorial, growth, and engineering. Everyone can confirm what is free vs. paid.
  • Analytics clarity: With consistent isAccessibleForFree flags you can segment paywalled traffic vs. open articles using structured data in analytics proxies or data layers.
  • Flexible sampling readiness: If you operate metered models or limited previews, schema clarifies what’s available to non-subscribers.

Essential properties to include

  • @type: Typically NewsArticle or Article on the main entity.
  • isAccessibleForFree: false for fully gated pages, true for free content. For metered models, set true but describe the limit in copy.
  • hasPart: Use WebPageElement with isAccessibleForFree: false and cssSelector (or xpath) pointing to the paywalled container.
  • cssSelector: Provide stable classes or IDs (e.g., .paywall-body, #subscriber-content) that persist through builds.
  • datePublished, dateModified, headline, image, author, publisher: ensure Article schema is complete so paywall data layers on top.
  • Optional: isPartOf (for sections), inLanguage, about, keywords, audience, and offers (for subscription packages).

Preparing paywall information before generating schema

  1. Catalog UX variants: Document hard paywall, meter, registration wall, and premium tier templates. Each might need unique selectors.
  2. Coordinate with engineering: Confirm paywall scripts add consistent wrapper elements or data attributes that you can target without brittle hashed class names.
  3. Define teaser content: Work with editorial to decide which paragraphs stay free and ensure they match the DOM region outside hasPart.
  4. Outline subscription packages: Gather plan names, price points, and URLs. Consider adding Offer data when referencing subscription products in CTA modules.
  5. Establish review cadence: Paywall behavior often changes with experiments. Set a weekly QA check or integrate schema validation into deployment pipelines.
  6. Document access policies: Note whether search crawlers receive “first click free” access, a metered amount, or paywall immediately. This affects isAccessibleForFree.
  7. Assign data owners: Typically growth product managers or audience teams own gating logic; ensure they sign off on schema updates.

Implementation workflow inside SwiftSchema

  1. Choose the appropriate Article/NewsArticle template within the generator and fill standard metadata (headline, description, authorship, images, canonical URL).
  2. Set isAccessibleForFree to reflect default access. Explain metered behavior in the description if relevant.
  3. Add hasPart entries for each gated block (main story, charts, appendix). Provide cssSelector, optional xpath, and isAccessibleForFree: false.
  4. If you have multiple gating experiences (e.g., newsletter subscriber vs. paid subscriber), document them using additional WebPageElement entries with descriptive name fields.
  5. Include subscription offers or CTA modules in the schema if they are part of the page experience (e.g., Offer referencing price and signup URL).
  6. Export JSON‑LD, deploy through your CMS or tag manager, and run the Rich Results Test with the paywall overlay active so the tool sees the same DOM.

Troubleshooting & QA

  • Broken selectors: Whenever front-end engineers rename classes, update the selectors in schema. Use data attributes (e.g., data-paywall) to minimize breakage.
  • Mismatch between schema and reality: If you flag a page as free but show a paywall, Google may treat it as cloaking. Align the boolean with actual UX.
  • Metered confusion: For metered articles, keep isAccessibleForFree: true but describe the meter in visible copy and metadata.
  • Paywall popovers: If a modal covers the entire page, ensure the paywalled content still exists in the DOM and is referenced by selectors. Otherwise, add a placeholder explaining the gating.
  • Multiple paywalls: Some sites gate both text and multimedia. Add separate hasPart entries for each container so Google knows all restricted elements.

Maintenance and governance

  • Tie schema updates to your experimentation system: whenever a paywall test launches, confirm selectors and booleans still reflect the control experience.
  • Conduct monthly validations across key templates (hard paywall, meter, audio, video) to ensure CSS selectors still resolve.
  • Keep a shared doc listing selectors per template plus the owners who approve changes.
  • When migrating paywall vendors or frameworks, include structured data verification in the migration checklist before flipping traffic.
  • Track lastReviewed dates so newsroom leadership can confirm compliance for audits.

Common errors & quick fixes

  • Omitting hasPart: Setting isAccessibleForFree: false without pointing to the gated section leaves crawlers guessing. Always add the WebPageElement.
  • Targeting invisible wrappers: Selectors should reference the container that actually hides content, not a parent layout div.
  • Multiple conflicting booleans: Avoid one snippet saying free and another saying paid. Keep a single, authoritative schema block.
  • Forgetting https: Serve JSON‑LD over HTTPS and ensure paywall scripts load securely to avoid mixed-content warnings.
  • No governance: If nobody owns paywall schema, assign it today. Lack of ownership is the fastest route to inaccurate disclosures.

Required properties

  • isAccessibleForFree
  • hasPart.@type=WebPageElement
  • hasPart.isAccessibleForFree
  • hasPart.cssSelector

Recommended properties

  • @type=NewsArticle or Article
  • headline
  • datePublished
  • inLanguage
Article with Paywalled Section
Validate
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Advanced Schema Strategies",
  "isAccessibleForFree": false,
  "hasPart": {
    "@type": "WebPageElement",
    "isAccessibleForFree": false,
    "cssSelector": ".paywall"
  },
  "datePublished": "2025-09-01",
  "inLanguage": "en",
  "url": "https://example.com/articles/advanced-schema-strategies"
}

FAQs

How do I mark paywalled content?Show

Set `isAccessibleForFree` to `false` on the page entity (e.g., Article) and include `hasPart` as a `WebPageElement` with `isAccessibleForFree: false` and a `cssSelector` pointing to the paywalled section.

What should the CSS selector target?Show

Target the container element that holds the paywalled portion of the content so crawlers can understand which parts are not free.

Does this affect ranking?Show

This markup doesn’t guarantee ranking changes; it clarifies content access and supports eligibility for features that respect paywalls.

Related types

Browse all schema types

References