Paywalls and SEO: how to get gated content indexed

Charging people to read does not get you dropped from Google. Serving the crawler what the reader cannot see does. A working paywall SEO setup is three tags and one product decision: what to mark, how much to give away, and what must never reach the browser.

What Google counts as gated content

Google uses a deliberately broad idea: content that requires a subscription or a registration before it can be read. That covers three situations. Paid subscription, the classic newspaper or premium newsletter. A registration wall, where the report or course is handed over for an email. And partial content, where the first third reads freely and the rest stays locked.

The detail that organizes everything else is that Google does not separate charging from data collection. Its guidance talks about subscription-based access or pages where users must register, and treats both the same way. To a crawler, a form is a wall just like a checkout page. There is also a precondition: the documentation only applies to content you want indexed. If the material should never appear in Google, mark nothing and apply noindex or deindex it.

The real risk is not lost rankings, it is being read as cloaking

The usual fear is "Google will push me down". The real problem is that your implementation falls inside the definition of cloaking: presenting different content to users and search engines with the intent to manipulate rankings and mislead users.

The spam policy carries the exception, and it is the sentence to memorize: a paywall is not considered cloaking if Google can see the full content behind the wall just like any person with access to the gated material, and if you follow the flexible sampling guidance. Two conditions, not one. Fail either and you are back in cloaking territory.

The pattern that breaks the rule is the most common one on the market: JavaScript paywalls that include the full article in the server response and then hide it with a script until the subscription is confirmed. Google's JavaScript guide is blunt: that is not a reliable way to limit access. The typical consequence is not an immediate, loud penalty but contradictory signals: a page that renders differently on each inspection, and snippets showing paragraphs the reader cannot open.

How to mark the wall with structured data

The markup is what tells Google "this is legitimate paid content, not a trick". The required property is isAccessibleForFree set to false at article level. The recommended ones are hasPart with type WebPageElement, its own isAccessibleForFree set to false, and a cssSelector pointing at the class of the paid block.

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

The hard rules are easy to break: cssSelector accepts class selectors only, never IDs or compound selectors; sections must not be nested; and the markup has to be present on every version of the page, AMP and non-AMP alike. Supported types are CreativeWork and its descendants: article, news article, blog, comment, course, how-to, review and web page. It works for a blog or a report, not just a newspaper. With several paid sections on one page, hasPart becomes an array with one element per class.

Rich Results Test is enough to validate, with the caveat the guidance repeats: Google does not guarantee that features consuming structured data will show up in search results.

What the markup does not fix

It does not unlock clicks, it does not change the snippet, and it does not stop anyone from copying the text. It only classifies the page. For the rest, see structured data and rich snippets.

Flexible Sampling: how much to give away before the wall

Flexible sampling has two official models. Metering gives each user a quota of articles before requiring a subscription or login. Lead-in shows a portion of the article above the wall. Both are legitimate, and Google describes them as good practice, not as a concession to the crawler.

Three concrete numbers come from the guidance. For most daily news publishers, the expected value falls between 6 and 10 articles per user per month. The starting recommendation is 10 monthly articles for users arriving from search, then iterate. And the patience threshold: general user satisfaction starts to degrade significantly when paywalls are shown more than 10% of the time, which generally means about 3% of the audience has been exposed.

That 10% is of pageviews, not of users: one loyal reader who hits the wall twenty times weighs more than twenty readers who passed once. That is why monthly sampling beats daily sampling, since going from 10 to 11 a month is barely noticeable compared with going from 3 to 4 a day. If you are not a daily publisher, those numbers are a starting point, not a rule.

Registration walls and lead magnets: what to index, really

Outside media, the most common case is the resource traded for an email: the 40-page PDF, the template, the technical report. The correct answer is almost always the same: index the page that describes the resource, not the file.

That landing page needs real text, not just a form: its own title, an honest summary of what the document contains and what problem it solves. The form is one step in the journey, not the page. When the landing is reduced to "Download the report" plus two filler lines, the result is thin content that wastes the only page that could have ranked.

If the resource is published as HTML after registration, the same markup from the previous section applies. If it is a PDF, see PDF SEO. In a SaaS product, this landing page competes for the same keyword as the blog: see SaaS SEO.

Implementing the wall without breaking crawling

There is one principle: the same HTML for everyone. How much text is delivered gets decided on the server; whatever sits behind the wall does not travel to the browser until there is a valid session.

With AMP the path is amp-subscriptions, and the authorization endpoint has to grant access to the relevant crawlers. The guidance flags a detail that produces hard-to-read errors: the bot access policy must be identical on AMP and non-AMP, or Search Console reports content mismatch between the two.

Two tools confirm it: the URL Inspection API to see the HTML Google receives, and crawler verification to rule out a CDN serving something else. A wall that answers 403 to the crawler drops the page from the index. And the home test: disable JavaScript and open the article. If it reads in full, the paywall does not exist.

Controlling the preview: data-nosnippet and max-snippet

The guidance names two tools for the snippet. The data-nosnippet attribute excludes specific sections from the text Google may display. The max-snippet meta tag caps how many characters it can use.

Be honest about scope: they shape the snippet, they do not deindex or block access. What you do not want read must not reach the browser. For generative answers, the documentation states they are subject to Search's preview controls, with no separate switch, as detailed in the Search Console generative AI report.

Common mistakes and how to spot them in Search Console

Six failures cover almost everything seen in production, each with its symptom:

• Hard wall plus template-inherited noindex. Paid pages drop out of the index and nobody decided it.
• robots.txt blocking subscriber URLs. They show up as indexed while blocked, and the crawler never sees the content.
• Full HTML served to everyone. No error in Search Console, but a snippet displaying the paid text. Open the source and search for the wall class.
• cssSelector using an ID or a compound selector. The markup is ignored and the validator flags it.
• Nested paid sections. The markup becomes invalid.
• Whole article marked as paid with no lead-in. No useful snippet and CTR collapses.

To check at scale, the URL Inspection API processes hundreds of addresses without opening them one by one.

Paywall SEO checklist before you ship

Eight one-line checks, in order:

1. Is the page indexed, and do we want it indexed?
2. Is the HTML Google receives the same a subscriber receives?
3. Is isAccessibleForFree set to false on the article markup?
4. Does the cssSelector use classes only, with no nesting?
5. Is there enough lead-in for the snippet to make sense?
6. How many free articles per month, and on what reasoning?
7. Do AMP and non-AMP share the same bot access policy?
8. Is the snippet limited where it needs to be?

Get those eight right and the wall stops being a technical risk and goes back to being a business decision. If someone promises that the markup "unlocks" rankings, remember the other line: paid content is marked to avoid being confused with cloaking.