El sitio abierto para las personas, cerrado para la IA

La avería más caro de septiembre no parece una avería. El sitio abre, el diseño está en su lugar, el responsable entra desde el móvil y lo ve todo. Pero las posiciones caen, Google Ads escribe "Destination not accessible" y en las respuestas de IA el sitio ya no aparece. En el análisis publicado el 7 de septiembre de 2026 la situación se describe literalmente: en julio de 2026 un proveedor activó en Cloudflare el bloqueo de todos los bots, Googlebot quedó dentro de ese bloqueo y junto con el orgánico se cayó la publicidad. Abajo, a quién hay que dejar volver de forma explícita y por qué el segundo canal de pérdidas, scripts en lugar de enlaces, no se ve en absoluto en los informes.

De dónde salió la ola de 403

El 1 de julio de 2026 Cloudflare quitó el interruptor único "bloquear bots de IA" y dividió los bots en tres categorías: Search, Agent, Training. Las opciones están disponibles para todos, incluido el plan gratuito. Suena a mejora, y lo es, solo con una salvedad que poca gente leyó hasta el final.

La salvedad es que Cloudflare considera que parte de los crawlers tienen propósito mixto: son buscador y entrenamiento a la vez. Entre los mixtos están Googlebot, Bingbot y Applebot. Cualquier configuración que bloquee el entrenamiento, incluida la vieja opción "Block AI bots", los bloquea también a ellos. El aviso sobre esto se publicó el 5 de agosto de 2026, pero la gente estuvo tocando los ajustes en junio y julio.

El 4 de agosto de 2026 Search Engine Journal describió un mensaje de r/SEO: con AI Training = Block junto con Bot Fight Mode activado, Googlebot y Bingbot recibían HTTP 403 al intentar coger el sitemap, y en la sección AI Crawlers del panel de Cloudflare ambos aparecían como bloqueados. En un hilo de Cloudflare Community el dueño de un sitio cuenta que ya a principios de julio de 2026 las peticiones verificadas de Googlebot recibían 403 con la marca en Security Events: "Blocked by 'Block AI training crawlers'".

Y ahora una fecha importante. Desde el 15 de septiembre de 2026 cambian los valores por defecto de Cloudflare: para los dominios nuevos, los bots de las categorías Training y Agent se bloquean en las páginas donde se muestra publicidad, y Search sigue permitido. O sea, un dominio nuevo llega ya con el bloqueo activado por defecto, y habrá que lidiar con él antes del lanzamiento, no después de la primera queja.

1. 1 de julio de 2026Cloudflare divide los bots en Search, Agent, Training
2. 4 de agosto de 2026informe de 403 para Googlebot y Bingbot en el sitemap
3. 5 de agosto de 2026aviso: Googlebot, Bingbot y Applebot cuentan como mixtos
4. 31 de agosto de 2026informes de superficies de IA en todas las Search Console
5. 15 de septiembre de 2026nuevos valores por defecto de bloqueo para dominios nuevos

Por qué esto dejó de ser una historia rara

Hace un año bloquear crawlers era tema de una docena de grandes editoriales. Ahora es el fondo del paisaje. Según datos de Cloudflare, la proporción de respuestas 4xx para todos los crawlers de su red fue del 35,79% en julio de 2026 frente al 14,04% en julio de 2025, un crecimiento de 21,75 puntos. Las series semanales lo confirman: del 11,70% al 16,77% en 2025 y del 34,85% al 37,10% en 2026.

La causa es clara. Según las estadísticas de Cloudflare de junio de 2026, los crawlers de entrenamiento generaron el 50,6% del tráfico de bots de modelos, los de búsqueda solo el 10,7%, y más de la mitad de los rastreos fue a páginas que no habían cambiado desde la visita anterior. En junio de 2026 el jefe de Cloudflare, Matthew Prince, declaró que el tráfico de bots superó por primera vez al humano. Cuando en los logs se ve que la mitad de la carga es rebombear páginas idénticas al dataset de alguien, el botón "prohibir" se pulsa solo. La única pregunta es qué cae dentro de paso.

Un detalle más que cambia hábitos: la gestión de bots se ha ido del nivel de robots.txt al nivel de la infraestructura. Las categorías de Cloudflare, Content Signals con el campo use (immediate, reference, full), la identificación criptográfica Web Bot Auth. Shopify aplica desde el 7 de mayo de 2026 límites más duros a los bots que no firman sus peticiones vía Web Bot Auth. Los cambios en robots.txt no desaparecen, simplemente ya no son el único lugar donde tu sitio le dice "no" a un bot.

A quién mantener siempre en la lista blanca

La lista es corta y no va de IA. Son los bots sin los cuales se rompen la búsqueda, la publicidad y los feeds de producto.

• Googlebot
• Google InspectionTool
• AdsBot-Google
• AdsBot-Google-Mobile
• Storebot-Google

Sobre AdsBot hay una posición oficial, y zanja la discusión. La ayuda de Google Ads sobre "Destination not accessible" nombra directamente como causas los códigos 404 y 403 durante el rastreo de AdsBot, la prohibición de AdsBot en robots.txt y las configuraciones de servidor que bloquean el acceso. La recomendación, en el mismo sitio: añadir a la lista blanca los user agents AdsBot-Google y AdsBot-Google-Mobile y garantizar que el sitio esté accesible desde todos los países. Esto último duele especialmente a quien cierra medio mundo con un geofiltro a nivel de CDN: el bot no llega desde donde tú lo esperas.

Google InspectionTool es lo que usa la inspección de URL en Search Console. Storebot-Google recorre las páginas de producto. Si no los dejas pasar, no verás una caída de posiciones, verás una rareza: los informes vacíos y el soporte diciendo "aquí todo está bien".

Por qué el visto verde en Search Console no demuestra nada

En el mismo análisis del 7 de septiembre de 2026 hay una frase por la que valía la pena leerlo: una comprobación exitosa con URL Inspection confirma el acceso del bot de búsqueda, pero no demuestra el acceso de AdsBot. Son user agents distintos, y una regla en el CDN puede dejar pasar a uno y cortar al otro.

Así que el orden de revisión es este: primero los logs por user agent de los últimos 30 días, luego los eventos de seguridad en el panel del CDN, y solo después las herramientas de Google. En los logs no ves opiniones, ves códigos de respuesta. Si Googlebot llega y recibe 403, allí estará el 403, y ningún visto en la interfaz lo va a tapar. En mi caso lanzo esta revisión una vez al mes y después de cada toque a la infraestructura, sea con manos ajenas o propias [falta cifra: cuántas veces al año encontré una regla de más].

Qué mostró el experimento de 41 días

La otra mitad de las pérdidas es técnica, pero de un tipo muy distinto. Vinicius Stanule, Associate Director SEO en LOCOMOTIVE, montó un experimento de 41 días y lo describió en Search Engine Land. En el sitio hicieron 11 secciones a las que los enlaces iban en HTML puro y 10 secciones a las que los enlaces se insertaban vía JavaScript. El sitemap devolvía 404, las migas de pan y los paneles de jerarquía se quitaron, o sea, al bot le dejaron solo los enlaces.

Resultado: Googlebot llegó al 2% de las páginas accesibles a través de enlaces JS. Y GPTBot, ClaudeBot, Bingbot, los crawlers de Meta y Amazonbot encontraron prácticamente cero de esas páginas.

Esto encaja con una medición anterior de Vercel y MERJ de diciembre de 2024: no se registró ejecución de JavaScript en ningún crawler grande de IA. Los crawlers de ChatGPT descargaban archivos JS en el 11,50% de las peticiones, los de Claude en el 23,84%, pero no los ejecutaban. Descargar y ejecutar no es lo mismo, y justo en esa diferencia desaparecen los catálogos, los filtros, los bloques que se cargan al hacer clic y los scrolls infinitos.

De ahí una práctica sencilla. Abres la página, desactivas JavaScript en el navegador, mira qué queda. Si queda un marco vacío en lugar de productos y texto, para los bots de IA esa página no existe. Los enlaces deben ser una etiqueta a con atributo href, no un manejador de clic, y las páginas principales deben estar en un sitemap que devuelva 200.

Cómo notar que te has caído de las respuestas de IA

Otro problema es que esa caída no se ve en los informes habituales. Las posiciones clásicas pueden seguir en su sitio, el tráfico orgánico fluye tranquilo, y de las respuestas de IA el sitio ha desaparecido. En el informe mensual estándar esa columna simplemente no existe.

Algo ya lo da Google. El 3 de junio de 2026 lanzaron en Search Console los informes Search Generative AI performance, y el 31 de agosto de 2026 los desplegaron a todos los sitios del mundo. Allí hay impresiones, páginas, países, dispositivos y fechas. Clics no hay. Ese mismo 31 de agosto de 2026 activaron globalmente el interruptor que permite cerrar el contenido para que no se muestre en las superficies de IA de Google, incluidas AI Overviews, AI Mode y las funciones generativas de Discover. Además, en los informes aparecieron visualizaciones para plataformas externas, entre ellas Instagram, YouTube y TikTok.

Y una limitación que conviene saber de antemano: los datos generativos viven solo en la interfaz. Una comprobación del 11 de agosto de 2026 mostró que ni la Search Analytics API ni la exportación a BigQuery devuelven esas cifras. Es decir, un panel automático de visibilidad en IA por ahora no se puede montar, habrá que entrar a mano y hacer capturas por semanas. Impresiones sin clics, sin exportación, agujeros en el histórico: los datos existen, pero no puedes apoyarte en ellos como en un informe normal de consultas.

Por qué es pronto para culpar al algoritmo de la bajada

Cuando las posiciones caen, la primera versión es siempre la misma: una actualización. Miremos el calendario. La última actualización de ranking confirmada es el spam update: lanzado el 18 de agosto de 2026 hacia las 12:30 en hora de la costa este de EE. UU. terminado el 21 de agosto de 2026 a las 4:50, el despliegue duró unos 2,5 días, global y para todos los idiomas, tercer spam update de 2026. Todo lo demás que bajó en septiembre es más bien técnica: acceso de bots, renderizado, landings rotas.

Aquí encaja otra historia de septiembre. Google Data Manager cambia el esquema de recogida de datos en el sitio, el análisis de riesgos salió el 8 de septiembre de 2026. El sentido es el mismo: mientras todos discuten la calidad de los textos, se rompe la capa que nadie mira, porque siempre funcionó.

Qué hacer esta semana

1. Abrir los logs de 30 días y encontrar todas las respuestas 403 y 404 por user agent: Googlebot, AdsBot-Google, AdsBot-Google-Mobile, Google InspectionTool, Storebot-Google.
2. En el panel del CDN, comprobar si está activado el bloqueo de crawlers de entrenamiento o un modo de lucha contra bots que afecte a los crawlers mixtos. Para dominios nuevos, hacerlo antes del 15 de septiembre de 2026, no después.
3. Desactivar JavaScript en el navegador y recorrer tres páginas tipo: portada, categoría, producto o artículo. Lo que no se ve sin scripts no existe para los bots de IA.
4. Asegurarse de que el sitemap devuelve 200 y que los enlaces importantes son etiquetas a con href.
5. Entrar en los informes de superficies de IA en Search Console, anotar las impresiones actuales por secciones y ponerse un recordatorio para anotarlas una vez a la semana. No hay exportación, el histórico no se junta solo.

Bloquear crawlers de entrenamiento, por cierto, es una decisión normal. Lo que no es normal es enterarte de a quién has bloqueado por un correo sobre publicidad detenida. Si quieres, miro tu caso por logs y ajustes, escribe al soporte.