Notas de la agencia
Cómo saber si ChatGPT puede leer tu sitio web
Si le preguntas a ChatGPT o a Claude por una empresa de tu rubro y no apareces, hay dos explicaciones posibles y son muy distintas. Una es que te leyeron y prefirieron a otro. La otra es que nunca pudieron leerte.
La segunda es más común de lo que parece, y tiene una particularidad incómoda: tu web puede verse perfecta en el navegador y estar completamente vacía para ellos. Nadie te avisa. No hay error, no hay alerta, no hay caída. Simplemente no existes en la respuesta.
Este mes lo comprobamos en nuestro propio sitio. Lo que sigue son los comandos exactos para revisar el tuyo, y lo que encontramos en el nuestro cuando los corrimos.
¿Qué ve un buscador de IA cuando entra a tu web?
Menos de lo que crees. Los rastreadores de IA —GPTBot, ClaudeBot, PerplexityBot y el resto— no ejecutan JavaScript. Bajan el HTML tal como sale del servidor, leen lo que hay escrito ahí, y siguen de largo.
Tu navegador hace algo distinto: descarga ese mismo HTML, ejecuta el JavaScript, y recién entonces arma la página que tú ves. Si tu sitio está hecho con React, Vue, Angular o casi cualquier framework moderno sin renderizado en el servidor, el HTML que sale del servidor es un cascarón: unas etiquetas de configuración y un <div> vacío que el JavaScript llenará después.
Tú ves la página. El crawler ve el div vacío.
Para comprobarlo hay un comando, y funciona en cualquier terminal:
curl -s https://tusitio.cl/ | wc -c
Eso te dice cuántos bytes de HTML entrega tu servidor antes de ejecutar nada. Un sitio con contenido real devuelve decenas de miles. Si te da menos de 10.000, casi seguro estás sirviendo un cascarón.
Cuando lo corrimos en innobate.cl en agosto, nos dio 4.260 bytes sin una sola palabra de contenido. Éramos una agencia de IA que la IA no podía leer.
¿Cómo ver el contenido, y no solo el peso?
El peso te da una señal, pero puede engañarte: un cascarón con muchas etiquetas de configuración también pesa. Lo que hay que mirar es si hay texto de verdad.
curl -s https://tusitio.cl/ | grep -o "<h1>[^<]*"
Si eso no devuelve nada, tu título principal no está en el HTML servido. Ningún buscador —ni de IA ni Google— lo está viendo.
Prueba lo mismo con <h2> y verás cuántas secciones de tu sitio existen realmente para quien no ejecuta JavaScript.
¿Cuántos enlaces ve un crawler en tu portada?
Este es el que más nos sorprendió, porque no se nos había ocurrido mirarlo.
curl -s https://tusitio.cl/ | grep -c "<a href"
Nosotros ya habíamos arreglado el contenido: nuestra portada pasó a servir 19.634 bytes con 1.605 palabras reales. Todo bien. Pero al contar los enlaces nos dio 2: un correo y la política de privacidad.
Un crawler entraba a la portada, leía todo, y no tenía por dónde seguir. Una isla. El contenido estaba, y el camino para llegar al resto no.
El error que cometimos midiendo, y que te va a pasar
Este vale más que los comandos anteriores, porque casi nos hace tomar una decisión equivocada.
Para saber si nos bloqueaban, corrimos esto:
curl -s -o /dev/null -A "GPTBot/1.2" -w "%{http_code}" https://innobate.cl/
Nos devolvió 403 para todos los bots de IA. Conclusión inmediata y alarmante: estamos bloqueados en todas partes.
Era falsa. Ese comando no es GPTBot: es alguien diciendo que lo es. Las plataformas como Cloudflare verifican a los bots reales por dirección IP y firma, así que un curl que se presenta con ese nombre es un impostor y recibe un 403 que el bot verdadero no recibe.
Cuando fuimos a mirar las métricas reales del panel, el bot de búsqueda de Claude había entrado 15 veces con respuesta 200 en las últimas 24 horas. Nunca estuvo bloqueado.
La lección no es sobre bots: es sobre medir. Un comando que responde algo no es lo mismo que un comando que responde lo que crees. Antes de actuar sobre un resultado alarmante, pregúntate qué está midiendo exactamente.
Si quieres saber de verdad quién te rastrea, el dato está en los registros de tu servidor o en el panel de tu proveedor de CDN, no en un curl.
¿Qué hacemos con lo que encontramos?
Nuestros dos defectos se arreglaron el mismo día y ninguno requirió rehacer el sitio.
El primero: publicar el contenido principal como HTML real dentro de la página, aunque después el JavaScript lo reemplace al cargar. El visitante no nota nada; el crawler se lleva el texto completo.
El segundo: poner enlaces de verdad a las secciones dentro de ese contenido. Pasamos de 2 a 10.
Y hubo un tercero que descubrimos de paso. Teníamos cuatro preguntas frecuentes escritas en la página, pero maquetadas como una lista de definiciones en vez de como encabezados. Para una persona se ve idéntico. Para un modelo que busca un par pregunta-respuesta que poder citar, contaban cero. Cambiarlas a encabezados no tocó ni una coma del texto.
Medido con la misma herramienta antes y después, en las dos notas que importan:
- Visibilidad ante buscadores de IA: de 69,5 a 81,8 sobre 100
- SEO clásico: de 65,9 a 78,1 sobre 100
Por dónde empezar mañana
Si solo vas a hacer una cosa, corre el primer comando en tu sitio. Toma diez segundos y te dice si tienes un problema o no.
Si te da un número bajo, no necesitas migrar de tecnología ni rehacer nada: necesitas que tu contenido principal exista en el HTML que sale del servidor. Eso es un cambio acotado en casi cualquier stack.
Y si te da un número alto, revisa los enlaces igual. Nosotros habríamos jurado que ese estaba bien.
Un detalle final que casi nadie mira a tiempo: si todavía no tienes tu sitio conectado a Google Search Console, conéctalo hoy aunque no lo vayas a usar por meses. El dato no es retroactivo. Empieza a acumularse desde que verificas, y lo que no se junte esos meses no se recupera nunca. Nosotros perdimos ese tiempo y no hay forma de ir a buscarlo.