Cómo Revisar tus Core Web Vitals en AmICited

Las páginas rápidas y estables también importan para la visibilidad en IA — los motores de respuesta favorecen las fuentes que cargan rápido. Antes de entrar en la auditoría de AmICited, conviene entender qué miden realmente los Core Web Vitals y por qué un problema de velocidad de página puede convertirse, sin que te des cuenta, en un problema de citas de IA.

Qué son los Core Web Vitals

Los Core Web Vitals son un conjunto de métricas estandarizadas que Google creó para cuantificar la experiencia de página en condiciones reales: qué tan rápido aparece el contenido principal de una página, con qué rapidez responde a la interacción y qué tan estable se mantiene visualmente mientras carga. Fueron diseñadas para sustituir la vaga noción de “el sitio se siente lento” por números que se pueden medir, comparar y usar para exigir cuentas a los equipos de ingeniería. Google los incorporó a sus señales de posicionamiento hace años, y esos mismos datos subyacentes —recopilados de usuarios reales de Chrome a través del Chrome UX Report (CrUX)— influyen cada vez más en qué fuentes están dispuestos a obtener, renderizar y citar los motores de respuesta.

Las tres métricas principales son Largest Contentful Paint (LCP), Interaction to Next Paint (INP) y Cumulative Layout Shift (CLS), cada una con un umbral de aprobado/reprobado que Google publica y actualiza periódicamente. Dos métricas complementarias, First Contentful Paint (FCP) y Time to First Byte (TTFB), completan el panorama de velocidad de página al aislar qué tan rápido responde el servidor y qué tan rápido aparece cualquier cosa en pantalla, incluso antes de que el contenido principal esté listo. Como CrUX se construye a partir de datos de campo anonimizados —visitas reales de usuarios reales de Chrome—, las cifras reflejan condiciones reales (mezcla de dispositivos, calidad de red, geografía) en lugar de una sola prueba de laboratorio hecha en una conexión rápida de oficina.

¿Por qué importa esto específicamente para la optimización para motores generativos ? Los rastreadores de IA y los sistemas de recuperación detrás de AI Overviews, la búsqueda de ChatGPT y Perplexity tienen que obtener y analizar tu página antes de poder citarla. Una página que se agota por tiempo de espera, que carga lentamente o que desplaza su contenido mientras carga resulta más costosa de rastrear a gran escala y menos fiable para extraer contenido limpio. Un TTFB lento en particular puede hacer que un rastreador abandone la solicitud antes de que llegue siquiera tu contenido principal. Nada de esto es el factor dominante para que te citen —la relevancia, autoridad y estructura del contenido importan mucho más—, pero una página principal crónicamente lenta o inestable es una fricción que los motores de respuesta no tienen motivo para tolerar cuando un competidor más rápido ofrece la misma información.

Este es también un caso en el que el SEO técnico y la optimización para motores de respuesta se solapan casi por completo: las mismas correcciones de ingeniería que mejoran tu posicionamiento en Google —el tamaño de las imágenes, el tiempo de respuesta del servidor, la estabilidad del diseño— son las que mantienen tus páginas accesibles y citables para los sistemas de IA. Ese solapamiento es exactamente el motivo por el que AmICited muestra los Core Web Vitals dentro de una auditoría más amplia de visibilidad en IA en lugar de como una herramienta de SEO independiente: es un factor más entre los que determinan si los motores de IA consideran tu sitio confiable y fácil de procesar.

Dónde encontrarlo

Abre Auditoría → Web Vitals desde la navegación lateral. La página lo explica: “Core Web Vitals para la página principal de tu dominio… la velocidad de carga es un factor de posicionamiento en Google y los motores de respuesta de IA favorecen las páginas que cargan rápido.” AmICited obtiene estos datos automáticamente para tu dominio monitoreado y para cada competidor que estés siguiendo, así que no necesitas usar una herramienta aparte ni pegar URLs manualmente — es el mismo conjunto competitivo que ya utilizas para rastrear el share of voice y el ranking de citas en el resto de la plataforma.

Como CrUX requiere un volumen mínimo de tráfico real de Chrome antes de publicar cifras estables para una URL, los dominios con poco tráfico —incluidos muchos sitios B2B y de nicho— a veces mostrarán valores en blanco durante un tiempo. Eso es un comportamiento esperado, no un error: significa que Google todavía no ha acumulado suficientes datos de campo para informar con confianza, y se completará una vez que se acumule tráfico (o tiempo).

Qué significan las métricas

La tabla de comparación de competidores muestra cada dominio con:

• Puntuación — un resumen general de aprobado/reprobado de Core Web Vitals, que te da de un vistazo si un dominio supera los umbrales de Google en todos los aspectos.
• LCP (Largest Contentful Paint) — qué tan rápido carga el contenido principal, normalmente la imagen o el bloque de texto más grande dentro del viewport. Es la métrica más directamente ligada a la percepción de un visitante —o de un rastreador— de si “la página ya está lista”.
• INP (Interaction to Next Paint) — qué tan receptiva se siente la página cuando un usuario realmente interactúa con ella (haciendo clic, tocando, escribiendo). Sustituyó a la antigua métrica First Input Delay porque captura la capacidad de respuesta durante toda la visita a la página, no solo en la primera interacción.
• CLS (Cumulative Layout Shift) — qué tan estable es visualmente la página mientras carga. Un CLS alto significa que los elementos se mueven a medida que cargan imágenes, anuncios o fuentes, lo cual resulta molesto para los visitantes y puede dificultar que los sistemas automatizados analicen el contenido de forma coherente.
• FCP (First Contentful Paint) — qué tan rápido aparece algo por primera vez en pantalla, incluso antes de que el contenido principal esté listo. Es una señal temprana de que la página está cargando, en lugar de mostrar una pantalla en blanco.
• TTFB (Time to First Byte) — velocidad de respuesta del servidor: el tiempo entre solicitar la página y recibir el primer byte de vuelta. Es una métrica casi enteramente de backend/infraestructura, y suele ser la más fácil de corregir con cambios de hosting, caché o CDN.

Tu propio dominio aparece marcado como Tú, con las páginas principales de tus competidores monitoreados debajo, de modo que cada métrica se compara de inmediato en lugar de verse de forma aislada.

Cómo usarlo

1. Compárate con tus rivales. Si las páginas de tus competidores son más rápidas, esa es una ventaja adicional que tienen tanto en búsquedas como en respuestas de IA — y una brecha que resulta barata de cerrar en comparación con el trabajo de contenido o de autoridad.
2. Corrige los rojos. Un LCP o CLS deficiente señala trabajo de ingeniería específico: imágenes de cabecera sobredimensionadas, atributos de ancho/alto faltantes, scripts que bloquean el renderizado o fuentes web sin optimizar son los culpables habituales.
3. Prioriza el TTFB si es lento. Como está ubicado antes que todas las demás métricas, un TTFB lento también arrastra al LCP, y suele ser la métrica más rápida de mejorar —a menudo mediante caché, una CDN o una mejora de hosting, en lugar de una reescritura de contenido.
4. Vuelve a revisar tras los cambios. A medida que los datos de campo se actualizan, regresa para confirmar que las mejoras se consolidaron. Los datos de CrUX son una ventana móvil de 28 días, así que los cambios tardan en reflejarse — no esperes que las cifras se muevan al día siguiente de un despliegue.
5. Trata el TTFB como una señal de alerta temprana. Un servidor que habitualmente tarda más de un segundo en devolver el primer byte es un firme candidato a tener problemas de rastreo y renderizado que van mucho más allá de esta auditoría — vale la pena leer por qué los ingenieros de rastreadores tratan cada vez más un TTFB rápido como un umbral para el éxito con rastreadores de IA en lugar de considerarlo algo simplemente deseable.

Ninguna de estas cuatro métricas opera de forma aislada respecto al resto de tu huella técnica. Una página principal que obtiene buena puntuación en Core Web Vitals pero bloquea a los rastreadores de IA en el robots.txt, o que sirve una página prácticamente vacía a clientes sin JavaScript, seguirá sin conseguir citas — la velocidad solo ayuda una vez que un rastreador tiene realmente permiso para entrar y puede analizar lo que hay ahí. Por eso vale la pena tratar esta auditoría como un punto de control más dentro de una rutina más amplia, en lugar de como una corrección puntual: ejecútala junto al resto de tus auditorías de AmICited de forma periódica, del mismo modo en que revisarías regularmente una lista de verificación técnica más amplia que cubra la rastreabilidad, los datos estructurados y la extraibilidad del contenido.

Los Web Vitals por sí solos no ganarán citas, pero las páginas lentas e inestables pueden frenarte — esta auditoría te indica en qué posición te encuentras respecto a los sitios entre los que eligen los motores de IA. Si quieres profundizar en la investigación detrás de esta recomendación, consulta si la velocidad de página realmente afecta la visibilidad en búsquedas de IA , y combina esta revisión con una auditoría de accesibilidad para IA más amplia de tu sitio para cubrir el aspecto de la rastreabilidad. A partir de ahí, el siguiente paso natural es incorporar los Web Vitals a tu rutina de monitoreo regular junto con el rastreador de ranking en IA de AmICited y el seguimiento de citas, de modo que una regresión de rendimiento se detecte al mismo tiempo que notarías una caída en las menciones — en lugar de descubrirla por separado, semanas después, cuando ya te haya costado visibilidad.