Hiciste el trabajo. La página es server-rendered. El JSON-LD está en la respuesta cruda. curl devuelve el artículo entero, titular incluido. Un crawler que pida tu URL recibe todo lo que necesita.
Solo que el crawler nunca pide tu URL. Se lo pide al CDN, y el CDN responde 403.
Tu contenido es perfecto e inalcanzable. Esta es la capa que hay debajo de la que todo el mundo comenta — y es invisible en cualquier herramienta a la que normalmente recurrirías.
Dos clases distintas de «no»
robots.txt es una nota pegada a la puerta. Dice «por favor, no entres». Un crawler educado la lee y da media vuelta. Uno grosero la ignora y pasa de largo. En cualquier caso, la nota nunca toca tus bytes — es una petición, garantizada solo por los modales del propio visitante.
Una regla de WAF o CDN es la puerta. Responde a la petición ella misma, en el borde, antes de que nada llegue a tu origin: 403 Forbidden, 429 Too Many Requests o un desafío JavaScript que el bot no resuelve. El HTML tras esa puerta podría ser una obra maestra o una página en blanco. El bot no ve ninguno de los dos. Ve el código de estado.
La gente pasa semanas puliendo la nota y no comprueba nunca si la puerta está cerrada con llave.
Esto no es hipotético — aquí están los datos
Cloudflare Radar publica lo que realmente ocurre con el tráfico de crawlers de IA en su red. Del panel AI Insights (vista de 7 días, a 18 de julio de 2026), de todas las respuestas HTTP servidas a bots y crawlers de IA:
- 200 OK — 73,6%
- 403 Forbidden — 5,2%
- 429 Too Many Requests — 1,3%
- 503 — 1,1%
Léelo otra vez. Más de una de cada quince peticiones de crawlers de IA se rechaza activamente en el borde — 403 o 429 — antes de tocar el contenido. No se despriorizan. Se rechazan.
Y la mayoría no es una decisión. Es un valor por defecto — un ruleset de WAF gestionado, un interruptor de «bloquear bots de IA» activado en 2024, un bot-fight score demasiado alto. El rastreador de robots.txt del mismo panel muestra GPTBot, CCBot y ClaudeBot como los crawlers más bloqueados en los dominios top — en gran parte heredado, no decidido.
Por qué nunca lo notarás por tu cuenta
Abre tu sitio. Carga. Claro que sí — tu navegador no está en la lista de bloqueo. IP residencial, User-Agent de Chrome, superas cualquier comprobación.
Abre robots.txt. Allow: /. Parece del todo acogedor.
Ver código fuente. HTML limpio, datos estructurados, todo. (Esa parte ya la arreglaste.)
Cualquier herramienta a la que recurras confirma que estás bien — porque todas vienen de ti, no de GPTBot. El bloqueo apunta a una clase de visitante que tú nunca vas a ser.
El único sitio donde se ve: los logs del servidor
El navegador miente, porque el navegador eres tú. robots.txt miente, porque es orientativo. El log de acceso no miente. Tiene una fila por cada petición real, con el User-Agent del visitante y el estado exacto que devolviste. Es el único registro de lo que GPTBot recibió de verdad.
Filtra con grep los que importan y cuenta sus códigos de estado:
grep -E "GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-SearchBot|PerplexityBot|Google-Extended" access.log \
| awk '{print $9}' \
| sort | uniq -c200 significa que recibió la página. 403 significa que el borde la rechazó. 429 significa que la limitaste hasta el silencio. El fallo que nadie detecta tiene esta pinta: robots.txt de par en par, logs llenos de 403. Todo lo que ves dice sí; lo que decide dice no.
He leído esta misma historia más de una vez. Meses de contenido, cero citas en ChatGPT o Perplexity, y una auditoría que por fin descubre que Cloudflare llevaba todo ese tiempo entregándole a GPTBot un 403.
La trampa dentro del arreglo
El remedio obvio — permitir todo cuyo User-Agent contenga GPTBot — está mal, porque un User-Agent es una cadena que cualquiera puede escribir. Un scraper de precios se etiqueta como GPTBot y cruza tranquilamente tu generosa regla nueva.
El propio rastreo de transparencia de Cloudflare lo deja claro: marca qué operadores pueden siquiera verificarse. A mediados de 2026, ByteDance figura como no verificado — y por eso exactamente no se puede confiar solo en el User-Agent.
Así que la verificación real no es el nombre. Es el origen. Dos vías:
1. Verifica por rangos de IP publicados. OpenAI, Anthropic y los demás publican las IP de sus crawlers — openai.com/gptbot.json, openai.com/searchbot.json, openai.com/chatgpt-user.json y sus equivalentes. Haz reverse-DNS de la IP que pide, confirma que el hostname pertenece al proveedor y luego resuélvelo hacia adelante de vuelta a la misma IP. Si cualquiera de los pasos falla, es un impostor con el nombre puesto.
2. Verifica por firma criptográfica. Hacia ahí va todo. Web Bot Auth — un borrador de la IETF liderado por Cloudflare (draft-meunier-web-bot-auth-architecture, sobre RFC 9421) — hace que los crawlers firmen cada petición con una clave Ed25519, de modo que la identidad se demuestra, no se afirma. Está integrado en el programa Verified Bots de Cloudflare con un directorio de Signed Agents, y el agente de ChatGPT estuvo en la primera cohorte firmada en 2025. Y no es solo Cloudflare — AWS WAF añadió soporte para Web Bot Auth a finales de 2025, permitiendo automáticamente a los agentes verificados.
Con el estado claro: Web Bot Auth es un borrador activo de la IETF, no un estándar ratificado. Pero con Cloudflare, OpenAI, Anthropic y AWS moviéndose al unísono, ya es la dirección de facto.
Lo que te importa: «bloquear a los bots malos» y «dejar entrar a la IA» son el mismo problema, y el User-Agent no resuelve ninguno. Verifica por origen o por firma — o bloquearás al crawler que quieres y admitirás al que no.
Qué hacer de verdad
Mira los logs, no el navegador. Saca una semana de logs de acceso, filtra por los User-Agent de IA, mira los códigos de estado. Esa es la auditoría entera — una tarde, no un proyecto.
Si ves 403/429, busca la regla. Casi siempre es un ruleset gestionado, un ajuste de «bloquear bots de IA» o un bot-fight score demasiado agresivo — no una línea que escribiste. Pon en la allowlist los crawlers que quieres por IP verificada o Web Bot Auth, nunca solo por User-Agent.
La regla que me llevé
Tu HTML es lo último en el camino de la petición, no lo primero. Antes de que un bot lea un solo byte, la petición tiene que pasar DNS, el CDN, el WAF, el rate limiter, el score de bot-management. Cualquiera de ellos puede terminar la petición con un código de estado que tú nunca ves — en una página que para ti renderiza sin fallo.
«Funciona en mi navegador» siempre fue un argumento débil. Para los crawlers ni siquiera es la pregunta correcta. La pregunta correcta es: ¿qué código de estado recibió el bot? Y la única respuesta honesta está en los logs.