Optimizar la base de datos de WordPress puede ser útil cuando una instalación acumula años de cambios, plugins eliminados, revisiones, transients y opciones que ya no aportan valor. El problema aparece cuando “limpiar” se convierte en borrar tablas o registros sin saber quién los utiliza.
Una base de datos más pequeña no es automáticamente una web más rápida. Antes de eliminar nada conviene identificar qué ocupa espacio, qué se carga en cada petición y si el cuello de botella está realmente en MySQL/MariaDB, en PHP, en consultas de plugins o en otra capa.
Qué guarda WordPress en la base de datos
En una instalación estándar, WordPress almacena contenido, configuración, usuarios, comentarios, taxonomías y metadatos en distintas tablas. Los plugins y temas también pueden crear tablas propias o guardar opciones en wp_options.
Por eso no existe una “limpieza universal” segura. Dos webs con el mismo tamaño pueden tener necesidades completamente distintas: una tienda puede depender de tablas adicionales y tareas en segundo plano, mientras que una web corporativa sencilla puede concentrar casi todo en las tablas nativas.
Primero: copia y diagnóstico
Antes de tocar datos, prepara una copia restaurable. No basta con descargar un archivo SQL y asumir que funciona: conviene poder recuperar la instalación si una limpieza elimina una opción, relación o registro que parecía prescindible.
Si quieres revisar este punto con más detalle, puedes consultar la guía sobre cómo probar la restauración de copias de WordPress.
Después, mide. Revisa al menos:
- tamaño de cada tabla;
- crecimiento reciente;
- cantidad de revisiones;
- transients almacenados;
- opciones autoload;
- tablas pertenecientes a plugins ya eliminados;
- consultas lentas si el hosting permite observarlas;
- errores o bloqueos en la base de datos.
La limpieza debería responder a un hallazgo concreto, no a una rutina de “borrar todo lo viejo”.
Revisiones: útiles, pero deben tener un criterio
WordPress mantiene revisiones de entradas y páginas para poder recuperar versiones anteriores. Es una función valiosa, especialmente cuando varias personas editan contenido o se realizan cambios importantes.
La documentación de WordPress permite limitar cuántas revisiones se conservan mediante WP_POST_REVISIONS. Eso puede evitar un crecimiento indefinido en sitios con mucha actividad editorial, pero no significa que debas desactivar las revisiones por completo.
Antes de eliminar revisiones antiguas, comprueba si las necesitas como mecanismo de recuperación editorial y si el ahorro de espacio es realmente significativo.
Transients: caché temporal, no basura por definición
La Transients API permite guardar datos temporales con una caducidad. En instalaciones sin caché de objetos persistente, muchos transients se almacenan en la base de datos. Con Redis, Memcached u otra caché persistente, el comportamiento puede ser diferente.
Un transient caducado puede eliminarse, pero conviene distinguir entre caducado, activo y permanente. Borrar todos los transients indiscriminadamente suele provocar que plugins y WordPress tengan que reconstruir cachés, realizar nuevas consultas o volver a solicitar información externa.
El objetivo no es “tener cero transients”, sino evitar acumulaciones anómalas y entender qué componente las genera.
Opciones autoload: una zona que merece atención
Las opciones marcadas para carga automática se recuperan en muchas peticiones. WordPress advierte de que un volumen excesivo de opciones autoload puede afectar al rendimiento y recomienda revisarlas cuando crecen demasiado.
WP-CLI permite listar opciones y calcular el tamaño total de las que se cargan automáticamente. Ese inventario es mucho más útil que borrar entradas por nombre.
wp option list --autoload=on --format=total_bytesTambién puedes ordenar opciones por tamaño para localizar valores grandes. Antes de cambiar una opción de autoload a manual o eliminarla, identifica qué plugin, tema o función la utiliza. Una opción grande puede ser innecesaria, pero también puede ser imprescindible para una parte crítica de la web.
Tablas de plugins desinstalados
Algunos plugins eliminan sus tablas al desinstalarse y otros las conservan para facilitar una futura reinstalación. Encontrar una tabla con el nombre de un plugin antiguo no significa automáticamente que pueda borrarse.
Comprueba primero:
- si el plugin está realmente desinstalado;
- si otro componente reutiliza esos datos;
- si existe documentación oficial de desinstalación;
- si los datos tienen valor histórico o legal;
- si una reinstalación futura necesitaría conservarlos.
Cuando exista duda, exportar la tabla antes de retirarla es más prudente que eliminarla directamente.
Qué hace realmente “optimizar tablas”
WP-CLI incluye el comando wp db optimize, que utiliza las herramientas de MySQL para solicitar una optimización de la base de datos. Es una operación distinta a eliminar revisiones, transients o tablas de plugins.
wp db optimizePuede ayudar a reorganizar determinadas tablas según el motor y su estado, pero no corrige consultas ineficientes, un plugin pesado, una arquitectura de datos deficiente o un exceso de opciones cargadas en cada petición.
Por eso debe entenderse como una operación de mantenimiento, no como una solución automática de rendimiento.
No confundas tamaño con rendimiento
Una base de datos de varios gigabytes puede responder bien si está correctamente indexada, dispone de recursos suficientes y las consultas son eficientes. En cambio, una base pequeña puede rendir mal si una petición ejecuta consultas costosas o carga demasiadas opciones en cada acceso.
Cuando el objetivo sea acelerar la web, combina el análisis de base de datos con mediciones reales de servidor y frontend. Los Core Web Vitals pueden señalar problemas visibles para el usuario, pero no sustituyen el diagnóstico de consultas o TTFB.
Proceso seguro para optimizar la base de datos
- Haz una copia restaurable.
- Trabaja primero en staging si el cambio incluye borrados o modificaciones masivas.
- Mide tablas y opciones antes de limpiar.
- Relaciona cada dato con su propietario: WordPress, tema o plugin.
- Elimina solo elementos identificados y con una razón concreta.
- Ejecuta la optimización de tablas únicamente cuando tenga sentido.
- Limpia cachés si la operación afecta a datos cacheados.
- Valida la web: frontend, administración, formularios, búsquedas e integraciones.
- Comprueba rendimiento después para saber si el cambio tuvo efecto real.
Si necesitas una zona segura para validar este tipo de intervención, revisa también la guía sobre staging en WordPress.
Qué evitar
- Ejecutar consultas SQL copiadas de Internet sin entender qué eliminan.
- Borrar todas las opciones con nombres “raros”.
- Eliminar tablas únicamente porque un plugin ya no aparece activo.
- Desactivar revisiones sin valorar su utilidad.
- Borrar transients como solución permanente a un problema que vuelve a generarlos.
- Instalar varios plugins de limpieza para realizar la misma tarea.
- Dar por hecho que una base de datos más pequeña mejorará las métricas de usuario.
Optimización como parte del mantenimiento
La base de datos debería revisarse como una pieza más del mantenimiento, junto con actualizaciones, copias, seguridad, rendimiento y comprobaciones funcionales. Una limpieza agresiva cada pocos meses es menos fiable que un proceso basado en inventario, medición y cambios reversibles.
En la guía de mantenimiento WordPress mensual puedes ver cómo encaja este trabajo dentro de una revisión técnica más amplia.
¿Tu WordPress acumula datos y no sabes qué se puede limpiar?
Puedo revisar tablas, opciones, rendimiento y dependencias antes de aplicar cambios, con copia y validación para evitar borrar información necesaria.
