Optimización y limpieza avanzada de la base de datos para un WordPress saneado

Una base de datos saneada es sinónimo de un WordPress más rápido, más seguro y más fácil de mantener. Sin embargo, muchas veces se pasa por alto su mantenimiento hasta que comienzan los problemas: carga lenta del panel, errores intermitentes, funciones que fallan o incluso caídas del sitio.

WordPress, por su diseño flexible y extensible, acumula una gran cantidad de datos innecesarios con el paso del tiempo. Revisiones de entradas, transients caducados, opciones autoload mal gestionadas, tablas huérfanas de plugins eliminados… Todo esto puede convertirse en una carga que ralentiza tu sitio sin que te des cuenta.

En este artículo vamos a ver cómo hacer una optimización y limpieza avanzada de la base de datos de WordPress, de forma segura y efectiva, combinando herramientas como WP-CLI, consultas SQL, plugins específicos y automatización con scripts.

No nos quedaremos en el clásico «instala X o Y plugin y dale al botón». Vamos a entender qué limpiar, por qué y cómo hacerlo bien, según el tipo de proyecto.

Si eres desarrollador, freelance, gestor de sitios WordPress o responsable de mantenimiento, este artículo te ayudará a:

• Detectar y eliminar lastres ocultos en la base de datos.
• Entender qué tablas y datos deberías conservar o eliminar.
• Automatizar el mantenimiento con código.
• Evitar errores comunes al limpiar.

Todo ello con un enfoque profesional, pero sin requerir conocimientos avanzados de bases de datos.

1. Anatomía de la base de datos de WordPress
2. Limpiezas esenciales que todos deberíamos hacer
3. Limpiezas avanzadas para proyectos más complejos
4. Auditoría detallada con WP-CLI y SQL
5. Cómo afecta la base de datos al rendimiento real y al TTFB
6. Herramientas para auditar y limpiar con seguridad
7. Automatización y buenas prácticas
8. Casos especiales y recomendaciones según tipo de sitio
9. Consejos finales, errores comunes y buenas prácticas

Anatomía de la base de datos de WordPress

Antes de empezar a limpiar o automatizar procesos, es fundamental entender la estructura que hay detrás de WordPress. La base de datos es el núcleo dinámico del CMS: todo el contenido, configuraciones y relaciones entre elementos se almacenan aquí. Una mala manipulación puede romper el sitio entero.

WordPress utiliza por defecto una base de datos MySQL o MariaDB con una estructura sencilla pero extensible. En la mayoría de los casos, está compuesta por doce tablas básicas que cubren desde las entradas hasta los comentarios, pasando por los usuarios o las opciones generales.

Tablas por defecto de WordPress

A continuación tienes un resumen de las tablas que encontrarás en cualquier instalación limpia:

El prefijo wp_ puede ser personalizado en la instalación por razones de seguridad, así que no lo des por hecho¹.

¿Dónde se acumula la basura?

Aunque estas tablas son necesarias, muchas veces acumulan datos que no deberían quedarse indefinidamente:

• wp_postmeta: metadatos obsoletos de plugins antiguos.
• wp_options: opciones con autoload activado que ralentizan la carga.
• wp_comments: comentarios de spam no moderados.
• wp_posts: revisiones automáticas y borradores que ya no tienen sentido.

Además, la mayoría de plugins instalan sus propias tablas, y muchas veces no las eliminan al desinstalarse. Un ejemplo típico:

wp_woocommerce_order_items
wp_woocommerce_order_itemmeta
wp_gf_entry
wp_gf_entry_meta
wp_yoast_indexable

Si un plugin fue eliminado hace meses, pero sus tablas siguen presentes, estás ocupando espacio innecesario y aumentando la complejidad de gestión.

Cómo listar tablas y tamaños

Para tener una visión rápida desde consola:

wp db size --tables --human-readable

Este comando te da el tamaño estimado de cada tabla y te ayuda a identificar las más pesadas. También puedes usar SQL directamente²:

SELECT 
    table_name AS 'Tabla', 
    ROUND((data_length + index_length) / 1024 / 1024, 2) AS 'Tamaño (MB)',
    ROUND((data_free) / 1024 / 1024, 2) AS 'Overhead (MB)'
FROM information_schema.TABLES
WHERE table_schema = 'nombre_de_tu_bd'
ORDER BY (data_length + index_length) DESC;

¿Qué hacer con las tablas huérfanas?

Antes de borrar cualquier tabla, asegúrate de que no esté en uso:

1. Haz un backup completo.
2. Compara con los plugins activos: wp plugin list --status=active > plugins-activos.txt
3. Identifica qué tabla pertenece a qué plugin (busca por prefijos o revisa documentación).

Si confirmas que una tabla no pertenece a ningún plugin activo, puedes archivarla (renombrándola con _old):

RENAME TABLE wp_tabla_sospechosa TO wp_tabla_sospechosa_old;

Después de unos días de monitorización y comprobar que la tabla no es usada por ningún plugin o por el tema, podrás eliminarla:

DROP TABLE wp_tabla_sospechosa_old;

Herramientas visuales para complementar

Aunque WP-CLI y SQL son potentes, si prefieres una interfaz visual, puedes usar:

• Adminer³ o phpMyAdmin⁴: gestión directa desde navegador.
• Plugins como WP DB Cleaner⁵: identifican automáticamente tablas de plugins desactivados.

Limpiezas esenciales que todos deberíamos hacer

Una instalación estándar de WordPress acumula, con el uso, mucha información que deja de ser útil: revisiones infinitas, entradas en papelera, transients caducados, comentarios de spam y más. Estas limpiezas pueden hacerse de forma segura en casi cualquier proyecto y aportan mejoras inmediatas en rendimiento y orden interno.

A continuación veremos las más efectivas y cómo realizarlas manualmente, con WP-CLI o directamente en SQL.

1. Revisiones de entradas y páginas

Cada vez que guardas un post, WordPress genera una nueva revisión. Si el contenido cambia a menudo, puedes acabar con cientos de copias innecesarias.

Eliminar todas las revisiones:

DELETE FROM wp_posts WHERE post_type = 'revision';

Limitar futuras revisiones (en wp-config.php):

define('WP_POST_REVISIONS', 5); // guarda solo 5 revisiones por post

La extensión de navegador Best WordPress Tools⁶ nos puede ayudar a configurar esta y otras opciones en nuestra instalación de WordPress.

2. Entradas en papelera y borradores automáticos

Post, páginas y adjuntos que han sido eliminados no desaparecen hasta que vacíes la papelera. Lo mismo ocurre con borradores que nunca se publicaron.

Eliminar papelera y borradores caducados:

DELETE FROM wp_posts WHERE post_status IN ('trash', 'auto-draft');

3. Comentarios spam y en papelera

Si tienes comentarios abiertos, es habitual acumular muchos que nunca se moderaron o que están marcados como spam.

Mostramos los comentarios no aprobados (WP-CLI):

wp comment list --status=hold --fields=ID,comment_date,comment_author

Eliminar comentarios no aprobados y en papelera (SQL):

DELETE FROM wp_comments WHERE comment_approved = 'spam';
DELETE FROM wp_comments WHERE comment_approved = 'trash';

WP-CLI equivalente:

wp comment delete $(wp comment list --status=spam --format=ids)
wp comment delete $(wp comment list --status=trash --format=ids)

Desde WP CLI también podemos aprobar un comentario sabiendo su ID o borrarlo (o hacerlo con todos los pendientes):

wp comment approve <comment_ID>
wp comment delete <comment_ID>
wp comment approve $(wp comment list --status=hold --format=ids)
wp comment delete $(wp comment list --status=hold --format=ids)

4. Transients caducados

WordPress y muchos plugins usan transients para almacenar información temporal en wp_options. Con el tiempo, muchos caducan y no se eliminan.

Ver número de transients caducados (SQL):

SELECT COUNT(*) AS total_transients_caducados
FROM wp_options
WHERE option_name LIKE '%<em>transient_timeout</em>%'
AND option_value < UNIX_TIMESTAMP();

Eliminar transients caducados (SQL):

DELETE a, b
FROM wp_options a
INNER JOIN wp_options b
    ON a.option_name = REPLACE(b.option_name, '_timeout', '')
WHERE b.option_name LIKE '%_transient_timeout_%'
AND b.option_value < UNIX_TIMESTAMP();

WP-CLI equivalente:

wp transient delete --expired

⚠️ Solo usa --all en lugar de --expired si sabes lo que estás haciendo. Algunos transients activos podrían afectar a plugins o cachés de objetos.

5. Opciones huérfanas o temporales

Algunos plugins dejan entradas en wp_options que ya no se usan, pero siguen con autoload = on o autoload = yes, cargándose en cada carga del sitio⁷.

Ver las más pesadas:

SELECT 
    option_name, 
    ROUND(LENGTH(option_value) / 1024, 2) AS size_kb
FROM wp_options 
WHERE autoload IN ('yes', 'on')
ORDER BY size_kb DESC
LIMIT 20;

Puedes revisar y eliminar manualmente desde WP-CLI:

wp option delete nombre_opcion

O bien marcarlas como autoload = off⁸ si no estás seguro de eliminarlas:

UPDATE wp_options SET autoload = 'off' WHERE option_name = 'nombre_opcion';

Estas limpiezas pueden ser parte de un cron semanal en servidores donde gestiones múltiples sitios. Pero antes de automatizar nada, asegúrate de hacer backups y testear los efectos.

Limpiezas avanzadas para proyectos más complejos

En sitios más grandes o con mucho tiempo en producción, las limpiezas básicas no son suficientes. Especialmente si hablamos de tiendas online, LMS, membresías o instalaciones con muchos plugins históricos, necesitamos ir más allá. Aquí entramos en el terreno de la optimización avanzada: autoload, tablas huérfanas, índices y más.

1. Opciones con autoload problemático

La tabla wp_options puede contener miles de entradas con autoload = on (o autoload = 'yes'), lo que significa que WordPress las carga en cada visita, incluso si ya no son necesarias. En sitios con muchos plugins instalados y desinstalados, esta tabla puede volverse una fuente de cuellos de botella.

Ver el peso total de opciones autoload:

SELECT 
    ROUND(SUM(LENGTH(option_value)) / 1024, 2) AS total_size_kb
FROM wp_options
WHERE autoload IN ('yes', 'on');

Listar las más grandes:

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload IN ('yes', 'on')
ORDER BY size DESC
LIMIT 30;

Revisa especialmente opciones con nombres de plugins ya desactivados. Puedes mover su autoload a no temporalmente:

UPDATE wp_options SET autoload = 'off' WHERE option_name = 'nombre_opcion';

2. Tablas de plugins desinstalados

Muchos plugins crean tablas que no eliminan al desinstalarse. Esto deja «escombros digitales» en tu base de datos que consumen espacio y generan ruido.

Detectar tablas huérfanas:

1. Lista de plugins activos:

wp plugin list --status=active

2. Lista todas las tablas:

wp db tables --all-tables

3. Busca tablas con prefijos no asociados a los plugins actuales.

Si confirmas que no se usan, puedes renombrarlas antes de borrarlas:

RENAME TABLE wp_plugin_viejo TO wp_plugin_viejo_backup;

Y tras unos días de observación:

DROP TABLE wp_plugin_viejo_backup;

3. Revisión de índices y overhead

Cada vez que haces operaciones de borrado masivo, las tablas pueden acumular «overhead»: espacio reservado pero no reutilizado. Además, algunas tablas crecen sin índices óptimos.

Ver tablas con overhead (desde phpMyAdmin):

SHOW TABLE STATUS WHERE Data_free > 0;

Esto indica qué tablas pueden beneficiarse de un OPTIMIZE TABLE:

Optimizar (desde WP CLI):

wp db optimize

O desde SQL:

OPTIMIZE TABLE wp_postmeta;

4. Plugins que generan mucho contenido residual

Algunos plugins dejan un rastro muy pesado si no se controlan:

• WooCommerce: pedidos antiguos, sesiones, historial de carritos abandonados.
• Formularios (Gravity Forms, WPForms…): entradas que no se borran.
• Plugins de caché o SEO: entradas temporales o estadísticas.

Revisar tablas específicas:

SELECT COUNT(*) FROM wp_wc_order_stats;  -- WooCommerce
SELECT COUNT(*) FROM wp_gf_entry;         -- Gravity Forms

Si esos datos no se usan, evalúa exportarlos y limpiarlos.

Para los pedidos de WooCommerce hay varios plugins que permiten separar o exportar de la tabla principal los pedidos antiguos, como por ejemplo Advanced Order Export For WooCommerce.

También podemos eliminar manualmente esas entradas en la base de datos, previa exportación de la tabla.

Con WP CLI exportaríamos la tabla wp_gf_entry con el siguiente comando:

wp db export backup_gf-entries.sql --tables=wp_gf_entry

Y podríamos borrar las entradas que no se hayan modificado en el último año con la siguiente sentencia SQL:

DELETE FROM wp_gf_entry WHERE date_updated < NOW() - INTERVAL 1 YEAR;

5. Cron jobs y entradas en wp_cron

WordPress ejecuta tareas programadas simulando un cron real. El problema es que plugins mal diseñados pueden generar cientos de tareas programadas sin ejecutar.

Ver eventos programados (WP-CLI):

wp cron event list

Eliminar eventos antiguos o innecesarios:

wp cron event delete nombre_evento

Este tipo de limpiezas requiere más precaución. Revisa, haz backups y documenta los cambios. La recompensa es grande: bases de datos mucho más ligeras, menor carga en back-end y mejor tiempo de respuesta.

Auditoría detallada con WP-CLI y SQL

Antes de borrar cualquier dato en tu base de datos, es esencial hacer una auditoría: inspeccionar qué tablas consumen más recursos, qué entradas están obsoletas y qué configuraciones están cargando cada vez que alguien visita tu web.

Una auditoría bien hecha evita errores, revela cuellos de botella y te permite optimizar con precisión.

Análisis general del tamaño de tablas

Comienza con una vista global del peso de cada tabla:

Desde WP-CLI:

wp db size --all-tables --human-readable

Consulta SQL equivalente:

SELECT table_name AS Tabla,
       ROUND(((data_length + index_length) / 1024 / 1024), 2) AS Tamaño_MB
FROM information_schema.TABLES
WHERE table_schema = 'nombre_basedatos'
ORDER BY Tamaño_MB DESC;

Esto te ayuda a identificar qué tablas son candidatas para limpieza o revisión (ej. wp_postmeta, wp_options, tablas de WooCommerce…)

Si estamos utilizando phpMyAdmin, podemos hacer clic en la columna Tamaño para ordenar las tablas por tamaño en orden ascendente o descendente.

Buscar revisiones, borradores y entradas en papelera

Desde WP-CLI:

wp post list --post_type=revision --format=count
wp post list --post_status=trash --format=count
wp post list --post_status=auto-draft --format=count

Desde SQL:

SELECT post_status, COUNT(*)
FROM wp_posts
WHERE post_status IN ('revision', 'auto-draft', 'trash')
GROUP BY post_status;

Transients acumulados

Listar cantidad total de transients:

SELECT COUNT(*) FROM wp_options WHERE option_name LIKE '%transient%';

Ver su tamaño:

SELECT 
    option_name, 
    ROUND(LENGTH(option_value) / 1024, 2) AS size_kb
FROM wp_options
WHERE option_name LIKE '%transient%'
ORDER BY size_kb DESC;

Ver los caducados:

SELECT * FROM wp_options
WHERE option_name LIKE '%transient_timeout%'
AND option_value < UNIX_TIMESTAMP();

Auditoría de metadatos huérfanos

Postmeta sin post asociado:

SELECT COUNT(*) FROM wp_postmeta
WHERE post_id NOT IN (SELECT ID FROM wp_posts);

Usermeta sin usuario existente:

SELECT COUNT(*) FROM wp_usermeta
WHERE user_id NOT IN (SELECT ID FROM wp_users);

Estos datos suelen quedarse tras borrar entradas o usuarios sin una limpieza posterior.

Una buena auditoría⁹ siempre debe ir antes de cualquier proceso de optimización. Detectar primero los datos obsoletos, pesados o inútiles te permite tomar decisiones más seguras y efectivas, especialmente cuando gestionas varios sitios o un WordPress con muchos años de uso.

Cómo afecta la base de datos al rendimiento real y al TTFB

Una base de datos mal optimizada no solo ocupa más espacio: afecta directamente al tiempo de respuesta del servidor y, por tanto, al TTFB (Time To First Byte). Este indicador es clave tanto para SEO como para experiencia de usuario, especialmente en sitios donde el contenido se genera dinámicamente en cada petición.

Qué es el TTFB y por qué importa

El TTFB mide el tiempo que pasa desde que un navegador solicita una página hasta que recibe el primer byte desde el servidor. Si bien parte de este tiempo depende de la red y el servidor, otra parte clave depende de lo rápido que WordPress puede generar esa primera respuesta.

Factores que afectan al TTFB en WordPress:

• Tiempo que tarda en cargar WordPress y sus dependencias
• Tiempo que tardan los hooks y plugins en ejecutarse
• Tiempo de consulta a la base de datos

Una base de datos lenta o sobrecargada puede retrasar cada uno de esos pasos.

Consultas lentas: el enemigo oculto

Cuando la base de datos contiene demasiadas entradas en wp_options con autoload, miles de filas en postmeta, o tablas sin índices adecuados, WordPress necesita más tiempo para consultar y procesar los datos. Esto genera:

• Retrasos en el back-end (carga lenta del panel)
• Mayor uso de CPU en el servidor
• Respuestas lentas al frontend (TTFB elevado)

Cómo detectar si la base de datos ralentiza tu sitio

1. Medir el TTFB directamente

Puedes usar herramientas como:

• GTmetrix
• WebPageTest
• Chrome DevTools → pestaña Network

Un TTFB sano suele estar por debajo de los 200–400 ms en sitios con caché. Si supera los 600–800 ms constantemente, hay margen de mejora.

2. Activar WP_DEBUG y registrar queries lentas

En tu wp-config.php:

define( 'SAVEQUERIES', true );
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );

Luego analiza el archivo wp-content/debug.log para ver qué consultas están tardando más de lo debido.

Las consultas de la base de datos se almacenan en la variable global $wpdb->queries que podemos ver con:

global $wpdb;
print_r( $wpdb->queries );

Es muy importante no dejar estas opciones en producción porque afectan al rendimiento, debug.log puede crecer mucho y pueden exponer información sensible.

3. Usar Query Monitor

Este plugin te permite ver en tiempo real:

• Qué consultas se ejecutan en cada carga
• Cuánto tarda cada una
• Qué plugin o función las dispara

Ideal para detectar consultas innecesarias o mal optimizadas.

También se trata de un plugin a tener activado en entornos de desarrollo o cuando estamos buscando un problema, no tenerlo activado continuamente.

Casos comunes donde la base de datos eleva el TTFB

• Plugins que cargan muchas opciones con autoload sin control
• Temas que hacen múltiples queries complejas en la home
• WooCommerce con miles de pedidos sin paginar ni archivar¹⁰
• Plugins de estadísticas o seguridad que escriben en cada carga

Cómo reducir el impacto

• Limpiar y limitar las opciones autoload
• Revisar índices en postmeta, usermeta, tablas grandes
• Usar caché de objetos (Redis, Memcached) bien configurado
• Hacer limpieza de metadatos huérfanos y transients

Recordemos: WordPress no es lento por sí mismo. La lentitud suele venir por acumulación de datos innecesarios, plugins mal diseñados y falta de mantenimiento. Una base de datos optimizada reduce el trabajo del servidor en cada petición, mejora el TTFB y, con ello, todas las métricas de rendimiento percibido.

Herramientas para auditar y limpiar con seguridad

Llegados a este punto, ya conoces qué limpiar, pero igual de importante es saber cómo hacerlo de forma segura, repetible y eficiente. Tanto si prefieres trabajar desde consola como si gestionas webs desde un panel visual, hay herramientas que te ayudan a mantener la base de datos bajo control.

A continuación se listan las principales opciones divididas por tipo de uso.

Herramientas visuales

1. phpMyAdmin, Adminer o AdminNeo

Los tres permiten inspeccionar el contenido de cada tabla, buscar por condiciones, hacer copias de seguridad y ejecutar consultas SQL directamente desde el navegador. Son ideales para revisar antes de eliminar datos:

• Buscar revisiones o autoloads grandes
• Exportar tablas concretas
• Analizar relaciones entre datos

Adminer y AdminNeo suelen ser más ligeros y portables, perfectos para servidores sin interfaz gráfica.

2. Plugins especializados

• Advanced Database Cleaner: permite eliminar revisiones, transients, comentarios spam, tareas cron antiguas, etc. También identifica tablas huérfanas y permite programar limpiezas.
• WP-Optimize: además de limpiar, puede optimizar tablas, controlar revisiones y eliminar datos temporales.
• Plugins Garbage Collector (no siempre actualizado): identifica qué tablas no están asociadas a plugins activos.

⚠️ Aunque estos plugins son útiles, evita activarlos de forma permanente en producción. Úsalos y desactívalos tras su uso.

WP-CLI: el enfoque profesional

WP-CLI te permite automatizar tareas y ejecutar limpiezas desde terminal. Algunas ventajas:

• Puedes integrarlo en cron jobs
• Es mucho más rápido que plugins o la interfaz gráfica
• Ideal para scripts de mantenimiento masivo

Comandos útiles:

wp transient delete --expired
wp comment delete $(wp comment list --status=spam --format=ids)
wp db optimize
wp option list --autoload=on --fields=option_name,option_value --format=csv

También puedes ejecutar sentencias SQL directamente:

wp db query "DELETE FROM wp_posts WHERE post_type = 'revision';"

Scripts Bash personalizados

Si gestionas varios sitios o trabajas con servidores VPS, puedes preparar scripts automatizados. Ejemplo básico:

#!/bin/bash

wp db export backups/db-$(date +%F).sql
wp transient delete --expired
wp db optimize

Esto puede ejecutarse con cron semanalmente:

0 3 * * 1 /home/usuario/scripts/limpieza-wp.sh

Respaldos antes de actuar

Antes de usar cualquier herramienta, realiza un backup completo de la base de datos. Puedes hacerlo con WP-CLI:

wp db export backups/previo-limpieza-$(date +%F).sql

O directamente desde phpMyAdmin si prefieres la interfaz gráfica.

Trabajar con seguridad significa siempre tener un punto de retorno ante cualquier error inesperado.

Una vez que dominas las herramientas, puedes empezar a crear rutinas periódicas de limpieza e integrarlas en tu mantenimiento mensual o trimestral.

Automatización y buenas prácticas

Limpiar y optimizar una base de datos no debe ser una acción puntual, sino parte de una estrategia de mantenimiento continuo. Automatizar estas tareas no solo ahorra tiempo, también garantiza que el rendimiento de WordPress no se degrade con el uso. En este capítulo veremos cómo automatizar limpiezas de forma segura y qué buenas prácticas seguir para evitar problemas.

Automatización con cron + WP-CLI

Si gestionas tu propio servidor o tienes acceso por SSH, puedes automatizar limpiezas con scripts Bash y WP-CLI. Ejemplo:

Script de limpieza (limpieza.sh)

#!/bin/bash
FECHA=$(date +%F)
DIR_BACKUP="/home/backups/miweb"

mkdir -p "$DIR_BACKUP"
wp db export "$DIR_BACKUP/db-$FECHA.sql"
wp transient delete --expired
wp comment delete $(wp comment list --status=spam --format=ids)
wp db optimize

Programar con cron (ejecución semanal):

0 3 * * 1 /bin/bash /ruta/limpieza.sh

Puedes añadir notificaciones por email o logs si deseas seguimiento detallado.

Plugins con programación de tareas integrada

Plugins como Advanced Database Cleaner Pro permiten programar tareas específicas (eliminar transients, revisiones, spam, etc.) de forma periódica. Esta es una opción cómoda para quienes no usan línea de comandos, pero se debe revisar cada cierto tiempo.

Asegúrate de:

• Hacer una copia de seguridad antes de ejecutar limpiezas automáticas.
• Desactivar tareas innecesarias si tu sitio cambia de estructura o plugins.

Separar backups y limpiezas

Nunca hagas limpieza sin automatizar también un backup previo. Algunos consejos:

• Usa wp db export para copias rápidas diarias o semanales.
• En sitios grandes, copia por partes o usa mysqldump.
• Sube los backups a almacenamiento externo (Dropbox, S3, FTP…).

Backup de la base de datos con mysqldump (si tu BD ocupa más de 2 GB aproximadamente).

mysqldump -u usuario -p basedatos > backup-$(date +%F).sql

# con compresión
mysqldump -u usuario -p basedatos | gzip > /home/backups/backup-$(date +%F).sql.gz

Ejemplo backup a servidor remoto vía SCP:

scp /home/backups/backup-2025-11-04.sql usuario@servidor:/ruta/backups/

Checklist de buenas prácticas

• Revisa manualmente antes de automatizar.
• Realiza copias completas y programadas.
• Usa herramientas que entiendas (no automatices sin saber qué borra cada acción).
• Documenta tus limpiezas, sobre todo si gestionas sitios de clientes.
• Mantén separados entornos de pruebas y producción.

Con estas prácticas estableces una rutina de mantenimiento proactiva, sin depender de intervenciones manuales urgentes cuando algo empieza a fallar.

Casos especiales y recomendaciones según tipo de sitio

No todos los WordPress son iguales. Un blog personal, una tienda WooCommerce o un multisite tienen estructuras y necesidades muy diferentes. Aquí revisamos qué tener en cuenta según el tipo de instalación y los plugins involucrados.

WooCommerce: cuidado con pedidos, sesiones y estadísticas

WooCommerce añade muchas tablas y genera gran cantidad de datos dinámicos:

• Pedidos (wp_wc_orders, wp_postmeta, wp_woocommerce_order_items)
• Sesiones (wp_woocommerce_sessions)
• Historial de carritos, cupones caducados, logs de actividad

Recomendaciones específicas:

• No borres entradas antiguas de wp_posts sin comprobar si son pedidos.
• Usa filtros en wp_postmeta para limpiar solo metadatos huérfanos:

DELETE pm FROM wp_postmeta pm
LEFT JOIN wp_posts wp ON wp.ID = pm.post_id
WHERE wp.ID IS NULL;

• Limpia sesiones caducadas:

wp transient delete --expired

Algunos plugins como WooCommerce Cleaner o WP-Optimize en modo avanzado permiten limpiar pedidos cancelados, devoluciones antiguas o sesiones inactivas.

Sitios con muchos formularios

Plugins como Gravity Forms, WPForms, Ninja Forms generan entradas internas por cada formulario enviado. En algunos casos estas entradas nunca se eliminan.

Qué revisar:

• Tablas como wp_gf_entry, wp_gf_entry_meta, wp_nf3_actions
• Formularios de prueba o spam acumulado

Revisa también transients o entradas en wp_options si se usan formularios con lógica condicional o cálculos temporales.

Sitios con membresías o LMS

Los plugins de membresía (MemberPress, Paid Memberships Pro) o cursos online (LearnDash, TutorLMS) generan metadatos complejos:

• Control de progreso, certificados, logs, accesos, historial de cursos
• Usuarios con muchos datos en usermeta

Sugerencias:

• Revisa la tabla wp_usermeta buscando entradas huérfanas:

DELETE FROM wp_usermeta WHERE user_id NOT IN (SELECT ID FROM wp_users);

• No elimines datos sin confirmar si afectan al acceso de los usuarios
• Haz pruebas en staging antes de optimizar un entorno de producción

Instalaciones multisite

Cada sitio del multisite tiene su propio conjunto de tablas, lo que multiplica por N la cantidad de datos:

• wp_2_posts, wp_3_options, wp_4_usermeta, etc.

Consejos clave:

• No hagas limpiezas masivas sin filtrar por blog ID
• Usa --url en WP-CLI para limpiar por subsitio:

wp --url=subsite.ejemplo.com transient delete --expired

• Controla el crecimiento global: los plugins activos en red afectan a todos los sitios

Sitios antiguos con legado técnico

Muchos WordPress llevan años online y han pasado por múltiples desarrolladores, plugins y temas.

Qué revisar con atención:

• Tablas de plugins desaparecidos
• Opciones en wp_options que ya no usa nadie
• Metadatos no documentados que pueden romper funciones si se eliminan sin más

En estos casos conviene ir más despacio, revisar logs de errores, habilitar WP_DEBUG y depurar desde staging antes de borrar definitivamente.

Cada tipo de instalación tiene su complejidad. Entenderla y adaptar la limpieza a sus particularidades es clave para no romper nada mientras optimizas.

Consejos finales, errores comunes y buenas prácticas

La optimización de base de datos es una de esas tareas que, cuando se hace bien, pasa desapercibida. Pero cuando se ignora o se ejecuta mal, puede tener consecuencias graves. Por eso conviene cerrar este recorrido con un resumen práctico y algunas advertencias importantes.

Lo que NO deberías hacer

Borrar sin backup

Nunca ejecutes sentencias SQL destructivas sin un backup previo. Usa siempre wp db export o una copia desde tu panel de hosting antes de eliminar datos.

Limpiar por costumbre sin analizar

No automatices la limpieza de revisiones, metadatos o transients si no sabes qué plugins las están usando. Algunos datos aparentemente inútiles pueden ser funcionales.

Usar plugins sin entenderlos

Muchos plugins de limpieza tienen opciones agresivas que eliminan datos importantes sin preguntar. Léete la documentación y, si es posible, haz pruebas en staging antes.

Pasar por alto autoload

Aunque no ocupen mucho espacio en la base de datos, las entradas autoload = on (y autoload = 'yes') cargan en cada petición, lo que impacta directamente en el rendimiento del frontend y del admin.

Checklist final de optimización segura

• Conocer la estructura de tu base de datos (y tablas añadidas por plugins).
• Usar wp db size --all-tables --human-readable para identificar tablas pesadas.
• Limpiar revisiones, comentarios de spam y transients caducados.
• Controlar el tamaño y número de entradas autoload en wp_options.
• Automatizar tareas con WP-CLI y scripts con cron.
• Auditar plugins antiguos y eliminar restos de los desinstalados.
• Revisar usermeta y postmeta por entradas huérfanas.
• Evitar limpiezas destructivas en producción sin testeo previo.

Recomendaciones extra

• Prueba antes de automatizar: configura todo en entorno de pruebas y documenta bien el proceso.
• Registra las limpiezas importantes: si gestionas varios sitios o clientes, documentar qué limpiaste y por qué puede ahorrarte muchos dolores de cabeza.
• Integra en tu ciclo de mantenimiento: una base de datos optimizada no es algo que se hace una vez. Programa revisiones trimestrales o mensuales, según el tipo de proyecto.
• Educa a tu cliente o equipo: si otros usuarios tienen acceso al back-end, ayúdales a entender por qué mantener limpio el sistema importa (por ejemplo, controlando las revisiones o desinstalando plugins que ya no se usan).

Optimizar una base de datos no es una tarea decorativa: es una forma tangible de mejorar rendimiento, seguridad y escalabilidad de un sitio WordPress. Con las herramientas y prácticas adecuadas, puedes mantener tu instalación saneada y lista para crecer sin arrastrar lastres invisibles.

1. En todo el artículo asumiremos el prefijo wp_ por lo que si el prefijo de tus tablas es diferente, deberás adaptarlo al que corresponda. ↩︎
2. Cambia nombre_de_tu_bd por el nombre de base de datos. ↩︎
3. Adminer es un gestor de bases de datos en web que funciona con un único archivo PHP https://www.adminer.org/en/ ↩︎
4. Completo gestor de bases de datos desde una interfaz gráfica en web https://www.phpmyadmin.net/ ↩︎
5. https://es.wordpress.org/plugins/advanced-database-cleaner/ ↩︎
6. https://tabernawp.com/en/best-wordpress-tools ↩︎
7. Autoload On era el comportamiento por defecto hasta la versión 6.6. En el ticket oficial del core (Ticket #42441) se detalla que el cambio responde a que muchos plugins han estado auto-cargando opciones grandes innecesariamente. ↩︎
8. Hasta la versión 6.6 era no, ahora se ha cambiado a off aunque funcionen ambas opciones por compatibilidad. ↩︎
9. Artículo Cómo realizar una auditoría WPO efectiva para tu proyecto https://wordpress.com/es/blog/2025/07/21/como-realizar-una-auditoria-wpo-efectiva-para-tu-proyecto/ ↩︎
10. Aunque esto ha mejorado mucho con HPOS al tener ahora sus propias tablas https://woocommerce.com/document/high-performance-order-storage/ ↩︎