Informe de Core Web Vitals (Google Search Console)

TL;DR — El informe de Core Web Vitals (Métricas web esenciales) en Google Search Console muestra cómo se comportan tus páginas para visitantes reales en las tres métricas de velocidad y estabilidad de Google (LCP, INP, CLS). Son datos del mundo real de usuarios de Chrome, agrupados en conjuntos de páginas similares y divididos en pestañas Mobile y Desktop. Es una herramienta de triaje para todo el sitio, no un comprobador de velocidad página por página, y si tienes un sitio pequeño o nuevo, podría no mostrar ningún dato en absoluto.

Qué es el informe de Core Web Vitals (Métricas web esenciales)

Lo encontrarás en Google Search Console, en la sección Experience. La descripción de una línea del propio Google sobre el informe:

• “shows how your pages perform, based on real world usage data (sometimes called field data).” (traducción) «muestra cómo se comportan tus páginas, según datos de uso del mundo real (a veces llamados datos de campo).»

Lo importante que debes tener claro desde el principio: este es un informe, no las métricas en sí. Core Web Vitals (Métricas web esenciales) —LCP, INP y CLS— son tres mediciones de cómo percibe tu página un visitante real (qué tan rápido se carga el contenido principal, con qué rapidez responde la página a un toque y cuánto saltan los elementos durante la carga). Estas métricas se definen en detalle en otra parte de este sitio. Este artículo trata sobre el informe —la herramienta de Search Console que te muestra esos números y los organiza.

De dónde proceden los datos

El informe no ejecuta una prueba de velocidad. Extrae datos de campo del Chrome User Experience Report (CrUX): tiempos anonimizados de usuarios reales de Chrome que visitaron tus páginas. Esto es diferente de una prueba de laboratorio como PageSpeed Insights, que carga tu página una vez en un entorno controlado. Los datos de campo son lo que realmente les ocurrió a personas reales, promediado durante los últimos 28 días.

Cómo se organiza el informe

Tres cosas que debes saber sobre cómo agrupa tus URL:

• Mobile y Desktop son pestañas separadas. Una página puede ser “Good” en móviles y “Poor” en escritorio al mismo tiempo. Nunca se promedian entre sí.
• Tres grupos de estado: Poor, Need improvement y Good. El estado de una URL lo determina su peor métrica: un número malo arrastra toda la página.
• Las URL se agrupan, no se puntúan una por una. Google agrupa las páginas que son similares (normalmente la misma plantilla de página), por lo que a menudo verás un problema que afecta a todo un lote de URL a la vez.

Lo que la mayoría de las personas entiende mal

Este informe no puede decirte de manera fiable si una página específica es lenta. Google lo dice claramente: “not designed [to] find the status of a specific URL, but rather to see your site’s performance as a whole.” (traducción) «no está diseñado [para] encontrar el estado de una URL específica, sino para ver el rendimiento de tu sitio en su conjunto.» Sirve para detectar problemas de todo el sitio y a nivel de plantilla. Para comprobar una página, usa PageSpeed Insights o la herramienta de inspección de url.

Dos cosas más que vale la pena saber desde el principio:

• “No data available” es común y normalmente no es un problema con tus páginas. Significa una de dos cosas: tu propiedad es nueva en Search Console, o no hay suficiente tráfico de Chrome para el dispositivo que estás consultando (móvil o escritorio) para superar el umbral de informes de Google.
• Tiene aproximadamente un mes de retraso. Como es un promedio de 28 días, una corrección que lances hoy no aparecerá completamente aquí durante semanas. Usa PageSpeed Insights para obtener retroalimentación más rápida.

¿Quieres conocer la mecánica completa — cómo funciona realmente la agrupación de URL, por qué no coincidirá con PageSpeed Insights, el flujo de trabajo de validación y qué ocurrió con FID? Cambia a la pestaña Avanzado.

TL;DR — El Core Web Vitals report muestra datos de campo de CrUX (periodo móvil de 28 días, percentil 75) para tus URL indexadas —no calcula nada nuevo—. Agrupa las URL por dispositivo (pestañas independientes Mobile/Desktop), estado (Poor / Need improvement / Good, la peor métrica prevalece) y grupo de URL (grupos de páginas con plantillas similares que comparten un mismo estado). Solo aparecen las URL indexadas y presenta una muestra, no todas las URL. Cuando un grupo de URL es demasiado pequeño para informar de forma privada, Google recurre a un grupo de origen de nivel superior —y si ni siquiera eso supera el umbral, obtienes “No data available.” No coincidirá con PageSpeed Insights (grupo frente a URL individual; GSC mantiene los parámetros de URL distintos, PSI los elimina). Es para la evaluación inicial en todo el sitio, no para consultas de URL individuales. FID se eliminó el 12 de marzo de 2024 cuando INP se convirtió en una Core Web Vital (Métrica web esencial) —GSC lo eliminó de inmediato, a diferencia del periodo de gracia de seis meses de PSI/CrUX. Corrige primero “Poor”, valida con Start Tracking y espera que los datos de campo se pongan al día en aproximadamente un mes.

Es un informe, no una redefinición de las métricas

El marco más útil para este artículo: el Core Web Vitals report es una vista de datos que ya existen, no una nueva medición. Google es explícito al afirmar que _“the data for the Core Web Vitals report comes from the CrUX report. The CrUX report gathers anonymized metrics about performance times from actual users visiting your URL (called field data). The CrUX database gathers information about URLs whether or not the URL is part of a Search Console property.” (traducción) «los datos para el Core Web Vitals report provienen del informe de CrUX. El informe de CrUX recopila métricas anonimizadas sobre tiempos de rendimiento de usuarios reales que visitan tu URL (lo que se denomina datos de campo). La base de datos de CrUX recopila información sobre URL, independientemente de si la URL forma parte de una propiedad de Search Console.»

Así que el informe tiene cero datos de laboratorio — sin puntuaciones de Lighthouse, sin pruebas sintéticas. Son 100 % datos de campo: usuarios reales de Chrome, una ventana móvil de 28 días, evaluados en el percentil 75 y divididos por dispositivo. Las definiciones de las métricas, los umbrales y el peso de la señal de posicionamiento se encuentran en el glosario de Core Web Vitals (Métricas web esenciales) y en el tema web-vitals — no los volveré a derivar aquí. Esto trata sobre la herramienta.

Solo URL indexadas, y solo una muestra

Tres reglas de alcance que se suelen pasar por alto. Primera, y la más fundamental: un grupo de URL solo aparece una vez que supera un umbral de datos para tanto LCP como CLS — si un grupo no tiene suficientes datos de informes para ambos, se omite por completo del informe, no se marca como aprobado. Segunda: solo las URL indexadas pueden aparecer en este informe; no es un inventario completo de todas las URL indexadas, sino una muestra de páginas para ayudarte a evaluar el rendimiento del sitio según los Core Web Vitals (Métricas web esenciales). La cita textual y su traducción se conservan en la sección de fuentes oficiales más abajo. Así que no lo leas como una auditoría exhaustiva. Tercera, una regla sutil que suele confundir a cualquier persona acostumbrada a otros informes de GSC: “Data is assigned to the actual URL, not the canonical URL, as it is in most other reports.” (traducción) «Los datos se asignan a la URL real, no a la URL de referencia, como ocurre en la mayoría de los demás informes». La mayoría de los informes de Search Console se agregan en la URL de referencia; este no.

Móvil y escritorio son conjuntos de datos independientes

El informe desglosa todo por dispositivo, y las dos pestañas son totalmente independientes — nunca se promedian. Un grupo de URL puede ser Good en móvil y Need improvement en escritorio simultáneamente, porque son conjuntos de datos de CrUX diferentes que reflejan dispositivos, redes y clases de CPU distintos. Comprueba siempre ambas pestañas; un resumen de “Good” en una puede ocultar una categoría de “Poor” en la otra.

Estado: prevalece la peor métrica

Cada grupo de URL cae en una de tres categorías — Poor, Need improvement o Good — y el estado del grupo es el de su métrica con peor rendimiento. Un grupo con buen LCP y buen INP, pero con un CLS deficiente, es un grupo “Poor”. Esta regla de “la peor métrica gana” es la razón por la que un único elemento de diseño inestable puede hundir una plantilla que, por lo demás, es rápida.

Los umbrales subyacentes (LCP ≤ 2,5s / INP ≤ 200ms / CLS ≤ 0,1 para “Good”, cada uno en p75) son las definiciones de las métricas, tratadas en el glosario de Core Web Vitals (Métricas web esenciales), y vale la pena señalar: según mi investigación, la documentación de Search Central publicada todavía enumera esos números originales. Si has visto una afirmación circulando de que Google redujo en silencio el umbral “Good” de LCP a 2,0 segundos, o que alguna actualización principal de finales de 2025 convirtió Core Web Vitals (Métricas web esenciales) en un factor de posicionamiento mucho más importante, no pude verificar ninguna de las dos frente a ninguna fuente propiedad de Google, y la documentación las contradice. Trátalas como rumores.

Grupos de URL — la mecánica principal

Esta es la característica definitoria del informe y el mayor cambio de modelo mental para cualquiera que venga del hábito de una sola URL de PageSpeed Insights. Google:

• “URLs in the report are grouped into pages that have a similar user experience. The LCP, INP, and CLS status applies to the entire group. Some outlier URLs might have better or worse values on some visits, but 75% of visits to all URLs in the group experienced the group status shown.” (traducción) «Las URL del informe se agrupan en páginas que tienen una experiencia de usuario similar. El estado de LCP, INP y CLS se aplica al grupo completo. Algunas URL atípicas pueden mostrar valores mejores o peores en ciertas visitas, pero el 75 % de las visitas a todas las URL del grupo experimentaron el estado que se muestra.»

John Mueller describió el mecanismo en 2021: “We do that with the Chrome User Experience Report data, the field real-world data, essentially, where we try to recognize when there are pages that are similar enough that we could group them together.” (traducción) «Hacemos eso con los datos del Chrome User Experience Report, los datos de campo del mundo real, esencialmente, donde intentamos reconocer cuándo hay páginas que son lo suficientemente similares como para agruparlas.» Y de forma crítica, los datos del grupo pueden suplir a una URL que no tiene datos propios: “If we find a new URL that is also a part of this group, we don’t have to have data for that new URL. We can rely on the data for the group overall.” (traducción) «Si encontramos una URL nueva que también forma parte de este grupo, no tenemos que tener datos para esa URL nueva. Podemos confiar en los datos del grupo en general.»

Eso también explica por qué el informe puede parecer alarmante para lo que en realidad es un único error. Mueller lo resumió así: un sitio puede tener un solo grupo que reúna miles de URL, de modo que Search Console puede informar de miles de URL afectadas por el mismo problema. La cita de Mueller queda recogida en su sección de fuentes más abajo. Un fallo de plantilla, miles de URL marcadas.

Lo cual es exactamente la razón por la que la agrupación resulta útil en lugar de molesta. Como lo expresé en la guía de Core Web Vitals (Métricas web esenciales) de Ahrefs: “This grouping of pages makes a lot of sense. This is because most of the changes to improve Core Web Vitals are done for a particular page template that impacts many pages.” (traducción) «Esta agrupación de páginas tiene mucho sentido. Esto se debe a que la mayoría de los cambios para mejorar los Core Web Vitals (Métricas web esenciales) se realizan para una plantilla de página concreta que afecta a muchas páginas.» Y en la guía de PageSpeed Insights: “The benefit of GSC is that it buckets similar URLs. For the bucketed pages, you will likely be working in one system or template.” (traducción) «La ventaja de GSC es que agrupa URL similares. Para las páginas agrupadas, probablemente estarás trabajando en un solo sistema o plantilla.» Corrige la plantilla una vez, corrígela para todo el grupo. O, como lo planteé en una entrevista con Outside Communications: “Basically, here are groups with issues that probably share the exact same theme. You fix it once, you fix that issue for all those pages.” (traducción) «Básicamente, aquí hay grupos con problemas que probablemente comparten exactamente el mismo tema. Lo corriges una vez, corriges ese problema para todas esas páginas.»

El umbral de privacidad y el fallback por grupo de origen

Agrupar no es solo una conveniencia: es un requisito de privacidad. Google indica que el grupo de URL necesita una cantidad mínima de datos para entrar en el informe; si no la alcanza, Search Console crea un grupo de origen de nivel superior con el volumen de URL y datos necesario. La formulación íntegra figura en la sección de fuentes oficiales más abajo, junto con su traducción. Así que la cascada es: grupo de URL → grupo de origen → nada. Cuando ni siquiera el origen puede superar el umbral, obtienes “No data available.” Esta es la razón mecánica por la que los sitios con poco tráfico ven agrupaciones amplias y poco detalladas o ningún dato en absoluto.

Por qué un grupo “Poor” aún puede contener páginas rápidas

Dado que el estado se aplica a todo el grupo en el percentil 75, una URL rápida individual puede verse arrastrada a un grupo lento. Estar en un grupo Poor no demuestra que esa URL sea lenta —significa que el conjunto, considerado en su totalidad, tiene un problema. No asumas que todos los miembros son culpables; el grupo es la unidad de análisis.

Lectura del informe: gráfico vs. tabla

Un detalle genuinamente confuso que la mayoría de las guías de terceros omiten: el gráfico de páginas de destino registra cada URL una sola vez según su problema más lento, mientras que la tabla suma cada problema asociado a esa URL. La formulación íntegra aparece en la sección de fuentes oficiales más abajo, junto con su traducción. Por lo tanto, una URL con un problema Poor y un problema Need-improvement aparece una vez (como Poor) en el gráfico, pero aparece en ambas filas de la tabla. Por eso los totales no coinciden: es por diseño, no es un error. Al hacer clic en un problema, tal como lo describo:

• “gives you a breakdown of page groups that are impacted” (traducción) «te ofrece un desglose de los grupos de páginas afectados» Con URL de ejemplo ordenadas por impresiones.

Validación de correcciones: el flujo de trabajo Start Tracking

El informe tiene un bucle de validación integrado que es fácil de pasar por alto. Google: “When you think a particular issue is fixed, click Start Tracking on the issue details page in the Search Console Core Web Vitals report.” (traducción) «Cuando creas que un problema concreto está corregido, haz clic en Start Tracking en la página de detalles del problema del Core Web Vitals report de Search Console.» Esto inicia una sesión de supervisión de 28 días para el problema: Google observa cómo se acumulan los datos de campo del grupo durante esa ventana en lugar de volver a comprobarlo al instante. Hay tres cosas que vale la pena saber sobre cómo se resuelve: una sola URL afectada que siga fallando durante la ventana puede impedir que todo el problema pase; los estados que verás son “Not started / Started / Looking good / Passed / N/A / Failed” (traducción) «Sin iniciar / Iniciado / Todo bien / Aprobado / N/D / Fallido» a nivel de problema, y “Pending / Passed / Failed” (traducción) «Pendiente / Aprobado / Fallido» por URL; y hacer clic en Start Tracking no activa la reindexación ni ningún otro comportamiento activo de rastreo: es puramente un indicador de supervisión sobre los datos que Google ya recopila. Esta es la forma adecuada de confirmar que una corrección se implementó en el campo, no solo mirar por encima el gráfico agregado y esperar.

Core Web Vitals report frente a PageSpeed Insights

Estas dos herramientas beben del mismo pozo de CrUX, pero lo presentan de manera diferente, y con regularidad discreparán para una URL. Dos razones documentadas:

• Grupo vs. individual. Google: “Core Web Vitals combines data and status into URL groups; PageSpeed Insights generally shows data for individual URLs.” (traducción) «Core Web Vitals combina datos y estado en grupos de URL; PageSpeed Insights generalmente muestra datos de URL individuales.» Una sola URL puede ser un valor atípico en su grupo, por lo que el estado del grupo y el valor de PSI para esa URL exacta no coincidirán.
• Parámetros de URL. “Core Web Vitals URLs include URL parameters when distinguishing the page; PageSpeed Insights strips all parameter data from the URL, and then assigns all results to the bare URL.” (traducción) «Las URL de Core Web Vitals incluyen parámetros de URL al distinguir la página; PageSpeed Insights elimina todos los datos de parámetros de la URL y, a continuación, asigna todos los resultados a la URL simple.» Solo esto explica muchas quejas de «por qué estas dos herramientas no coinciden».

También hay una diferencia en la amplitud de los datos que conviene tener clara, porque “datos de campo” y “datos de laboratorio” se usan de manera imprecisa. El informe de GSC contiene solo datos de campo de CrUX, agrupados — nada más. PageSpeed Insights combina tres cosas separadas: datos de campo de CrUX a nivel de URL, una alternativa a datos de campo de CrUX a nivel de origen cuando la propia URL no tiene suficientes, y una ejecución de laboratorio de Lighthouse en vivo. Como señalo en la guía de PSI, “PageSpeed Insights also pulls in the page level data, as well as origin data and lab test data which comes from Lighthouse.” (traducción) «PageSpeed Insights también incluye los datos a nivel de página, así como los datos de origen y los datos de pruebas de laboratorio que provienen de Lighthouse.» El informe de GSC no incluye nada de esa capa de laboratorio — son datos de campo, punto.

Mi flujo de trabajo real y el consejo práctico que la mayoría de los artículos de la competencia pasan por alto: diagnostica y valida rápido en los datos de laboratorio de PSI, confirma que es lento pero real en GSC. De la guía de PSI: “The CWV data will take longer to show the impact of any changes because it is a 28-day average, so use PSI or the PSI data in Ahrefs to check if the changes you made improved the lab test metrics.” (traducción) «Los datos de CWV tardarán más en mostrar el impacto de cualquier cambio porque son un promedio de 28 días, así que usa PSI o los datos de PSI en Ahrefs para comprobar si los cambios que hiciste mejoraron las métricas de prueba de laboratorio.» Obtienes retroalimentación instantánea de laboratorio de que un cambio ayudó; luego esperas a que los datos de campo en GSC se pongan al día durante las semanas siguientes.

”No data available” y sitios con poco tráfico

La propia explicación de Google: “If you see a ‘No data available’ screen, it means either that your property is new in Search Console, or that there is not enough data available in the CrUX report to provide meaningful information for the chosen device type (desktop or mobile).” (traducción) «Si ves una pantalla ‘No data available’, significa que tu propiedad es nueva en Search Console o que no hay suficientes datos disponibles en el informe de CrUX para proporcionar información significativa para el tipo de dispositivo elegido (escritorio o móvil).» CrUX tiene un umbral de elegibilidad: una URL o un origen necesita suficiente tráfico de Chrome antes de que aparezca ningún dato de campo.

¿Qué tan común es eso? Mucho. En mi estudio de enero de 2022 que comparó CrUX con 43,66 millones de páginas únicas de Site Audit, “We found only 5.21M (~11.9%) had at least one Core Web Vitals metric, and 93% of those (or ~4.85M total) had all three metrics.” (traducción) «Solo encontramos que 5,21 millones (~11,9 %) tenían al menos una métrica de Core Web Vitals (Métricas web esenciales), y el 93 % de esas (o ~4,85 millones en total) tenían las tres métricas.» Ese estudio observó el conjunto de datos sin procesar de CrUX (la misma fuente que utiliza el informe de GSC), no GSC en sí, y el número es de enero de 2022 — así que trátalo como una referencia de escala, no como un porcentaje actual. La conclusión se mantiene: la mayoría de las páginas de la web simplemente no reciben suficiente tráfico de Chrome para generar datos de campo, lo cual es exactamente la razón por la que el informe se apoya en la agrupación a nivel de origen y por la que tantos sitios no ven nada. Si eres uno de ellos, eso no es una garantía de que todo esté bien — en su lugar, prueba URLs individuales en PageSpeed Insights o Lighthouse.

FID desapareció — qué cambió en marzo de 2024

Acierta este punto con exactitud, porque los tutoriales desactualizados todavía lo muestran de forma incorrecta. Interaction to Next Paint (INP) reemplazó a First Input Delay (FID) como una de las Core Web Vitals (Métricas web esenciales) el 12 de marzo de 2024. El detalle específico de Search Console que casi nadie aborda: según el anuncio en web.dev del equipo de Chrome, “FID will be removed from Google Search Console as soon as INP becomes a Core Web Vital on March 12. All other tools—such as PageSpeed Insights and CrUX—will offer a six-month deprecation period to give developers a chance to update their code.” (traducción) «FID se eliminará de Google Search Console en cuanto INP se convierta en una Core Web Vital el 12 de marzo. Todas las demás herramientas —como PageSpeed Insights y CrUX— ofrecerán un periodo de obsolescencia de seis meses para dar a los desarrolladores la oportunidad de actualizar su código.» Así que GSC eliminó FID de inmediato, sin periodo de gracia, mientras que PSI y CrUX siguieron mostrándolo durante seis meses más. Si ves FID en una captura de pantalla de Search Console, es de antes de marzo de 2024.

¿Qué pasó con el informe de Experiencia de página?

Un punto de confusión real, que todavía se busca. Google eliminó el Page Experience report independiente —el antiguo panel de resumen que combinaba Core Web Vitals con HTTPS y otras señales de UX— de Search Console el 19 de abril de 2023. Lo que sobrevivió: el Core Web Vitals report y el HTTPS report continúan existiendo como sus propios informes independientes. Solo desapareció el resumen combinado. Así que si estás buscando un panel de “Page Experience” y no lo encuentras, por eso: los dos informes subyacentes todavía están allí. (Los informes relacionados, como el Performance report y el Page Indexing report, cubren el resto de tu presencia en Search Console.)

Priorizar y corregir lo que encuentra el informe

Google divide su propia orientación en vías no técnicas y para desarrolladores — una buena señal de que este informe lo leen audiencias muy diferentes. La regla de priorización para todos: corrige primero “Poor” y luego “Need improvement”. Para desarrolladores, las URL dentro de un grupo se ordenan por impresiones en orden descendente, así que las que están en la parte superior son las que más hacen cambiar el estado del grupo.

Las correcciones comunes a nivel de página que Google señala son directas, pero reales:

• “Reduce your page size: best practice is less than 500KB for a page and all its resources.” (traducción) «Reduce el tamaño de tu página: la buena práctica es menos de 500KB para una página y todos sus recursos.» Más allá de eso, el cómo mejorar realmente LCP, INP y CLS pertenece a los temas individuales de cada métrica; no lo duplicaré aquí. El trabajo del informe es decirte qué plantillas ir a corregir, no corregirlas por ti.

¿Por qué cambió mi estado cuando no toqué nada?

Es extremadamente común y normalmente no es un error. La propia guía de solución de problemas de Google:

• “If you didn’t make any changes in your site, but you see a big change in status for a lot of pages, it’s possible that you had a borderline status for many pages, and some site-wide event pushed your pages over the edge.” (traducción) «Si no hiciste ningún cambio en tu sitio, pero ves un gran cambio de estado en muchas páginas, es posible que tuvieras un estado límite en muchas páginas y que algún evento en todo el sitio empujara tus páginas más allá del límite.» Los cambios en la composición del tráfico, un cambio de latencia de una CDN o de un alojamiento de imágenes, una actualización de navegador ampliamente adoptada — cualquiera de estos puede empujar a un lote de URL ya en el límite a cruzar un umbral al mismo tiempo, porque el informe es un agregado p75 de 28 días.

Y a veces la cantidad de URL aptas simplemente fluctúa. Durante un episodio de julio de 2025 en el que la cantidad de URL que mostraban datos aptos disminuyó (especialmente en móvil), John Mueller caracterizó este tipo de movimiento como una variación normal del tamaño de la muestra, no como un problema — que estos informes se basan en muestras de lo que Google sabe sobre un sitio, que los tamaños de las muestras cambian y que eso no es indicativo de un problema. Barry Pollard, de Google, que trabaja en el proyecto Core Web Vitals (Métricas web esenciales), reconoció la caída y dijo que se estaba implementando una corrección. La enseñanza: la cantidad de URL aptas y la calidad subyacente de las métricas son dos cosas diferentes — una muestra cambiante no significa que tus páginas se hayan vuelto más lentas.

¿El informe afecta al posicionamiento?

El informe refleja los mismos datos de campo que los sistemas de clasificación de Google pueden tener en cuenta, pero los representantes han presentado de forma constante Core Web Vitals (Métricas web esenciales) como una señal menor, de nivel de desempate, junto a la relevancia del contenido — la discusión más completa sobre el peso en la clasificación está en el glosario de Core Web Vitals (Métricas web esenciales), así que aquí lo limitaré a una línea. Mi opinión sincera: no creo que alcanzar estos umbrales cambie mucho las cosas hoy, aunque Google podría apoyarse más en la señal con el tiempo, como finalmente hizo con la compatibilidad con móviles y HTTPS. También hay una razón no relacionada con la clasificación para prestar atención que se pasa por alto: las páginas más rápidas capturan más datos registrados (CrUX y tu propia analítica), porque menos usuarios rebotan antes de que la página termine de cargar. Mejorar estas métricas ayuda sobre todo porque es un indicador indirecto de una experiencia genuinamente mejor.

Una nota rápida sobre Bing

No hay un equivalente directo de Bing — un Core Web Vitals report dedicado, al estilo de CrUX, con agrupación de URL — dentro de Bing Webmaster Tools. Bing centra sus informes en un Performance Report (clics/impresiones) y una auditoría técnica Site Scan, en lugar de un desglose de datos de campo de Core Web Vitals (Métricas web esenciales). Bing hace referencia a métricas al estilo de Core Web Vitals (Métricas web esenciales) en su documentación, pero no ha lanzado un informe agrupado de datos de campo comparable al de Google. Las herramientas de Bing cambian con bastante frecuencia, así que verifícalo en la documentación actual de Bing Webmaster Tools si esto te importa.

Dónde encaja esto

Este informe es uno de los varios que hay en Google Search Console. El Performance report cubre cómo te fue realmente en la búsqueda (clics, impresiones, posición); el Page Indexing report cubre el lado de cobertura/indexación. Las métricas que muestra este informe —Core Web Vitals (Métricas web esenciales), CrUX y PageSpeed Insights como complemento de datos de laboratorio— tienen sus propios análisis detallados en el clúster de rendimiento web.

Resumen de IA

Una síntesis de la versión Advanced:

• Es un informe, no las métricas. El Core Web Vitals report (GSC → Experience) muestra datos de campo de CrUX (período móvil de 28 días, percentil 75) para tus URL indexadas. No calcula nada nuevo y no contiene ningún dato de laboratorio.
• Tres agrupaciones: dispositivo (pestañas Mobile/Desktop independientes, nunca promediadas), estado (Poor / Need improvement / Good, la peor métrica gana) y grupo de URL (conjuntos de páginas con plantillas similares que comparten un estado).
• Los grupos de URL son la unidad atómica — no las URL individuales. Una corrección de plantilla puede resolver miles de URL marcadas (Mueller). Un grupo “Poor” aún puede contener páginas rápidas.
• Cascada de privacidad: grupo de URL → grupo de origen → “No data available.” Los sitios nuevos o con poco tráfico a menudo no ven nada; solo ~12 % de las páginas tenían algún dato de CrUX en el estudio de Patrick de 2022.
• No coincidirá con PageSpeed Insights: datos de grupo frente a datos de URL única, y GSC mantiene los URL Parameters diferenciados, mientras que PSI los elimina para dejar la URL básica.
• Filtro de elegibilidad: un grupo de URL necesita datos de umbral para tanto LCP como CLS antes de aparecer; si hay datos insuficientes en cualquiera de los dos, se omite, no se marca como aprobado. Solo URL indexadas, y solo una muestra; los datos se asignan a la URL real, no a la canónica.
• Gráfico y tabla cuentan de forma diferente (gráfico = cada URL una vez por el peor problema; tabla = cada problema), por lo que los totales no concuerdan.
• FID se eliminó el 12 de marzo de 2024 cuando INP se convirtió en una Core Web Vital (Métrica web esencial) — GSC lo eliminó de inmediato, frente al período de gracia de seis meses de PSI/CrUX.
• El Page Experience report se eliminó en abril de 2023; los informes Core Web Vitals report (Métricas web esenciales) y HTTPS report permanecen.
• Flujo de trabajo: corrige primero “Poor”, valida con Start Tracking — una sesión de monitorización de 28 días en la que cualquier URL que aún falle bloquea una aprobación y no se reindexa nada — diagnostica rápidamente en PSI y espera ~un mes a que los datos de campo se pongan al día. Los cambios de estado sin cambios en el sitio suelen deberse a URL en el límite que superan un umbral, o a ruido del tamaño de la muestra.

Documentación oficial

Documentación de fuentes primarias de Google.

Google

• Core Web Vitals report — la página de ayuda canónica: fuente de datos (CrUX), organización por dispositivo, estado y grupo de URL, “No data available”, la alternativa de grupo de origen, el recuento en gráfico frente a tabla, las diferencias con PageSpeed Insights y el flujo de trabajo de validación de Start Tracking.
• Interaction to Next Paint se convierte en una Core Web Vital el 12 de marzo — el anuncio del equipo de Chrome, incluida la línea específica de Search Console que indica que FID se eliminó de GSC inmediatamente (frente al periodo de gracia de seis meses en PSI/CrUX).
• Presentación de INP en Core Web Vitals (Métricas web esenciales) — el anuncio de Google Search Central de mayo de 2023 sobre la transición de FID → INP.
• Entender Core Web Vitals (Métricas web esenciales) y los resultados de búsqueda de Google — la descripción general de Search Central con los umbrales actuales (todavía 2,5 s / 200ms / 0,1 en el momento de la investigación).

Citas de la fuente

Declaraciones oficiales de Google. Cada enlace es un enlace profundo que salta al fragmento citado en la página de origen.

Google — qué es el informe y de dónde proceden los datos

• “The Core Web Vitals report shows how your pages perform, based on real world usage data (sometimes called field data).” (traducción) «El Core Web Vitals report muestra el rendimiento de tus páginas, basado en datos de uso del mundo real (a veces llamados datos de campo).» — Ayuda de Search Console. Ir a la cita
• “The data for the Core Web Vitals report comes from the CrUX report… The CrUX database gathers information about URLs whether or not the URL is part of a Search Console property.” (traducción) «Los datos del Core Web Vitals report provienen del informe de CrUX… La base de datos de CrUX recopila información sobre las URL, independientemente de si la URL forma parte de una propiedad de Search Console.» Ir a la cita
• “Only indexed URLs can appear in this report. This report isn’t a comprehensive list of all indexed URLs. It shows a sample of pages to help you assess your site’s performance based on Core Web Vitals.” (traducción) «Solo las URL indexadas pueden aparecer en este informe. Este informe no es una lista exhaustiva de todas las URL indexadas. Presenta una muestra de páginas para ayudarte a evaluar el rendimiento de tu sitio basado en Core Web Vitals (Métricas web esenciales).» Ir a la cita
• “Data is assigned to the actual URL, not the canonical URL, as it is in most other reports.” (traducción) «Los datos se asignan a la URL real, no a la URL canónica, como ocurre en la mayoría de los demás informes.» Ir a la cita

Google — Grupos de URL y el respaldo de privacidad

• “URLs in the report are grouped into pages that have a similar user experience. The LCP, INP, and CLS status applies to the entire group. Some outlier URLs might have better or worse values on some visits, but 75% of visits to all URLs in the group experienced the group status shown.” (traducción) «Las URL del informe se agrupan en páginas que tienen una experiencia de usuario similar. El estado de LCP, INP y CLS se aplica a todo el grupo. Algunas URL atípicas podrían tener valores mejores o peores en algunas visitas, pero el 75 % de las visitas a todas las URL del grupo experimentaron el estado del grupo mostrado.» Ir a la cita
• “In order to respect user privacy, a URL group must have a minimum amount of data to be shown in the report. If a URL group doesn’t have enough information to display in the report, Search Console creates a higher-level origin group that should contain enough URLs and data to show in the report.” (traducción) «Para respetar la privacidad del usuario, un grupo de URL debe tener una cantidad mínima de datos para mostrarse en el informe. Si un grupo de URL no tiene suficiente información para mostrarse en el informe, Search Console crea un grupo de origen de nivel superior que debería contener suficientes URL y datos para mostrarse en el informe.» Ir a la cita

Google — leer el informe y validar las correcciones

• “The chart counts each URL only once, for the slowest issue affecting that URL. The table, in contrast, counts every issue associated with a URL.” (traducción) «El gráfico cuenta cada URL solo una vez, por el problema más lento que afecta a esa URL. La tabla, en cambio, cuenta cada problema asociado a una URL.» Ir a la cita
• “The report is not designed find the status of a specific URL, but rather to see your site’s performance as a whole, and troubleshoot issues affecting multiple pages on your site.” (traducción) «El informe no está diseñado para encontrar el estado de una URL específica, sino para ver el rendimiento de tu sitio en su conjunto y solucionar problemas que afectan a varias páginas de tu sitio.» Ir a la cita
• “When you think a particular issue is fixed, click Start Tracking on the issue details page in the Search Console Core Web Vitals report.” (traducción) «Cuando creas que un problema en particular está solucionado, haz clic en Start Tracking en la página de detalles del problema del Search Console Core Web Vitals report.» Ir a la cita

Google — vs. PageSpeed Insights y “No data available”

• “Core Web Vitals combines data and status into URL groups; PageSpeed Insights generally shows data for individual URLs.” (traducción) «Core Web Vitals (Métricas web esenciales) combina datos y estado en grupos de URL; PageSpeed Insights generalmente muestra datos de URL individuales.» Ir a la cita
• “Core Web Vitals URLs include URL parameters when distinguishing the page; PageSpeed Insights strips all parameter data from the URL, and then assigns all results to the bare URL.” (traducción) «Las URL de Core Web Vitals (Métricas web esenciales) incluyen parámetros de URL al distinguir la página; PageSpeed Insights elimina todos los datos de parámetros de la URL y luego asigna todos los resultados a la URL sin parámetros.» Ir a la cita
• “If you see a ‘No data available’ screen, it means either that your property is new in Search Console, or that there is not enough data available in the CrUX report to provide meaningful information for the chosen device type (desktop or mobile).” (traducción) «Si ves una pantalla ‘No data available’, significa que tu propiedad es nueva en Search Console o que no hay suficientes datos disponibles en el informe CrUX para proporcionar información significativa para el tipo de dispositivo elegido (escritorio o móvil).» Ir a la cita

Google — FID → INP en Search Console (equipo de Chrome, web.dev)

• “FID will be removed from Google Search Console as soon as INP becomes a Core Web Vital on March 12. All other tools—such as PageSpeed Insights and CrUX—will offer a six-month deprecation period to give developers a chance to update their code.” (traducción) «FID se eliminará de Google Search Console en cuanto INP se convierta en una Core Web Vital (Métrica web esencial) el 12 de marzo. Todas las demás herramientas —como PageSpeed Insights y CrUX— ofrecerán un período de desuso de seis meses para dar a los desarrolladores la oportunidad de actualizar su código.» Ir a la cita

John Mueller, Google — por qué el informe agrupa las URL (2021)

• “We do that with the Chrome User Experience Report data, the field real-world data, essentially, where we try to recognize when there are pages that are similar enough that we could group them together.” (traducción) «Hacemos eso con los datos del Chrome User Experience Report, los datos de campo del mundo real, esencialmente, donde intentamos reconocer cuándo hay páginas que son lo suficientemente similares como para agruparlas.»
• “We might have one group, essentially, for a site. But that could contain thousands of URLs. So, in the report in Search Console, I think we would report that as thousands of URLs have this problem.” (traducción) «Podríamos tener un grupo, esencialmente, para un sitio. Pero eso podría contener miles de URL. Así que, en el informe de Search Console, creo que lo informaríamos como que miles de URL tienen este problema.» Leer la cobertura

¿Qué herramienta (o ruta) debería tomar?

“Quiero comprobar los Core Web Vitals (Métricas web esenciales) de una página específica.” → Este informe no. Usa PageSpeed Insights (datos de campo + laboratorio para esa URL) o la herramienta de inspección de url. El Core Web Vitals report: “not designed [to] find the status of a specific URL.” (traducción) «no está diseñado [para] encontrar el estado de una URL específica.»

“El informe dice ‘No data available.’” → ¿La propiedad es completamente nueva? Dale a CrUX unos días para que se complete. → De lo contrario, casi con certeza es tráfico insuficiente — ni siquiera el grupo de origen puede superar el umbral de privacidad. Prueba las URL individuales en PageSpeed Insights / Lighthouse en su lugar. “No data” no es un estado de salud impecable.

“Un grupo es ‘Poor’ — ¿qué corrijo primero?” → Corrige todo lo etiquetado como Poor antes que cualquier cosa etiquetada como Need improvement. → Dentro de un grupo, las URL se ordenan por impresiones de forma descendente — las que están en la parte superior mueven más el estado del grupo. → El estado se establece por la peor métrica del grupo — encuentra cuál de LCP / INP / CLS está fallando y corrige esa.

“Mi estado de GSC y PageSpeed Insights no coinciden para la misma URL.” → Esperado. GSC informa sobre el grupo; PSI informa sobre la URL individual (que puede ser un caso atípico). Y GSC mantiene los URL parameters diferenciados mientras que PSI los elimina para dejar la URL base. Ninguna de las dos está equivocada: están midiendo cosas diferentes.

“Implementé una corrección; ¿cómo confirmo que funcionó?” → Comprueba de inmediato el resultado de laboratorio en PageSpeed Insights para obtener retroalimentación rápida. → Haz clic en Start Tracking en el problema en GSC para validarlo en el campo. → Luego espera: la ventana móvil de 28 días significa que el informe tarda aproximadamente un mes en reflejar completamente el cambio.

“My status changed but I didn’t touch the site.” (traducción) «Mi estado cambió, pero no toqué el sitio.» → Por lo general, se trata de URL limítrofes que sobrepasan un umbral debido a un cambio externo (mezcla de tráfico, latencia de CDN/imágenes, una actualización del navegador) o de una simple fluctuación del tamaño de la muestra. Comprueba si lo que se mueve es el recuento de URL aptas o la calidad subyacente de la métrica; son cosas diferentes.

Lectura del informe de Core Web Vitals (Métricas web esenciales) — una lista de verificación de coherencia

Un repaso rápido antes de que saques conclusiones o le entregues a un desarrollador una lista de tareas pendientes:

• Comprobaste las pestañas Móvil y Desktop — son independientes y pueden discrepar.
• Estás tratando grupos de URL, no URL individuales, como la unidad — es probable que una sola corrección resuelva todo el grupo.
• Entiendes que un grupo “Deficiente” puede contener páginas rápidas (el estado del grupo es el p75 del clúster).
• Sabes que el gráfico y la tabla no coincidirán (el gráfico cuenta cada URL una vez por el peor problema; la tabla cuenta todos los problemas).
• Estás corrigiendo “Deficiente” antes que “Necesita mejorar”, y priorizando por las URL con más impresiones.
• Identificaste qué métrica (LCP / INP / CLS) establece el estado de cada grupo antes de tocar el código.
• Para comprobaciones de una sola URL, cambiaste a PageSpeed Insights / Inspección de URL, no a este informe.
• No esperas que GSC coincida con PageSpeed Insights (grupo frente a URL; parámetros conservados frente a eliminados).
• Si ves “No hay datos disponibles”, comprobaste el tráfico/la elegibilidad en lugar de suponer que tus páginas están bien.
• Después de una corrección, hiciste clic en Iniciar seguimiento y estás dando a los datos de campo ~un mes para ponerse al día.
• No persigues un cambio de estado que en realidad es ruido de umbral límite o de tamaño de muestra.

Los modelos mentales

1. Es un informe, no un medidor. Cada número son datos de campo de CrUX — usuarios reales de Chrome, ventana móvil de 28 días, percentil 75. El informe muestra esos datos; no calcula nada nuevo y no tiene capa de laboratorio. Por eso siempre describe el pasado reciente, nunca “ahora mismo”.

2. El grupo de URL es el átomo. Deja de pensar en URL individuales. Google agrupa páginas con plantillas similares, asigna un estado a todo el clúster y puede marcar miles de URL por un fallo en una plantilla. Corrige la plantilla una vez y corrige el grupo. Una URL rápida puede seguir dentro de un grupo “Poor”.

3. La peor métrica prevalece. El estado de un grupo lo establece la más débil de LCP / INP / CLS. Antes de optimizar nada, averigua qué métrica está fallando — no corriges “el grupo”, corriges la métrica que lo arrastra.

4. La cascada de privacidad explica los vacíos. Grupo de URL → grupo de origen → “No data available.” Que no haya tráfico suficiente para informar de forma privada significa agrupaciones amplias o nada en absoluto. “No data” significa datos de CrUX insuficientes, no un sitio limpio.

5. Dos herramientas, dos trabajos — diagnosticar rápido, confirmar lento. PageSpeed Insights = URL única, campo + laboratorio, retroalimentación instantánea. El informe de GSC = agrupado, solo campo, con aproximadamente un mes de retraso. Diagnostica y valida una corrección en los datos de laboratorio de PSI; espera a que los datos de campo de GSC lo confirmen en el mundo real.

Core Web Vitals report — guía rápida

Cómo está organizado

Informe de GSC vs. PageSpeed Insights

Datos clave

• Fuente de datos: datos de campo de CrUX, periodo móvil de 28 días, p75, por dispositivo.
• Solo URL indexadas; una muestra, no todas; asignadas a la URL real, no a la canónica.
• “No data available” = propiedad nueva o tráfico de CrUX insuficiente (grupo de URL → grupo de origen → nada).
• El gráfico cuenta cada URL una vez (el peor problema); la tabla cuenta cada problema; los totales no coincidirán.
• FID se eliminó de GSC el 12 de marzo de 2024 (de inmediato; PSI/CrUX lo mantuvieron 6 meses más).
• El informe Page Experience se eliminó el 19 de abril de 2023; los informes Core Web Vitals report y HTTPS report continúan.
• Corrige primero Deficiente, valida con Start Tracking y espera ~28 días para que el informe lo refleje.
• Regla general sobre el peso de página (Google): menos de 500KB para una página y todos sus recursos.

Errores del Core Web Vitals report

Tratar cada URL de un grupo Poor como si fuera individualmente lenta. El estado corresponde al grupo en el percentil 75, por lo que un miembro individual puede ser más rápido o más lento. Diagnostica las URL representativas y luego corrige la plantilla o el componente compartido.

Comprobar solo Mobile o solo Desktop. Los conjuntos de datos son independientes y pueden diferir. Clasifica ambas pestañas por separado en lugar de promediarlas en una sola historia.

Considerar “No data available” como una aprobación. Por lo general, significa que la URL o el origen carece de suficiente tráfico elegible de CrUX para informar. Usa pruebas de laboratorio y otras fuentes de datos de campo; no afirmes que la página es Good.

Esperar que GSC coincida con PageSpeed Insights para una sola URL. GSC informa grupos y conserva los parámetros de URL; PSI generalmente informa una única URL simple. Comprende la unidad y el manejo de URL antes de tratar una diferencia como un error.

Optimizar la métrica que ya es Good. La métrica más débil del grupo establece su estado. Identifica si LCP, INP o CLS es responsable antes de pasar el trabajo a un desarrollador.

Llamar a Start Tracking inmediatamente después de una corrección solo de laboratorio. Primero verifica que el cambio esté implementado en todas las plantillas afectadas. Luego inicia la validación de campo una vez y permite que la ventana móvil de CrUX recopile evidencia de usuarios reales.

Usar los totales del gráfico y de la tabla como comprobación de conciliación. El gráfico cuenta cada URL una vez por su peor problema; la tabla cuenta cada problema asociado a una URL. Se esperan totales diferentes.

Valida una corrección de Core Web Vitals (Métricas web esenciales)

Usa tres capas de evidencia. Ninguna capa por sí sola es suficiente.

1. Evidencia de despliegue

• Reproduce la interacción lenta, el elemento inestable o el elemento más grande que carga tarde en una URL afectada representativa.
• Confirma que el código modificado está presente en producción, no solo en una vista previa, y en cada plantilla representada por el grupo de URL.
• Ejecuta Lighthouse u otra traza de laboratorio antes y después en las mismas condiciones de prueba. La métrica objetivo debería mejorar sin que otra métrica de Core Web Vitals (Métricas web esenciales) empeore.

2. Evidencia del flujo de trabajo de informes

• Abre la fila exacta del problema y registra su dispositivo, estado, métrica, grupo de URL y las URL de ejemplo.
• Comprueba puntualmente ejemplos en PageSpeed Insights, recordando que una URL individual puede diferir de su grupo de GSC.
• Haz clic en Start Tracking solo después de que el despliegue en producción esté completo. Observa el estado de validación del problema en lugar de reiniciarlo repetidamente.

3. Evidencia de resultados de campo

• Espera a que la ventana móvil de 28 días de CrUX absorba las visitas posteriores al lanzamiento.
• Confirma que el grupo afectado mejora en el mismo dispositivo y la misma métrica que originalmente falló.
• Comprueba tanto Mobile como Desktop, y distingue una mejora real de la métrica de un cambio en qué URL tenían datos suficientes para ser elegibles.
• Si GSC no cambia, compara las URL de ejemplo del grupo con los datos de PSI a nivel de URL y a nivel de origen antes de decidir que el despliegue falló.

La condición de aprobación no es “Lighthouse se puso en verde una vez”. Es: la corrección en producción está presente en todo el grupo, la evidencia controlada de laboratorio mejora y la incidencia de campo de GSC relevante se resuelve después de que llegan suficientes datos de usuarios reales.

Mide el progreso sin inventar una puntuación de rendimiento

Realiza un seguimiento por separado según dispositivo, métrica, grupo de URL y fecha de lanzamiento:

Utiliza los umbrales Good publicados por Google —LCP igual o inferior a 2,5 segundos, INP igual o inferior a 200 milisegundos y CLS igual o inferior a 0,1, medidos en el percentil 75— como el nivel de calidad. No inventes un plazo universal ni un objetivo porcentual de mejora. La tendencia útil es menos URL aptas en los grupos con fallos, validaciones de problemas resueltas y ganancias estables en ventanas sucesivas de 28 días sin intercambiar una métrica por otra.

Recursos que valen tu tiempo

Mis artículos relacionados

• Qué son los Core Web Vitals (Métricas web esenciales) (CWV) y cómo mejorarlos — mi guía sobre las propias métricas y cómo el informe de GSC agrupa las páginas afectadas por plantilla.
• Google PageSpeed Insights para SEO y desarrolladores — el complemento de los datos de laboratorio y mi flujo de trabajo “diagnose in PSI, monitor in GSC” (traducción) «diagnostica en PSI, supervisa en GSC» (el consejo sobre el retraso de 28 días se encuentra aquí).
• Estudio de datos de Core Web Vitals (Métricas web esenciales) con CrUX y 5,2 M de páginas — mi análisis a gran escala de lo pocas que son las páginas que tienen algún dato de CrUX (la cifra de ~12 %), lo que explica la mayoría de las pantallas “No data available”.

Mis charlas / entrevistas

• Core Web Vitals (Métricas web esenciales) de Google para pymes: una conversación con Patrick Stox (Outside Communications) — una explicación breve y no técnica de para qué sirve el informe: “you fix it once, you fix that issue for all those pages.” (traducción) «lo arreglas una vez y arreglas ese problema para todas esas páginas.»

Oficial

• Core Web Vitals report — Ayuda de Search Console — la referencia canónica para todo lo de este artículo.
• INP se convierte en una Core Web Vital el 12 de marzo — web.dev — el detalle de que FID se eliminó de GSC inmediatamente.

De la industria

• Google analiza la agrupación de URL para las puntuaciones de Core Web Vitals (Métricas web esenciales) (Search Engine Journal) — la transcripción de las Office Hours de John Mueller sobre por qué un grupo puede marcar miles de URL.
• Google Search Console: Cómo usar el Core Web Vitals report (DebugBear) — un recorrido práctico desde la configuración hasta la corrección, y una buena explicación de por qué las páginas rápidas pueden caer en grupos lentos.
• Core Web Vitals (Métricas web esenciales) en Google Search Console: Corregir y optimizar (Quattr) — un flujo de trabajo de optimización estructurado (ordenar → priorizar → probar → resolver → validar).
• El informe de Page Experience de Google Search Console desaparece (Search Engine Land) — cobertura de la eliminación del resumen de Page Experience en abril de 2023.
• Actualización del Core Web Vitals report en Google Search Console (Search Engine Land) — la adición de la capa de respaldo por grupo de origen en marzo de 2023.
• Actualización de Google Search Console sobre Core Web Vitals (Métricas web esenciales) (Search Engine Roundtable) — la caída de URL aptas en julio de 2025, con Mueller y Pollard sobre la fluctuación del tamaño de la muestra.

Estadísticas que vale la pena citar

• Solo ~12 % de las 43,66 M de páginas únicas de Site Audit en la muestra de enero de 2022 tenía alguna métrica de CrUX. En mi estudio, “We found only 5.21M (~11.9%) had at least one Core Web Vitals metric, and 93% of those (or ~4.85M total) had all three metrics.” (traducción) «Encontramos que solo 5,21 M (~11,9 %) tenían al menos una métrica de Core Web Vitals (Métricas web esenciales), y el 93 % de aquellos (o ~4,85 M en total) tenían las tres métricas.» Ese es el conjunto de datos subyacente de CrUX en el que se basa el informe: el factor que determina la escala por la que tantos sitios ven “No data available.”
• FID eliminado de GSC el 12 de marzo de 2024 — de inmediato, sin período de gracia, mientras que PSI y CrUX ofrecieron un período de descontinuación de seis meses. Fuente
• Regla general sobre el peso de la página: por debajo de 500KB para una página y todos sus recursos, según la propia orientación de Google en la sección “Fix issues” del informe. Fuente
• Informe de Page Experience eliminado el 19 de abril de 2023 — los informes de Core Web Vitals (Métricas web esenciales) y HTTPS son lo que queda de ese antiguo informe consolidado. Cobertura

Pon a prueba tus conocimientos: el informe de Core Web Vitals (Métricas web esenciales)

Cinco preguntas rápidas sobre cómo funciona el informe de Core Web Vitals (Métricas web esenciales) de Search Console. Elige una respuesta para cada una y luego compruébalo.

Registro de cambios