Paywalls y SEO: cómo indexar contenido tras el muro de pago

Cobrar por leer no te saca de Google. Servirle al rastreador lo que el lector no ve, sí. Un paywall SEO bien hecho son tres etiquetas y una decisión de producto: qué marcar, cuánto regalar y qué no debe viajar al navegador.

Qué cuenta como "contenido tras el muro" para Google

Google usa una expresión amplia: contenido que exige una suscripción o un registro. Cubre tres casos. Suscripción de pago, típica de un diario o una newsletter premium. Muro de registro, donde el informe o el curso se entrega a cambio de un correo. Y contenido parcial, con el primer tercio libre y el resto bloqueado.

El matiz que ordena lo demás es que Google no distingue cobrar de pedir datos: su guía habla de acceso por suscripción o de páginas donde el usuario debe registrarse, y aplica el mismo tratamiento. Para el rastreador, un formulario es un muro igual que una pasarela de pago. Y hay una condición previa: la guía solo aplica a contenido que quieres indexar. Si no debe aparecer, no marques nada y usa noindex o desindexa.

El riesgo no es perder posiciones: es que te lean como cloaking

El miedo habitual es "Google me va a bajar". El problema real es que tu implementación entre en la definición de cloaking: mostrar contenido distinto a usuarios y buscadores con la intención de manipular el ranking y engañar al lector.

La política de spam trae la excepción, y es la frase que hay que memorizar: un paywall no se considera cloaking si Google puede ver el contenido completo tras el muro igual que cualquier persona con acceso al material, y si sigues las recomendaciones de muestreo flexible. Dos condiciones, no una. Si falla cualquiera, vuelves al terreno del cloaking.

El patrón que rompe la regla es el más común del mercado: paywalls por JavaScript que incluyen el artículo completo en la respuesta y luego lo ocultan con un script hasta confirmar la suscripción. La guía de problemas de JavaScript lo dice sin rodeos: no es una forma fiable de limitar el acceso. La consecuencia típica no es una penalización sonora, sino señales contradictorias: una página que se renderiza distinto en cada inspección y fragmentos que muestran lo que el usuario no puede leer.

Cómo marcar el muro con datos estructurados

El marcado le dice a Google "esto es contenido de pago legítimo, no un truco". La propiedad obligatoria es isAccessibleForFree en false a nivel del artículo. Las recomendadas son hasPart con tipo WebPageElement, su propio isAccessibleForFree en false y un cssSelector que apunte a la clase del bloque de pago.

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

Las reglas duras se incumplen con facilidad: en cssSelector solo valen clases, nunca identificadores ni combinaciones; no se anidan secciones; y el marcado debe estar en todas las versiones, AMP y no AMP. Los tipos admitidos son CreativeWork y sus derivados (artículo, noticia, blog, curso, guía práctica, reseña, página web), así que sirve para un blog o un informe, no solo para un diario. Con varias secciones de pago, hasPart pasa a ser un arreglo con un elemento por clase.

Para validar alcanza el Rich Results Test, con la advertencia que la guía repite: Google no garantiza que las funciones que consumen datos estructurados aparezcan en los resultados.

Lo que el marcado no resuelve

No desbloquea clics, no cambia el fragmento y no impide que otro copie el texto. Solo clasifica la página. Para el resto están las guías de datos estructurados y de rich snippets.

Flexible Sampling: cuánto contenido regalar antes del muro

El muestreo flexible tiene dos modelos oficiales. El metering entrega una cuota de artículos por usuario antes de exigir suscripción o login. El lead-in deja visible una parte del artículo por encima del muro. Ambos son legítimos y Google los describe como buenas prácticas, no como concesiones al rastreador.

Tres cifras salen de la guía. Para la mayoría de los medios diarios, el valor esperado cae entre 6 y 10 artículos por usuario al mes. La recomendación de partida es ofrecer 10 mensuales a quienes llegan desde la búsqueda e iterar desde ahí. Y el umbral de paciencia: la satisfacción general empieza a degradarse de forma significativa cuando el muro se muestra más del 10% de las veces, lo que suele equivaler a un 3% de la audiencia expuesta.

Ese 10% es de vistas, no de usuarios: un lector fiel que choca veinte veces pesa más que veinte lectores que pasaron una vez. De ahí que el muestreo mensual supere al diario, porque pasar de 10 a 11 al mes se nota mucho menos que pasar de 3 a 4 al día. Si no eres un diario, esas cifras son solo un punto de partida.

Muros de registro y lead magnets: qué indexar de verdad

Fuera de los medios, el caso más común es el recurso a cambio de correo: el PDF de 40 páginas, la plantilla, el informe técnico. La respuesta correcta casi siempre es la misma: indexa la página que describe el recurso, no el archivo.

Esa landing necesita texto real, no solo un formulario: su propio título, un resumen honesto de qué contiene y qué problema resuelve. El formulario es un paso del recorrido, no la página. Cuando la portada se limita a "Descarga el informe" con dos líneas de relleno, el resultado es contenido pobre que desperdicia la única página que podía posicionar.

Si el recurso se publica como HTML tras el registro, aplica el mismo marcado del apartado anterior. Si es un PDF, el tema está en PDF y SEO. En un SaaS, esa landing compite por la misma keyword que el blog: ver SEO para SaaS.

Implementar el muro sin romper el rastreo

Hay un solo principio: el mismo HTML para todos. La cantidad de texto se decide en el servidor; lo que queda tras el muro no viaja al navegador hasta que exista una sesión válida.

Con AMP el camino es amp-subscriptions, y el endpoint de autorización debe dar acceso a los rastreadores correspondientes. La guía avisa de un detalle que genera errores difíciles de leer: la política de acceso a bots debe ser idéntica en AMP y en no AMP, o Search Console reporta desajustes de contenido.

Para comprobarlo están la API de inspección de URL, que muestra el HTML que recibe Google, y la verificación de rastreadores, que descarta que un CDN sirva otra cosa. Un muro que responde 403 al rastreador saca la página del índice. Y la prueba casera: desactiva JavaScript y abre el artículo. Si se lee completo, el paywall no existe.

Controlar la vista previa: data-nosnippet y max-snippet

La guía cita dos herramientas para el fragmento. El atributo data-nosnippet excluye secciones concretas del texto que Google puede mostrar. La meta max-snippet limita cuántos caracteres puede usar.

Honestidad sobre su alcance: sirven para el fragmento, no desindexan ni bloquean el acceso. Lo que no quieres que se lea no debe llegar al navegador. Para las respuestas generativas, la documentación indica que están sujetas a los mismos controles, sin interruptor aparte, como se detalla en el informe de IA generativa de Search Console.

Errores frecuentes y cómo detectarlos con Search Console

Seis fallos cubren casi todo lo que se ve en producción, cada uno con su síntoma:

• Muro duro con noindex heredado de la plantilla. Páginas de pago fuera del índice sin que nadie lo decida.
• robots.txt con Disallow sobre URLs de suscriptores. Quedan indexadas pero bloqueadas, y el rastreador no ve el contenido.
• HTML completo servido a todos. Sin error en Search Console: el síntoma es un fragmento con el texto de pago. Se detecta buscando la clase del muro en el código fuente.
• cssSelector con identificador o selector compuesto. El marcado se ignora y el validador lo señala.
• Secciones de pago anidadas. El marcado queda inválido.
• Artículo entero marcado como paywall, sin lead-in. No hay fragmento útil y el CTR se hunde.

Para revisar en lote, la API de inspección de URL permite pasar cientos de direcciones sin abrir una por una.

Checklist de paywall SEO antes de publicar

Ocho comprobaciones de una línea, en orden:

1. ¿La página se indexa y queremos que se indexe?
2. ¿El HTML que recibe Google es el mismo que recibe un suscriptor?
3. ¿Está isAccessibleForFree en false en el marcado del artículo?
4. ¿El cssSelector usa solo clases y sin anidar?
5. ¿Hay lead-in suficiente para que el fragmento tenga sentido?
6. ¿Cuántos artículos gratis al mes y con qué criterio se eligió el número?
7. ¿AMP y no AMP tienen la misma política de acceso a bots?
8. ¿El fragmento está limitado donde hace falta?

Si las ocho están bien, el muro deja de ser un riesgo técnico y vuelve a ser una decisión de negocio. Y si alguien promete que el marcado "desbloquea" posiciones, recuerda la otra frase de la guía: el contenido de pago se marca para no confundirse con cloaking.