Paywalled Content SEO: Index Without Cloaking

The page returns a 200. The headline renders. Googlebot reads about forty words, hits a subscribe button, and leaves. Six weeks later the flagship investigation that used to rank third for its head term sits on page four, and nobody on the team can point at a single deploy that caused it.

This is the most common way subscription businesses lose search traffic. Not a penalty. Not a core update. A wall that was built in a hurry, by engineers told to stop the leak, with no one asking what Google would see on the other side. Paywalled content fails in search for mechanical reasons, almost never editorial ones.

Here is the part that surprises most people. Google has said, in writing, that gating your content is fine. A paywall is not cloaking. The spam policies carve out an explicit exception for it. What trips sites up is never the decision to charge. It is the plumbing underneath.

What will you actually get out of this guide?

You are going to leave with a working model of how Google treats content readers cannot freely reach, and a rollout you can hand to an engineer on Monday. We will cover the exact structured data properties Google asks for and what each one does. We will look at the two sampling models Google endorses, and how many free articles the documentation actually recommends. And we will cover how to let Googlebot through your wall without handing the same key to every scraper on the internet.

Four things in here run against the usual advice. First, the markup is a compliance signal, not a ranking feature, and teams that ship it expecting a traffic bump are misreading it. Second, lead-in-only walls are often the worst option for search even though they feel like the safest one. Third, most B2B teams are gating the wrong asset entirely. Fourth, the reflex to block AI Overviews from your paid work usually costs more than it protects.

Your main objection is probably this. If Google can read it, can a reader spoof their way in and read it free? Short answer, yes, a determined one can, and we will deal with that trade-off honestly rather than pretending the risk is zero. Scope note. This guide is about Google Search indexing of paid and gated pages. If your question is whether to let AI training crawlers near that same content, that is a different decision, and our guide to whether to block AI crawlers like GPTBot in robots.txt handles it properly.

What actually counts as paywalled or gated content?

Google groups three things together here. Content behind a payment, content behind a subscription, and content behind a registration form where no money changes hands. All three are cases where a reader must do something before they see the full page. Google's guidance treats them the same way, which means a free whitepaper behind an email form sits under exactly the same rules as a newspaper article behind a credit card.

That last point catches B2B marketers off guard. They assume the paywall documentation is a media-industry thing. It is not. Google's subscription and paywalled content documentation states plainly that it applies when users must register for access to any content you want indexed. A gated ebook and a metered news article are the same technical problem wearing different clothes.

Within that, four patterns dominate in the wild. A hard wall shows a headline and nothing else. A metered wall lets a reader consume a set number of pieces before it closes. A dynamic wall decides per reader using behavioral signals. A registration wall asks for an email instead of a payment. Each one sends a different amount of text to the browser, and that difference is what determines whether the page has enough substance to rank at all.

Is putting up a paywall cloaking?

No, and Google says so in the spam policies themselves. The policy states that operating a paywall or a content-gating mechanism is not considered cloaking if Google can see the full content behind it just as any person with access can, and if you follow the flexible sampling guidance. The exception is conditional. Break either condition and you are back in cloaking territory.

Read those two conditions again, because the whole article hangs on them. Google must see the full content, and it must see the same full content a paying subscriber sees. Serving Googlebot a keyword-stuffed variant, an older version, or a stripped copy is not sampling. That is the behavior the Google Search spam policies define as cloaking, which is presenting different content to users and search engines with intent to manipulate rankings.

This exception has history. Until October 2, 2017, Google ran a program called First Click Free that forced publishers to open a fixed number of articles per day to anyone arriving from search. Publishers hated the loss of control. Google replaced it with flexible sampling, which handed the numbers back to the publisher. Search Engine Land and Nieman Lab both covered the switch at the time. Google's vice president for news, Richard Gingras, named the early test partners to Search Engine Land. They were The New York Times and the Financial Times. The practical legacy is that you now choose your own sampling model, and Google asks only that you declare it.

What structured data does a paywalled page need?

You mark the page with CreativeWork or one of its supported subtypes, set the isAccessibleForFree property to false at the page level, and then add a hasPart block that points at the gated section. Inside hasPart you declare the type as WebPageElement, set cssSelector to the class name wrapping the locked text, and set that section's own isAccessibleForFree to false as well.

Google's documentation, last updated on 2026-09-08, lists the supported types explicitly. CreativeWork itself, plus Article, NewsArticle, Blog, Comment, Course, HowTo, Message, Review, and WebPage. You can combine types on one item when a page is genuinely two things at once. The isAccessibleForFree property comes from schema.org, where it is a boolean available on CreativeWork, Event, and Place, and where it supersedes an older term simply called free.

Two rules break more implementations than anything else. Use only class selectors in cssSelector, never an id or an element selector. And do not nest one declared section inside another. If your template wraps the locked region in a div that already sits inside a declared parent, your markup will validate and still describe the wrong boundary. Run the result through the Rich Results Test, which Google names as the validation step on that page. If the output looks wrong, our guide to debugging structured data errors walks through the diagnosis, and the broader complete JSON-LD schema markup guide covers how the surrounding graph should be shaped.

Now the contrarian bit. This markup does not rank you. It does not unlock a rich result. It has one job, which is to tell Google that the gap between what the crawler sees and what a logged-out human sees is intentional and declared. Teams ship it, watch the dashboard, and conclude it did not work. It did work. It just is not a growth lever. Read the subscription and paywalled content documentation with that framing and it makes far more sense.

Should you meter, or show a lead-in?

Metering gives each reader a quota of full articles per period before the wall appears. Lead-in shows every reader the opening of every article and stops there. Google endorses both under flexible sampling. For search performance specifically, metering is usually the stronger choice, because a metered page can serve the whole article to a crawler while a lead-in page structurally cannot.

Here is the mechanism almost nobody explains. Google's JavaScript troubleshooting documentation states that HTTP cookies and local and session storage are cleared across page loads. Googlebot carries no state between requests. So a meter that counts consumption in a cookie never advances for Googlebot. Every crawl looks like a first visit, the counter reads zero, and the full article gets served without you writing a single line of bot-detection code.

Lead-in walls have no such escape hatch. If the server only ever emits three paragraphs, three paragraphs is all Google ever gets. Barry Adams of SEO for Google News has argued this point for years, writing that lead-in-only paywalls generally perform worse because the shorter text carries fewer signals for Google to judge quality against. I agree with him, and I would put it more bluntly. A lead-in wall asks Google to rank an article it has never read.

Model	What Googlebot receives	Best suited to	Main risk
Metered	The complete article, because the counter never advances for a stateless crawler	Daily news and high-volume publishing	Readers learn to clear cookies or browse privately
Lead-in	Only the visible opening, unless you add server-side crawler access	Deep archives and premium research	Too little text to compete for competitive terms
Hard wall	Headline and teaser only, unless explicitly opened	Trade data and proprietary research nobody else has	Near-total loss of long-tail organic discovery
Registration	Whatever you choose to render before the form	B2B lead generation and community sites	Friction with no revenue behind it to justify the cost

Methodology note on that table. The Googlebot column reflects Google's documented statelessness plus its published paywall guidance, not a crawl test of any specific site. Your own server logs are the only authority on what your stack actually emits.

How many free articles should you actually give away?

Google's flexible sampling guidance, last updated 2025-12-10, recommends 6 to 10 free articles per user per month for daily news publishers, and suggests starting at 10. It prefers monthly metering over daily. It also warns that general user satisfaction starts to degrade significantly when paywalls are shown more than 10 percent of the time.

That 10 percent ceiling is the most actionable number in the whole document and the most widely ignored. It is not a search directive. It is a product warning. Work it backwards. If your site serves a million article views a month, more than a hundred thousand paywall impressions puts you in the zone Google flags as corrosive to satisfaction. I suspect a lot of sites sit well past that line without knowing it, and read the resulting bounce rate as a content problem instead.

Google's reasoning for monthly over daily metering is worth internalizing. Moving from ten free monthly articles to nine is a small change in reader experience. Moving from three free daily articles to two is enormous. Monthly meters give you a dial with fine gradations. Daily meters give you a switch. Monthly metering also concentrates the wall on your most engaged readers. Those are the readers most likely to convert. Newer readers still get room to find out whether your work is worth paying for. The flexible sampling guidance is short and worth reading in full.

Consider a worked example. A regional publisher running a five-article daily meter almost never walls a casual reader, because casual readers rarely open five pieces in one day. It does not wall the loyalist either, because tomorrow the counter resets to five. Switch to a ten-article monthly meter and the casual reader still sails through untouched. The reader who visits daily now hits the wall in the first third of the month. That is precisely when a subscription offer lands best. Same casual experience, very different targeting.

What breaks when the paywall runs in JavaScript?

Client-side paywalls fail in two directions. Either they send the full text to the browser and hide it with CSS, so anyone can read it in view-source. Or they withhold it properly, and Google's renderer may never see it either. Google's guidance is conditional. If you do not want the content reaching the browser, it says to choose an implementation that does not send it there.

The hide-with-CSS pattern is depressingly common because it is the fastest thing a front-end developer can ship. It also converts nobody, because your most valuable readers are exactly the ones who know how to open developer tools. If you are building the wall in JavaScript, the gated text has to be fetched after an authentication check, from an endpoint that refuses unauthenticated requests.

That immediately raises the rendering question. Google queues pages for rendering after the initial crawl, and anything that depends on a successful client-side fetch is a dependency Google might not resolve. Our explainer on how Google renders JavaScript covers why pages vanish this way. My honest recommendation is to move paywall logic to the server or to the edge. Decide at request time who gets the full document, and emit a complete HTML response either way. The wall becomes a rendering decision rather than a client-side trick, and the failure modes drop dramatically.

Also check what status code you return. A gated page should still return 200 with its teaser and markup intact. Returning a 401 or 403 to crawlers takes the page out of the index entirely, which is a different outcome than most teams intend. Our reference on which HTTP status code to return has the full decision tree.

How do you let Googlebot in without opening the door to everyone?

Verify the crawler, do not trust it. Google documents two approved methods. Run a reverse DNS lookup on the requesting IP and confirm the hostname resolves to googlebot.com, google.com, or googleusercontent.com, then run a forward lookup to confirm the IP matches. Or, for scale, match the IP against Google's published JSON range files. Never grant access on the user agent string alone.

A user agent is a text field anyone can type. Whitelisting on it is the same as leaving the door unlocked and putting up a sign asking people not to come in. Google's verification documentation, updated 2026-03-20, publishes machine-readable lists including common-crawlers.json and special-crawlers.json, which is what you want for a production access-control layer.

Make sure the allowance covers Googlebot-News too if you publish anything that belongs in the news ecosystem. The paywall documentation names it specifically. If Top Stories matters to your business, our guide to winning a place in Google News and Top Stories covers the surrounding requirements.

Now the honest trade-off. Once you let verified Googlebot read everything, your full text exists in Google's systems, and a technically capable person can approximate crawler conditions well enough to read some of it. Every publisher who indexes paid content accepts this. The question is not whether leakage is possible. It is whether the organic discovery you gain outweighs the small fraction of readers who will bother. For most subscription businesses I think the discovery is worth far more than the leak. If it does not for you, the correct answer is a hard wall with a genuinely useful teaser, not a half-measure.

Should B2B teams gate whitepapers behind a form at all?

Usually not the whitepaper itself. Gate the thing that only makes sense with the reader's own inputs. A benchmark comparison, a pricing calculator, a template pack configured to their stack. Publish the research openly so it can rank, earn links, and get cited, then ask for the form on the asset that genuinely requires knowing who they are.

Here is the arithmetic nobody runs before building the form. A gated PDF that captures 200 emails a month feels like a win on the dashboard. The ungated version of the same research might attract organic sessions indefinitely, earn references from other sites, and get quoted in AI answers, all of which compound. The form captures a moment. The indexed page captures a stream. Most teams are optimizing the moment because it is the one their attribution model can see.

There is a middle path worth trying. Publish the full narrative as an HTML page and gate only the downloadable artifact, the spreadsheet, or the raw dataset. Google indexes real content. Your form still captures people who want the working file. You stop asking a search engine to rank a landing page whose only unique content is a form label. Our guides to B2B SEO built around buyers and SaaS SEO measured in pipeline rather than traffic both dig into how to value those two outcomes against each other.

If you do keep the gate, at least reduce it. Ask for what you need to route the lead, not what would be nice to have in the CRM. Every additional field is a tax on the same traffic you paid to acquire, which is squarely the territory covered in our conversion rate optimization guide.

How do you stop AI Overviews from giving away what you sell?

Google's robots meta tag documentation, updated 2026-03-24, states that nosnippet prevents content being used as a direct input for AI Overviews and AI Mode, and that max-snippet with a character limit restricts how much may be used. The data-nosnippet attribute does the same job for a specific span, div, or section. These are preview controls, not indexing controls, so the page stays indexed either way.

That distinction matters enormously and gets muddled constantly. Applying nosnippet does not remove your page from search. It removes the text preview. Which means it also removes the ordinary snippet that persuades people to click in the first place. You are trading click-through rate for protection against summarization, and on a paywalled page where the snippet is often the only free text a searcher sees, that trade can be expensive.

My recommendation is surgical rather than blanket. Leave the lead-in snippetable, because it is your shop window. Apply data-nosnippet to the specific paragraphs that carry the conclusion, the number, or the scoop. You keep the invitation and withhold the payoff. A max-snippet limit set generously enough for a compelling preview but short enough to be useless as a substitute is the other lever worth testing.

Do not confuse any of this with noindex, which removes the page altogether, or with robots.txt, which blocks crawling before indexing is even considered. Those mechanics are laid out in our guide to robots.txt, meta robots and noindex directives. And if your worry is that summaries are eating your traffic generally, our survival guide for zero-click search frames the wider problem.

How do you measure whether the wall is costing you rankings?

Instrument the boundary, not the totals. Compare crawled-and-indexed status for gated URLs against comparable ungated ones in Search Console. Watch average position on the gated cohort specifically. Then reconcile against your own logs to confirm verified Googlebot is receiving the full response body and not the teaser. Aggregate sessions will never tell you which side of the wall the problem sits on, so measure paywalled content as its own cohort.

The single highest-value check is a server-log comparison. Pull requests from verified Googlebot IPs to a sample of gated URLs and record the response byte size. If the bytes match what a logged-out human gets, your access layer is not working, no matter what the markup says. This is a ten-minute check that catches the majority of broken implementations, and almost nobody runs it.

Then layer on the reporting. Use the URL Inspection tool for coverage status on individual gated pages rather than inferring from impressions, because low-volume pages get censored in aggregate reporting. Our practitioner's guide to Search Console covers the distinction. Confirm the gated section is discoverable at all with the approach in our guide to XML sitemaps and the Indexing API. And because subscription businesses live or die on logged-in behavior that analytics platforms handle badly, our work on first-party data measurement is directly relevant here.

What are the failure modes that quietly kill paywalled indexing?

Six failures are worth checking before anything else. Blocking the gated path in robots.txt. Returning 401 or 403 to crawlers. Declaring the wrong cssSelector after a template change. Sending the full text to the browser and hiding it visually. Whitelisting on the user agent string. And declaring isAccessibleForFree as false on pages that are actually free.

The robots.txt own goal

Someone disallows the subscriber path to keep bots off the member area, and takes every gated article with it. Google cannot honor your paywall markup on a URL it is not allowed to fetch. Check your disallow rules against your gated URL patterns before anything else.

The template drift problem

Your cssSelector points at a class name. A redesign renames that class. The markup still validates because the property is syntactically fine, but it now describes a region that does not exist. This is the failure that degrades silently over months, which is exactly the pattern we describe in the context of content decay and refreshing. Add an assertion to your build that fails if the declared class is absent from the rendered template.

The over-declaration problem

Marketing decides everything should look premium, so isAccessibleForFree gets set to false site-wide, including on free posts. Now you are telling Google that content anyone can read is gated. It is inaccurate, and inaccurate structured data is not a good look on a domain trying to build the trust signals covered in our guide to E-E-A-T and the authority Google rewards.

A regional note

European publishers running consent management platforms have an extra layer to check. A consent gate that blocks rendering before the paywall logic runs will starve the crawler. Your markup can be perfect and it will still not help. And if you sell subscriptions into Korea, remember that Naver, Korea's home-grown search engine, runs its own index with its own rules, so a correct Google implementation buys you nothing there.

What does a sensible 30-day rollout look like?

Week one, audit what the crawler currently receives. Week two, fix access and status codes. Week three, ship and validate the structured data. Week four, set your sampling numbers and start measuring. Do them in that order, because markup on top of a broken access layer is decoration.

In week one, pull verified Googlebot requests from your logs for a sample of gated URLs and compare response sizes against logged-out requests. Confirm no disallow rule covers the gated paths. Record current position and coverage for a fixed cohort of twenty gated URLs so you have a real baseline rather than a memory. Budget half a day.

In week two, move paywall logic server-side or to the edge if it is currently client-side, implement IP-based or reverse-DNS crawler verification, and make sure every gated page returns 200 with a substantive teaser. This is the engineering-heavy week. Budget three to five days depending on your stack.

In week three, add isAccessibleForFree and the hasPart declaration with a cssSelector that matches your actual template, validate with the Rich Results Test, and add a build-time assertion on the class name. Budget one day, plus a code review.

In week four, choose your meter, monthly rather than daily, and start at ten if you publish daily. Set your preview controls deliberately rather than by default. Then leave it alone for six weeks. Indexing changes on gated content are slow, and the urge to keep tuning is the enemy of knowing what worked. If you publish an email edition, this is a good time to look at turning email archives into indexable pages. Those archives are often the ungated counterweight a subscription site needs.

Frequently asked questions

Does Google rank paywalled content lower than free content?

There is no documented ranking penalty for gating content. Google's spam policies explicitly permit paywalls and content gating. What changes is the evidence Google has to work with. A page that serves the crawler four hundred words instead of two thousand competes with less substance behind it. It also earns fewer links, because fewer people can read and reference it. So the effect on paywalled content is real. It just comes from reduced signals, not from a rule that punishes paid work.

Will adding isAccessibleForFree improve my rankings?

No, and you should not budget for it as though it will. The property tells Google that the difference between what the crawler sees and what a logged-out visitor sees is deliberate and declared. It protects you from being read as cloaking. It does not unlock a rich result, a badge, or a ranking boost. Teams that ship it and then look for a traffic lift are measuring the wrong thing. Ship it because it keeps you compliant, then look for gains elsewhere.

Can I just show Googlebot the full article and readers the teaser?

Yes, provided you declare it with the paywall structured data and follow the flexible sampling guidance. That is precisely the carve-out Google's spam policies describe. The catch is that the content you serve the crawler must be identical to what a paying subscriber sees. The moment it diverges, by being longer, keyword-enriched, or a different version entirely, you have crossed from a declared paywall into cloaking, and that is a policy violation with real consequences.

How many free articles per month should I offer?

Google's flexible sampling guidance recommends 6 to 10 per user per month for daily news publishers and suggests starting at 10. It prefers monthly over daily metering because monthly gives you finer control when testing. It also cautions that user satisfaction degrades significantly once paywalls appear more than 10 percent of the time. Those numbers are a starting point, not a law. Google itself notes there is no single optimal sampling value across different businesses.

Does a metered paywall block Googlebot automatically?

Not if the meter counts using cookies or browser storage. Google documents that HTTP cookies and local and session storage are cleared across page loads, so the crawler carries no state between requests. Every crawl reads as a first visit and the counter sits at zero. That is why metered walls tend to index cleanly with no special handling. If your meter counts server-side against an IP or a fingerprint instead, you do need explicit crawler handling.

What happens if I block AI crawlers but allow Googlebot?

Those are separate decisions with separate controls. Blocking a training crawler in robots.txt has no effect on Google Search indexing, because Googlebot is a different agent. However, Google's own AI surfaces are governed by preview controls rather than by blocking, so nosnippet and max-snippet are the relevant levers there. Blocking AI crawlers also removes you from answer surfaces your future subscribers increasingly use, which is a genuine trade-off rather than a free win.

Should a registration wall use the same markup as a paywall?

Yes. Google's documentation covers cases where users must register for access to any content you want indexed, whether or not money is involved. A free ebook behind an email form is technically the same situation as a subscription article. Declare it the same way. Personally I think most registration walls are harder to justify than paywalls. A paywall has revenue on the other side of the friction. A registration wall has a contact record.

Can I use an id selector instead of a class in cssSelector?

No. Google's documentation says to use only class selectors for that property. It also says not to nest content sections inside one another. Both rules exist so the boundary between free and gated text is unambiguous. An implementation using an id will often still validate, because the syntax is legal, which makes this one of the quieter ways a paywall implementation ends up wrong. Check the rendered markup, not just the template source.

Will a paywall hurt my chances in Google News or Top Stories?

Not inherently. Google's paywall guidance specifically mentions making sure Googlebot-News can reach your pages where applicable, which signals that gated journalism is expected in that ecosystem. Plenty of subscription publishers appear in Top Stories. What hurts is a wall that prevents the news crawler from reading the article at all, or an access layer that treats Googlebot-News differently from Googlebot. Verify both agents can fetch the complete article body.

How long until I see the effect of fixing a broken paywall setup?

Longer than you want. Google has to recrawl the affected URLs, re-render them where JavaScript is involved, and reassess pages it previously saw as thin. On a large archive that is weeks rather than days, and the recovery arrives unevenly because recrawl frequency varies enormously by URL. Resist the urge to keep changing things while you wait. Fix it once, verify at the log level that the fix is live, then hold steady for at least six weeks.

Where to start tomorrow

Go back to that flagship investigation sitting on page four. Before you touch the markup, before you argue about the meter, pull your server logs and find a verified Googlebot request to that exact URL. Look at the response size. If it matches what a logged-out reader receives, you have found your answer in ten minutes. Every structured data ticket in your backlog was going to be decoration on a broken foundation.

That is the priority order for paywalled content, and it does not change. Access first. Status codes second. Markup third. Sampling numbers last. The teams that get paywalled content indexed well are not the ones with the cleverest schema. They are the ones who checked what the crawler actually received before they built anything on top of it.

My prediction for the next couple of years is that the interesting fight moves from indexing to previewing. Getting gated pages into the index is a solved problem with documented answers. Controlling how much of your paid work gets summarized into an answer you are not paid for is not solved at all, and the preview controls are a blunt instrument for it. Publishers who learn to use data-nosnippet surgically, paragraph by paragraph, will have an edge over the ones who flip nosnippet on site-wide and wonder where their clicks went.

So here is my question for you. If you had to choose today between full snippet visibility and full protection of your best paragraphs, which way would you go, and what number in your own reporting would make you change your mind?