Cómo leer Core Web Vitals en Google Search Console y mejorar la velocidad del sitio web
Google Search Console (GSC) es una herramienta gratuita que te muestra cómo Google ve tu sitio web en los resultados de búsqueda. Esto incluye una visión sobre la velocidad, es decir, las métricas de Core Web Vitals. Y aquí es donde muchos se pierden.
Este artículo es para aquellos responsables de la velocidad de los sitios web, pero que tienen dificultades con Search Console. Desarrolladores, especialistas en marketing, gestores de proyectos y propietarios de sitios web que necesitan entender los datos de Core Web Vitals y saber qué hacer con ellos.
¿Por qué lo escribimos nosotros? En PageSpeed.ONE hemos optimizado con éxito decenas de sitios web grandes y pequeños de nuestros clientes. Search Console es nuestra segunda herramienta más importante después de nuestro propio monitoreo de velocidad. La tomamos en serio porque vemos regularmente la conexión entre Core Web Vitals y los resultados en SEO, el costo por clic en PPC y las conversiones.
¿Qué es Google Search Console y por qué es importante?
Google Search Console es un conjunto de informes sobre cómo se desempeña tu sitio web en la Búsqueda de Google. Podrás ver en qué consultas apareces, qué páginas ha indexado Google, qué problemas técnicos tiene con el sitio y cómo evalúa la experiencia del usuario, incluida la velocidad.
Para los desarrolladores es crucial por una sencilla razón: son datos directamente de Google, no una estimación de terceros. Cuando Google dice que parte de tus páginas son "malas" desde la perspectiva de Core Web Vitals, es la misma señal que se refleja en la valoración en los resultados de búsqueda.
¿Y por qué especialmente para la velocidad? La velocidad es una de las señales de evaluación. Influye en el SEO y en el costo por clic en PPC, porque una página de destino lenta empeora el Quality Score en Google Ads. Vemos repetidamente el impacto de Core Web Vitals en el negocio, por ejemplo, en la tienda en línea Denatura, donde combinamos la optimización de la velocidad con análisis continuos en Search Console y gradualmente observamos mejoras en los rankings de búsqueda.
Search Console rápidamente muestra dónde tienes URLs problemáticas o grupos de páginas desde la perspectiva de Google.
¿Cómo mide Google la velocidad?
Antes de sumergirnos en los informes, es necesario entender cómo Google mide la velocidad. Sin esto, te perderás en los números.
Fundamentos: métricas, CrUX y evaluación por la métrica más débil
La velocidad se describe mediante tres métricas Core Web Vitals: velocidad de carga (LCP), tiempo de respuesta a la interacción (INP) y estabilidad visual (CLS). Cada una tiene sus propios umbrales para valores "buenos", "necesitan mejora" y "malos". Las desglosamos en detalle en artículos separados sobre LCP, INP y CLS.
Lo importante es de dónde provienen los números. No son pruebas únicas, sino datos de usuarios reales de Chrome del conjunto de datos Chrome UX Report (CrUX). Google recopila la velocidad tal como la experimentaron los visitantes reales en los últimos 28 días, separadamente para móvil y escritorio.
Cuidado con una regla que confunde incluso a los avanzados: un grupo de páginas se evalúa según la métrica más baja. Si un grupo tiene un CLS malo pero un INP excelente, todo el grupo se considera "malo". Basta un problema para que todo el grupo caiga en rojo.
Tres niveles de medición de la velocidad
La velocidad no se mide en un solo nivel. Vale la pena distinguir tres, porque cada uno responde a una pregunta diferente y tiene una herramienta distinta:
- Nivel de dominio: indica cómo está todo el sitio. Estos datos los encuentras en el monitoreo de PageSpeed.ONE y otras herramientas que trabajan con CrUX.
- Nivel de grupos de páginas: muestra qué tipos de páginas arrastran al sitio hacia abajo. Este es el dominio del informe de Core Web Vitals en Search Console.
- Páginas concretas: se trata cuando necesitas ajustar una URL específica. Para esto sirve el test de velocidad del sitio web (Insights) o la API de CrUX.
Tres niveles de medición de la velocidad del sitio web. Search Console cubre principalmente el nivel medio, es decir, grupos de páginas.
A continuación, detallamos cada nivel y dónde obtener los datos.
Principios: a quién se asignan los datos
Google no asigna la velocidad a todas las páginas por igual. Funciona en pasos:
- Si una página específica tiene suficiente tráfico, se evalúa según sus propios Core Web Vitals.
- Si la página no tiene datos propios, Google la asigna a un grupo de páginas similares (esto es lo que se ve en Search Console) o utiliza la evaluación de todo el dominio. El valor del dominio cubre la mayoría de las URLs en el sitio, por lo que es tan importante.
- Ten en cuenta que ni siquiera el dominio puede tener datos CrUX. En sitios nuevos o con poco tráfico, Google simplemente no tiene suficientes mediciones.
Estos principios se complementan con otras reglas de CrUX que aquí solo tocaremos brevemente, pero es bueno saber: los datos se ejecutan en una ventana acumulativa de 28 días, por lo que los cambios se manifiestan con retraso, y en aplicaciones de una sola página (SPA) algunas métricas se miden de manera diferente. Los detalles están en el artículo sobre el Informe de Experiencia de Usuario de Chrome.
Informes de velocidad en Google Search Console
Ahora lo principal: dónde encontrar los informes y cómo leerlos para no sacar conclusiones equivocadas.
Informe Core Web Vitals
Encontrarás el informe en el menú izquierdo de Search Console en la sección Experiencia de página (Experience), elemento Core Web Vitals. Se te abrirá un resumen dividido en móvil y escritorio. Siempre aborda ambas partes por separado, ya que la experiencia móvil y de escritorio suele diferir.
Al hacer clic en móvil o escritorio, accederás a grupos de páginas individuales con una descripción del problema (por ejemplo, "LCP superior a 2,5 s"). Aquí está la mayor pista sobre qué optimizar. Google te ofrecerá ejemplos de URLs específicas para cada grupo.
Cuidado con el gráfico confuso de Core Web Vitals
El gráfico en el informe de Core Web Vitals puede llevar a errores. Los no expertos piensan que muestra el valor de la métrica. No lo hace. Muestra el número de páginas en las bandas verde, naranja y roja.
Esto tiene una consecuencia práctica. Mover páginas de la banda naranja a la verde puede significar, por ejemplo, una mejora del LCP de 2,51 s a 2,49 s, donde solo se cruzó el umbral de la banda, pero la velocidad real apenas cambió. Y al contrario, un gran salto en el gráfico no necesariamente significa un gran salto en la velocidad percibida.
El informe en Search Console muestra cuántas URL caen en la banda "necesita mejora", no el valor promedio de la métrica para el dominio.
Entonces, ¿cómo leerlo correctamente? Observa la proporción de páginas naranjas y rojas. Si más del 10% de las URLs están en naranja o rojo, definitivamente debes abordarlo para no perder puntos innecesariamente con Google.
Informe de respuesta del backend
El segundo informe importante está algo oculto y nuevamente es algo confuso. Lo encontrarás en Configuración (Settings) en la sección Estadísticas de rastreo (Crawl stats), donde Google informa el tiempo de respuesta promedio del servidor. Básicamente es el TTFB, es decir, el tiempo que tarda el servidor en comenzar a responder. Aunque el informe está escondido, es muy importante por dos razones.
Primero, la respuesta del servidor tiene un impacto directo en las métricas de Core Web Vitals. Un backend lento retrasa la carga y afecta principalmente al LCP. Segundo, influye en el llamado Presupuesto de Rastreo (Crawl Budget), es decir, cuántas páginas y con qué frecuencia está dispuesto Google a rastrear. Cuanto más lento sea el servidor, menos podrá Google rastrear. El concepto y las recomendaciones están descritos en la documentación de Google sobre el Presupuesto de Rastreo.
¿Cómo interpretar el tiempo de respuesta?
- Si está constantemente por encima de 0,8 s, definitivamente deberías abordarlo con infraestructura, desarrolladores o expertos.
- Si las fluctuaciones hacia peores cifras correlacionan con la cantidad de visitantes, refuerza la infraestructura, el servidor no está haciendo frente a los picos.
- Si las fluctuaciones no están relacionadas con el tráfico, podrían ser causadas por el tráfico de robots. Cada vez más son bots de IA, para los cuales tenemos una Estrategia para bots de IA.
Cómo medir la velocidad con Google Search Console
Search Console es una excelente pieza del rompecabezas, pero por sí sola no es suficiente. Repasemos qué puedes obtener de ella y cómo complementarla.
Necesitas datos de dominio
La perspectiva de dominio, es decir, cómo está la velocidad de todo el sitio a lo largo del tiempo, no es algo que Search Console maneje adecuadamente. Esto debes tenerlo en otro lugar, en el monitoreo. Las tres cosas clave son: alertas, medición a largo plazo con historial de datos e información de depuración para los desarrolladores.
En PageSpeed.ONE se utiliza el informe de Dominio con datos completos de CrUX. Verás la evolución día a día y mes a mes, y datos de depuración, como el desglose de LCP en sus partes individuales. Además, una versión de prueba gratuita, Watchdog, que te alerta automáticamente sobre deterioros, y otras funciones. Esta es exactamente la parte que Search Console no cubre, y por eso, sin monitoreo independiente, no puedes trabajar seriamente en mejorar la velocidad.
Monitoreo de Velocidad PLUS
Prueba nuestra aplicación de monitoreo gratis por un mes.
5 400 CZK al año por el sitio web. Factura, no necesitas tarjeta de crédito.
Para diagnósticos únicos, basta con el test de velocidad del sitio web PageSpeed.ONE o PageSpeed Insights de Google. Son útiles para una revisión rápida, no para monitorear la evolución a lo largo del tiempo.
URL individuales
Recomendamos abordar las URL específicas solo en páginas realmente importantes, típicamente la página principal, o en sitios web donde ya tienes los datos de dominio y de grupos en orden (ver más abajo). No tiene sentido ajustar una página mientras tienes grupos enteros en mal estado.
Necesitas grupos de páginas
Los grupos de páginas son el dominio de Search Console, no los encontrarás tan organizados en otro lugar. Trabaja con los dos informes que describimos anteriormente: el informe de Core Web Vitals y el informe de respuesta del backend. El primero te dirá qué tipos de páginas son problemáticos, el segundo revelará un servidor lento.
¿Has solucionado el problema y Google Search Console todavía lo muestra?
Search Console suele tener retrasos y no es completamente precisa, por lo que una corrección no se reflejará de inmediato. No entres en pánico. Después de solucionar los problemas, puedes hacer clic en el botón Start Tracking (Iniciar seguimiento) en el informe de Core Web Vitals. Comenzará una ventana de monitoreo de 28 días que verificará automáticamente si la corrección funcionó. Verás los estados de las URL como Pending (pendiente), Passed (pasó) o Failed (falló).
¿Qué significa "No data available"?
A veces te encontrarás con el mensaje "No data available" (sin datos disponibles) en el informe. Esto significa una de dos cosas: o la propiedad en Search Console es nueva y Google aún no tiene qué mostrar, o el sitio tiene poco tráfico y falta de datos en CrUX. En ambos casos, la perspectiva de dominio se complementa con mediciones sintéticas en el monitoreo.
Listas de comprobación prácticas
Para concluir, aquí tienes dos listas que puedes seguir en la práctica.
Qué hacer regularmente
- Monitorea el dominio. La perspectiva de dominio sobre la velocidad te dará una visión rápida del estado de todo el sitio. Idealmente, con una herramienta que te alerte por sí sola.
- Monitorea los grupos de páginas en Search Console. Aquí verás qué tipos de páginas están afectando la puntuación y dónde comenzar con las correcciones.
- Busca el impacto en SEO y PPC. Relaciona mejoras o deterioros en velocidad con los datos del informe Rendimiento (Performance) en Search Console. Verás si se traduce en posiciones y clics.
- Elige la frecuencia adecuada. Un sitio pequeño basta con revisarlo una vez al mes, un sitio grande tal vez cada semana o incluso cada día. Lo ideal es que las herramientas se reporten solas: el monitoreo de PageSpeed.ONE lo hace, en Search Console tienes que mirar manualmente.
Qué hacer cuando un grupo en Core Web Vitals está en naranja o rojo
- Tómalo como prioridad. Estas son las URLs que están recibiendo una calificación más baja. Encuentra ejemplos específicos de páginas en el grupo, Search Console te los ofrecerá.
- Monitorea estas URLs. Ponlas bajo vigilancia para ver la evolución, no solo una instantánea.
- Consulta los datos de depuración. Combina mediciones sintéticas y datos de depuración de CrUX para saber exactamente qué está afectando a la métrica.
- Prueba la página en el navegador. Cómo hacerlo se describe en el artículo sobre Web Vitals en el navegador.
- Recurre a nuestras guías. Según la métrica problemática, consulta la optimización de LCP, INP o CLS. Para un inicio rápido: en LCP aborda el tamaño y formato de las imágenes y la respuesta del servidor, en INP el JavaScript innecesario y el código de terceros, en CLS siempre especifica las dimensiones de las imágenes y reserva espacio para elementos que se cargan tarde.
- ¿No puedes con todo? Ponte en contacto con expertos. Podemos ayudar con la optimización y la interpretación de datos en el marco de nuestros servicios.
- Después de la corrección, haz clic en Start Tracking. En los informes de Core Web Vitals, inicia el seguimiento y deja que Google verifique la corrección.