Base de Datos WordPress Lenta: Por Qué Pasa

Si tu web es una tienda y lo que se ralentiza es justo el catálogo -categorías, filtros, fichas con variaciones-, no es esto: es un problema específico de WooCommerce, y está explicado en WooCommerce lento con muchos productos. Esta guía es distinta: aplica a cualquier WordPress, tenga o no tienda online, y no tiene que ver con cuánto tráfico recibas.

Tu web no ha crecido, pero cada vez va más lenta

Es una de las quejas más desconcertantes que recibimos: "no me ha cambiado el tráfico, no he tocado nada, y aun así va cada vez peor". Cuando el tráfico no es la variable que ha cambiado, lo lógico es mirar lo que sí cambia solo con el paso del tiempo, sin que nadie haga nada especial: la base de datos. WordPress escribe en ella constantemente como parte de su funcionamiento normal, y buena parte de lo que escribe no se borra sola.

Revisiones de cada entrada, guardadas para siempre

Cada vez que guardas un borrador o publicas un cambio en una entrada o página, WordPress guarda una copia completa como revisión, por si quieres volver atrás. Por defecto no hay límite: una página que se ha editado 80 veces tiene 80 filas extra en la base de datos, cada una con el contenido completo de esa versión. Se puede limitar añadiendo esto a wp-config.php:

define( 'WP_POST_REVISIONS', 5 );

Eso conserva solo las últimas 5 revisiones de cada contenido a partir de ahora (las antiguas no se borran solas con este cambio; hace falta una limpieza aparte, que vemos más abajo).

Transients caducados que nadie ha borrado

Los transients son la forma que tienen los plugins y temas de guardar datos temporales -el resultado de una consulta cara, la respuesta de una API externa- para no repetir el trabajo en cada visita. El problema es que "caducado" y "borrado" no son lo mismo en WordPress: cuando un transient caduca, sigue ocupando su fila en la base de datos hasta que algo vuelve a pedirlo explícitamente. Si el plugin que lo creó se desactivó hace un año, nadie vuelve a pedirlo nunca, y se queda ahí de forma indefinida.

El problema silencioso: los datos "autoload" de wp_options

Este es el que más sorprende cuando se explica. WordPress guarda buena parte de su configuración en la tabla wp_options, y una parte de esas filas está marcada como autoload = yes: significa que WordPress las carga todas en cada página que sirve, la necesite esa página o no. Si esa tabla ha ido acumulando transients caducados, configuraciones de plugins que ya no existen y datos que ningún plugin activo usa -todo marcado como autoload-, cada visita paga ese peso de más, sea la portada, el checkout o el propio panel de administración. No es un problema de "esa parte de la web": es un impuesto que paga la web entera en cada carga.

Comentarios spam y papelera que nunca se vacía

WordPress tiene una tarea programada que vacía la papelera de comentarios (y de entradas) pasados 30 días por defecto. El detalle que se le escapa a mucha gente: esa tarea se dispara con las visitas a la web (lo que se conoce como WP-Cron), o con un cron real del servidor si el hosting lo tiene configurado así. Como parte de la optimización de rendimiento es habitual desactivar ese WP-Cron "de mentira" para que no interfiera en la carga de página, y sustituirlo por uno real en el servidor. El problema aparece cuando se desactiva el primero y nunca se configura el segundo: esa tarea de limpieza deja de ejecutarse sin que nadie lo note, y los comentarios en papelera y marcados como spam se acumulan sin fecha de caducidad real.

Cómo comprobarlo antes de tocar nada

Sin borrar todavía nada, se puede ver el tamaño del problema desde phpMyAdmin, mirando cuántas filas tienen wp_posts (revisiones incluidas) y wp_comments, y el tamaño total de wp_options. Si prefieres no escribir consultas SQL a mano, plugins como WP-Optimize o Advanced Database Cleaner dan ese mismo diagnóstico -cuántas revisiones, cuántos transients caducados, cuánto pesa cada tabla- sin ejecutar ninguna limpieza hasta que tú lo confirmes.

Limpiar sin cargarte nada

Con el diagnóstico hecho, el orden que evita sustos:

• Copia de seguridad antes de tocar la base de datos. Siempre, sin atajos.
• Limita las revisiones futuras con WP_POST_REVISIONS y borra el exceso de las antiguas.
• Borra solo los transients caducados, no todos. Borrar transients activos de golpe obliga a la web a recalcular todo ese contenido de una vez, lo que puede provocar justo el pico de carga que se quería evitar.
• Vacía papelera y spam de comentarios, y revisa si tu WP-Cron está realmente funcionando o si lo desactivaste sin sustituirlo por uno real.

No es un problema de tráfico, es de mantenimiento acumulado

La conclusión incómoda es esta: no hace falta que te crezca ni una visita para que tu WordPress vaya cada vez peor, porque la causa no está en cuánta gente entra, está en cuánto tiempo lleva sin que nadie limpie por dentro. La optimización de base de datos ya aparece como tarea mensual en nuestra guía de mantenimiento de WordPress; si prefieres que se haga sola en vez de acordarte tú, es justo lo que cubre nuestro plan de mantenimiento. Y si el problema ya está instalado y quieres que lo resolvamos de una vez, nuestro servicio de optimización web entra también en la base de datos, no solo en imágenes y caché.