Con el paso de los meses, cualquier instalación de WordPress acumula datos que ya no sirven para nada: revisiones antiguas de entradas, borradores automáticos, comentarios marcados como spam, transients caducados y tablas enteras que dejaron atrás plugins que desinstalaste hace tiempo. Toda esa carga extra hace que las consultas tarden más, que las copias de seguridad pesen el doble de lo necesario y que el panel de administración se sienta lento. Aprender a optimizar la base de datos de WordPress es una de esas tareas de mantenimiento que casi nadie hace y que, sin embargo, marca una diferencia real en el rendimiento, sobre todo en webs con años de historia o con muchos plugins instalados. En esta guía vamos a ver qué basura se acumula exactamente, cómo limpiarla de forma segura con consultas SQL y con plugins, y qué ajustes preventivos puedes dejar configurados para que el problema no vuelva a crecer.
Por qué la base de datos de WordPress acumula basura
WordPress guarda absolutamente todo en la base de datos: entradas, páginas, ajustes, usuarios, comentarios y también un montón de datos temporales que en teoría deberían limpiarse solos, pero que en la práctica se quedan ahí para siempre. Los principales culpables son estos:
- Revisiones de entradas: cada vez que guardas una entrada, WordPress almacena una copia completa de la versión anterior. Un artículo editado veinte veces son veinte filas extra en la tabla de posts, con su contenido íntegro duplicado.
- Borradores automáticos y papelera: los auto-drafts que se crean al abrir el editor y las entradas enviadas a la papelera siguen ocupando espacio hasta que alguien las elimina de verdad.
- Transients caducados: son datos temporales en caché que plugins y temas guardan en la tabla de opciones. Muchos tienen fecha de caducidad, pero WordPress solo los borra cuando alguien vuelve a pedirlos, así que los de plugins desinstalados no se limpian nunca.
- Comentarios spam y en papelera: en blogs con tráfico, Akismet puede acumular miles de comentarios spam con sus metadatos asociados.
- Metadatos huérfanos: filas de
wp_postmetaowp_commentmetaque apuntan a entradas o comentarios que ya no existen. - Tablas de plugins desinstalados: muchos plugins crean sus propias tablas y no las borran al desinstalarse, por si vuelves a instalarlos.
El resultado típico: una web mediana con tres o cuatro años de vida puede tener una tabla wp_options de 40 o 50 MB cuando debería pesar dos o tres, y una tabla de posts en la que el 70 % de las filas son revisiones que nadie va a restaurar jamás.
Antes de tocar nada: haz una copia de seguridad
Esta parte no es negociable. Vamos a lanzar consultas DELETE directamente contra la base de datos, y un error de escritura o una consulta demasiado agresiva puede dejar tu web inservible. Antes de continuar:
- Exporta la base de datos completa desde phpMyAdmin (pestaña Exportar, método rápido, formato SQL) o con la herramienta de copias de tu hosting.
- Comprueba que el fichero descargado pesa algo coherente y que se abre (es un fichero de texto SQL).
- Si tu hosting ofrece copias automáticas, verifica cuándo se hizo la última y que puedes restaurarla tú mismo.
Con la copia hecha, cualquier error tiene vuelta atrás en cinco minutos. Sin ella, no la tiene.
Cómo optimizar la base de datos de WordPress manualmente con SQL
La vía manual es la más transparente: ves exactamente qué borras y cuánto ocupaba. Necesitas acceso a phpMyAdmin (lo encontrarás en el panel de tu hosting, dentro del apartado de bases de datos) o a la línea de comandos de MySQL. Todas las consultas siguientes asumen el prefijo por defecto wp_; si tu instalación usa otro (lo verás en wp-config.php, en la variable $table_prefix), sustitúyelo en cada consulta.
1. Mide el punto de partida
Antes de limpiar, mira cuánto ocupa cada tabla para saber dónde está el problema:
SELECT table_name AS tabla,
ROUND((data_length + index_length) / 1024 / 1024, 2) AS mb
FROM information_schema.TABLES
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC;2. Elimina revisiones, borradores automáticos y papelera
Estas tres consultas borran contenido que WordPress considera desechable. Las revisiones desaparecen para siempre, así que asegúrate de que no necesitas restaurar ninguna versión antigua:
DELETE FROM wp_posts WHERE post_type = 'revision';
DELETE FROM wp_posts WHERE post_status = 'auto-draft';
DELETE FROM wp_posts WHERE post_status = 'trash';3. Limpia los metadatos huérfanos
Al borrar posts quedan metadatos apuntando a la nada. Estas consultas los eliminan de forma segura, porque solo tocan filas cuyo post o comentario padre ya no existe:
DELETE pm FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;
DELETE cm FROM wp_commentmeta cm
LEFT JOIN wp_comments c ON c.comment_ID = cm.comment_id
WHERE c.comment_ID IS NULL;4. Elimina el spam y los comentarios en papelera
DELETE FROM wp_comments WHERE comment_approved = 'spam';
DELETE FROM wp_comments WHERE comment_approved = 'trash';5. Borra los transients caducados
Los transients caducados son basura pura: tienen fecha de expiración en el pasado y nadie los va a leer. Esta pareja de consultas borra primero los temporizadores vencidos y después los datos asociados que se han quedado sin temporizador:
DELETE FROM wp_options
WHERE option_name LIKE '\_transient\_timeout\_%'
AND option_value < UNIX_TIMESTAMP();
DELETE t FROM wp_options t
LEFT JOIN wp_options timeout
ON timeout.option_name = CONCAT('_transient_timeout_',
SUBSTRING(t.option_name, 12))
WHERE t.option_name LIKE '\_transient\_%'
AND t.option_name NOT LIKE '\_transient\_timeout\_%'
AND timeout.option_id IS NULL;Si prefieres una limpieza más simple, borrar todos los transients (caducados o no) también es razonablemente seguro: WordPress y los plugins los regeneran cuando los necesitan. Eso sí, justo después la web puede ir algo más lenta durante unos minutos mientras se reconstruyen las cachés.
6. Optimiza las tablas
Borrar filas no devuelve automáticamente el espacio al disco. El último paso es compactar las tablas principales:
OPTIMIZE TABLE wp_posts, wp_postmeta, wp_options,
wp_comments, wp_commentmeta, wp_terms, wp_term_taxonomy;En tablas InnoDB (las habituales hoy) MySQL mostrará un aviso indicando que en realidad recrea la tabla; es el comportamiento esperado y el resultado es el mismo: espacio recuperado e índices reconstruidos.
Optimizar la base de datos con plugins: la vía cómoda
Si phpMyAdmin te impone o quieres programar la limpieza para que se repita sola, los plugins de optimización hacen exactamente lo mismo que las consultas anteriores, con red de seguridad y a golpe de clic. Estos son los más sólidos:
| Plugin | Puntos fuertes | Ideal para |
|---|---|---|
| WP-Optimize | Limpieza completa (revisiones, transients, spam), programación semanal, compresión de imágenes y caché en el mismo plugin | Quien quiere una solución todo en uno gratuita |
| Advanced Database Cleaner | Detecta tablas, opciones y tareas cron huérfanas de plugins desinstalados (la versión Pro las clasifica por plugin) | Webs veteranas con muchos plugins retirados |
| WP-Sweep | Ligero, usa siempre las funciones nativas de borrado de WordPress en lugar de SQL directo | Quien busca el enfoque más conservador |
| WP Rocket | Incluye limpieza programada de base de datos como extra de su caché de pago | Quien ya lo usa para WPO |
Si ya tienes WP Rocket para la caché, no necesitas instalar nada más: su pestaña de base de datos cubre revisiones, borradores, spam y transients con programación automática. Te contamos qué más ofrece en nuestro análisis de WP Rocket como plugin de caché de referencia. Y una regla general con cualquiera de ellos: la primera vez, revisa elemento a elemento lo que el plugin propone borrar antes de marcar la casilla de ejecución automática.
Ajustes preventivos: que la basura no vuelva a crecer
Limpiar está bien; no volver a ensuciar, mejor. WordPress permite limitar de raíz los dos mayores generadores de peso con un par de constantes en wp-config.php, siempre antes de la línea que dice «¡Eso es todo, deja de editar!»:
define( 'WP_POST_REVISIONS', 5 ); // máximo 5 revisiones por entrada
define( 'AUTOSAVE_INTERVAL', 300 ); // autoguardado cada 5 minutos
define( 'EMPTY_TRASH_DAYS', 15 ); // vaciar papelera a los 15 díasCon WP_POST_REVISIONS en 5, WordPress conserva las cinco revisiones más recientes de cada entrada y borra las anteriores automáticamente: mantienes la posibilidad de deshacer cambios recientes sin acumular cientos de copias. Si prefieres no tocar ficheros del servidor, puedes añadir estas constantes como snippet PHP con un gestor como el que analizamos en WPCode, el gestor de snippets de WordPress, aunque en el caso concreto de las constantes de wp-config.php la edición directa del fichero sigue siendo la opción más fiable.
Tablas huérfanas de plugins desinstalados
Es el residuo más difícil de limpiar con garantías. Cuando desinstalas un plugin, sus tablas (por ejemplo wp_yoast_indexable o wp_wfconfig) suelen quedarse en la base de datos. Para identificarlas:
- Lista todas las tablas con la consulta de tamaños del principio y anota las que no reconozcas como tablas nativas de WordPress (las nativas son doce: posts, postmeta, options, comments, commentmeta, users, usermeta, terms, termmeta, term_taxonomy, term_relationships y links).
- Busca el prefijo de cada tabla sospechosa en Google junto a la palabra «plugin»: casi siempre identificarás al responsable en el primer resultado.
- Solo si confirmas que el plugin está desinstalado y que no piensas volver a usarlo, elimina la tabla con
DROP TABLE nombre_de_la_tabla;.
Precaución doble aquí: un DROP TABLE no tiene deshacer, y algunas tablas pertenecen a plugins que siguen activos aunque el nombre no te suene. Ante la mínima duda, déjala estar o apóyate en Advanced Database Cleaner, que asocia cada tabla con su plugin de origen. Y recuerda que una base de datos hinchada también puede ser síntoma de algo peor: si encuentras tablas o usuarios que no reconoces en absoluto, repasa nuestra guía para detectar y limpiar un WordPress atacado.
Cada cuánto conviene repetir la limpieza
No hay una cifra universal, pero estas referencias funcionan bien en la práctica:
- Blog o web corporativa con publicación semanal: limpieza completa cada dos o tres meses, o programada mensualmente con WP-Optimize.
- Tienda WooCommerce o web con mucho movimiento: revisión mensual, vigilando especialmente los transients y las sesiones caducadas que genera la propia tienda.
- Web pequeña casi estática: una limpieza cada seis meses es más que suficiente.
Ten en cuenta también que la base de datos es solo una pata del rendimiento: si tu web sigue lenta después de optimizarla, el cuello de botella puede estar en la versión de PHP o en la configuración del servidor. En ese caso, sigue con nuestra guía para acelerar WordPress con ajustes de PHP.
Preguntas frecuentes
¿Es peligroso borrar las revisiones de WordPress?
No para el funcionamiento de la web: las revisiones son copias históricas del contenido y ninguna función del sitio depende de ellas. Lo único que pierdes es la posibilidad de restaurar versiones antiguas de tus entradas. Si sueles rescatar párrafos de versiones anteriores, limita las revisiones con WP_POST_REVISIONS en lugar de borrarlas todas.
¿Qué son exactamente los transients y por qué hay tantos?
Son un sistema de caché temporal que WordPress ofrece a temas y plugins: guardan resultados costosos (una petición a una API externa, un cálculo pesado) con fecha de caducidad. El problema es que WordPress no tiene un recolector de basura activo: un transient caducado solo se borra si algo vuelve a solicitarlo. Los de plugins eliminados, por tanto, se quedan huérfanos indefinidamente.
¿Cuánto espacio y velocidad puedo recuperar?
Depende de la edad y el historial de la web. En instalaciones veteranas es habitual reducir la base de datos entre un 30 % y un 70 %. La mejora de velocidad se nota sobre todo en el panel de administración y en webs cuya tabla de opciones estaba muy hinchada, porque WordPress carga en cada visita todas las opciones marcadas como autoload.
¿Sirve OPTIMIZE TABLE en tablas InnoDB?
Sí. MySQL responde con el aviso «Table does not support optimize, doing recreate + analyze instead», que puede parecer un error pero no lo es: significa que reconstruye la tabla y sus índices desde cero, que es precisamente lo que buscamos. El espacio liberado y el resultado final son equivalentes.
Conclusión
Optimizar la base de datos de WordPress no exige ser administrador de sistemas: con una copia de seguridad previa, media docena de consultas SQL bien elegidas (o un plugin como WP-Optimize que las ejecute por ti) y un par de constantes preventivas en wp-config.php, puedes recortar el peso de la base de datos a la mitad y mantenerla ligera de forma indefinida. La clave está en el orden de los pasos: primero copia de seguridad, después limpieza de revisiones, spam y transients, luego optimización de tablas y, por último, los ajustes que evitan que el problema se reproduzca. Dedica una hora a hacerlo bien la primera vez, deja la limpieza programada y tu WordPress te lo devolverá en forma de copias de seguridad más rápidas, un panel más ágil y un servidor con menos trabajo que hacer.
