Has optimizado tu contenido. Tu sitio tiene señales de experiencia, autoridad y confianza. Pero cuando un rastreador de IA llega a tu página y se encuentra con un tiempo de espera agotado, porque tu servidor tarda 6 segundos en responder o porque el LCP no termina de renderizarse en 5 segundos, el rastreador sigue adelante. Tu contenido nunca se indexa. Tus citas nunca llegan.
La velocidad mata la visibilidad. No de forma lenta. De forma instantánea y definitiva.
Los rastreadores de IA funcionan con limitaciones que los buscadores tradicionales no tienen. Tienen ventanas de tiempo de espera estrictas, presupuestos de computación limitados y poca paciencia. Una página que se posiciona de maravilla en Google puede ser totalmente invisible para ChatGPT, Perplexity o Claude porque no carga dentro del plazo del rastreador. Este capítulo explica cómo funcionan los Core Web Vitals para la IA, qué métricas importan más y qué cambios necesitas hacer.
Qué miden los Core Web Vitals y por qué existen
Los Core Web Vitals son tres métricas que Google creó para medir la experiencia real del usuario. Capturan el momento en que el navegador empieza a mostrar contenido, el momento en que los usuarios pueden interactuar con la página y lo estable que se mantiene el diseño durante la carga. Google las trata como factores de posicionamiento. Pero para los rastreadores de IA son factores de supervivencia.
Las tres métricas son:
Largest Contentful Paint (LCP): cuánto tarda en cargarse el elemento visual más grande. El objetivo es menos de 2,5 segundos. Es lo primero que ven los usuarios: si tu imagen principal, tu titular o tu sección de contenido principal tarda 4 segundos en aparecer, tanto las personas como los rastreadores tienen que esperar.
Interaction to Next Paint (INP): cuánto tarda el navegador en responder después de que un usuario haga clic en algo. El objetivo es menos de 200 milisegundos. Esta métrica comprueba si tu JavaScript está inflado o si tu página se congela cuando los rastreadores simulan interacción.
Cumulative Layout Shift (CLS): cuánto rebota la página mientras carga. El objetivo es menos de 0,1. Cuando los elementos se desplazan sin avisar, los rastreadores extraen contenido desordenado o incompleto. Tus párrafos cuidadosamente escritos quedan confusos en el análisis del rastreador.
Para la búsqueda tradicional, son orientaciones. Para los rastreadores de IA, son límites estrictos.
Por qué los rastreadores de IA tienen requisitos de velocidad distintos de los de Google
El rastreador de Google reparte el trabajo. Rastrea millones de URL en miles de servidores. Puede permitirse esperar 10 segundos a que cargue una página porque la espera se reparte en una infraestructura enorme.
Los rastreadores de IA funcionan con inferencia por consulta. Cuando un usuario le hace una pregunta a ChatGPT, Perplexity tiene de 3 a 5 segundos para encontrar, recuperar y analizar tu contenido antes de que la respuesta tenga que empezar a generarse. Cada segundo cuenta. Cada milisegundo se descuenta del presupuesto de rastreo.
Los estudios sobre el comportamiento de los rastreadores de IA muestran que los sitios con un First Contentful Paint inferior a 0,4 segundos promedian 6,7 citas, mientras que los sitios que cargan en más de 1,13 segundos promedian 2,1 citas. No es correlación. Es causalidad. Las páginas lentas se saltan.
El rastreador de recuperación de ChatGPT tiene un umbral de tiempo de espera documentado. Las páginas que no responden dentro de esa ventana se marcan como inaccesibles y pierden prioridad en futuros intentos de rastreo. El bot de Perplexity hace lo mismo. Un sitio que tarda 6 segundos en responder no tiene una segunda oportunidad.
Time to First Byte (TTFB): la métrica que más les importa a los rastreadores de IA
El TTFB mide el momento entre el envío de una solicitud y la recepción del primer byte de vuelta desde el servidor. Es la medida más pura de la capacidad de respuesta del servidor.
Para los rastreadores de IA, el TTFB determina si siquiera intentan el renderizado. Si tu servidor tarda 700 milisegundos en responder, el rastreador ya ha malgastado 700 milisegundos de su ventana de 3 a 5 segundos. El rastreador abandona el renderizado por completo y recurre a analizar solo el HTML, lo que significa que tu contenido renderizado con JavaScript se vuelve invisible.
Las referencias son claras. Un TTFB por debajo de 200 milisegundos se considera excepcional. De 200 a 500 milisegundos es aceptable pero no ideal. Por encima de 600 milisegundos, tienes un problema de infraestructura del servidor.
La mayoría de los artículos de rendimiento tratan el TTFB como secundario frente a las métricas visuales. Para los rastreadores de IA, es el guardián. Si el TTFB falla, nada más importa.
Entre las causas habituales de un TTFB lento están las consultas lentas a la base de datos detrás de cada carga de página, un alojamiento sobrecargado con demasiados sitios por servidor, un enrutamiento geográfico deficiente de las solicitudes y la falta de caché en una red de distribución de contenidos (CDN). No son problemas de diseño. Son problemas de infraestructura.
Largest Contentful Paint (LCP): esperar al elemento grande
El LCP mide el tiempo hasta que el elemento visual más grande se carga por completo. Normalmente es una imagen principal, una imagen de fondo o un bloque grande de texto. En las páginas con mucho contenido, es el área de contenido principal.
Un LCP por debajo de 2,5 segundos es el umbral "bueno". Los rastreadores de IA citan las páginas de este rango 2,8 veces más a menudo que las páginas con un LCP más lento. La diferencia no es sutil.
El rastreador no espera a que cargue cada recurso. Pero sí espera a que aparezca el contenido principal. Si tu imagen principal pesa 4 megabytes y no la has optimizado para la web, el rastreador se queda parado mientras la imagen se descarga. Cuando la imagen termina de cargar, ya has superado el tiempo de espera del rastreador.
Entre las causas habituales de un LCP lento están las imágenes sobredimensionadas sin comprimir, los vídeos incrustados sin optimizar que bloquean el renderizado, las fuentes web que no están reducidas y no cargan rápido, y los scripts de terceros que se renderizan en la parte visible sin desplazarse. Cada uno de ellos añade segundos al LCP.
La solución no es esperar más. La solución es que el LCP ocurra más rápido. Esto significa optimizar imágenes, cargar de forma diferida el contenido que queda fuera de la pantalla, cargar scripts de forma asíncrona y, posiblemente, sustituir los pesados contenidos incrustados de terceros por alternativas en HTML estático.
Interaction to Next Paint (INP): rendimiento de ejecución de JavaScript
El INP mide la capacidad de respuesta. Cuando un usuario (o un rastreador que simula a un usuario) interactúa con la página, ¿cuánto tarda en cambiar algo en pantalla? El objetivo es menos de 200 milisegundos.
Para los rastreadores de IA, el INP revela si tu JavaScript está optimizado o inflado. Una mala puntuación de INP indica que tu página tiene demasiado código ejecutándose en el hilo principal, o que el código no está bien dividido ni diferido.
Los rastreadores que simulan interacción lo hacen para extraer contenido dinámico. Si tu página carga HTML estático pero depende de JavaScript para renderizar formularios, contenido condicional o elementos interactivos, el rastreador necesita ejecutar ese JavaScript. Si el JavaScript es lento, el rastreador obtiene una mala puntuación de INP y marca tu página como ineficiente.
El problema oculto del renderizado en el cliente es que la mayoría de los rastreadores de IA no renderizan JavaScript en absoluto. Las investigaciones muestran que el HTML estático con marcado schema logra un 94% de éxito de análisis, mientras que el contenido renderizado con JavaScript se queda en un 23%. Esto significa que, si tu contenido está oculto tras JavaScript, los rastreadores de IA quizá nunca lo vean.
Si tu sitio usa renderizado en el cliente, el problema del INP se convierte en un problema de visibilidad. El rastreador no puede esperar a que se ejecute el JavaScript, así que se salta el contenido que depende de JavaScript.
Cumulative Layout Shift (CLS): estabilidad durante la extracción
El CLS mide la inestabilidad visual. Cuando los elementos de la página se mueven durante la carga, el Cumulative Layout Shift aumenta. El objetivo es menos de 0,1.
Para los rastreadores, el CLS no tiene que ver con la experiencia del usuario. Tiene que ver con la exactitud del análisis. Cuando el DOM se desplaza mientras el rastreador extrae contenido, puede tomar los elementos equivocados. Un titular puede desplazarse al espacio de otro titular. Una barra lateral puede empujar el contenido principal fuera de su sitio. El rastreador extrae el texto que haya en una posición, no el texto que lógicamente corresponde ahí.
Entre las causas habituales de un CLS alto están los espacios publicitarios que cargan tarde y empujan el contenido hacia abajo, las imágenes sin dimensiones especificadas que cargan y desplazan el diseño, las fuentes web que se intercambian y cambian el espaciado, y los carruseles que se reproducen solos y desplazan el contenido. Cada uno hace que el diseño se mueva.
La solución es reservar espacio para todo lo que se vaya a cargar. Especifica las dimensiones de las imágenes en el HTML. Define font-display como swap para que las fuentes no bloqueen el renderizado. Carga los anuncios y el contenido dinámico en contenedores reservados que no provoquen desplazamientos del diseño.
Cómo optimizar la velocidad para los rastreadores de IA
Optimizar la velocidad para los rastreadores de IA es distinto de optimizarla para las personas. A los usuarios les importa cuándo ven la página y cuándo pueden interactuar con ella. A los rastreadores les importa cuándo responde el servidor y si todo el contenido termina de renderizarse.
Empieza por el TTFB. Si tu servidor tarda más de 500 milisegundos en responder, nada más importa. Audita tus consultas a la base de datos, pásate a un proveedor de alojamiento más rápido, implementa caché a nivel de aplicación o usa una CDN. La inversión en TTFB se amortiza de inmediato en cobertura de rastreo.
Optimiza las imágenes. Cada imagen de tu página debe estar comprimida, redimensionada a sus dimensiones de visualización y servida en formatos modernos como WebP con alternativas en PNG. Usa una herramienta de compresión de imágenes. Para las imágenes principales, usa una CDN con optimización automática.
Difiere el JavaScript no crítico. Carga solo el JavaScript que sea absolutamente necesario para que el rastreador vea el contenido. Los scripts que siguen la analítica, cargan anuncios o activan funciones interactivas deben diferirse o cargarse de forma asíncrona. Así el hilo principal queda libre y la ejecución es rápida.
Renderiza en el servidor el contenido crítico. Si tu sitio usa un framework de cliente, renderiza la ruta crítica en el servidor e hidrata en el cliente. Así los rastreadores ven el contenido de inmediato. La generación de sitios estáticos (SSG) es aún mejor: construye tus páginas en HTML en el momento del despliegue.
Evita los contenidos incrustados grandes de terceros. Si incrustas reproductores de YouTube, reproductores de audio o widgets externos grandes, bloquean el renderizado. Sustitúyelos por marcadores que se cargan al hacer clic, o extrae la información esencial a HTML estático.
Reserva espacio para el contenido dinámico. Define dimensiones explícitas para imágenes, anuncios y secciones dinámicas. Esto evita los desplazamientos del diseño y asegura que el rastreador extraiga el contenido correcto.
Usa una CDN. Una red de distribución de contenidos dirige las solicitudes al servidor geográficamente más cercano, lo que reduce la latencia y el TTFB. La mayoría de las CDN también ofrecen optimización y compresión automática de imágenes.
Qué incluye WEMASY para la velocidad y la optimización de rastreadores
El creador de webs de WEMASY incluye alojamiento con caché CDN automática, optimización de imágenes al subirlas y renderizado en el servidor de todo el contenido del sitio. Las páginas creadas con WEMASY cumplen por defecto los estándares de Core Web Vitals.
Cuando publicas un sitio con WEMASY, tu TTFB se optimiza gracias a nuestra CDN, tus imágenes se redimensionan y comprimen automáticamente y tu HTML se sirve como páginas estáticas, no generadas bajo demanda. Esto significa que los rastreadores de IA ven tu contenido de inmediato, sin esperar a ningún renderizado ni procesamiento.
Descubre qué incluyen los planes de precios de WEMASY.
Preguntas frecuentes
¿La velocidad de página afecta más a las citas de IA que al SEO tradicional?
Los rastreadores de IA son más sensibles a la velocidad porque funcionan con restricciones de tiempo más estrictas. Los rastreadores tradicionales de Google pueden esperar 10 segundos a que cargue una página. Los rastreadores de IA suelen agotar el tiempo de espera a los 3 a 5 segundos. En el SEO tradicional, la velocidad es una señal de posicionamiento. En el GEO, la velocidad es un umbral. Si no lo superas, las citas no ocurren en absoluto. Con el creador de webs de WEMASY puedes montarlo directamente en tu web.
¿Cómo sé si mi TTFB es lo bastante rápido para los rastreadores de IA?
Usa Google PageSpeed Insights (ejecútalo como si fuera un rastreador comprobando la versión de escritorio). Busca un TTFB inferior a 500 ms. Si es mayor, tienes que investigar tu alojamiento, tu base de datos o el código de tu aplicación. Otras herramientas gratuitas de prueba de velocidad también muestran el TTFB. Si tu TTFB está de forma constante por encima de 600 ms, contacta con tu proveedor de alojamiento o plantéate pasarte a uno más rápido.
¿Debo optimizar los Core Web Vitals si no sigo los posicionamientos tradicionales de Google?
Sí. Los Core Web Vitals afectan directamente a la visibilidad en la IA. Los estudios muestran que el 85% de los sitios citados por las plataformas de IA superan los tres umbrales de los Core Web Vitals. Aunque los posicionamientos de Google no importen a tu negocio, la visibilidad en la IA sí. La optimización es la misma.
¿Merece la pena cambiar a un proveedor de alojamiento más rápido solo por los Core Web Vitals?
Si tu TTFB actual está por encima de 600 ms, sí. La diferencia de coste entre un alojamiento básico y uno rápido suele ser de $5 a $15 al mes. El retorno de unas mejores citas de IA y de una mayor cobertura de rastreo es mucho mayor. Un alojamiento rápido también mejora la experiencia del usuario y las tasas de conversión, no solo la capacidad de rastreo.
¿El almacenamiento en caché mejora los Core Web Vitals?
El caché es esencial. El caché del navegador indica a los navegadores de los visitantes que guarden imágenes y archivos estáticos en local para no tener que descargarlos de nuevo. El caché del servidor guarda en memoria páginas ya renderizadas para no tener que reconstruirlas desde cero. Ambos reducen el TTFB y el LCP de forma notable. Implementa cabeceras de caché con decisión y usa una CDN con caché automático.
¿Optimizar la velocidad para los rastreadores de IA perjudicará la experiencia del usuario?
No. Las optimizaciones para la velocidad de los rastreadores, como servidores más rápidos, compresión de imágenes y diferir JavaScript, mejoran la experiencia del usuario en todos los sentidos. Las páginas que cargan más rápido para los rastreadores cargan más rápido para las personas. La única excepción es si intentas optimizar solo para los rastreadores quitando imágenes o recortando contenido, lo que perjudicaría a los usuarios. No lo hagas. Optimiza la velocidad sin quitar valor.