Desarrollador web | Entusiasta del hacking | Diseñador UI

La caché es una de esas cosas que todo el mundo recomienda activar en WordPress, pero que poca gente entiende de verdad.

Cuando funciona bien, una web carga más rápido, consume menos recursos del servidor y mejora la experiencia del usuario. Cuando funciona mal, puede convertirse en una fuente de errores extraños: cambios que no aparecen, estilos antiguos, formularios que fallan, imágenes que parecen rotas, redirecciones obsoletas o problemas que “ya corregiste” pero siguen apareciendo.

En WordPress, la caché no es una sola cosa. Es una cadena de capas. Puede haber caché en el navegador, en el plugin, en el servidor, en LiteSpeed, en una CDN como Cloudflare, en objetos de WordPress, en transients, en la base de datos e incluso en el propio constructor visual que estés usando.

El problema es que, cuando algo falla, casi nunca aparece un mensaje diciendo:

“Este error viene de la caché.”

Simplemente ves una web que no se comporta como debería.

Esta guía explica cómo funciona realmente la caché en WordPress, qué capas intervienen, qué problemas puede provocar y cómo depurarlos con criterio técnico.

Qué es la caché en una web

La caché consiste en guardar una respuesta para reutilizarla después, evitando repetir trabajo innecesario.

En una web, ese “trabajo” puede ser:

- Consultar la base de datos.
- Ejecutar PHP.
- Cargar WordPress.
- Procesar plugins.
- Generar HTML.
- Descargar imágenes.
- Descargar CSS.
- Descargar JavaScript.
- Volver a pedir archivos que no han cambiado.

La caché HTTP permite almacenar respuestas asociadas a solicitudes y reutilizarlas en peticiones posteriores, lo que reduce la necesidad de contactar de nuevo con el servidor de origen.

En términos simples:

Sin caché:
usuario → servidor → PHP → WordPress → MySQL → HTML → usuario

Con caché:
usuario → respuesta guardada → usuario

Eso no significa que la caché sea siempre buena. Significa que es poderosa. Y como toda herramienta poderosa, mal configurada puede causar problemas difíciles de ver.

Qué ocurre cuando visitas una página WordPress sin caché

Cuando alguien entra en una página de WordPress sin caché, normalmente ocurre algo parecido a esto:

1. El navegador pide una URL.
2. El servidor recibe la petición.
3. PHP empieza a ejecutarse.
4. WordPress carga su núcleo.
5. WordPress carga el tema activo.
6. WordPress carga plugins.
7. Se hacen consultas a MySQL.
8. Se genera el HTML final.
9. El servidor envía la respuesta al navegador.
10. El navegador descarga CSS, JS, imágenes y fuentes.
11. El navegador renderiza la página.

Este proceso puede ser razonablemente rápido en una web pequeña, pero empieza a volverse pesado cuando hay muchos plugins, constructores visuales, consultas lentas, imágenes grandes, anuncios, scripts externos o un hosting limitado.

Cada visita obliga al servidor a repetir parte del mismo trabajo.

La caché intenta evitar eso.

Qué ocurre cuando visitas una página WordPress con caché

Con caché de página activa, WordPress no tiene que generar siempre el HTML desde cero.

La primera visita puede generar la página normalmente:

usuario → WordPress → MySQL → HTML generado

Pero después, esa respuesta se guarda:

HTML generado → caché

Y las siguientes visitas reciben una copia ya preparada:

usuario → HTML cacheado

Esto reduce el uso de PHP, las consultas a la base de datos y el tiempo de respuesta del servidor. En rendimiento web, esto suele impactar directamente en el TTFB, es decir, el tiempo que tarda el navegador en recibir el primer byte de respuesta.

La caché no mejora todo por arte de magia, pero sí elimina una parte importante del trabajo repetitivo.

Las capas reales de caché en WordPress

En una instalación real de WordPress pueden existir varias capas funcionando al mismo tiempo:

┌──────────────────────────────┐
│ Navegador del usuario        │
├──────────────────────────────┤
│ CDN / Cloudflare             │
├──────────────────────────────┤
│ Servidor / LiteSpeed         │
├──────────────────────────────┤
│ Plugin de caché              │
├──────────────────────────────┤
│ WordPress                    │
├──────────────────────────────┤
│ Caché de objetos             │
├──────────────────────────────┤
│ Transients                   │
├──────────────────────────────┤
│ Base de datos                │
└──────────────────────────────┘

Por eso borrar “la caché” no siempre soluciona nada. Hay que saber qué caché estás borrando.

Puedes limpiar la caché del plugin y seguir viendo el problema porque Cloudflare aún sirve una copia antigua. Puedes limpiar Cloudflare y seguir viendo CSS viejo porque el navegador lo tiene guardado. Puedes borrar caché de página y seguir teniendo datos temporales guardados en transients.

La caché no es una caja. Es una pila.

Caché del navegador

La caché del navegador guarda recursos en el equipo del usuario.

Por ejemplo:

- Imágenes.
- Archivos CSS.
- Archivos JavaScript.
- Fuentes.
- Iconos.
- Logotipos.

Si un archivo no cambia con frecuencia, no tiene sentido descargarlo en cada visita. El navegador puede conservarlo durante un tiempo y reutilizarlo.

Esto se controla mediante cabeceras HTTP como:

Cache-Control: max-age=31536000

O mediante validadores como:

ETag
Last-Modified

La cabecera Cache-Control define directivas para controlar el almacenamiento en caché en navegadores y cachés compartidas.
Un ETag identifica una versión específica de un recurso y permite validar si el contenido cambió antes de descargarlo completo otra vez.

El problema aparece cuando cambias un archivo CSS, pero el navegador sigue usando la versión anterior.

Ejemplo típico:

Cambias el color de un botón.
Guardas.
Limpias caché de WordPress.
Abres la página.
El botón sigue igual.

Puede que WordPress ya esté bien. Puede que el servidor ya esté bien. Puede que el problema sea simplemente que el navegador sigue usando un CSS antiguo.

Una forma de evitarlo es versionar archivos:

<link rel="stylesheet" href="/style.css?v=2">

WordPress suele hacer esto con parámetros de versión, pero algunos plugins de optimización o constructores pueden alterar ese comportamiento.

Caché de página

La caché de página guarda el HTML final de una URL.

Es una de las capas más importantes en WordPress porque evita generar la página completa en cada visita.

Ejemplo:

https://davidatb.com/cache-wordpress/

Sin caché, WordPress genera esa URL cada vez.
Con caché, el servidor puede entregar un HTML ya generado.

Esto es muy útil para:

- Entradas de blog.
- Páginas estáticas.
- Landing pages.
- Documentación.
- Páginas informativas.

Pero puede ser peligroso en páginas dinámicas como:

- Carrito.
- Checkout.
- Mi cuenta.
- Formularios personalizados.
- Paneles privados.
- Páginas con contenido específico por usuario.

Una regla importante:

No todo debe cachearse.

Una entrada técnica puede cachearse sin problema. Un checkout de WooCommerce no debería tratarse igual.

Caché de LiteSpeed en WordPress

En muchos hostings modernos, especialmente en entornos optimizados para WordPress, LiteSpeed es una pieza importante del rendimiento.

LiteSpeed Cache para WordPress combina caché a nivel de servidor con funciones de optimización como minificación, carga diferida, optimización de imágenes y otras herramientas de rendimiento. El propio plugin se describe como una solución de aceleración con caché a nivel de servidor.

La diferencia importante es esta:

Plugin de caché normal:
WordPress/PHP gestiona gran parte del proceso.

LiteSpeed Cache:
El servidor LiteSpeed puede intervenir antes y servir contenido cacheado con menos coste.

Eso puede ser muy rápido, pero también puede confundir durante el desarrollo o mantenimiento.

Por ejemplo:

- Actualizas una página y no ves el cambio.
- Cambias CSS y el frontend sigue igual.
- Migras la web y persiste un error antiguo.
- Reparas permisos y WordPress sigue mostrando un fallo.
- Desactivas un plugin y algo parece seguir activo.

No siempre es que el cambio no haya funcionado. A veces estás viendo una copia.

LiteSpeed permite purgar la caché desde su panel. La documentación indica que “Purge All LSCache” limpia las páginas cacheadas del sitio WordPress actual.

Caché de CDN

Una CDN, como Cloudflare, puede guardar archivos en servidores distribuidos.

Su objetivo es acercar los recursos al usuario.

Sin CDN:

usuario en México → servidor en Europa

Con CDN:

usuario en México → nodo cercano de CDN

Normalmente una CDN cachea recursos estáticos:

- Imágenes.
- CSS.
- JavaScript.
- Fuentes.
- Archivos descargables.

Pero también puede cachear HTML si se configura para ello.

Aquí aparecen problemas interesantes:

- La web ya cambió en WordPress, pero Cloudflare sirve la versión anterior.
- Una redirección antigua sigue viva.
- Una imagen reemplazada sigue mostrando el archivo anterior.
- Googlebot recibe una versión distinta a la que ves tú.

Por eso, al depurar, no basta con limpiar WordPress. Si hay CDN, también hay que revisar esa capa.

Caché de objetos

La caché de objetos guarda resultados de operaciones internas, normalmente consultas o datos usados por WordPress y plugins.

No es lo mismo que caché de página.

La caché de página guarda HTML final.
La caché de objetos guarda datos internos reutilizables.

Ejemplo simplificado:

$opciones = get_option('mi_plugin_config');

Si esa consulta se repite muchas veces, una caché de objetos puede evitar ir constantemente a la base de datos.

WordPress incluye la clase WP_Object_Cache, y cuando existe una caché persistente configurada, ciertos mecanismos pueden apoyarse en ella para evitar consultas repetidas.

En instalaciones más avanzadas, esto puede apoyarse en sistemas como:

- Redis.
- Memcached.

La caché de objetos suele ser útil en:

- Sitios con mucho tráfico.
- WooCommerce.
- Membership sites.
- Foros.
- Sitios con muchas consultas repetidas.
- WordPress multisite.

Pero en una web pequeña o mal configurada, no siempre produce una mejora visible.

Transients en WordPress

Los transients son una forma de almacenar datos temporales en WordPress con una fecha de expiración.

Sirven para guardar resultados que no necesitas recalcular en cada carga.

Ejemplo:

set_transient( 'davidatb_api_resultado', $datos, HOUR_IN_SECONDS );

Luego puedes recuperarlo:

$datos = get_transient( 'davidatb_api_resultado' );

La Transients API permite almacenar datos temporales con un nombre y un tiempo de expiración; por defecto puede usar la tabla de opciones de WordPress, aunque con caché persistente puede apoyarse en la caché de objetos.

Esto se usa mucho en plugins para:

- Guardar respuestas de APIs.
- Evitar consultas repetidas.
- Almacenar datos temporales.
- Reducir carga externa.

El problema es que, si un transient queda con datos antiguos o corruptos, puedes limpiar la caché de página y aun así seguir viendo información vieja.

Por eso algunos plugins incluyen opciones como:

- Clear expired transients.
- Clear all transients.
- Optimize database.

LiteSpeed Cache, por ejemplo, incluye opciones para limpiar transients expirados o todos los transients desde su sección de base de datos.

Problemas comunes causados por caché

La caché puede provocar errores que parecen venir de otra parte.

1. Cambios de diseño que no aparecen

Esto suele ocurrir por CSS cacheado.

Ejemplo:

Cambias margen, color, tipografía o tamaño.
Guardas.
Abres la página.
Nada cambia.

Posibles causas:

- Caché del navegador.
- Caché del plugin.
- CSS minificado antiguo.
- Archivo CSS combinado.
- CDN sirviendo assets viejos.
- Caché interna del constructor visual.

2. Imágenes que siguen rotas

Puedes subir una imagen nueva, reemplazar un archivo o corregir una ruta, pero seguir viendo el recurso anterior.

Posibles causas:

- CDN.
- Navegador.
- Caché del plugin de optimización de imágenes.
- WebP generado previamente.
- Lazy loading mal configurado.

3. Errores que persisten después de corregirlos

Este es uno de los casos más frustrantes.

Ejemplo:

WordPress mostraba un error.
Corriges permisos.
Corriges rutas.
La web sigue mostrando el error.

A veces no estás viendo el estado real actual, sino una respuesta cacheada.

4. Redirecciones antiguas

Las redirecciones también pueden quedar cacheadas.

Ejemplo:

Cambias una URL.
Corriges .htaccess.
Actualizas WordPress.
Pero el navegador sigue redirigiendo igual.

Aquí puede intervenir:

- Caché del navegador.
- Plugin de redirecciones.
- Servidor.
- CDN.
- HSTS, si aplica.

5. Formularios que fallan

Algunos formularios dependen de tokens, nonces o sesiones. Si una página con formulario se cachea mal, puedes tener errores como:

- El formulario no envía.
- El captcha falla.
- El nonce caducó.
- El usuario ve una versión antigua.

En WordPress, páginas con interacciones dinámicas deben revisarse con cuidado antes de cachearlas agresivamente.

Cómo saber si un problema viene de caché

No hay una única prueba perfecta, pero sí un proceso razonable.

Paso 1: prueba en incógnito

Abre la URL en una ventana privada.

Si ahí funciona, probablemente el problema está en:

- Caché del navegador.
- Cookies.
- Sesión.
- Estado local del usuario.

Paso 2: añade un parámetro a la URL

Prueba:

https://tusitio.com/pagina/?v=123

Si con ese parámetro ves la versión correcta, puede haber caché de página o CDN sirviendo una copia anterior.

Paso 3: limpia caché del plugin

En LiteSpeed Cache:

LiteSpeed Cache → Toolbox → Purge → Purge All

Paso 4: limpia caché del servidor o hosting

Algunos hostings tienen su propia caché fuera de WordPress.

Esto es importante porque puedes desactivar el plugin y aun así seguir teniendo caché del servidor.

Paso 5: limpia CDN

Si usas Cloudflare u otra CDN:

Purge Cache

En casos extremos:

Development Mode

Paso 6: prueba otro navegador o dispositivo

Esto ayuda a separar problemas locales de problemas reales del sitio.

Paso 7: revisa cabeceras HTTP

Puedes usar DevTools del navegador:

F12 → Network → selecciona la página o recurso → Headers

Busca cabeceras como:

cache-control
etag
last-modified
cf-cache-status
x-litespeed-cache
age
expires

Estas cabeceras suelen dar pistas sobre quién está sirviendo la respuesta.

Orden recomendado para limpiar cachés

Cuando algo no se actualiza, yo seguiría este orden:

1. Caché del plugin de WordPress.
2. Caché de LiteSpeed o del servidor.
3. Caché de CDN.
4. Caché del navegador.
5. Caché del constructor visual.
6. Caché de objetos.
7. Transients.
8. DNS, solo si el problema es de dominio o migración.

No siempre hace falta limpiar todo. Pero este orden evita perder tiempo.

Caché y rendimiento web

La caché impacta especialmente en rendimiento percibido.

Puede mejorar:

- TTFB.
- Tiempo de carga inicial.
- Uso de CPU del servidor.
- Escalabilidad.
- Consumo de recursos.
- Experiencia de usuario.

Pero no arregla todo.

Una web puede tener buena caché y aun así ser lenta por:

- Imágenes enormes.
- JavaScript excesivo.
- Fuentes mal cargadas.
- Demasiados plugins.
- Constructor visual pesado.
- Terceros externos lentos.
- Mala jerarquía de CSS.

Los Core Web Vitals actuales se centran en LCP, INP y CLS como métricas principales de experiencia de usuario.

La caché ayuda mucho con la entrega inicial, pero no sustituye una buena arquitectura frontend.

Por ejemplo:

La caché puede mejorar el TTFB.
La caché puede ayudar indirectamente al LCP.
La caché no corrige por sí sola un layout que se mueve.
La caché no elimina JavaScript innecesario.
La caché no convierte una imagen de 4 MB en una imagen optimizada.

Caché y diseño web

Un diseñador web que trabaja con WordPress necesita entender la caché.

No para convertirse en administrador de sistemas, sino para no tomar decisiones equivocadas.

Muchos problemas visuales no vienen del diseño, sino de assets antiguos:

- CSS viejo.
- JS minificado roto.
- Fuentes cacheadas.
- Imágenes WebP generadas antes del cambio.
- Breakpoints que no reflejan la versión actual.

Esto es especialmente común con constructores visuales.

Puedes estar modificando una landing page y pensar:

“El constructor no guarda.”

Pero en realidad el constructor sí guardó. Lo que ocurre es que el frontend sigue entregando una versión previa del CSS generado.

En proyectos reales, entender caché ahorra horas.

Caché y SEO técnico

Desde el punto de vista SEO, la caché importa porque afecta a cómo se entrega el sitio.

Una buena configuración puede ayudar a:

- Reducir tiempos de respuesta.
- Mejorar rastreo.
- Entregar páginas más rápido.
- Estabilizar la experiencia del usuario.
- Reducir carga del servidor ante picos.

Pero una mala configuración puede provocar problemas serios:

- HTML antiguo.
- Canonicals desactualizados.
- Sitemaps cacheados incorrectamente.
- Redirecciones antiguas.
- Contenido distinto para usuarios y bots.
- Páginas dinámicas servidas como si fueran estáticas.

La caché debe acelerar el sitio, no congelarlo.

Checklist práctico para depurar caché en WordPress

Cuando algo no se actualiza o parece roto, revisa esto:

[ ] ¿El cambio está guardado en WordPress?
[ ] ¿Probaste en incógnito?
[ ] ¿Probaste añadiendo ?v=123 a la URL?
[ ] ¿Limpiaste la caché del plugin?
[ ] ¿Limpiaste LiteSpeed Cache?
[ ] ¿Existe caché del hosting?
[ ] ¿Hay CDN activa?
[ ] ¿Cloudflare está sirviendo contenido antiguo?
[ ] ¿El navegador conserva CSS/JS viejo?
[ ] ¿El constructor visual tiene caché propia?
[ ] ¿Hay CSS minificado o combinado?
[ ] ¿Hay WebP generado previamente?
[ ] ¿Hay transients antiguos?
[ ] ¿Hay caché de objetos activa?
[ ] ¿Las cabeceras HTTP confirman caché?

Configuración razonable para una web WordPress normal

Para una web corporativa, blog técnico o sitio personal, una configuración sensata suele ser:

- Caché de página activada.
- Purga automática al actualizar entradas.
- Caché de navegador para estáticos.
- Lazy loading en imágenes.
- Optimización de imágenes.
- Minificación CSS/JS con cuidado.
- Combinar CSS/JS solo si no rompe nada.
- Excluir páginas dinámicas.
- No cachear usuarios logueados.
- Revisar formularios.
- Probar frontend después de cada cambio importante.

Evitaría activar todas las opciones de optimización de golpe.

Mejor hacerlo por fases:

1. Activar caché de página.
2. Probar.
3. Activar optimización de imágenes.
4. Probar.
5. Activar minificación CSS.
6. Probar.
7. Activar minificación JS.
8. Probar.
9. Revisar Core Web Vitals.

La optimización web no consiste en marcar todos los checks. Consiste en entender qué hace cada opción.

Conclusión

La caché en WordPress no es solo un botón para “hacer la web más rápida”.

Es una arquitectura de capas.

Puede estar en el navegador, en WordPress, en LiteSpeed, en el servidor, en una CDN, en objetos, en transients o en el propio constructor visual. Por eso, cuando una web no muestra cambios o mantiene errores antiguos, limpiar una sola caché puede no ser suficiente.

Un buen flujo técnico consiste en identificar qué capa está interviniendo, purgar en orden, revisar cabeceras HTTP y probar con método.

La caché bien configurada mejora rendimiento, estabilidad y experiencia de usuario.

La caché mal entendida convierte el mantenimiento web en una pelea contra fantasmas.