Core Web Vitals y Latencia: ¿Las páginas más rápidas obtienen más citas de IA?

Core Web Vitals y Latencia: ¿Las páginas más rápidas obtienen más citas de Inteligencia Artificial?

Introducción

Un sitio web rápido es más fácil de usar para las personas. También puede ser más fácil de recuperar, renderizar y entender para los motores de búsqueda y los sistemas de inteligencia artificial.

Pero a menudo se pasa por alto una distinción importante:

Una página más rápida puede mejorar el rastreo y la disponibilidad del contenido. Esto no significa que la velocidad por sí sola haga que un sistema de inteligencia artificial cite la página.

A partir del 2 de agosto de 2026, Google afirma que los tiempos de respuesta estables del servidor y una menor latencia pueden aumentar la capacidad de rastreo de un sitio. Google también afirma que sus funciones de búsqueda con inteligencia artificial utilizan los mismos sistemas básicos de búsqueda e indexación que la búsqueda tradicional y no requieren un marcado especial de inteligencia artificial u optimizaciones de velocidad. (developers.google.com)

Este artículo presenta un plan de pruebas basado en evidencia, en lugar de afirmar que ya se ha ejecutado un experimento completo. No se proporcionó ningún sitio, conjunto de páginas, registro de servidor o conjunto de datos de citas. El objetivo es definir un estudio controlado que pueda medir:

1. Si un tiempo hasta el primer byte más bajo aumenta la frecuencia de rastreo.
2. Si un Largest Contentful Paint más bajo mejora el descubrimiento o la indexación.
3. Si un Cumulative Layout Shift más bajo afecta el rastreo o la recuperación de inteligencia artificial.
4. Si las mejoras de rendimiento aumentan la tasa a la que las páginas son citadas visiblemente por los sistemas de búsqueda de inteligencia artificial.

La Respuesta Breve

Un tiempo hasta el primer byte más bajo puede mejorar el rastreo bajo las condiciones adecuadas

La documentación actual de rastreo de Google dice que su límite de capacidad de rastreo puede aumentar cuando un sitio tiene tiempos de respuesta estables o en mejora, incluyendo el tiempo hasta el primer byte. Si los tiempos de respuesta aumentan, o si un sitio devuelve demasiados errores del servidor o respuestas de límite de tasa, Google puede reducir el rastreo. (developers.google.com)

Sin embargo, un tiempo de respuesta más rápido no garantiza un mayor rastreo. La demanda de rastreo también depende de factores como:

• Con qué frecuencia cambia el sitio.
• Cuán populares son el sitio y sus páginas.
• Si el contenido es útil y único.
• Cuántas URL duplicadas o de bajo valor existen.
• Si las URL actualizadas se incluyen en los sitemaps.

Esto significa que una menor latencia debería tener el efecto más fuerte en sitios web grandes, actualizados con frecuencia o con limitaciones de servidor, no necesariamente en un sitio pequeño con contenido nuevo limitado.

Un Largest Contentful Paint más bajo puede ayudar indirectamente

Largest Contentful Paint mide cuándo aparece el contenido principal visible para un usuario. Google también afirma que tanto el tiempo de respuesta del servidor como el tiempo requerido para renderizar páginas y recursos incrustados pueden afectar la eficiencia del rastreo. (developers.google.com)

La relación probable es indirecta:

Menor latencia → entrega de recursos más rápida → renderización o recuperación más eficiente → menos tiempos de espera de rastreo o recuperaciones incompletas.

El efecto debería ser más fuerte cuando el contenido importante depende de:

• JavaScript lento.
• Imágenes grandes.
• Hojas de estilo que bloquean la renderización.
• Renderizado del lado del cliente.
• Recursos incrustados pesados.

Es poco probable que una puntuación rápida de Largest Contentful Paint por sí sola sea una señal directa de citación de inteligencia artificial.

Un Cumulative Layout Shift más bajo probablemente tiene poco efecto directo en el rastreo

Cumulative Layout Shift mide el movimiento inesperado del contenido visible. Es principalmente una métrica de experiencia de usuario. Las causas comunes incluyen imágenes sin dimensiones, anuncios insertados dinámicamente, contenido incrustado y fuentes web. (web.dev)

Un rastreador no experimenta un cambio de diseño de la misma manera que un visitante humano. Por lo tanto, una relación directa entre un Cumulative Layout Shift más bajo y un mayor rastreo es improbable.

Puede haber una relación indirecta cuando un gran cambio de diseño es causado por:

• Contenido insertado tarde por JavaScript.
• Texto importante oculto hasta que se ejecutan los scripts.
• Imágenes o incrustaciones que retrasan la construcción de la página.
• Plantillas inestables que producen contenido diferente durante diferentes recuperaciones.

En esos casos, el problema real no es la puntuación del cambio de diseño. El problema real es que la página puede ser difícil de procesar o puede exponer contenido importante demasiado tarde.

Las páginas más rápidas no son citadas automáticamente con mayor frecuencia

Google dice que las páginas que aparecen en las funciones de inteligencia artificial primero deben estar indexadas y ser elegibles para aparecer en los resultados de búsqueda normales con un fragmento. Google también dice que no hay requisitos técnicos adicionales u optimizaciones especiales de inteligencia artificial para sus descripciones generales de inteligencia artificial y su modo de inteligencia artificial. (developers.google.com)

OpenAI, de manera similar, afirma que las clasificaciones de búsqueda de ChatGPT dependen de múltiples factores y que permitir su rastreador de búsqueda, OAI-SearchBot, es importante para la inclusión. No afirma que unos Core Web Vitals más bajos aumenten directamente la probabilidad de citación. (help.openai.com)

Esto sugiere un modelo de cuatro etapas:

1. Descubrimiento — ¿El sistema aprende que la URL existe?
2. Recuperación y procesamiento — ¿Puede el sistema recuperar y entender la página?
3. Indexación y recuperación — ¿Se selecciona la página para una consulta particular?
4. Selección de citación — ¿Se muestra la página como una fuente visible en la respuesta?

La velocidad de la página puede afectar las dos primeras etapas. No se ha establecido como una causa directa de la cuarta etapa.

Investigaciones recientes también muestran que los sistemas de inteligencia artificial pueden leer muchas páginas relevantes pero citar solo algunas de ellas. En otras palabras, la recuperación y la citación son eventos separados. (cambridge.org)

¿Qué debería probarse?

El estudio debería probar dos preguntas diferentes en lugar de tratar la “visibilidad de la inteligencia artificial” como una sola métrica.

Pregunta 1: ¿El rendimiento afecta el rastreo?

Resultados primarios:

• Tiempo desde la publicación hasta la primera solicitud del rastreador.
• Número de solicitudes de rastreadores por página por día.
• Tiempo entre rastreos exitosos.
• Número de páginas rastreadas por cada 1,000 páginas publicadas.
• Porcentaje de recuperaciones exitosas.
• Tasa de errores del servidor y respuestas de límite de tasa.
• Tiempo desde la publicación hasta la indexación.

Pregunta 2: ¿El rendimiento afecta la selección de citaciones?

Resultados primarios:

• Porcentaje de consultas probadas que producen una citación visible.
• Tasa de citación por página elegible.
• Cuota de citación dentro de una consulta.
• Porcentaje de páginas recuperadas que se convierten en citaciones visibles.
• Persistencia de la citación a lo largo del tiempo.
• Tasa de citación por sistema de inteligencia artificial.

Estos resultados deben separarse por proveedor. Una descripción general de inteligencia artificial de Google, un resultado de búsqueda de ChatGPT, una respuesta de Microsoft Copilot, una respuesta de Perplexity y una respuesta de búsqueda de Claude pueden usar diferentes índices, rastreadores, sistemas de clasificación y horarios de actualización.

Diseño Experimental

1. Construir un conjunto de páginas controlado

Utilice un conjunto de páginas lo suficientemente grande como para producir datos significativos de rastreo y citación.

Un diseño inicial práctico incluiría:

• 240 a 800 páginas.
• Al menos 20 páginas por plantilla de página.
• Tres a cinco categorías de contenido.
• Una mezcla de páginas perennes y páginas actualizadas regularmente.
• Igual número de páginas en cada grupo de tratamiento.

Cada página debería tener:

• Estructura HTML similar.
• Longitud de contenido similar.
• El mismo sistema de publicación.
• El mismo patrón de enlaces internos.
• Las mismas reglas canónicas.
• El mismo tratamiento de sitemap.
• Los mismos permisos de robots.txt.
• Un tema único y útil.

No cree cientos de páginas delgadas o casi duplicadas solo para el experimento. La guía de Google advierte que las URL duplicadas y de bajo valor pueden desperdiciar recursos de rastreo y reducir la eficiencia de un sitio. (developers.google.com)

Un diseño de pares emparejados es útil. Por ejemplo, empareje páginas con características similares de:

• Longitud de contenido.
• Demanda del tema.
• Frecuencia de actualización.
• Recuento de enlaces internos.
• Recuento de enlaces externos.
• Tráfico histórico.
• Posición en el ranking de búsqueda.

Luego, coloque una página de cada par en el grupo de control y la otra en un grupo de tratamiento.

2. Utilizar un diseño de tratamiento factorial

Los principales tratamientos de rendimiento deben probarse de forma independiente y conjunta.

Esto crea un experimento controlado para las tres optimizaciones solicitadas:

• HTTP/3.
• Almacenamiento en caché en el borde de la red de entrega de contenido.
• Compresión de imágenes.

El tratamiento de estabilidad del diseño es necesario porque las tres primeras optimizaciones no aíslan de forma fiable el Cumulative Layout Shift. La compresión de imágenes puede reducir el Largest Contentful Paint sin cambiar la estabilidad del diseño en absoluto.

Por qué HTTP/3 necesita su propia medición

HTTP/3 utiliza el protocolo de transporte QUIC y proporciona flujos independientes, lo que puede evitar el bloqueo de cabecera de línea a nivel de transporte que se encuentra en HTTP/2 sobre TCP. Sus beneficios dependen de si el cliente o el rastreador realmente negocian HTTP/3. (rfc-editor.org)

Por lo tanto, registre el protocolo negociado para cada solicitud:

• HTTP/1.1.
• HTTP/2.
• HTTP/3.

No asuma que habilitar HTTP/3 significa que todos los rastreadores lo utilizan. Si Googlebot, OAI-SearchBot u otro rastreador sigue usando HTTP/2, HTTP/3 no puede afectar las solicitudes de ese rastreador.

Por qué el almacenamiento en caché en el borde debe probarse cuidadosamente

Una red de entrega de contenido puede reducir el tiempo hasta el primer byte sirviendo contenido más cerca del solicitante. También puede reducir el número de solicitudes que llegan al servidor de origen. (web.dev)

Pruebe al menos tres estados de caché:

1. Caché fría — El borde debe contactar al origen.
2. Caché caliente — El borde sirve la página sin contactar al origen.
3. Caché revalidada — El borde o el rastreador usa un valor ETag o Last-Modified y recibe una respuesta 304 Not Modified.

Google recomienda específicamente el almacenamiento en caché HTTP eficiente y admite el uso de respuestas 304 Not Modified para reducir el procesamiento y el ancho de banda innecesarios. (developers.google.com)

No permita que el almacenamiento en caché sirva contenido obsoleto o incorrecto a los rastreadores. Registre:

• Acierto o fallo de caché.
• Antigüedad de la caché.
• Ubicación del borde.
• Tiempo de respuesta del origen.
• Versión del contenido.
• Código de estado.
• Cabeceras de validación.

Por qué la compresión de imágenes debe vincularse al Largest Contentful Paint

WebP y AVIF generalmente proporcionan una mejor compresión que los formatos de imagen más antiguos. Las imágenes más pequeñas pueden reducir el tiempo de transferencia y pueden mejorar el Largest Contentful Paint cuando la imagen es el elemento Largest Contentful Paint. (web.dev)

La prueba debe usar:

• Las mismas dimensiones de imagen.
• El mismo objetivo de calidad visual.
• Imágenes srcset adaptables.
• Un formato moderno con una reserva adecuada.
• Valores explícitos de width y height.
• Sin carga diferida para la imagen Largest Contentful Paint.
• Una URL de imagen visible en el HTML inicial.

La compresión de imágenes por sí sola puede no mejorar el Largest Contentful Paint si el retraso real proviene de JavaScript o de un descubrimiento tardío de recursos. La guía de rendimiento de Google señala que reducir el tiempo de descarga de imágenes puede simplemente trasladar el retraso a otra parte de la página si el elemento Largest Contentful Paint se revela tarde. (web.dev)

3. Ejecutar la prueba el tiempo suficiente

Una prueba corta puede pasar por alto los efectos de la programación de rastreo y la actualización del índice.

Un diseño práctico es:

• Dos semanas de medición de referencia.
• De seis a doce semanas de medición de tratamiento.
• Un período final de reversión o cruce si es posible.

Para una prueba de cruce, cambie los tratamientos entre grupos de páginas emparejados. Si el efecto del rendimiento desaparece cuando se elimina el tratamiento, el resultado es más sólido que una simple comparación antes y después.

Los datos de campo de Core Web Vitals deben evaluarse durante un período adecuado. El Informe de Experiencia del Usuario de Chrome utiliza una agregación móvil de 28 días, por lo que no está diseñado para mostrar cambios instantáneos después de una implementación. (developer.chrome.com)

4. Medir la población completa de rastreadores

No trate todo el tráfico automatizado como un solo grupo.

Como mínimo, separe:

Rastreadores de búsqueda

• Googlebot.
• Bingbot.

Rastreadores de búsqueda de inteligencia artificial

• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.

Recuperadores solicitados por el usuario

• Perplexity-User.
• Claude-User.
• Recuperadores de usuario de ChatGPT donde sean identificables.

Rastreadores de entrenamiento

• GPTBot.
• ClaudeBot.
• Controles de Google-Extended.

Los rastreadores de entrenamiento no deben usarse como un proxy para las citaciones de búsqueda de inteligencia artificial. Anthropic, OpenAI y Google distinguen entre los rastreadores utilizados para entrenamiento, búsqueda o recuperación solicitada por el usuario. Google también afirma que Google-Extended no afecta la inclusión o clasificación en la Búsqueda de Google. (help.openai.com)

Perplexity, de manera similar, distingue entre PerplexityBot, que admite la indexación de búsqueda, y Perplexity-User, que puede recuperar una página en respuesta a una solicitud del usuario. (docs.perplexity.ai)

Verifique la identidad del rastreador utilizando los rangos de IP publicados o el DNS inverso donde el proveedor lo admita. Las cadenas de agente de usuario pueden ser copiadas por rastreadores no relacionados. Google advierte específicamente que las cadenas de agente de usuario de Googlebot pueden ser falsificadas. (developers.google.com)

Métricas a Recopilar

Métricas de rendimiento

Recopile datos tanto de laboratorio como de usuarios reales:

• Tiempo hasta el primer byte.
• First Contentful Paint.
• Largest Contentful Paint.
• Cumulative Layout Shift.
• Interaction to Next Paint.
• Peso total de la página.
• Tamaño inicial del HTML.
• Tamaño de transferencia de la imagen.
• Número de solicitudes.
• Tiempo dedicado al procesamiento del servidor.
• Tiempo dedicado a esperar el recurso Largest Contentful Paint.
• Protocolo HTTP.
• Estado de la caché.

Google recomienda un objetivo aproximado de tiempo hasta el primer byte de 800 milisegundos o menos, pero el tiempo hasta el primer byte no es en sí mismo una Core Web Vital. (web.dev)

Los umbrales “buenos” actuales de Core Web Vitals en el percentil 75 son:

• Largest Contentful Paint: 2.5 segundos o menos.
• Cumulative Layout Shift: 0.1 o menos.
• Interaction to Next Paint: 200 milisegundos o menos. (web.dev)

Métricas de rastreo

Para cada solicitud de rastreador verificada, registre:

text timestamp url user_agent verified_bot source_ip http_protocol status_code response_time time_to_first_byte bytes_sent cache_status edge_location etag last_modified referrer

Calcule:

text crawl_requests_per_url_day successful_fetch_rate 5xx_rate 429_rate median_recrawl_interval p75_recrawl_interval publication_to_first_fetch publication_to_first_index

Métricas de citación de inteligencia artificial

Utilice un conjunto fijo de consultas en cada plataforma. El conjunto de consultas debe incluir:

• Preguntas fácticas directas.
• Preguntas de comparación.
• Preguntas de “mejor” o de recomendación.
• Preguntas sensibles a la frescura.
• Preguntas en las que la página probada es la respuesta más sólida.
• Preguntas en las que la página probada es relevante pero no dominante.

Para cada consulta, registre:

text engine model or experience timestamp location device query pages shown as sources page citation order whether the tested page was cited whether the tested page was retrieved but not cited answer text hash

Repita las consultas porque las respuestas de inteligencia artificial pueden variar. Utilice un horario fijo, como tres veces por semana, y registre los cambios en el motor o modelo.

Microsoft Bing Webmaster Tools ahora proporciona un informe de rendimiento de inteligencia artificial que muestra las páginas citadas, las consultas de fundamento y las tendencias de citación en las experiencias de inteligencia artificial de Microsoft compatibles. Microsoft advierte que los datos son agregados, muestreados y observacionales; no pueden probar que un cambio particular en la página haya causado un cambio en la citación. (bing.com)

Google también comenzó a implementar informes dedicados de rendimiento de inteligencia artificial generativa en Search Console en junio de 2026. Los informes estuvieron inicialmente disponibles solo para un subconjunto de sitios web, por lo que el acceso puede variar. (developers.google.com)

Análisis Estadístico

Frecuencia de rastreo

Utilice un modelo de conteo de efectos mixtos, como un modelo binomial negativo:

text crawl_count ~ treatment + time_to_first_byte + page_age + update_frequency + sitemap_status + internal_links + server_errors + (1 | page) + (1 | crawler)

Los efectos de la página y del rastreador importan porque algunas páginas naturalmente reciben más atención que otras, y diferentes rastreadores tienen diferentes horarios.

Descubrimiento e indexación

Utilice análisis de supervivencia para:

• Tiempo desde la publicación hasta la primera recuperación.
• Tiempo desde la publicación hasta el primer índice.
• Tiempo desde la actualización hasta el nuevo rastreo.

El resultado clave no es simplemente si una página fue finalmente rastreada. Es si el tratamiento redujo el tiempo requerido para que la página fuera encontrada y procesada.

Selección de citaciones de inteligencia artificial

Utilice un modelo logístico jerárquico:

text citation_present ~ treatment + time_to_first_byte + largest_contentful_paint + cumulative_layout_shift + indexed_status + search_visibility + content_freshness + page_authority + (1 | query) + (1 | engine) + (1 | page)

Ejecute dos modelos separados:

1. Modelo de recuperación — ¿La página fue recuperada o mostrada como candidata?
2. Modelo de citación — Si fue recuperada, ¿la página fue citada visiblemente?

Esta distinción es esencial. Una mejora de rendimiento que aumenta el rastreo pero no la recuperación no es un efecto de citación de inteligencia artificial. Una mejora de rendimiento que aumenta la recuperación pero no las citaciones sugiere que la página está siendo considerada pero pierde durante la selección de fuentes.

Resultados Esperados

Estas son hipótesis de trabajo, no resultados experimentales declarados.

Hipótesis 1: El tiempo hasta el primer byte tendrá el efecto de rastreo más claro

Espere una relación positiva entre un tiempo hasta el primer byte más bajo y la capacidad de rastreo cuando:

• El sitio tiene muchas páginas.
• Las páginas cambian con frecuencia.
• El servidor de origen es lento o está sobrecargado.
• El sitio devuelve respuestas 5xx o 429.
• El rastreador dedica mucho tiempo a esperar respuestas.

Espere poco efecto medible en un sitio pequeño con baja demanda de rastreo.

Hipótesis 2: Largest Contentful Paint importará a través de la renderización y la entrega de recursos

Espere que un Largest Contentful Paint más bajo ayude cuando:

• La página depende de la renderización del navegador.
• El contenido importante está detrás de JavaScript.
• Se requieren imágenes o hojas de estilo grandes para la indexación.
• El rastreador recupera muchos recursos de la página.
• El tratamiento más lento produce tiempos de espera o renderización incompleta.

Espere una relación débil cuando el texto importante de la página ya esté presente en el HTML inicial.

Hipótesis 3: Cumulative Layout Shift tendrá poco efecto directo

No espere una relación directa significativa entre Cumulative Layout Shift y la frecuencia de rastreo o la tasa de citación después de controlar la estructura de la página y el comportamiento de JavaScript.

Si Cumulative Layout Shift parece predecir citaciones, investigue si está actuando como un proxy para:

• Renderizado del lado del cliente.
• Inserción tardía de contenido.
• Anuncios inestables.
• Texto oculto o retrasado.
• HTML mal estructurado.

Hipótesis 4: La velocidad por sí sola no producirá más citaciones de inteligencia artificial

Los predictores más fuertes de la selección de citaciones probablemente seguirán siendo:

• Relevancia para la consulta.
• Calidad del contenido.
• Respuestas claras.
• Frescura.
• Autoridad y confianza.
• Elegibilidad del índice de búsqueda.
• Rango de recuperación.
• Si la página apoya directamente la afirmación que se hace.

La guía de Google enfatiza el contenido útil, fiable y centrado en las personas, y dice que las funciones de búsqueda de inteligencia artificial se basan en los sistemas de búsqueda e indexación existentes. (developers.google.com)

Un Presupuesto de Rendimiento Sintonizado para la Recuperación de Inteligencia Artificial

El siguiente es un presupuesto operativo propuesto. No es una fórmula publicada de clasificación de inteligencia artificial.

La documentación actual de Google dice que Googlebot recupera los primeros 2 megabytes de un archivo compatible y recupera scripts externos y hojas de estilo por separado. También recomienda colocar metadatos importantes y datos estructurados al principio del HTML. (developers.google.com)

Recomendaciones de Implementación

HTTP/3

Utilice HTTP/3 cuando sea compatible con el proveedor de alojamiento y la red de entrega de contenido.

Mida:

• Tasa de negociación HTTP/3.
• Tasa de reserva HTTP/2.
• Tiempo de configuración de la conexión.
• Tiempo hasta el primer byte.
• Rendimiento por región geográfica.
• Rendimiento por rastreador.

No trate HTTP/3 como una optimización garantizada de búsqueda o inteligencia artificial. Es una mejora de transporte que puede ayudar solo a los clientes que lo utilizan.

Almacenamiento en Caché en el Borde de la Red de Entrega de Contenido

Para páginas públicas y no personalizadas:

• Establezca reglas claras de Cache-Control.
• Utilice almacenamiento en caché de larga duración para activos estáticos versionados.
• Utilice almacenamiento en caché corto pero útil para HTML actualizado con frecuencia.
• Evite la fragmentación de la caché por parámetros de consulta innecesarios.
• Preserve las URL canónicas.
• Soporte ETag y Last-Modified.
• Pruebe los estados de caché fría, caliente y revalidada.
• Confirme que las solicitudes del rastreador reciben el mismo contenido importante que las solicitudes humanas.

Una red de entrega de contenido debe reducir la latencia sin crear versiones de página obsoletas, inconsistentes o específicas para bots.

Compresión de Imágenes

Para imágenes:

• Utilice AVIF o WebP cuando la calidad visual sea aceptable.
• Proporcione tamaños de imagen adaptables.
• No sirva una imagen de tamaño de escritorio a una pantalla móvil pequeña.
• No cargue de forma diferida la imagen Largest Contentful Paint.
• Incluya las dimensiones de la imagen.
• Coloque la imagen Largest Contentful Paint en el HTML inicial.
• Use fetchpriority="high" solo cuando sea apropiado.
• Mantenga las explicaciones importantes en texto en lugar de incrustarlas solo dentro de imágenes.

La compresión de imágenes es más valiosa cuando la imagen es el elemento Largest Contentful Paint. No solucionará una página cuyo retraso principal proviene de la renderización del servidor o la ejecución de JavaScript. (web.dev)

Estabilidad del Diseño

Para reducir el Cumulative Layout Shift:

• Establezca atributos de ancho y alto en las imágenes.
• Reserve espacio para anuncios.
• Reserve espacio para videos incrustados y contenido social.
• Evite insertar banners encima del texto existente.
• Utilice estrategias de carga de fuentes estables.
• Evite reemplazar grandes bloques de contenido renderizado por el servidor después de la carga de la página.

Estos cambios mejoran la experiencia del usuario incluso si no tienen un efecto medible en el rastreo o las citaciones. (web.dev)

Herramientas y Monitorización

Herramientas de rendimiento

Utilice:

• Informe de Experiencia del Usuario de Chrome para Core Web Vitals de usuarios reales.
• Interfaz de programación de aplicaciones del Informe de Experiencia del Usuario de Chrome para la recopilación automatizada de datos de campo.
• PageSpeed Insights para auditorías de laboratorio y datos de campo.
• Lighthouse para pruebas de laboratorio repetibles.
• Lighthouse Continuous Integration para presupuestos de rendimiento de solicitudes pull.
• WebPageTest para pruebas multiubicación, estados de caché y comparaciones de protocolos.
• Chrome DevTools para la depuración de Largest Contentful Paint y layout shift.
• La librería JavaScript web-vitals para el monitoreo de usuarios reales.

La interfaz de programación de aplicaciones del Informe de Experiencia del Usuario de Chrome proporciona datos de campo agregados a nivel de página y de origen, incluyendo Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint y un tiempo experimental hasta el primer byte. (developer.chrome.com)

Lighthouse Continuous Integration puede ejecutar comprobaciones de rendimiento en cada cambio de código y fallar las compilaciones cuando se exceden los presupuestos. (github.com)

Monitorización de rastreadores

Utilice registros del servidor, registros de borde y un pequeño conjunto de sondas sintéticas.

Sonda de ejemplo:

bash curl --http3 -sS -o /dev/null -D -
-w 'status=%{http_code}\nhttp_version=%{http_version}\nnamelookup=%{time_namelookup}\nconnect=%{time_connect}\nstarttransfer=%{time_starttransfer}\ntotal=%{time_total}\nsize=%{size_download}\n'
-A 'Mozilla/5.0 (compatible; OAI-SearchBot/1.0)'
https://example.com/page

Ejecute la misma prueba con:

• Googlebot.
• Bingbot.
• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.
• Un agente de usuario de navegador normal.

La prueba debe verificar:

• Código de estado.
• Permiso de robots.
• Cabeceras de respuesta.
• Contenido HTML.
• Versión HTTP.
• Estado de la caché.
• Tiempo de respuesta.
• Si el texto importante está presente sin JavaScript.

Monitorización de búsqueda e indexación

Utilice:

• Estadísticas de rastreo de Google Search Console.
• Informes de indexación de páginas de Google Search Console.
• Inspección de URL de Google Search Console.
• Datos de sitemap de Google Search Console.
• Informes de inteligencia artificial generativa de Google Search Console cuando estén disponibles.
• Solicitudes de rastreo y páginas indexadas de Bing Webmaster Tools.
• Rendimiento de inteligencia artificial de Bing Webmaster Tools.
• Comprobaciones diarias de sitemap y lastmod.

La interfaz de programación de aplicaciones de Search Console puede recuperar datos de rendimiento por página, consulta, fecha, dispositivo y apariencia de búsqueda, sujeto a sus límites de datos. (developers.google.com)

Monitorización de citaciones

Cree un panel de citaciones que contenga de 50 a 200 consultas estables por tema. Ejecute el panel en un horario fijo y registre:

• Si la plataforma buscó.
• Qué fuentes aparecieron.
• Si la URL probada fue citada.
• Orden de citación.
• La fecha y hora de la respuesta.
• Si la página cambió.
• Si el modelo o la experiencia de búsqueda cambiaron.

No compare los recuentos de citaciones de diferentes sistemas como si fueran equivalentes. Microsoft afirma que la actividad de citación no es una puntuación de clasificación, una puntuación de autoridad, una medida de tráfico o una puntuación de calidad. (bing.com)

Reglas de Alerta

Cree alertas para:

• Tiempo hasta el primer byte que aumenta en más del 25 por ciento.
• Largest Contentful Paint que supera los 2.5 segundos en el percentil 75.
• Cumulative Layout Shift que supera los 0.1.
• Un aumento sostenido en las respuestas 5xx o 429.
• Una caída en la tasa de éxito del rastreador.
• Un cambio en robots.txt.
• Un error de sitemap.
• Una caída repentina en las páginas indexadas.
• Una caída repentina en las citaciones de inteligencia artificial en varias plataformas.
• Un cambio en el volumen de citaciones que afecta solo a una plataforma.

Una disminución de las citaciones que afecta a una plataforma puede ser causada por un cambio de modelo, índice, consulta o producto, en lugar de un problema de rendimiento de la página. Microsoft advierte explícitamente que las tendencias de citación son observacionales y pueden cambiar debido a actualizaciones de contenido, demanda de los usuarios y cambios en el sistema o modelo. (bing.com)

Conclusión Final

La conclusión más defendible es:

Las páginas más rápidas pueden mejorar la eficiencia del rastreo, especialmente cuando la latencia del servidor, el tamaño de los recursos, los errores o los retrasos en la renderización son factores limitantes. Pero actualmente no hay pruebas sólidas de que unos Core Web Vitals más bajos hagan que los sistemas de inteligencia artificial seleccionen directamente una página como citación.

La cadena causal esperada es:

text Menor latencia → mejor capacidad del servidor → menos recuperaciones fallidas o retrasadas → descubrimiento y procesamiento más rápidos → mayor probabilidad de ser indexado y recuperado → posible aumento de citaciones

El paso final sigue siendo incierto porque la selección de citaciones depende de la relevancia, la calidad, la frescura, la autoridad, la intención de la consulta, el rango de recuperación y el comportamiento de cada sistema de inteligencia artificial.

Para la mayoría de los sitios web, la estrategia de rendimiento correcta no es, por lo tanto, “optimizar para citaciones de inteligencia artificial” de forma aislada. Es:

1. Mantenga el contenido importante disponible en el HTML inicial.
2. Mantenga el tiempo hasta el primer byte estable.
3. Utilice almacenamiento en caché en el borde para contenido público.
4. Comprima y priorice las imágenes importantes.
5. Evite los cambios de diseño.
6. Devuelva códigos de estado fiables.
7. Mantenga los sitemaps y los enlaces internos actualizados.
8. Permita los rastreadores de búsqueda correctos.
9. Mida el rastreo, la indexación, la recuperación y la citación como etapas separadas.

Ese enfoque produce un sitio web más rápido para las personas, un sitio más saludable para los rastreadores de búsqueda y una base comprobable para comprender la visibilidad de la inteligencia artificial.