Lingue

Paywall e SEO

Come mantenere i contenuti dietro paywall o registrazione indicizzabili senza cloaking: campionamento flessibile, markup isAccessibleForFree/cssSelector, la trappola del paywall JavaScript e la strategia di metering.

Prima pubblicazione: 3 lug 2026 · Ultimo aggiornamento: 3 ago 2026 · Advanced
Lingue
AIScritto daAI v2

Un paywall non danneggia di per sé la SEO: Google non ha pregiudizi verso i contenuti a pagamento, e i più grandi editori con paywall si posizionano bene. Ciò che danneggia è che Google non riesca a vedere abbastanza contenuti per capire la pagina. La soluzione supportata è il campionamento flessibile: lascia che Googlebot esplori l'articolo completo, poi dichiara la parte a pagamento con dati strutturati (isAccessibleForFree più un cssSelector). Questa è un'eccezione esplicita e autorizzata al cloaking: il cloaking riguarda l'intento di ingannare; questo è un meccanismo dichiarato. Usa il metering (inizia con circa 6-10 articoli gratuiti al mese) o il lead-in, applica il paywall lato server (non con JavaScript che nasconde semplicemente il contenuto nel DOM), dai alle pagine di login testi unici e non usare mai robots.txt per nascondere URL privati.

TL;DR — I paywall non danneggiano di per sé il posizionamento; è Google che non riesce a vedere i tuoi contenuti a causare problemi. Il modello supportato è il campionamento flessibile — metering o lead-in — dichiarato con dati strutturati (isAccessibleForFree: false più un hasPart/cssSelector che contrassegna la sezione a pagamento, solo selettori di classe). Questa dichiarazione è ciò che rende servire a Googlebot l’articolo completo non cloaking: il cloaking richiede l’intento di manipolare e ingannare, e la policy antispam di Google esclude esplicitamente i paywall da quella definizione. Applica il gate lato server (l’aggiornamento della documentazione del 2025 e l’avvertimento di Mueller sullo screen reader mirano entrambi allo stesso errore di nascondere tramite JS), fornisci alle pagine di login testi unici, non usare mai robots.txt per URL privati, e usa noarchive per impedire che una copia cache faccia trapelare il testo completo. I muri di registrazione usano lo stesso markup di quelli a pagamento.

Cosa causa realmente problemi di posizionamento (non è il gate)

L’idoneità al paywall dipende da contenuti indicizzabili e markup accurato; la sola presenza di un paywall non è documentata come penalità. 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 Le scelte di campionamento restano decisioni dell’editore con compromessi per utenti e business. 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 non ha alcuna penalità per i contenuti a pagamento, e l’hub principale di questo articolo lo dice chiaramente: i contenuti protetti da gate vanno bene purché Google possa leggerli tramite l’approccio supportato. La modalità di fallimento è a monte del posizionamento — è la comprensione. Se Googlebot vede solo un teaser, quello è tutto ciò che può indicizzare e per cui può posizionarti. Ogni tecnica qui sotto esiste per risolvere un problema: far leggere al motore l’intero contenuto, mentre gli utenti umani non autenticati incontrano comunque il gate.

Due limiti vale la pena dichiarare chiaramente, poiché è facile eccedere in entrambe le direzioni. Primo, questo markup è uno strumento per contenuti che vuoi indicizzare sotto un gate dichiarato — non un meccanismo per esporre contenuti che non vuoi affatto indicizzare. Gli URL privati di account/admin sono un caso diverso (vedi l’albero decisionale sotto): quelli ricevono noindex o un redirect di autenticazione, non isAccessibleForFree. Secondo, markup valido e accesso completo alla scansione non sono una garanzia di posizionamento. Le linee guida sui dati strutturati di Google dicono direttamente che “Google does not guarantee that features that consume structured data will show up in search results” — il markup è la dichiarazione che ti tiene fuori dalla categoria del cloaking, non una promessa di indicizzazione, posizionamento, traffico o risultato avanzato.

Storicamente è qui che arriva il più grande racconto ammonitore. Quando il Wall Street Journal uscì dal vecchio programma First Click Free di Google nel 2017, riportò un calo di circa il 44% nel traffico di ricerca Google — non perché i paywall siano penalizzati, ma perché Google non poteva più vedere gli articoli. (Maggiori dettagli su First Click Free sotto; è storia, non policy attuale.)

Campionamento flessibile: metering e lead-in

Il modello attuale e attivo è il campionamento flessibile, descritto nelle linee guida sul Flexible Sampling di Google. Google descrive due tipi di campionamento: “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.”

I numeri che contano, tutti dalla documentazione di Google:

  • Preferisci la misurazione mensile a quella giornaliera. Google: “In generale, riteniamo che la misurazione mensile, piuttosto che quella giornaliera, offra maggiore flessibilità e un ambiente più sicuro per i test.” Una variazione di una sola unità è molto meno brusca con 10 campioni mensili che con 3 giornalieri.
  • Inizia con circa 6–10 articoli gratuiti al mese. “Come punto di partenza per le tue esplorazioni, ti incoraggiamo a fornire 10 articoli al mese… per la maggior parte degli editori di notizie quotidiane, prevediamo che il valore si collochi tra 6 e 10 articoli per utente al mese.”
  • Osserva il tetto di esposizione. “La nostra analisi mostra che la soddisfazione generale degli utenti inizia a degradarsi in modo significativo quando i paywall vengono mostrati più del 10% delle volte (il che generalmente significa che circa il 3% del pubblico è stato esposto al paywall).”
  • L’introduzione è una buona pratica. Mostrare le prime frasi sopra il paywall consente agli utenti di “sperimentare il valore del contenuto.”

Nessuno di questi numeri è un obbligo. Google dice direttamente: “Non esiste un valore unico per un campionamento ottimale tra diverse aziende” — la cifra di 6–10/mese è un punto di partenza che Google fornisce specificamente per gli editori di notizie quotidiane, e anche questo arriva con “lasciamo il numero esatto alla discrezione dei singoli editori, che sono nella posizione migliore per comprendere le esigenze particolari delle loro attività.” Trattalo come un intervallo di partenza testato, non come una regola da copiare alla lettera.

Il punto sottovalutato: la misurazione non è puramente una leva di monetizzazione. Google apre il documento notando che “anche piccole modifiche ai livelli di campionamento attuali potrebbero degradare l’esperienza utente e, poiché l’accesso degli utenti è limitato, influenzare involontariamente il ranking degli articoli nella Ricerca Google.” Restringere il contatore può costarti silenziosamente posizionamenti.

Perché questo non è cloaking — il ragionamento, non solo la regola

Questa è la parte portante dell’intero argomento, e la maggior parte delle guide afferma la conclusione (“i paywall non sono cloaking se usi i dati strutturati”) senza mostrare perché. Ecco il ragionamento effettivo, direttamente dalle politiche sullo spam di Google.

Inizia con la definizione. Il cloaking è “la pratica di presentare contenuti diversi a utenti e motori di ricerca con l’intento di manipolare i ranking di ricerca e ingannare gli utenti.” Il peso è su quella clausola — intento di manipolare e ingannare. Un paywall non cerca di ingannare nessuno; sta monetizzando i contenuti, e dichiara la differenza di trattamento attraverso il markup.

Poi l’esenzione esplicita, nella stessa politica: “Se gestisci un paywall o un meccanismo di gating dei contenuti, non consideriamo questo cloaking se Google può vedere il contenuto completo dietro il paywall proprio come qualsiasi persona che ha accesso al materiale riservato e se segui le nostre linee guida generali sul Flexible Sampling.”

Quindi l’eccezione ha due condizioni: (1) Google vede lo stesso contenuto completo che vedrebbe un abbonato pagante, e (2) segui il flexible sampling — che in pratica significa i dati strutturati di seguito. Il documento di Google sul flexible sampling rafforza la stessa logica: “Includi i contenuti dietro paywall con dati strutturati per aiutare Google a distinguere i contenuti dietro paywall dalla pratica del cloaking, dove il contenuto servito a Googlebot è diverso dal contenuto servito agli utenti.” I dati strutturati sono la dichiarazione che trasforma “contenuti diversi per i bot” da inganno in un meccanismo divulgato e autorizzato.

Implementazione dei dati strutturati

Il markup si trova nel documento di Google su Abbonamenti e contenuti dietro paywall. Due proprietà fanno il lavoro:

  • isAccessibleForFree (Boolean, obbligatorio) — indica se il contenuto è gratuito o a pagamento. Il reference delle proprietà di Google lo indica come obbligatorio; impostalo sul nodo di livello superiore CreativeWork/NewsArticle e su ogni sezione a pagamento.
  • hasPart (consigliato, non obbligatorio) — un array di oggetti WebPageElement, uno per sezione a pagamento, ciascuno con il proprio isAccessibleForFree: false e un cssSelector che punta alla classe con cui hai avvolto l’HTML a pagamento. È così che dici a Google quale parte del contenuto è a pagamento quando si tratta di una sezione e non dell’intero pezzo; è il modo consigliato per ottenere precisione a livello di sezione, non una seconda proprietà obbligatoria accanto al flag di livello superiore.

Un NewsArticle minimale si presenta così:

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

Tre dettagli di implementazione su cui le persone inciampano:

  • Solo selettori di classe. Il cssSelector “fa riferimento al nome della classe che hai impostato nell’HTML.” Usa .paywall — non un ID (#paywall), non un selettore discendente o di attributo.
  • Più sezioni a pagamento usano un array di oggetti hasPart, ciascuno con il proprio selettore basato su classe. Non annidare le sezioni a pagamento l’una dentro l’altra.
  • Non è solo per le notizie. Il markup è supportato su qualsiasi sottotipo di CreativeWork — Article, NewsArticle, Blog, Comment, Course, HowTo, Message, Review, WebPage. Le linee guida più ampie sui dati strutturati trattano isAccessibleForFree come una proprietà generale di CreativeWork, non solo per le notizie.
  • Un markup corretto non garantisce un risultato. Anche un markup completamente valido e correttamente annidato rende Google solo idoneo a comprendere il tuo paywall — non è una garanzia di ranking o di rich result. Tratta il markup come il meccanismo che ti tiene fuori dalla categoria del cloaking, non come una promessa di un risultato specifico.

I paywall per la registrazione usano il markup identico. Google non distingue “paga per accedere” da “registrati per accedere” a livello di schema. John Mueller ha detto altrettanto su Search Off the Record: il meccanismo “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.” (traduzione) «Potrebbe essere che richiedi un accesso, magari richiedi un pagamento, magari dopo un certo numero di iterazioni pensi: “Oh, questo è abbastanza contenuto gratuito.” Ora devi pagare… Può essere semplicemente qualcosa come un accesso o qualche altro meccanismo che fondamentalmente limita la visibilità del contenuto.» Se lo rendi a pagamento, contrassegnalo — a pagamento o no. Segnala anche i test A/B sui prezzi come motivo valido: “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.” (traduzione) «Se hai qualcosa come soglie diverse in cui dici che alcune persone possono visualizzare cinque pagine gratuitamente e altre hanno l’intero contenuto disponibile gratuitamente perché stai facendo test A/B… allora vorresti usare i dati strutturati per il paywall.»

La trappola del paywall JavaScript

Ecco l’errore più comune nel mondo reale, ed è distinto dal “dimenticare i dati strutturati.” Molte soluzioni di paywall inviano l’articolo completo nell’HTML che il server invia, poi usano JavaScript per nasconderlo finché lo stato dell’abbonamento non è confermato. Google ha avvertito esplicitamente di questo in un’aggiunta del 2025 al suo documento sulla risoluzione dei problemi JavaScript: “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.” (traduzione) «Alcune soluzioni di paywall JavaScript includono il contenuto completo nella risposta del server, poi usano JavaScript per nasconderlo finché lo stato dell’abbonamento non è confermato. Questo non è un modo affidabile per limitare l’accesso al contenuto. Assicurati che il tuo paywall fornisca il contenuto completo solo una volta che lo stato dell’abbonamento è confermato.»

Perché è negativo su tre fronti:

  1. È banalmente aggirabile. Disabilita JavaScript e l’articolo “nascosto” è proprio lì nel sorgente. Non stai realmente bloccando nulla.
  2. Offusca l’eccezione del cloaking. Se il testo completo è nel DOM per tutti, Google non può distinguere chiaramente quale contenuto era destinato a essere bloccato — che è esattamente ciò che la dichiarazione di dati strutturati dovrebbe chiarire.
  3. È un problema di accessibilità. Mueller ha sollevato proprio questo in 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.” (traduzione) «quando un utente guarda la tua pagina, non carichi il contenuto nell’HTML, ma ti assicuri che non sia davvero caricato nel DOM della pagina, così che, se un browser ha qualcosa come… uno screen reader, lo screen reader non vada a leggere tutto questo testo che stai cercando di nascondere… assicurati di non caricarlo nel browser e di usare JavaScript per attivarlo, ma che sia davvero servito all’utente solo quando vuoi renderlo disponibile.» L’aggiornamento del documento del 2025 e la cautela di Mueller sono lo stesso errore visto da due angolazioni.

La soluzione è il gating lato server: conferma lo stato di abbonamento/accesso sul server, e includi l’articolo completo nella risposta solo per gli utenti autenticati. Poi aggiungi isAccessibleForFree/cssSelector sopra così che Googlebot — che può vedere il testo completo con il campionamento flessibile — riceva comunque tutto, mentre gli umani non autenticati davvero non lo vedono. È anche qui che i paywall si intersecano con l’indicizzazione mobile-first: Google esegue la scansione e valuta la versione mobile, quindi il contenuto completo bloccato deve essere presente anche nella risposta mobile del server, non solo su desktop.

Pagine di accesso e barriere di registrazione: le insidie più silenziose

Due problemi distinti emergono attorno a login/registrazione, entrambi dallo stesso episodio di Search Off the Record.

Le pagine di accesso generiche vengono piegate nei duplicati. 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.” (traduzione) «se hai una pagina di accesso molto generica, vedremo tutti questi URL che mostrano quella pagina di accesso, che reindirizzano a quella pagina di accesso, come duplicati… Li uniremo come duplicati e ci concentreremo sull’indicizzazione della pagina di accesso… Se qualcuno cerca il tuo servizio… l’unica cosa… che trova nella ricerca è tipo ‘Ecco come accedere’, potrebbe essere un’esperienza un po’ strana per loro.» La soluzione è dare alle pagine di accesso contenuti contestuali unici per ogni servizio, così non sono tutte identiche.

Non usare robots.txt per URL privati. Questo contraddice un’intuizione comune. Mueller: “whether all of this should just be blocked by robots.txt, 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 noindex or redirect it to a login page somewhere. Don’t use robots.txt.” (traduzione) «se tutto questo dovrebbe essere semplicemente bloccato da robots.txt, che è un’altra strategia comune… Il problema, penso, nel farlo è che gli URL potrebbero diventare indicizzabili, quindi non vedremmo i contenuti della pagina di accesso… se è contenuto privato, servilo con un noindex o reindirizzalo a una pagina di accesso da qualche parte. Non usare robots.txt.» Un URL bloccato da robots può comunque essere indicizzato come URL nudo e senza contenuto — spesso peggio di un noindex pulito. (Questo è contenuto genuinamente privato, che è un caso diverso dal contenuto a pagamento ma che dovrebbe essere indicizzato; non confondere i due.)

Test e la preoccupazione della “perdita”

Testa con il Rich Results Test. Google ha aggiunto il supporto per i contenuti a pagamento al Rich Results Test nell’ottobre 2023, quindi valida isAccessibleForFree/cssSelector su un URL live, testando come Googlebot desktop o smartphone. Come ha detto Mueller in un office-hours del 2020, “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.” (traduzione) «useresti il rich results test, come qualsiasi altro tipo di dati strutturati… la parte complicata con alcune di queste implementazioni di paywall è che Googlebot, ovviamente, deve essere in grado di vedere il contenuto completo.»

Il trucco dell’autovalutazione: apri una finestra in incognito (disconnesso da tutto), cerca il tuo marchio o servizio e guarda cosa appare. Il consiglio di Mueller — “Se il primo risultato è qualcosa come una pagina di accesso e non c’è alcuna informazione su questa pagina, allora probabilmente è qualcosa che puoi migliorare.”

Mostrare a Googlebot l’articolo completo è “dispersivo”? No. Danny Sullivan, il Search Liaison di Google, ha affrontato la preoccupazione ricorrente che questo esponga contenuti a pagamento: “Il nostro sistema cerca di vedere il contenuto completo, se un editore vuole farlo. Se lo fa, ne capiamo di più. Se capiamo di più, allora potremmo essere in grado di mostrarlo per più query dove è rilevante,” e “Dato che solo noi lo vediamo, non c’è nulla di ‘dispersivo’ come suggerisci.” Il vero vettore di dispersione, ha notato, è la copia cache — risolta con noarchive, un controllo separato dal markup del paywall stesso. Le osservazioni di Sullivan sono riportate tramite la copertura di Search Engine Roundtable; trattale come riportate piuttosto che come trascrizione di prima parte.

L’approccio di Bing

La guida di Bing su abbonamenti e paywall (Fabrice Canel, maggio 2022) è strutturalmente simile ma non incentrata sullo schema. I suoi tre punti: (1) lascia che Bingbot indicizzi il contenuto completo dietro paywall, (2) usa noarchive/nocache (o l’header X-Robots-Tag: noarchive) così che le copie cache non disperdano contenuti, e (3) verifica che il crawler sia genuinamente Bingbot controllando l’IP richiedente rispetto agli intervalli pubblicati da Bing — non fidandoti della stringa user-agent, che chiunque può falsificare. Non esiste un equivalente pubblicato da Bing per isAccessibleForFree/cssSelector; il modello di Bing è accesso-alla-ricerca-più-controllo-cache, mentre quello di Google è incentrato sul markup. Non dare per scontata la parità delle funzionalità.

First Click Free — storia, non politica

Vedrai ancora post di blog e risposte su forum che descrivono First Click Free come se fosse attuale. Non lo è. Google l’ha ritirato nell’ottobre 2017, sostituendolo con il campionamento flessibile. Richard Gingras, allora VP delle News di Google: “In primo luogo, il campionamento flessibile sostituirà First Click Free. Gli editori sono nella posizione migliore per determinare quale livello di campionamento gratuito funziona meglio per loro.” First Click Free richiedeva agli editori partecipanti di permettere ai visitatori provenienti da Google di leggere un numero prestabilito di articoli al giorno (comunemente tre) anche oltre il loro paywall. Il campionamento flessibile ha restituito quella decisione agli editori. Se vedi FCF citato come qualcosa a cui puoi aderire oggi, quella guida è obsoleta da più di otto anni.

Dove si colloca nella SEO per le news

La gestione del paywall è un pezzo del quadro più ampio della SEO per News e Discover — insieme alle sitemap per le news, all’idoneità per Google News/Top Stories, a Discover e alla sindacazione (canonical vs. noindex). Se sei un editore, sistema il markup del paywall e la tua politica di sindacazione prima che uno dei due ti costi silenziosamente indicizzazione o attribuzione.

Add an expert note

Pin an expert quote

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