Core Web Vitals: qué miden, cuánto pesan en el SEO y cuándo merece la pena arreglarlas
Te llega un correo de Search Console con un aviso en rojo: "Problema con LCP: más de 2,5 s (móvil)". Las Core Web Vitals son tres métricas con las que Google mide la experiencia de los usuarios reales de tu web: cuánto tarda en aparecer el contenido principal (LCP), cuánto tarda la página en reaccionar cuando alguien toca algo (INP) y cuánto se mueve el diseño mientras carga (CLS).
El aviso asusta. Y casi todo lo que vas a leer después lo empeora: guías que exageran su peso en el posicionamiento, que mezclan la nota de PageSpeed con Search Console o que siguen hablando de FID, una métrica que Google retiró en 2024.
En las auditorías me encuentro las dos caras. Negocios que llevan meses persiguiendo un 100 en PageSpeed sin ganar una posición. Y webs con problemas reales que pierden clientes en móvil sin saberlo.
Aquí te explico qué mide cada métrica, cuánto influyen de verdad, cómo leer cada aviso y qué arreglar primero. Con un caso real y con mi criterio sobre cuándo merece la pena tocarlas.
Ve directo a lo que buscas:
- Qué son las Core Web Vitals y qué umbrales usa Google
- Cuánto influyen de verdad en el posicionamiento
- Por qué PageSpeed te da un 95 y Search Console te marca en rojo
- Qué significa cada aviso de Search Console y cómo se arregla
- Qué arreglar primero: por plantilla, no URL a URL
- Caso real: una clínica dental en Lucena
- Lo que las Core Web Vitals no miden: si una IA puede leer tu web
- Lo que no haría
- Checklist rápida
Puntos clave
- Las Core Web Vitals son LCP (bueno: hasta 2,5 s), INP (hasta 200 ms) y CLS (hasta 0,1), medidas en el percentil 75 de las visitas reales con Chrome. FID ya no forma parte de ellas.
- Google las usa para posicionar, pero dice expresamente que unas buenas cifras no garantizan posiciones.
- Donde más se notan es en la conversión, sobre todo en móvil.
- Search Console usa datos de usuarios reales. La nota de PageSpeed sale de una prueba de laboratorio. Que no coincidan es normal.
- Se arreglan por plantilla, no URL a URL. En WordPress, la causa suele estar en el constructor visual y los scripts de terceros.
Qué son las Core Web Vitals y qué umbrales usa Google
Son tres métricas: LCP mide la carga, INP la capacidad de respuesta y CLS la estabilidad visual. Según la documentación oficial de Google, una página ofrece buena experiencia cuando las tres están en verde para al menos el 75 % de sus visitas reales.
| Métrica | Qué mide | Buena | Necesita una mejora | Deficiente |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Cuánto tarda en pintarse el elemento más grande visible, normalmente la imagen principal o el titular | Hasta 2,5 s | Hasta 4 s | Más de 4 s |
| INP (Interaction to Next Paint) | Cuánto tarda la página en reaccionar cuando el usuario toca, hace clic o escribe | Hasta 200 ms | Hasta 500 ms | Más de 500 ms |
| CLS (Cumulative Layout Shift) | Cuánto se desplazan los elementos de forma inesperada | Hasta 0,1 | Hasta 0,25 | Más de 0,25 |
Dos detalles que casi nadie explica bien. El primero: el umbral se aplica al percentil 75. Si tu LCP es de 2 segundos para la mitad de tus visitas pero de 5 para una de cada tres, suspendes. Tu móvil con fibra no sirve como prueba.
El segundo: INP sustituyó a FID el 12 de marzo de 2024, y no fue un cambio de nombre. FID solo medía la espera antes de procesar la primera interacción. INP mide la respuesta completa a todas las interacciones de la visita. Si una guía te habla de FID, está desactualizada.
Cuánto influyen de verdad en el posicionamiento
Poco, y casi siempre como desempate. Google confirma que sus sistemas de ranking usan las Core Web Vitals, pero en su documentación sobre la experiencia de página deja claras dos cosas: que muestra el contenido más relevante aunque la experiencia de página sea deficiente, y que tener buenos resultados en el informe de Core Web Vitals no garantiza las primeras posiciones.
No voy a venderte humo. Arreglar el LCP no lleva una página de la tercera página de resultados a la primera. Si tu contenido no responde mejor que el de la competencia, la velocidad no lo compensa.
¿Por qué me las tomo en serio entonces? Por la conversión. Una web lenta, o que salta mientras carga, pierde a la gente que ya ha llegado, que es la más cara de conseguir. Vodafone hizo un test A/B con la mitad del tráfico en cada versión: mejoró el LCP un 31 % sin cambiar nada visible y obtuvo un 8 % más de ventas y un 15 % más de leads por visitante, según el caso publicado en web.dev. Tu negocio no tiene ese tráfico para medirlo con tanta precisión, pero el efecto va en la misma dirección.
Por qué PageSpeed te da un 95 y Search Console te marca en rojo
Porque miden cosas distintas. Search Console usa datos de campo: visitas reales de usuarios de Chrome en los últimos 28 días. La nota de 0 a 100 de PageSpeed Insights sale de Lighthouse, una prueba de laboratorio que carga tu página una vez, con un dispositivo y una conexión simulados. Google lo explica en su guía sobre datos de laboratorio y de campo: el laboratorio no ve con qué móvil entran tus usuarios, con qué cobertura ni en qué momento tocan la pantalla.
| Informe de Core Web Vitals (Search Console) | Nota de PageSpeed Insights (Lighthouse) | |
|---|---|---|
| Tipo de dato | Campo: usuarios reales de Chrome | Laboratorio: una carga simulada |
| Periodo | Últimos 28 días | El momento de la prueba |
| INP | Lo mide | No lo mide: usa el Total Blocking Time como aproximación |
| CLS | Durante toda la visita | Solo durante la carga |
| Lo usa Google para posicionar | Sí, los datos de Chrome que hay detrás | No |
| Para qué te sirve | Saber si tienes un problema | Buscar la causa |
PageSpeed Insights te enseña las dos cosas. Arriba, los datos de campo, que son los que cuentan. Abajo, la nota de laboratorio: una herramienta de diagnóstico, no un examen que haya que aprobar.
Qué significa cada aviso de Search Console y cómo se arregla
Cada aviso te dice qué métrica falla, en qué dispositivo y en qué grupo de URLs. El informe de Core Web Vitals agrupa páginas con una experiencia parecida y a cada grupo le asigna el estado de su peor métrica: basta con que una esté en "Deficiente" para que todo el grupo lo esté.
[PENDIENTE: captura real anonimizada del informe de Core Web Vitals de Search Console]
En las últimas 20 auditorías que he hecho a webs en WordPress, 14 tenían al menos un grupo de URLs en "Deficiente" en móvil. En 11 de esas 14, el origen estaba en el constructor visual, en los scripts de terceros o en los dos.
"Problema con LCP: más de 2,5 s (móvil)"
El contenido principal tarda demasiado en verse. En WordPress, las causas que más me encuentro son cuatro: la imagen principal se carga en diferido (lazy loading), va dentro de un slider o como fondo CSS, el servidor tarda en responder porque no hay caché de página, y el CSS del constructor bloquea el pintado.
La solución, por orden: la imagen principal nunca con lazy loading (Google lo dice sin matices en su guía de LCP), marcada con fetchpriority="high" y precargada si es un fondo CSS; después, caché de página y tiempo de respuesta del servidor. Si la cabecera es un slider, quítalo. En mi experiencia, pocas veces aporta algo que justifique lo que cuesta cargarlo.
"Problema con INP: más de 200 ms (móvil)"
La página tarda en reaccionar cuando el usuario toca un botón, abre un menú o escribe en un formulario. Casi siempre es exceso de JavaScript ocupando el hilo principal del navegador: constructores visuales, sliders, widgets de chat, banners de cookies, mapas de calor y un Tag Manager con veinte etiquetas que nadie revisa.
Aquí toca quitar antes que optimizar. Haz una lista con cada script de terceros. Lo que no aporta, fuera. Lo que sí, que se cargue tras la primera interacción o solo donde haga falta. Después viene el trabajo técnico de la guía de Google para optimizar INP: dividir las tareas largas y reducir el DOM, que los constructores visuales inflan con capas y capas de contenedores.
"Problema con CLS: más de 0,1 (móvil)"
Los elementos se mueven mientras la página carga y el usuario pulsa donde no quería. Las causas típicas: imágenes sin ancho y alto definidos, un banner de cookies o una barra promocional que empuja el contenido, fuentes web que cambian el tamaño del texto al cargar, y vídeos, mapas o anuncios sin espacio reservado.
Es la métrica más fácil de arreglar: ancho y alto (o aspect-ratio) en todas las imágenes, espacio reservado para lo que carga tarde y banners superpuestos en lugar de insertados en la página. Tienes las pautas completas en la guía de Google sobre CLS.
"No hay datos disponibles"
Chrome no tiene suficientes visitas de tu web para medirla, o la propiedad es nueva. Les pasa a muchos negocios locales. No significa que tu web vaya bien, sino que no hay datos para saberlo. Usa la nota de PageSpeed como orientación y, si quieres datos reales, instala la librería web-vitals de Google para enviar a Analytics las métricas de tus visitas.
Qué arreglar primero: por plantilla, no URL a URL
Empieza por la plantilla que genera contactos y por el móvil. Como Search Console agrupa URLs parecidas, el problema casi nunca está en una página concreta, sino en la plantilla que comparten: las fichas de servicio, las entradas del blog o la home.
Mi orden de prioridad:
- Plantillas que generan contactos o ventas, en móvil.
- Métricas en "Deficiente" antes que en "Necesita una mejora".
- Arreglos globales (servidor, caché, scripts que cargan en todas las páginas) antes que retoques en páginas sueltas.
- El escritorio, al final. Con los mismos umbrales, un ordenador con buena conexión procesa el mismo código mucho más rápido que un móvil de gama media con 4G. Si el móvil está en verde, el escritorio casi siempre lo está; al revés, casi nunca.
Cuando despliegues la corrección, inicia la validación en Search Console. El seguimiento dura 28 días, el mismo periodo sobre el que se calculan los datos de Chrome. No esperes ver el verde al día siguiente.
Caso real: una clínica dental en Lucena
ValleDental es una clínica dental de un solo centro en Lucena (Córdoba) que compite con franquicias regionales. En verano de 2022 rehicimos su web por completo: arquitectura por tratamiento, contenido y señales de confianza. Lo tienes contado en el caso completo de ValleDental.
Lo traigo aquí porque es el escenario que más me encuentro en negocios locales. Si pasas valledental.com por PageSpeed Insights, en los datos de campo aparece "No hay datos", tanto en móvil como en escritorio: Chrome no registra visitas suficientes para calcular sus Core Web Vitals.
Y aun así, en los últimos tres meses la web ha generado 2.480 clics orgánicos con una posición media de 7. Las Core Web Vitals no pueden haber influido en eso, porque Google ni siquiera tiene datos de campo de esa web. Esos clics los trajeron la arquitectura por tratamiento y el contenido.
No voy a esconder la otra cara. La prueba de laboratorio en móvil, con una conexión 4G lenta simulada, da un LCP de 8,2 segundos (consulta del 3 de octubre de 2026). Las causas son las de siempre: imágenes sin optimizar (PageSpeed calcula 642 KiB de ahorro), recursos que bloquean el renderizado e imágenes sin ancho y alto. Es la deuda técnica típica de una web de 2022, y es lo siguiente que toca arreglar, empezando por la plantilla de tratamientos, que es la que trae pacientes.
Esa es la idea con la que quiero que te quedes: las Core Web Vitals no son el motivo por el que te encuentran, pero sí pueden ser el motivo por el que te pierden. Y cuando no hay datos de campo, la única forma de saberlo es medirlo tú.
Lo que las Core Web Vitals no miden: si una IA puede leer tu web
Las Core Web Vitals miden la experiencia de personas que navegan con Chrome. No dicen nada sobre si ChatGPT, Claude o Perplexity pueden leer tu contenido, y para el GEO eso pesa más que la velocidad.
Un análisis de Vercel de diciembre de 2024 concluyó que ninguno de los grandes rastreadores de IA ejecutaba JavaScript: los de OpenAI, Anthropic, Meta y Perplexity descargaban los archivos, pero no los ejecutaban. Las excepciones eran Gemini, que usa la infraestructura de Googlebot, y Applebot. Así que una web puede aprobar las Core Web Vitals con nota y ser invisible para ChatGPT si sus servicios, precios u opiniones se cargan con JavaScript.
La comprobación rápida: desactiva JavaScript o mira el código fuente. Si lo importante no aparece, una IA tampoco lo ve. Lo desarrollo en mi página de SEO para IA y en cómo saber si ChatGPT, Gemini o Perplexity están citando tu web.
Lo que no haría
- Perseguir el 100 en PageSpeed. Es una nota de laboratorio, y la propia Google advierte en su guía de experiencia de página de que intentar una puntuación perfecta solo por SEO puede no ser la mejor forma de invertir tu tiempo.
- Instalar tres plugins de optimización a la vez. Se pisan entre ellos, rompen scripts y a veces empeoran el CLS. Uno bien configurado basta.
- Arreglar URL a URL lo que es un problema de plantilla. Si una ficha de servicio falla, fallan todas.
- Contratar una "optimización de velocidad" sin diagnóstico. Primero hay que saber qué plantilla pierde clientes y por qué. Lo demás es gastar por gastar.
Checklist rápida
- Abre el informe de Core Web Vitals, empieza por móvil y apunta qué métrica falla y en qué grupo de URLs.
- Pasa una URL del grupo por PageSpeed Insights y fíjate en los datos de campo, no en la nota.
- LCP: imagen principal sin lazy loading, con
fetchpriority="high", y caché de página activa. - INP: quita los scripts de terceros que no aporten y retrasa los demás.
- CLS: ancho y alto en las imágenes, espacio reservado y banners superpuestos.
- Corrige en la plantilla, inicia la validación y espera 28 días.
- Compara las conversiones desde móvil antes y después.
- Desactiva JavaScript y comprueba que tu contenido clave sigue ahí.
Resumen
Las Core Web Vitals pesan poco en el posicionamiento y mucho en la conversión. Mira los datos de campo de Search Console, no la nota de PageSpeed, y arregla por plantilla empezando por las páginas que te traen clientes desde el móvil. Y no confundas una web rápida con una web que una IA puede leer.
Preguntas frecuentes
¿Las Core Web Vitals son un factor de posicionamiento?
Sí, Google confirma que sus sistemas de ranking las usan. Pero unas buenas cifras no garantizan las primeras posiciones: la relevancia del contenido va por delante, y en la práctica funcionan como desempate.
¿Por qué PageSpeed Insights y Search Console no coinciden?
La nota de PageSpeed sale de una prueba de laboratorio simulada. Search Console usa datos de usuarios reales de Chrome de los últimos 28 días, que son los que cuentan para Google.
¿FID sigue siendo una Core Web Vital?
No. INP sustituyó a FID el 12 de marzo de 2024 y mide la respuesta a todas las interacciones de la visita, no solo a la primera.
¿Cuánto tarda Search Console en validar una corrección?
El seguimiento dura 28 días. Solo si el problema desaparece en todas las URLs afectadas durante ese periodo, Search Console lo da por corregido.
¿Qué significa "No hay datos disponibles" en el informe de Core Web Vitals?
Que Chrome no tiene suficientes visitas de tu web para calcular las métricas, o que la propiedad es nueva. No quiere decir que la web vaya bien: revísala con PageSpeed o mídela con la librería web-vitals.
Si Search Console te marca URLs en rojo y no sabes si merece la pena arreglarlas, es lo primero que reviso en una auditoría SEO: qué plantillas te hacen perder clientes y qué arreglo tiene retorno. Puedes ver cómo trabajo el SEO técnico o escribirme directamente.
