¿Qué es pay per crawl?

Pay per crawl añade una tercera opción a la relación entre un sitio web y un rastreador de inteligencia artificial. Hasta ahora existían dos: permitir el acceso sin condiciones, o bloquearlo con robots.txt. Pay per crawl introduce «permitir, pero solo si se paga».

El mecanismo técnico es el código de estado HTTP 402, Payment Required. Es un código que existe desde los primeros estándares HTTP, pensado originalmente para algún sistema de micropago que nunca llegó a generalizarse, y que durante décadas apenas se ha usado en la práctica. Pay per crawl lo recupera: cuando un rastreador pide una página con este control activo, el servidor responde 402 en lugar de entregar el contenido, y adjunta el precio de esa visita en una cabecera. El rastreador puede repetir la petición aceptando pagar, o desistir.

No es un estándar del W3C ni del IETF con adopción amplia todavía: es un modelo, implementado hasta la fecha de esta redacción principalmente por un proveedor grande de infraestructura web, y su comportamiento exacto (cabeceras, firma, moneda) depende de cómo lo implemente cada proveedor. Para un sitio, esto cambia la lógica habitual de robots.txt: en lugar de una regla fija para todos, surge una lista de precios que puede variar de un rastreador a otro.

El flujo típico tiene dos variantes. En la reactiva, el rastreador pide la página sin avisar, recibe un 402 con el precio en una cabecera, y si acepta, repite la petición añadiendo una cabecera que confirma el pago. En la proactiva, el rastreador ya incluye de entrada una cabecera con el precio máximo que está dispuesto a pagar; si el precio fijado por el sitio no lo supera, recibe el contenido sin el paso intermedio del 402.

La identidad del rastreador se verifica con firmas criptográficas (HTTP Message Signatures con claves Ed25519), no con el user-agent, que se puede falsificar. El editor fija un precio por rastreo para todo el dominio y decide, rastreador por rastreador, entre permitir gratis, cobrar o bloquear.

Hasta la fecha de esta redacción, agosto de 2026, Cloudflare es el proveedor que ha implementado este modelo de forma pública, en fase de beta privada desde su anuncio del 1 de julio de 2025. El 1 de julio de 2026 anunció además que, a partir del 15 de septiembre de 2026, los rastreadores que combinan varios usos a la vez (por ejemplo, indexación para búsqueda y entrenamiento de modelos) quedarán bloqueados por defecto en las páginas con publicidad, salvo que el sitio cambie esa configuración. No hay constancia pública de que otros proveedores de CDN hayan lanzado una implementación equivalente a fecha de esta redacción, de modo que cualquier afirmación sobre el modelo en general es, por ahora, también una afirmación sobre esta implementación concreta.

El código 402 llevaba reservado y prácticamente sin uso desde que se definió el protocolo HTTP. Que un proveedor grande de infraestructura lo convierta en mecanismo activo, y que además anuncie un cambio en las opciones por defecto para septiembre de 2026, cambia la pregunta que se le plantea a cualquier sitio con tráfico de rastreadores de IA: ya no es solo «permito o bloqueo», sino «quién decide qué pasa si no configuro nada».

Para un editor o un sitio con contenido de valor, quedarse sin decidir tiene una consecuencia concreta a partir de esa fecha: algunos rastreadores pasarán a estar bloqueados por defecto en páginas con publicidad, y otros seguirán entrando gratis, según cómo el proveedor de infraestructura clasifique a cada uno. Configurar la política explícitamente, en lugar de dejar la opción por defecto, es la única forma de que la decisión sea la del sitio y no la del proveedor.

Para un cliente de ZDS con contenido editorial o de investigación propia, esto se traduce en una tarea concreta: revisar antes de esa fecha qué rastreadores de IA tienen acceso hoy, cuáles interesa seguir permitiendo gratis (por ejemplo, los que citan con enlace de vuelta) y cuáles conviene cobrar o bloquear.

• Revisa qué proveedor de CDN o de protección contra bots usa el sitio y si ya ofrece algún control de pago o bloqueo por tipo de rastreador de IA.
• No confundas pay per crawl con un firewall o un bloqueo general: solo actúa sobre las peticiones que llegan identificadas como rastreadores de IA que respetan el mecanismo.
• Fija explícitamente la política por rastreador (permitir, cobrar, bloquear) en lugar de dejar la configuración por defecto del proveedor, sobre todo antes de fechas de cambio anunciadas.
• Si activas un precio, documenta también en robots.txt o en un estándar de licencia como RSL las condiciones, para que quede constancia fuera del propio servidor.
• Revisa periódicamente los registros del servidor para ver cuántas peticiones 402 se están produciendo realmente y de qué rastreadores, antes de asumir que el mecanismo está generando ingresos.
• Distingue entre bloquear un rastreador de entrenamiento y bloquear uno de búsqueda: una configuración mal ajustada puede terminar bloqueando también el tráfico de un buscador que sí interesa mantener.

• Asumir que pay per crawl es ya un estándar abierto con muchos proveedores: a fecha de esta redacción está ligado principalmente a la implementación de un solo proveedor.
• Pensar que activar el cobro bloquea automáticamente a todo bot no deseado: solo aplica a los rastreadores que reconocen el mecanismo y deciden pagar o desistir.
• No comprobar que un rastreador con varios usos a la vez (búsqueda y entrenamiento) puede quedar bloqueado por completo si se bloquea solo uno de esos usos.
• Dejar la configuración en modo automático después de una fecha de cambio anunciada por el proveedor, sin comprobar qué queda permitido y qué queda bloqueado.
• Presentar el modelo como garantía de ingresos: el pago depende de que el rastreador acepte pagar, no es automático.