Checklist técnico para no bloquear buscadores ni rastreadores de IA

El problema real: una web abierta para humanos puede estar cerrada para máquinas

Cuando una empresa revisa su web, normalmente abre la URL en Chrome, ve que carga y da por hecho que todo está correcto. Para SEO y visibilidad ia eso no basta. Un rastreador puede recibir una respuesta distinta por user agent, país, IP, frecuencia de petición o regla de seguridad.

El caso típico es una página comercial que devuelve 200 al usuario normal, pero 403 o 429 a Google-Extended, gptbot, OAI-SearchBot, perplexitybot o claudebot. En ese escenario el problema no es el copy: el problema es que parte del ecosistema no puede acceder a la página, o la accede con fricción suficiente como para reducir su utilidad.

Robots.txt: controlar rastreo no es controlar indexación

Google explica que robots.txt se usa principalmente para indicar qué URLs puede rastrear un crawler y para gestionar carga de servidor. No debe usarse como mecanismo de privacidad ni como sustituto de noindex. Si una URL privada no debe aparecer ni ser descubierta, debe protegerse con autenticación o control de acceso real.

Para una estrategia de visibilidad ia, la decisión práctica es separar tres tipos de bots: buscadores generales, bots de búsqueda/respuesta de plataformas IA y bots de entrenamiento. Puede tener sentido permitir unos y limitar otros, pero conviene hacerlo con intención, no con una regla copiada de internet.

• Comprobar que robots.txt devuelve 200 y no está cacheado con una versión antigua.
• Incluir la línea sitemap con la URL correcta del sitemap XML.
• Evitar disallow amplios sobre carpetas que contienen páginas comerciales, artículos, imágenes clave o recursos CSS/JS necesarios para renderizar.
• Documentar cualquier bloqueo explícito a bots IA para que marketing, SEO y sistemas sepan por qué existe.

Códigos HTTP que cambian la lectura de la web

Los códigos HTTP son una señal básica de accesibilidad. Un 200 indica que la URL entrega contenido. Un 301 puede consolidar una migración. Un 404 o 410 comunica ausencia. Un 403 indica bloqueo. Un 429 indica demasiadas peticiones. Un 5xx indica que el servidor no pudo responder bien.

La auditoría debe mirar esos códigos con varios user agents. No sirve validar solo con el navegador del técnico porque muchos problemas aparecen precisamente cuando la petición parece venir de un crawler o de una IP de centro de datos.

• 200 para páginas indexables y públicas.
• 301 para redirecciones permanentes, como una URL antigua que ya no debe posicionar.
• 404 o 410 para contenido eliminado de verdad.
• 403 solo cuando hay una razón clara para bloquear.
• 429 con cuidado: puede ser correcto contra abuso, pero problemático si se aplica a bots legítimos en páginas públicas.

Cloudflare y WAF: proteger sin esconder la web

Cloudflare permite reglas personalizadas, managed challenges, rate limiting y excepciones. Eso es útil, pero una configuración demasiado agresiva puede convertir el sitio en una web técnicamente publicada y prácticamente invisible para rastreadores.

La regla correcta no suele ser “permitir todo a los bots”. Lo razonable es proteger rutas sensibles como login, formularios, APIs internas o parámetros abusables, y permitir el acceso estable a páginas públicas importantes cuando el user agent y el patrón de petición encajan con rastreo legítimo.

• Separar reglas para páginas públicas, formularios, administración y endpoints dinámicos.
• Registrar qué regla bloquea cada 403 o 429 antes de tocar el WAF.
• Probar con user agents de googlebot, OAI-SearchBot, gptbot, ChatGPT-User, claudebot, perplexitybot y Applebot.
• Usar excepciones precisas antes que desactivar protecciones globales.

Sitemap, canonical y hreflang: señales de estructura

El sitemap no obliga a indexar, pero ayuda a descubrir URLs relevantes y sus últimas modificaciones. Es especialmente importante cuando una web tiene contenidos nuevos, versiones por idioma o páginas que no reciben todavía muchos enlaces internos.

Canonical y hreflang completan esa lectura. Canonical indica cuál es la versión principal cuando puede haber duplicados o variantes. Hreflang ayuda a relacionar versiones equivalentes en español, inglés y catalán para que Google entienda que no compiten entre sí.

• Cada URL indexable debe tener canonical absoluto hacia sí misma o hacia su versión principal.
• Cada grupo multidioma debe enlazar sus equivalentes ES, EN y CA.
• El sitemap debe actualizar lastmod cuando se reescribe de forma sustancial una página.
• Las URLs del sitemap deben devolver 200, no cadenas largas de redirecciones.

Bots IA que conviene revisar de forma separada

No todos los bots IA tienen el mismo objetivo. OpenAI distingue entre crawlers para búsqueda, entrenamiento y peticiones iniciadas por usuarios. Anthropic documenta agentes distintos para distintos usos. Perplexity diferencia su rastreador de indexación de otros accesos asociados a consultas.

Para una empresa que quiere ser visible en asistentes, bloquear todo por miedo a la IA puede ser contraproducente. Para una empresa que necesita limitar uso de contenido, permitir todo sin criterio también puede ser mala decisión. La clave es decidir por caso de uso.

• OAI-SearchBot y ChatGPT-User para escenarios relacionados con búsqueda o petición de usuario en OpenAI.
• GPTBot cuando la política de la empresa permite o limita uso para entrenamiento.
• ClaudeBot y Claude-User según la política de acceso deseada para Anthropic.
• PerplexityBot si la empresa quiere aparecer como fuente en Perplexity.
• Googlebot para Google Search y Google-Extended como control separado asociado a usos de IA de Google.

Checklist operativo antes de publicar una página importante

Antes de dar por terminada una landing, un servicio o un artículo, conviene pasar un checklist técnico mínimo. No es trabajo decorativo: evita que el contenido exista solo para usuarios que ya llegan por navegación directa.

La revisión debe hacerse después de subir a producción, porque los problemas reales suelen estar en CDN, WAF, caché, redirecciones, SSL o reglas del hosting, no en el HTML local.

• URL final devuelve 200 con navegador y con bots relevantes.
• No hay bloqueo accidental en robots.txt.
• Canonical apunta a la URL final.
• La URL aparece en sitemap y el sitemap está enlazado desde robots.txt.
• Si hay idiomas, hreflang cruza todas las versiones equivalentes.
• El contenido principal está en HTML y no depende exclusivamente de una interacción JS.
• La página tiene title, description, H1, datos estructurados y enlaces internos coherentes.
• Cloudflare no devuelve challenge, 403 o 429 a bots permitidos.

Cómo convertir la auditoría en decisiones

La salida útil no es una lista enorme de errores: es una decisión por URL. Hay URLs que deben indexarse, URLs que deben redirigir, URLs que deben devolver 410 y URLs que deben quedar bloqueadas. Mezclar todos esos casos produce ruido y decisiones pobres.

Para visibilidad ia, la prioridad es que las páginas que explican qué hace la empresa, para quién trabaja, dónde presta servicio y por qué es fiable sean accesibles, claras, enlazadas y respaldadas por fuentes o señales verificables.