Idiomas

Paywalls e SEO

Como manter conteúdo com paywall e restrito por cadastro indexável sem cloaking — amostragem flexível, marcação isAccessibleForFree/cssSelector, a armadilha do paywall em JavaScript e estratégia de medição.

Publicado pela primeira vez: 3 de jul. de 2026 · Última atualização: 20 de ago. de 2026 · Avançado
Idiomas
AIEscrito porAI v2

Um paywall não prejudica o SEO por si só. O problema é o Google não conseguir ver conteúdo suficiente para entender a página. Use amostragem flexível: permita que o Googlebot rastreie o artigo completo e declare a parte restrita com dados estruturados (isAccessibleForFree e cssSelector). Essa é uma exceção explícita ao cloaking porque a barreira é declarada e não há intenção de enganar. Escolha medição — começando, para notícias diárias, com cerca de 6–10 artigos gratuitos por mês — ou prévia; aplique a restrição no servidor, dê texto exclusivo às páginas de login e nunca use robots.txt para ocultar URLs privadas.

TL;DR — Paywalls não prejudicam o ranking por natureza; o problema é o Google não conseguir ver o conteúdo. O modelo compatível é a amostragem flexível — medição ou prévia — declarada com dados estruturados (isAccessibleForFree: false e um hasPart/cssSelector para a seção restrita, somente com seletores de classe). Essa declaração impede que o envio do artigo completo ao Googlebot seja cloaking: cloaking exige intenção de manipular e enganar, e a política de spam exclui paywalls declarados. Restrinja no servidor, dê texto exclusivo às páginas de login, nunca bloqueie URLs privadas com robots.txt e use noarchive para evitar vazamento por cache.

O que realmente causa problemas de ranking (não é a barreira)

A elegibilidade de um paywall depende de conteúdo rastreável e marcação correta; sua mera presença não é documentada como penalidade. 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 A escolha da amostragem continua sendo decisão do publisher, com impactos para usuários e negócio. 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

O Google não aplica penalidade a conteúdo com paywall: conteúdo restrito funciona desde que o Google consiga lê-lo pelo método compatível. A falha ocorre antes do ranking — na compreensão. Se o Googlebot vê apenas uma prévia, só pode indexar e classificar por ela. Todas as técnicas abaixo resolvem o mesmo problema: o mecanismo lê tudo, enquanto pessoas não autenticadas continuam encontrando a barreira.

Vale explicitar dois limites. Primeiro, essa marcação serve para conteúdo que você quer indexar sob uma barreira declarada — não para expor conteúdo que deveria permanecer privado. URLs de conta ou administração são outro caso (veja a árvore de decisão): use noindex ou redirecionamento de autenticação, não isAccessibleForFree. Segundo, marcação válida e acesso completo ao rastreador não garantem ranking. As diretrizes dizem: “Google does not guarantee that features that consume structured data will show up in search results” (tradução) “O Google não garante que recursos que usam dados estruturados aparecerão nos resultados”. A marcação evita a classificação como cloaking; não promete indexação, ranking, tráfego ou resultado avançado.

A história traz o principal alerta. Quando o Wall Street Journal saiu do antigo programa First Click Free em 2017, relatou queda de cerca de 44% no tráfego da busca do Google — não porque paywalls fossem penalizados, mas porque o Google deixou de ver os artigos. Há mais sobre isso abaixo; é história, não política atual.

Amostragem flexível: medição e prévia

O modelo atual é a amostragem flexível, descrita nas diretrizes do Google. O Google define duas modalidades: “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.” (tradução) “medição, que oferece uma cota de artigos antes de exigir assinatura ou login; e prévia, que oferece parte do artigo sem mostrá-lo por inteiro”.

Os números relevantes, todos da documentação do Google:

  • Prefira medição mensal à diária. O Google afirma: “In general, we think that monthly, rather than daily metering provides more flexibility and a safer environment for testing.” (tradução) “Em geral, a medição mensal oferece mais flexibilidade e um ambiente de teste mais seguro do que a diária”.
  • Comece com 6–10 artigos por mês. Para publishers de notícias diárias, o Google recomenda começar nessa faixa e ajustar com experimentos.
  • Observe a frequência do paywall. A satisfação cai significativamente quando a barreira aparece em mais de 10% das vezes, o que costuma expor cerca de 3% do público à barreira.
  • Use a prévia com intenção. Mostrar algumas frases antes da barreira é uma boa prática; o Google não determina um número mínimo de palavras.

Nenhum desses números é obrigatório. O Google declara: “There is no single value for optimal sampling across different businesses.” (tradução) “Não existe um único valor de amostragem ideal para negócios diferentes”. O ponto de partida de 6–10 artigos refere-se a publishers de notícias diárias; teste a economia da sua assinatura, a frequência de visita e a combinação de conteúdo.

Um ponto pouco valorizado: medição não é apenas um controle de monetização. O Google abre a documentação observando que “even minor changes in the current sampling levels could degrade user experience and, as a result, unintentionally affect article ranking in Google Search.” (tradução) “até pequenas alterações nos níveis de amostragem podem piorar a experiência e, por consequência, afetar sem intenção o ranking”. Trate a cota como experimento de experiência e receita, não como constante.

Por que isso não é cloaking — o raciocínio, não apenas a regra

Essa é a parte central do tema, mas muitos guias apenas afirmam que “paywalls não são cloaking se houver marcação” sem explicar por quê. O raciocínio vem diretamente das políticas de spam do Google.

Comece pela definição. Cloaking é “the practice of presenting different content to users and search engines with the intent to manipulate search rankings and mislead users.” (tradução) “a prática de apresentar conteúdo diferente a usuários e mecanismos de busca com a intenção de manipular rankings e enganar usuários”. A diferença decisiva não é apenas o conteúdo recebido, mas a intenção de enganar.

Depois vem a exceção explícita na mesma política: “If you operate a paywall or a content-gating mechanism, we don’t consider this to be cloaking if Google can see the full content of what’s behind the paywall just like any person who has access to the gated material and if you follow our Flexible Sampling general guidance.” (tradução) “Não consideramos cloaking quando o Google vê o conteúdo completo como qualquer pessoa autorizada e a orientação de amostragem flexível é seguida”.

Portanto, a exceção tem duas condições: (1) o Google vê o mesmo conteúdo completo que um assinante pago e (2) a orientação de amostragem flexível é seguida. A marcação é a declaração verificável que liga essas condições. Sem conteúdo completo, o Google não compreende a página; sem declaração, a diferença de entrega fica ambígua.

Como implementar os dados estruturados

A marcação aparece na documentação Conteúdo por assinatura e com paywall. Há duas peças com níveis de exigência diferentes:

  • isAccessibleForFree (booleano, obrigatório) — informa se o conteúdo é gratuito ou restrito. A referência do Google marca essa propriedade como obrigatória; defina-a no nó principal CreativeWork/NewsArticle e em cada seção restrita.
  • hasPart (recomendado, não obrigatório) — uma lista de objetos WebPageElement que identifica as partes restritas, cada qual com isAccessibleForFree: false e um cssSelector baseado em classe.

Um NewsArticle mínimo tem esta forma:

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

Três detalhes de implementação costumam causar erros:

  • Somente seletores de classe. cssSelector “references the class name that you set in the HTML.” (tradução) “referencia o nome da classe definida no HTML”. Use .paywall, não um ID (#paywall) nem seletor descendente ou de atributo.
  • Várias seções restritas usam uma lista de objetos hasPart, cada um com seu seletor baseado em classe. Não aninhe seções restritas umas nas outras.
  • Não serve apenas para notícias. A marcação funciona em qualquer subtipo de CreativeWork: Article, NewsArticle, Blog, Comment, Course, HowTo, Message, Review e WebPage. A orientação trata isAccessibleForFree como propriedade geral de CreativeWork.
  • Marcação correta não garante resultado. Ela apenas torna a barreira legível para o Google; não garante ranking nem resultado avançado.

Barreiras de cadastro usam a mesma marcação. Para o schema, o Google não distingue “pagar para acessar” de “cadastrar-se para acessar”. John Mueller explicou no Search Off the Record que o mecanismo pode exigir login, pagamento ou atingir uma quantidade de conteúdo gratuito. Se houver barreira, marque-a, paga ou não. Ele também cita testes A/B com limites diferentes como motivo válido para usar dados estruturados de paywall.

A armadilha do paywall em JavaScript

O erro prático mais comum é diferente de esquecer os dados estruturados. Muitas soluções enviam o artigo inteiro na resposta HTML e então usam JavaScript para ocultá-lo até a confirmação da assinatura. O Google alertou contra isso em uma atualização de 2025 da documentação de solução de problemas de JavaScript: o conteúdo completo só deve ser fornecido depois que o status da assinatura for confirmado.

Isso é ruim em três frentes:

  1. É trivial contornar. Desative o JavaScript e o artigo “oculto” aparece no código-fonte. Não existe controle de acesso real.
  2. Confunde a declaração de paywall. O texto está presente para todos, então o Google pode não identificar com segurança qual parte deveria estar restrita.
  3. Prejudica a acessibilidade. Leitores de tela podem anunciar o texto oculto. No Search Off the Record de setembro de 2025, Mueller citou exatamente esse problema.

A correção é a restrição no servidor: confirme a assinatura ou o login no servidor e inclua o artigo completo na resposta somente para usuários autorizados (e para o Googlebot sob amostragem flexível). A atualização de 2025 da documentação afirma que soluções JavaScript não são confiáveis e que o conteúdo completo só deve ser fornecido depois da confirmação do status de assinatura. Em seguida, aplique isAccessibleForFree e cssSelector para declarar a barreira ao Googlebot.

Páginas de login e barreiras de cadastro: problemas menos óbvios

Dois problemas distintos de login e cadastro aparecem no mesmo episódio do Search Off the Record.

Páginas genéricas de login são agrupadas como duplicadas. Mueller explicou que, se todas as URLs privadas redirecionam para uma página de login muito genérica, o Google pode considerá-las equivalentes. Dê à página de login texto contextual próprio sobre o serviço, em vez de apresentar a mesma tela sem contexto para toda URL.

Não bloqueie URLs privadas com robots.txt. Embora pareça intuitivo, uma URL bloqueada ainda pode ser indexada como endereço vazio, sem conteúdo. Mueller recomenda noindex ou redirecionamento de autenticação. A ressalva: o Google precisa rastrear a URL para ver a diretiva; portanto, não a bloqueie simultaneamente no arquivo robots.

Testes e o receio de “vazamento”

Teste com o Rich Results Test. Em outubro de 2023, o Google adicionou suporte a conteúdo com paywall ao Rich Results Test. A ferramenta valida isAccessibleForFree/cssSelector em uma URL publicada como Googlebot para desktop ou smartphone. Como Mueller explicou, o ponto difícil é garantir que o Googlebot consiga ver o conteúdo completo.

Autoauditoria: abra uma janela anônima, pesquise sua marca ou serviço e observe o resultado. Uma página genérica de login aparece em vez das páginas úteis? URLs privadas aparecem sem título ou descrição? Esse teste revela duplicação de login e URLs bloqueadas no robots.txt melhor do que uma inspeção autenticada.

Mostrar o artigo completo ao Googlebot causa “vazamento”? Não. Danny Sullivan, representante da Busca do Google, respondeu ao receio de exposição do conteúdo pago: “Nosso sistema procura receber o conteúdo completo, se o publisher quiser mostrá-lo. Se entendermos mais, talvez possamos exibi-lo para mais consultas relevantes”, e “Como somente nós vemos isso, não existe o ‘vazamento’ sugerido”. O vetor real de vazamento, observou ele, é a cópia em cache — resolvida com noarchive, um controle separado da marcação do paywall. As declarações de Sullivan foram reproduzidas pela cobertura do Search Engine Roundtable; trate-as como relato, não como transcrição primária.

A abordagem do Bing

A orientação do Bing sobre assinaturas e paywalls é semelhante, mas não centrada em schema: permita que o Bingbot rastreie o conteúdo completo, use noarchive/nocache (ou o cabeçalho X-Robots-Tag: noarchive) para evitar vazamento por cache e confirme o IP do rastreador, não apenas o agente de usuário. Não há equivalente publicado do Bing para isAccessibleForFree/cssSelector; seu modelo combina acesso de rastreamento e controle de cache.

First Click Free — história, não política

Ainda existem posts que descrevem First Click Free como política atual. Não é. O Google encerrou o programa em outubro de 2017 e o substituiu pela amostragem flexível, permitindo que publishers escolham medição ou prévia. Qualquer checklist que exija um clique gratuito diário está desatualizado.

Onde isso se encaixa no SEO para notícias

O tratamento de barreiras pagas é uma parte do cenário mais amplo de otimização de conteúdo jornalístico e recomendações, junto de mapas de páginas jornalísticas, elegibilidade no serviço jornalístico e nas Principais matérias do Google, presença no espaço de recomendações e sindicação (URL preferencial versus exclusão do índice). Publicadores devem resolver a marcação da barreira e a política de sindicação antes que qualquer uma prejudique indexação ou atribuição.

Add an expert note

Pin an expert quote

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