El código de estado HTTP 402 (Payment Required) es una respuesta del protocolo HTTP que indica que se necesita un pago para acceder al recurso solicitado. Fue incluido en la especificación HTTP/1.1 en 1997, pero se reservó «para uso futuro» y nunca se estandarizó del todo.

A diferencia de otros códigos como el 401 (no autorizado) o el 403 (prohibido), el 402 señala específicamente lo que podríamos llamar un muro de pago.

Aunque los navegadores no lo interpretan de forma nativa, hay plataformas como Stripe, Shopify o la API de Google que ya lo utilizan en sus sistemas, y recientemente Cloudflare lo ha propuesto como base de su sistema de cobro a rastreadores de inteligencia artificial.

En WordPress se puede implementar mediante la función status_header( 402 ) para señalizar contenido de pago a nivel de protocolo. Pero todo esto querrás que te lo cuente en detalle ¿verdad?, pues sígueme un poco más …

Índice de contenidos

Un código HTTP que casi nadie conoce

Seguro que te has cruzado más de una vez con el tristemente famoso error 404 (página no encontrada), el temido 500 (error interno del servidor) o el frustrante 403 (acceso prohibido), son viejos conocidos, casi. nunca queridos, pero conocidos son.

Pero hay otro código de estado HTTP que lleva casi tres décadas viviendo en la sombra, reservado «para uso futuro» desde que se definió el protocolo HTTP/1.1 allá por 1997. Ese código es el 402 Payment Required, que traducido al cristiano viene a decir «se requiere pago».

Lo curioso es que ese «uso futuro» nunca terminó de llegar, hasta ahora.

En 2025, con la explosión de la inteligencia artificial, los rastreadores automáticos devorando contenido web a destajo y nuevos protocolos de micropagos emergiendo por todas partes, el 402 está experimentando algo parecido a una resurrección. Y lo más interesante es que tiene aplicaciones prácticas para cualquiera que gestione un sitio WordPress, o sea, para nosotros.

Vamos a ver qué es exactamente este código, por qué existe, quién lo usa ya, qué tiene que ver con todo el lío de la IA y el contenido web, y cómo puedes implementarlo en tu WordPress.

Qué es el código de estado HTTP 402

Cuando tu navegador solicita una página web, el servidor le responde con un código de estado numérico de tres cifras. Es la forma que tienen las máquinas de decirse entre ellas cómo va la cosa. Un 200 significa «todo correcto, aquí tienes el contenido», un 301 dice «esto se ha mudado a otra dirección», un 404 avisa de que «lo que buscas no existe», y así sucesivamente.

Pues bien, el 402 pertenece a la familia de los códigos 4xx, que son los errores del cliente. Es decir, el problema no está en el servidor sino en quien hace la petición. Su significado literal es «Payment Required» (se requiere pago), y la idea original era bastante visionaria para 1997, que los navegadores pudieran gestionar micropagos de forma nativa, directamente integrados en el protocolo HTTP.

Imagina que llegas a un artículo de un periódico digital y, en lugar de encontrarte un muro de suscripción, un formulario de registro y toda la parafernalia habitual, tu navegador te muestra un aviso sencillo tipo «este contenido cuesta 0,05 €, ¿quieres pagar?». Aceptas, el pago se procesa instantáneamente y el contenido aparece. Sin cuentas, sin contraseñas, sin dar tus datos a nadie, esa era la idea.

¿Por qué nunca llegó a funcionar?

La idea era buena pero se adelantó a su tiempo. En 1997 no existía una infraestructura de pagos digitales que permitiera cobrar céntimos de forma instantánea y sin intermediarios. PayPal no nació hasta 1998, las tarjetas de crédito tenían comisiones mínimas que hacían inviable cualquier micropago, y los navegadores nunca implementaron un sistema de monedero integrado.

Mientras tanto, la publicidad online se convirtió en el modelo dominante para monetizar contenido. ¿Para qué cobrar al usuario si puedes mostrarle anuncios? Las suscripciones y los modelos freemium hicieron el resto.

El 402 quedó abandonado en la especificación HTTP con la etiqueta de «reservado para uso futuro», y la práctica totalidad de navegadores ni siquiera lo interpretan de forma especial. Actualmente, si un servidor te devuelve un 402 tu navegador simplemente muestra un error genérico.

La diferencia con el 401 y el 403

Para entender bien dónde encaja el 402, conviene compararlo con sus «vecinos» en la tabla de códigos de estado, porque se prestan a confusión.

El 401 Unauthorized significa que necesitas identificarte. Es un problema de identificación, de que no has presentado credenciales válidas (usuario y contraseña, token, etc.).
El 403 Forbidden indica que el servidor sabe quién eres pero no te deja pasar. Es un problema de permisos, estás identificado pero no tienes autorización para acceder a ese recurso.
El 402 Payment Required añade un tercer aspecto, el económico. No es que no estés identificado ni que no tengas permisos, es que hace falta un pago. Es un «puedo dejarte pasar, pero primero pasa por caja».

Quién usa ya el código 402

Aunque técnicamente sigue siendo «no estándar» según la documentación de MDN, lo cierto es que varias plataformas importantes llevan años dándole un uso real al 402. Cada una a su manera, eso sí, porque al no haber un estándar definido, cada cual lo implementa como le parece.

Stripe lo devuelve cuando cuando falla un pago con tarjeta. Si intentas procesar un pago y la tarjeta está caducada o no tiene fondos la API de Stripe responde con un 402.
Shopify lo utiliza cuando una tienda está «congelada» porque su propietario tiene pagos pendientes con la plataforma. Es su forma de decirle al administrador «ponte al día con la factura para que tu tienda vuelva a funcionar».
La API de Google Developers responde con un 402 cuando un desarrollador supera el límite de peticiones de su plan gratuito. No es estrictamente un problema de pago pero el mensaje está claro, «si quieres más paga».
YouTube también lo emplea internamente para limitar abusos en el uso de su API.

Pero quizá lo más significativo que ha pasado con el 402 en los últimos tiempos tiene que ver con el protocolo x402, impulsado por Coinbase. Lanzado en mayo de 2025, x402 integra pagos con criptomonedas (stablecoins como USDC) directamente en el protocolo HTTP usando precisamente el código 402.

En pocos meses ya ha procesado más de 100 millones de transacciones entre APIs, aplicaciones y agentes de IA. La idea es que un servicio web pueda responder con un 402, el cliente (sea un navegador, un programa o un agente de IA) realice un pago instantáneo en la cadena de bloques, y el contenido se sirva automáticamente. Sin formularios, sin suscripciones, sin intervención humana.

La idea de Cloudflare de cobrar a los rastreadores de IA

Si hay un uso reciente del 402 que ha generado titulares por todas partes ese es el sistema «pay per crawl» (pago por rastreo) que Cloudflare propuso en julio de 2025.

El planteamiento parte de un problema que afecta a cualquiera que publique contenido en internet, el hecho de que los rastreadores de empresas de inteligencia artificial (GPTBot de OpenAI, ClaudeBot de Anthropic, también Google y muchos otros) recorren la web absorbiendo (robando para que nos entendamos) todo el contenido que encuentran para entrenar sus modelos.

El propietario de una web se encuentra con una elección de todo o nada bastante frustrante, o dejas la puerta abierta y que se lleven todo sin darte nada a cambio, o bloqueas el acceso por completo.

Cloudflare propone una tercera opción, y es que puedas cobrarles, y para eso ha rescatado al 402 de su letargo.

El sistema, aún en beta privada cerrada (yo mismo llevo esperando a que me den acceso meses), da a los propietarios de webs tres opciones para cada rastreador de IA identificado: permitir el acceso gratuito, cobrar un precio fijo por cada solicitud, o bloquear el acceso completamente. Cloudflare actúa como intermediario, gestiona los cobros y distribuye los ingresos a los editores.

Un detalle interesante es que, aunque un rastreador no tenga relación comercial con Cloudflare (y por tanto no se le pueda cobrar realmente), el editor puede igualmente marcar la opción de «cobrar».

En la práctica, funciona como un bloqueo (devuelve un 402 en lugar del contenido), pero con el matiz de que le estás diciendo al bot «esto no es un portazo, es una puerta que se abre si pagas». Es una señal con mucha más intención que un simple 403.

Cómo funcionan las cabeceras de Cloudflare para el 402

Para que todo este sistema funcione Cloudflare ha definido un conjunto de cabeceras HTTP personalizadas (que no son estándar, son una propuesta propia) y dos flujos de negociación entre el servidor y el rastreador.

Flujo reactivo (el bot descubre que hay que pagar): Un rastreador solicita una página, como tiene configurado el cobro Cloudflare le responde con un HTTP 402 Payment Required y añade una cabecera crawler-price: USD 0.05 que le indica el precio, no le envía ningún contenido. El rastreador, si acepta, reenvía la petición incluyendo una cabecera crawler-exact-price: USD 0.05 para confirmar que acepta pagar exactamente esa cantidad. Si todo cuadra recibe un HTTP 200 OK con el contenido y una cabecera crawler-charged: USD 0.05 que confirma el cobro.
Flujo proactivo (el bot ya sabe que puede haber que pagar): El rastreador incluye desde el principio una cabecera crawler-max-price: USD 0.10 en su petición, indicando cuánto está dispuesto a pagar como máximo. Si el precio configurado por el editor es igual o inferior a esa cantidad, el contenido se sirve directamente con un 200 y la confirmación del cobro real, y si el precio es superior a lo que el bot ofrece, recibe un 402 con el precio real.

Es, en esencia, un protocolo de negociación económica automática entre máquinas.

Pero hay 2 problemas:

Suplantación de identidad

De nada sirve que un bot diga «soy GPTBot y quiero pagar» si cualquiera puede falsificar ese User-Agent (el identificador que envía el bot para decir quién es). Para resolverlo Cloudflare utiliza el sistema Web Bot Auth, que exige a los rastreadores firmar criptográficamente cada petición con claves Ed25519.

El rastreador genera un par de claves, publica la pública en un directorio accesible, y firma cada petición con la privada. El servidor verifica la firma y sabe con certeza que el bot es quien dice ser. Las susodichas cabeceras son Signature-Agent, Signature-Input y Signature.

Cabeceras que no son estándar HTTP.

Es importante tenerlo claro, porque son una propuesta de Cloudflare que podría convertirse en estándar si la industria las adopta ampliamente, pero a día de hoy son exclusivas de su ecosistema. Dicho esto, la lógica en sí misma (devolver un 402 con información de precio y negociar el acceso) es perfectamente replicable fuera de Cloudflare, como veremos enseguida.

Posibles usos del 402 en WordPress

Hasta aquí hemos hablado del 402 en general y de cómo lo usan las grandes plataformas. Pero, ¿qué puede hacer con él alguien que gestione un WordPress? Más de lo que parece, y con un enfoque bastante diferente al de los plugins de membresía o los muros de pago habituales.

Muros de pago a nivel de protocolo HTTP

Los plugins de membresía que conocemos (MemberPress, Restrict Content Pro, Paid Memberships Pro y similares) funcionan sirviendo la página con un código 200 OK y luego mostrando un bloqueo visual del tipo «Este contenido es solo para suscriptores». Para el navegador, para los buscadores y para cualquier bot, la página ha cargado correctamente. El bloqueo es solo visual, a nivel de presentación.

Un 402 actúa en una capa mucho más profunda. El servidor directamente no envía el contenido, la respuesta llega vacía (o con un mensaje mínimo) y el código de estado ya informa a la máquina que hace la petición de que ahí hay una barrera económica. Esto tiene una consecuencia práctica directa, que ningún rastreador (sea de Google, de una IA o de quien sea) puede extraer el contenido real.

La REST API de WordPress como servicio de pago

Si desarrollas o gestionas una API propia con WordPress (algo cada vez más habitual), puedes utilizar el 402 para señalizar endpoints que requieren pago. Imagina una API de datos (cotizaciones, estadísticas, directorios, información de productos) donde ciertos endpoints son gratuitos y otros devuelven un 402 con información del precio y cómo contratarlos.

Es exactamente lo que hacen Stripe o Google con sus APIs, pero aplicado a tu propio proyecto WordPress.

Protección de contenido frente a rastreadores de IA

No hace falta estar detrás de Cloudflare para decirle a un bot de IA que tu contenido no es gratis. Puedes detectar los los User-Agent de los principales rastreadores de IA y devolverles un 402 en lugar de tu contenido, mientras sigues sirviendo la página con normalidad a los visitantes humanos y a los buscadores tradicionales.

No es un sistema de cobro automático (eso requiere una infraestructura que no existe aún para WordPress como tal), pero sí es una declaración formal a nivel de protocolo que dice «esto vale dinero, ponte en contacto si quieres acceder».

Implicaciones SEO a tener en cuenta

Un detalle que no puedes pasar por alto es que Google desindexará las URLs que devuelvan un 402 de forma persistente. El contenido detrás de un 402 no se rastrea, no se indexa y desaparece de los resultados de búsqueda.

Esto es una ventaja si quieres proteger contenido premium de verdad, pero puede ser un problema si lo aplicas de forma indiscriminada. La clave está en ser selectivo, o sea, entregar un 402 a los bots que quieres bloquear o cobrar, código 200 para Google y Bing, y también 200 para los visitantes humanos.

A día de hoy no hay plugins que yo sepa en el repositorio de WordPress.org que implementen el 402 de forma específica.

Hay un proyecto llamado CrawlProfit Pro que busca llevar el modelo de pago por rastreo a WordPress sin depender de Cloudflare (con Stripe o PayPal como pasarela), incluyendo verificación criptográfica de bots, está en fases muy iniciales, pero marca la dirección hacia la que se mueven las cosas.

Cómo entregar un código de estado HTTP 402 en WordPress

Implementar un 402 en WordPress es técnicamente sencillo. WordPress incluye la función status_header() que permite enviar cualquier código de estado HTTP, y la función nativa de PHP header() para añadir cabeceras personalizadas. Combinando ambas puedes replicar la parte declarativa del sistema de Cloudflare sin depender de ningún servicio externo.

El siguiente código, añadido como mu-plugin, en el functions.php de un tema hijo, o mediante un plugin de fragmentos de código, detecta los principales rastreadores de IA por su User-Agent y les devuelve un 402 con cabeceras informativas, mientras sirve el contenido con normalidad al resto de visitantes.

<?php
/**
 * Devuelve HTTP 402 a rastreadores de IA conocidos
 *
 * Detecta los user agents de los principales bots de IA
 * y responde con 402 Payment Required en lugar del contenido
 * Los visitantes humanos y buscadores no se ven afectados
 *
 * Personalizable: añade o quita bots del array $ai_crawlers
 * Personalizable: ajusta el precio y la URL de contacto
 */
function ayudawp_block_ai_crawlers_402() {

    // No actuar en el admin ni en peticiones AJAX
    if ( is_admin() || wp_doing_ajax() ) {
        return;
    }

    $user_agent = isset( $_SERVER['HTTP_USER_AGENT'] ) 
        ? sanitize_text_field( wp_unslash( $_SERVER['HTTP_USER_AGENT'] ) ) 
        : '';

    if ( empty( $user_agent ) ) {
        return;
    }

    // Lista de rastreadores de IA conocidos
    $ai_crawlers = array(
        'GPTBot',
        'ChatGPT-User',
        'ClaudeBot',
        'anthropic-ai',
        'Bytespider',
        'CCBot',
        'Google-Extended',
        'FacebookBot',
        'PerplexityBot',
        'Applebot-Extended',
        'cohere-ai',
    );

    $is_ai_crawler = false;

    foreach ( $ai_crawlers as $crawler ) {
        if ( false !== stripos( $user_agent, $crawler ) ) {
            $is_ai_crawler = true;
            break;
        }
    }

    if ( ! $is_ai_crawler ) {
        return;
    }

    // Enviar respuesta 402 con cabeceras informativas
    status_header( 402 );
    header( 'Content-Type: text/plain; charset=UTF-8' );
    header( 'X-Content-Price: EUR 0.05' );
    header( 'X-Licensing-URL: https://tu-dominio.com/licencias/' );
    header( 'X-Robots-Tag: noindex, nofollow' );

    echo 'HTTP 402 - Payment Required. Este contenido requiere licencia para acceso automatizado. Contacto: https://tu-dominio.com/licencias/';
    exit;
}
add_action( 'template_redirect', 'ayudawp_block_ai_crawlers_402', 1 );

Este es el enfoque más básico, realizar un bloqueo total a todos los bots de IA listados en todo el sitio, pero puedes añadir condiciones de WordPress para hacerlo más selectivo. Por ejemplo, puedes limitar el 402 solo a determinados tipos de contenido, a entradas de una categoría concreta o incluso a publicaciones individuales.

Para aplicarlo solo a las entradas de una categoría específica, bastaría con añadir una comprobación como esta antes de enviar la respuesta 402:

// Solo aplicar el 402 a entradas de la categoría 'premium'
if ( ! is_single() || ! has_category( 'premium' ) ) {
    return;
}

O para aplicarlo solo a determinadas entradas o páginas por su ID:

// Solo aplicar a estos contenidos concretos
$contenidos_de_pago = array( 1234, 5678, 9012 );
if ( ! is_singular() || ! in_array( get_the_ID(), $contenidos_de_pago, true ) ) {
    return;
}

También puedes darle la vuelta y excluir rastreadores concretos del bloqueo. Por ejemplo, si llegas a un acuerdo con una empresa de IA y quieres dejarle pasar gratis, solo tienes que añadir una condición para su User-Agent antes del bloqueo.

En la REST API de WordPress

Si gestionas endpoints propios en la REST API de WordPress, también puedes devolver un 402 de forma limpia usando WP_Error:

// Dentro de la callback de un endpoint de la REST API
function ayudawp_mi_endpoint_premium( $request ) {

    // Comprobar si el usuario tiene acceso de pago
    $tiene_acceso = ayudawp_verificar_acceso_pago( $request );

    if ( ! $tiene_acceso ) {
        return new WP_Error(
            'payment_required',
            'Este endpoint requiere una suscripción activa.',
            array(
                'status' => 402,
                'price'  => 'EUR 9.99/mes',
                'info'   => 'https://tu-dominio.com/api-pricing/',
            )
        );
    }

    // Servir los datos normalmente
    return rest_ensure_response( $datos );
}

Cosas que pueden salir mal

Antes de lanzarte a implementar el 402 en tu WordPress hay algunas cosas que debes tener en cuenta.

La caché puede fastidiarlo todo: Si usas un plugin de caché (LiteSpeed Cache, WP Super Cache, W3 Total Cache) o un CDN, las páginas cacheadas se sirven antes de que PHP se ejecute. Eso significa que el código del 402 nunca llega a ejecutarse y el bot recibe la página cacheada con un 200 como si nada. Para que funcione correctamente necesitas configurar exclusiones en tu sistema de caché basadas en el User-Agent, o gestionar el 402 a nivel de servidor (en el .htaccess de Apache o en la configuración de Nginx) en lugar de desde PHP.
Los User-Agent se pueden falsificar: Algunos bots de IA (Perplexity es especialmente conocido por esto) cambian su User-Agent constantemente para saltarse los bloqueos. La detección por User-Agent es útil como primera barrera pero no es infalible. Para una protección más sólida habría que cruzar el user agent con la IP de origen y verificar que coincide con los rangos conocidos de cada empresa, algo que complica bastante la implementación.
Diferencia entre buscadores e IA: Googlebot y Bingbot deben seguir accediendo a tu contenido con normalidad (salvo que explícitamente quieras lo contrario), porque si les devuelves un 402 dejarán de indexar esas páginas. Asegúrate de que tu lista de rastreadores de IA no incluye por error a los bots de los buscadores tradicionales. Ten en cuenta además que Google tiene dos bots, está Googlebot (el rastreador de búsqueda que sí quieres dejar pasar) y Google-Extended (el que usa para entrenar sus modelos de IA, que sí podrías querer bloquear o cobrar).
El 402 no sustituye a robots.txt: El archivo robots.txt sigue siendo la forma estándar de indicar a los rastreadores qué pueden y qué no pueden rastrear. Un 402 es una señal a nivel de respuesta HTTP, que actúa cuando el bot ya ha hecho la petición. Lo ideal es combinar ambos: robots.txt para declarar tus intenciones y el 402 como mecanismo de aplicación real para los bots que ignoren el robots.txt (que, dicho sea de paso, son unos cuantos).

402, un código que se adelantó a su tiempo

Así que, ¿el HTTP 402 es un código de error o una funcionalidad? Ni una cosa ni la otra, en realidad. Es una reserva de futuro que hicieron los creadores del protocolo HTTP hace casi tres décadas, anticipando que internet necesitaría una forma nativa de gestionar pagos. Ese futuro no llegó como ellos imaginaban, pero está llegando ahora por caminos que nadie había previsto.

La inteligencia artificial, los micropagos con criptomonedas, los agentes autónomos que navegan y compran sin intervención humana, y la necesidad de los creadores de contenido de proteger y monetizar su trabajo en un entorno cada vez más automatizado están dando al 402 una razón de ser que no tuvo durante años.

Para los que gestionamos sitios WordPress merece la pena conocerlo y tenerlo en cuenta. No como algo que vayas a implementar mañana necesariamente, sino como una herramienta que ya existe en el protocolo, que es fácil de usar técnicamente, y que muy probablemente va a ganar protagonismo a medida que el debate sobre quién paga por el contenido que alimenta a las IAs siga calentándose.