Cómo pasar Core Web Vitals en WordPress sin cambiar de theme

Un cliente te reenvía un correo: su “consultor SEO” le ha dicho que la web suspende los Core Web Vitals y que “hay que rehacerla”. Entras en el proyecto y te encuentras lo de siempre: un WordPress con un theme premium que el cliente pagó, al que le tiene cariño y que no piensa tocar. Y tú en medio, con un informe en rojo y un presupuesto de rediseño que nadie va a aprobar.

La buena noticia para tu agencia: casi siempre puedes pasar los Core Web Vitals en WordPress sin cambiar de theme. El theme rara vez es el culpable real. Lo que penaliza Google suele ser un puñado de problemas concretos —imágenes sin optimizar, falta de caché, plugins de más, fuentes que bloquean— que arreglas sobre la web que ya tiene el cliente, sin rehacer nada y sin pasarle el marrón. Vamos a verlos en orden de impacto, para que entregues resultados en una iteración y no en un rediseño.

Qué miran los Core Web Vitals (lo justo para explicárselo al cliente)

Los Core Web Vitals son tres notas con las que Google mide la experiencia real de quien visita una web. Te interesan dos cosas: qué castiga cada una y poder traducirlo cuando el cliente pregunte.

• LCP (Largest Contentful Paint): cuánto tarda en aparecer el elemento principal —normalmente la imagen grande o el titular de la portada—. Objetivo: menos de 2,5 segundos.
• INP (Interaction to Next Paint): cómo de rápido responde la web cuando alguien pulsa un botón o abre el menú. Objetivo: menos de 200 milisegundos.
• CLS (Cumulative Layout Shift): cuánto bailan los elementos mientras carga, esos saltos que hacen pulsar el botón equivocado. Objetivo: menos de 0,1.

Las tres son factor de posicionamiento oficial desde 2021. Suspenderlas hunde al cliente en el ranking, y ahí es donde tu agencia entra a defender la cuenta —junto a otras palancas de SEO técnico como los datos estructurados de las fichas de producto si gestionas un e-commerce—.

¿Por qué cambiar el theme casi nunca es la respuesta?

Porque el theme rara vez es la causa real del suspenso: lo que penaliza Google es cómo se sirve el contenido, no el diseño. Recomendar un cambio de theme es la salida fácil, y casi siempre la más cara y arriesgada para la agencia: rehacer maquetación, revisar cada landing, arriesgarte a tumbar formularios y conversiones que ya funcionaban. Y en el 90% de los casos no ataca la causa real.

Porque los Core Web Vitals de un WordPress lento no dependen del diseño del theme, sino de cómo se sirve el contenido: imágenes de 3 MB, veinte plugins compitiendo, ninguna caché, fuentes que bloquean el render. Eso le pasa igual a un theme premium que a uno gratuito. Antes de proponer un rediseño que el cliente no va a pagar, agota esta lista.

Cómo pasar los Core Web Vitals en WordPress paso a paso

1. Optimiza las imágenes (el mayor impacto en el LCP)

Es la causa número uno de un mal LCP y la más rápida de corregir en una web heredada. El cliente sube fotos de 4 MB tal cual desde el móvil cuando esa misma imagen bien preparada pesaría treinta veces menos.

Lo que haces en el proyecto:

• Instalas un plugin de optimización (ShortPixel, Imagify o LiteSpeed) que comprime y sirve en WebP/AVIF automáticamente, también el histórico ya subido.
• Verificas que la carga diferida (lazy loading) está activa y que ningún plugin la pisa —pero quita el lazy de la imagen del LCP, o empeoras justo la métrica que quieres arreglar—.
• Fijas dimensiones (width/height) en las imágenes para que no provoquen saltos: eso también te sube el CLS.

Solo con esto muchas webs pasan de rojo a naranja sin que el cliente note un solo cambio visual.

2. Activa una buena caché

Sin caché, el servidor del cliente reconstruye la página entera en cada visita. Con caché, sirve una versión ya preparada en una fracción del tiempo. Es la mejora con mejor relación esfuerzo-resultado para entregar rápido.

Un plugin como WP Rocket (de pago, el más limpio para entornos de cliente) o LiteSpeed Cache / W3 Total Cache te da caché de página, minificación de CSS/JS y compresión desde un panel. Activa los ajustes con cabeza y prueba en staging: la minificación agresiva es la causa habitual de que un theme premium “se rompa” tras optimizar.

3. Quita los plugins que sobran (tu palanca para el INP)

Cada plugin activo añade peso y, sobre todo, JavaScript que el navegador tiene que procesar. Ese exceso de scripts es lo que más castiga el INP, porque la web tarda en responder a los clics.

Audita la lista de plugins del cliente y sé quirúrgico: el constructor que se probó una vez, el plugin de un evento que ya pasó, los tres que hacen lo mismo. Desactiva, prueba y borra. Documenta qué quitas para justificarlo ante el cliente y para no llevarte sustos en la siguiente revisión.

4. Controla las fuentes y los scripts de terceros

Las fuentes de Google servidas desde sus servidores y los scripts externos (chats, mapas, píxeles, herramientas de marketing del propio cliente) bloquean el render y empeoran el LCP. Dos arreglos limpios:

• Aloja las fuentes en el servidor del cliente: plugins como OMGF lo hacen con un clic.
• Carga los scripts pesados solo donde aportan. El píxel y el chat van en todas las páginas por inercia; el mapa de Google solo hace falta en “Contacto”.

Aquí es donde más tropieza la propia agencia: el stack de marketing que metiste tú también cuenta. Mídelo.

5. Revisa el hosting (el techo de todo lo demás)

Si el servidor tarda en responder (TTFB alto), ninguna otra optimización lo compensa del todo. Un alojamiento compartido barato pone un límite duro. No hace falta lo más caro, pero un hosting decente orientado a WordPress es la base. Si gestionas varias cuentas, estandarizar a un buen hosting gestionado te ahorra este problema en todos los clientes a la vez —lo desarrollo en mi artículo sobre por qué una web rápida vende más—.

Cómo medirlo para reportárselo al cliente

No trabajes a ciegas ni reportes sensaciones. Mide antes y después con PageSpeed Insights: pega la URL, analiza y mira dos bloques. Arriba, los datos de campo (usuarios reales, los que Google usa para posicionar); abajo, los datos de laboratorio y la lista priorizada de mejoras.

Haz un cambio, vuelve a medir, registra el impacto y pasa al siguiente: así construyes un antes/después defendible para el informe. Mide siempre en móvil —es donde se juega el tráfico y donde los Core Web Vitals aprietan— y recuerda que el dato de campo tarda semanas en moverse, no días.

¿Cuándo sí toca cambiar el theme?

Solo cuando, tras aplicar todo lo anterior y medir, la web sigue en rojo por culpa del propio theme. Para ser justos: a veces el theme sí es el problema. Plantéaselo al cliente si, tras aplicar todo lo anterior y medir, sigue en rojo y además:

• El theme carga decenas de funciones y librerías que el negocio no usa pero el navegador descarga igual.
• Lleva años sin actualizaciones del desarrollador (riesgo técnico y de seguridad, no solo de velocidad).
• Depende de un constructor visual muy pesado para absolutamente todo.

Incluso entonces, llega a esa conversación con datos: “aplicamos estas cinco optimizaciones, medimos, y el techo lo pone el theme”. Eso es vender un rediseño justificado, no un capricho.

Conclusiones clave

• En la mayoría de proyectos puedes pasar los Core Web Vitals en WordPress sin cambiar el theme del cliente.
• Ataca en orden de impacto: imágenes, caché, plugins de más, fuentes y scripts de terceros, y hosting.
• Casi todo se hace sobre la web existente, sin rediseño y sin frenar la cuenta.
• Mide antes y después con PageSpeed Insights, en móvil, y educa al cliente sobre la ventana de 28 días del dato de campo.
• El cambio de theme es el último recurso y, cuando toca, se propone con datos.

¿Necesitas un socio técnico para estos casos?

No toda agencia tiene en plantilla a alguien que se meta en el WordPress de un cliente a destripar plugins y afinar el LCP sin romper nada. Yo trabajo como socio técnico white-label para tu agencia: entro en los proyectos en los que tu equipo no quiere o no puede meterse, dejo los Core Web Vitals en verde y te paso un antes/después listo para reportar al cliente, siempre bajo tu marca.

Si quieres saber con quién hablas, te dejo un poco sobre mí. Y cuando tengas un cliente atascado, escríbeme y lo vemos juntos.

Preguntas frecuentes

¿Hay que cambiar el theme del cliente para pasar los Core Web Vitals?

Casi nunca, y conviene evitarlo: cambiar el theme de un cliente implica rehacer maquetación, revisar cada plantilla y arriesgarte a romper conversiones que ya funcionan. La mayoría de suspensos vienen de imágenes pesadas, falta de caché, exceso de plugins y fuentes mal cargadas, y todo eso se corrige sobre el theme actual. El cambio solo se justifica si el theme carga muchísimo código sin usar o está abandonado por su desarrollador.

¿Qué Core Web Vitals mide Google exactamente?

Tres métricas: LCP (cuánto tarda en aparecer el contenido principal, objetivo por debajo de 2,5 segundos), INP (cómo de rápido responde la página a las interacciones, objetivo por debajo de 200 milisegundos) y CLS (cuánto se mueven los elementos mientras carga, objetivo por debajo de 0,1).

¿Por qué PageSpeed da 95 en mi prueba y el cliente sigue suspendiendo en Search Console?

Porque son datos distintos. El número del momento es dato de laboratorio (una sola carga simulada); lo que Google usa para posicionar son los datos de campo (CrUX), una media de 28 días de visitas reales. Optimiza para el campo, no para el laboratorio, y mide siempre en móvil.

¿Cuánto tarda en reflejarse la mejora en el ranking del cliente?

Los datos de laboratorio cambian al instante, pero los de campo se basan en una ventana móvil de 28 días, así que la mejora en Search Console y en el ranking tarda algunas semanas en consolidarse. Conviene avisar al cliente para que no espere resultados al día siguiente.