Una limpieza “rápida” de WordPress puede reducir megabytes en la base de datos o dejar una web inestable si se borran revisiones y transients sin criterio. En agencias, el problema no es solo el espacio: es repetir el proceso en varias instalaciones, con distintos niveles de riesgo, permisos y necesidades de rollback.
Eliminar revisiones y transients de la base de datos de WordPress puede mejorar el rendimiento y reducir su tamaño, pero en agencias debe hacerse con checklist, backup, validación y rollback. La opción más segura suele ser un plugin fiable o un proceso SQL controlado, según el tipo de sitio, el volumen de datos y el nivel de automatización necesario.
Índice
Anuncio
Por qué se llena la base de datos y qué conviene borrar
La base de datos crece por uso normal; el problema no es tener datos, sino dejar que se acumulen sin control. La limpieza útil es la que quita peso sin romper funciones. En WordPress, esto afecta sobre todo a las revisiones de entradas, los autosaves, los transients y las opciones autoload, que pueden acumularse en sitios con mucho contenido, varios editores, lanzamientos frecuentes y muchas llamadas externas.
Revisiones de entradas y autosaves
Las revisiones guardan versiones antiguas de una entrada, como si un documento tuviera copias guardadas en un archivador. Sirven para volver atrás si un cambio sale mal, y WordPress puede crear una nueva copia cada vez que se guarda una entrada. En sitios con mucho contenido, una sola página puede acumular decenas o cientos de revisiones.
El error más frecuente es borrar sin mirar qué tipo de sitio se gestiona: un blog editorial con muchas correcciones no se trata igual que una web corporativa con cinco páginas fijas. Una revisión no pesa mucho por sí sola, pero miles de ellas ocupan espacio en wp_posts y empiezan a hacer más lenta la consulta de contenidos. Si una entrada tiene más revisiones que visitas útiles recibe al mes, ya sobra limpieza.
Transients, caché y restos temporales
Los transients son datos temporales, parecidos a notas que caducan solas, para no repetir cálculos. Si caducan bien, ayudan; si se quedan atascados, ensucian la tabla wp_options. Lo que omiten muchas guías es que no todos los transients son iguales: algunos sostienen cachés del propio WordPress, otros los crean plugins, temas o integraciones externas.
Muchos transients caducan solos, pero no siempre se eliminan con orden. Cuando un plugin falla, cambia de versión o se desactiva, puede dejar restos detrás. La basura temporal suele pesar más en webs con muchos plugins y muchas llamadas externas: cuantos más conectores, más restos. Según W3C, el rendimiento web depende mucho del trabajo que se evita en cada carga, no solo del servidor.
Autoload options sobredimensionadas
Las opciones autoload son un clásico en webs lentas. Cada una parece pequeña, pero juntas cargan mucho al inicio. El error típico es mirar solo el número de revisiones y olvidar wp_options. En sitios con varios editores, muchos lanzamientos y cambios frecuentes, este tipo de acumulación puede traducirse en consultas más pesadas, backups más lentos y un panel menos ágil.
Cómo limpiar sin romper nada
La limpieza segura empieza antes de borrar nada. Primero se protege el sitio. Luego se actúa. Y al final se comprueba que todo sigue vivo.
Backup y punto de restauración
Antes de tocar una sola tabla, hay que tener un backup reciente y probado. No vale una copia vieja ni una copia que nadie ha intentado restaurar.
El proceso correcto tarda entre 10 y 20 minutos si el sitio es pequeño. En webs grandes o tiendas, puede subir mucho más.
Si el backup falla, la limpieza no empieza. Así de simple.
Permisos y acceso de agencia
Quien limpia debe tener acceso suficiente para actuar y para volver atrás. Si el usuario solo puede instalar plugins, pero no restaurar copia, el riesgo sube.
En agencias, lo normal es revisar tres cosas: acceso al hosting, acceso a WordPress y acceso al sistema de copias. Si falta una, el plan queda cojo.
Un fallo muy habitual aparece cuando un técnico limpia desde una cuenta limitada y descubre tarde que no puede revertir nada. Ahí se pierde tiempo. Y confianza.
Pruebas en staging antes de producción
Staging es una copia de prueba del sitio. Sirve para ensayar sin tocar clientes reales. Es como probar una llave en una cerradura falsa antes de abrir la puerta de verdad.
Si el sitio tiene mucho tráfico o ventas, staging no es opcional. Permite ver si un plugin borra solo lo esperado o si toca algo más.
Como muestra la captura adjunta, la diferencia entre una limpieza prudente y una agresiva suele verse en el número de filas borradas y en las tablas afectadas.
Validación posterior de consultas
Después de limpiar, hay que comprobar que la web responde bien. No basta con ver que el panel carga.
Hay que revisar la home, una ficha de contenido, una ficha de producto, el carrito si existe y el formulario principal. También conviene mirar tiempos de carga y consultas lentas.
Un sitio puede parecer bien y seguir roto en un punto pequeño. Por eso la validación siempre va al final.
Anuncio
Qué método elegir según cada cliente
No todos los sitios piden el mismo método. Un blog simple permite más margen. Una tienda o una web con flujo editorial necesita más control.
Matriz de decisión por caso
Si el sitio es pequeño y no tiene ventas, un plugin fiable suele bastar. Si el sitio es grande, con mucho contenido o multisite, el control por SQL o WP-CLI suele dar más orden.
Si hay WooCommerce, membresías o reservas, la elección cambia. Ahí manda la seguridad de los datos activos, no la rapidez del borrado.
Una frase útil: cuanto más crítico es el sitio, más visible debe ser cada borrado.
Tabla comparativa de métodos
| Método | Ventaja | Riesgo | Mejor uso |
|---|---|---|---|
| Plugin de limpieza | Rápido y visible | Puede borrar más de lo esperado | Sitios pequeños y medianos |
| WP-CLI | Preciso y automatizable | Pide acceso técnico | Agencias con varios sitios |
| SQL manual | Muy controlado | Mayor riesgo si se equivoca la consulta | Técnicos con experiencia |
Pros y contras de cada opción
El plugin es la forma rápida. También es la más cómoda para equipos que gestionan muchas webs. El problema aparece si no se revisa qué tablas toca y qué tareas programa.
WP-CLI encaja bien cuando hay volumen y repetición. Permite usar el mismo proceso en varias instalaciones. El único freno real es que necesita acceso por terminal y cierta soltura.
SQL manual es la vía más fina. También es la que más castiga un despiste. Un espacio de más en una consulta puede salir caro.
Cuándo usar plugins de limpieza
Un plugin merece la pena cuando se quiere repetir el proceso con poca fricción. También cuando el cliente no necesita ver código ni comandos.
La mayoría de guías dicen que el plugin sirve para todo. Lo que no mencionan es que algunos crean tareas programadas que luego nadie controla. Eso deja basura nueva mientras se cree que la web ya está limpia.
Para agencias, el criterio práctico es este: usar plugin si se quiere velocidad operativa; usar SQL o WP-CLI si se necesita repetición exacta y auditoría.
Limpieza recurrente para varias webs
En una agencia, una limpieza aislada arregla un caso. Un sistema recurrente evita que el problema vuelva cada mes.
Checklist para agencias
Antes de cada limpieza, conviene revisar siempre lo mismo:
- Backup probado: copia reciente y restauración verificada.
- Staging disponible: prueba fuera de producción si el sitio es crítico.
- Permisos completos: acceso a WordPress, hosting y copias.
- Tipo de sitio: blog, corporativa, tienda o membresía.
- Volumen de datos: revisiones, transients y opciones autoload.
- Validación posterior: home, buscador, formularios y checkout.
Un checklist así ahorra discusiones con cliente. También evita saltarse pasos cuando el día va cargado.
Automatización con tareas programadas
La automatización tiene sentido cuando el patrón se repite. Limpiar cada semana o cada mes reduce trabajo manual en webs con mucha actividad.
Conviene programar solo tareas seguras. Nada de borrar por sistema sin revisar si una tienda depende de sesiones, caché o procesos de terceros.
La automatización funciona muy bien para revisiones antiguas y transients caducados. Falla cuando se confunde limpieza con poda a lo bruto.
Reglas por tipo de sitio
Una web corporativa suele aguantar limpiezas más simples. Un blog de alta producción necesita límites por revisión. Una tienda pide más cuidado con temporales y sesiones.
Matt Mullenweg y el equipo de WordPress han insistido muchas veces en mantener el sitio simple y sano, no cargado de restos innecesarios. Esa idea encaja bien aquí: menos ruido, más control.
Si el cliente publica mucho, la regla cambia. Mejor fijar límites de revisiones por entrada y revisar la base de datos cada cierto tiempo.
Control de permisos y auditoría
La limpieza deja rastro. Conviene registrar qué se borró, cuándo y con qué método.
En agencias, esto ayuda con clientes y con equipo interno. Si algo falla, la auditoría aclara rápido dónde estuvo el problema.
Un buen registro evita el clásico “nadie sabe quién tocó eso”. Y ese lío, cuando aparece, suele costar más que la limpieza.
Cuando una agencia gestiona varias webs, la limpieza no debería depender de decisiones improvisadas en cada proyecto. Funciona mejor un flujo estándar con revisión previa, backup, ejecución, validación y registro final, idealmente repetible con WP-CLI o con un proceso SQL controlado. Ese sistema permite programar tareas recurrentes para revisar revisiones de WordPress, transients y autoload sin esperar a que el sitio se ralentice.
Además, si cada intervención queda documentada con permisos, alcance y rollback, el equipo puede escalar el mantenimiento sin perder trazabilidad ni duplicar esfuerzos entre clientes.
Señales para decidir si merece la pena
No toda base de datos necesita limpieza. La decisión buena sale de datos, no de intuiciones.
Tamaño de tablas y crecimiento
Si wp_posts y wp_options crecen sin parar, ya hay señal. Lo normal es mirar su tamaño antes y después de cada limpieza.
Una tabla grande no es un problema por sí sola. Lo es cuando crece más rápido que el contenido útil.
Un crecimiento continuo durante semanas suele apuntar a revisiones, transients o autoload descontrolado.
Número de revisiones por entrada
Más de 10 o 15 revisiones por entrada ya suele ser demasiado en webs normales. En sitios de edición intensa, el límite puede subir, pero no conviene dejarlo libre.
El valor real depende del cliente. Una web de noticias tolera más revisiones que una landing que cambia poco.
La frase citable aquí es directa: si una entrada acumula muchas revisiones y nadie las consulta, sobra espacio y sobra peso.
Expiración de transients
Los transients válidos caducan y desaparecen. Los que se quedan vivos mucho tiempo suelen apuntar a un problema de plugin o de caché.
Si un sitio tiene miles de transients viejos, conviene revisar antes de borrar. Puede haber una integración que los regenere al momento.
Ese matiz marca la diferencia entre limpiar y pelearse con el sistema.
Métricas de WPO y consultas lentas
Cuando la limpieza merece la pena, suelen aparecer señales claras: backend más ágil, menos tiempo de espera y menos consultas pesadas.
No hace falta un panel complejo para verlo. A veces basta con medir antes y después la carga de una página de administración y una ficha de contenido.
Joost de Valk ha insistido en varias ocasiones en cuidar la base técnica antes de perseguir mejoras de SEO. Aquí encaja igual: primero quitar lastre, luego pedir más velocidad.
Relación con caché y tiempos de carga
La caché no arregla una base de datos mala. Solo la tapa durante un rato.
Si la web mejora mucho con caché pero sigue lenta en backend, la limpieza puede tener sentido. Si todo va bien y no hay síntomas, tocar por tocar no suma.
Los datos muestran que limpiar aporta más cuando ya hay señales de saturación. Si no las hay, el beneficio suele ser pequeño.
La señal más útil para decidir si una limpieza compensa no es solo el tamaño de la base de datos, sino su impacto en el rendimiento web. Si el backend tarda más en abrir, el editor responde con retraso, la tabla wp_options crece por autoload o el tiempo de respuesta del servidor empeora tras publicar contenido, ya hay un indicio claro. En SEO y WPO, una base de datos más ligera ayuda a reducir TTFB y a estabilizar el panel, algo especialmente visible en sitios con muchas consultas y en WooCommerce.
Medir antes y después con tiempos de carga, consultas lentas y peso de tablas da una referencia objetiva para decidir cuándo limpiar y cuándo no.
Anuncio
Casos especiales en WooCommerce y multisite
Hay sitios donde la limpieza necesita más cuidado. WooCommerce y WordPress Multisite entran de lleno en ese grupo.
Carritos, sesiones y pedidos
WooCommerce usa sesiones, caché y datos temporales para que el carrito funcione bien. Borrar sin mirar puede vaciar estados útiles o forzar recálculos molestos.
Un carrito roto no suele avisar con elegancia. El cliente solo ve que algo falla y abandona.
Por eso conviene revisar cada transient antes de tocarlo en una tienda activa.
Multisite y tablas compartidas
En Multisite, una limpieza mal planteada puede afectar varias webs a la vez. Eso cambia el nivel de riesgo.
No es lo mismo limpiar una instalación simple que una red con sitios, roles y configuraciones separadas. Aquí el acceso y el alcance importan mucho.
Si la red tiene varios clientes dentro, el registro de cambios debe ser más estricto.
Riesgos con hooks y procesos internos
Algunos plugins regeneran datos cuando detectan que faltan. Eso puede dejar la limpieza en un bucle.
El error típico aquí es borrar transients y pensar que el trabajo termina ahí. A veces el propio sitio vuelve a generarlos al instante.
Cuando eso pasa, el problema no era la basura. Era el plugin que la creaba sin control.
Cuándo escalar a soporte técnico
Si la web da errores tras la limpieza, si la tienda deja de calcular bien o si el tráfico cae raro, toca parar.
Escalar no es dramatizar. Es la forma normal de evitar daño mayor cuando el sitio depende de procesos internos delicados.
Un sitio que vende, reserva o mueve datos sensibles no se arregla solo con una pasada rápida.
En la práctica, no todos los plugins de limpieza de base de datos sirven para el mismo escenario. Para un blog pequeño, un plugin fiable con opciones claras para borrar revisiones de WordPress y transients puede ser suficiente; en una tienda WooCommerce, conviene priorizar herramientas que permitan excluir sesiones, carritos y tablas sensibles; y en una red multisite, el criterio debe ser aún más conservador. Lo ideal es comparar qué hace cada plugin sobre wp_posts, wp_options y la caché, si permite simulación antes del borrado, si registra cambios y si ofrece rollback.
En agencias, esa comparativa ahorra incidencias y evita elegir una herramienta “rápida” que luego no encaja con el tipo de cliente.
Preguntas frecuentes sobre mantenimiento WordPress
¿Es seguro borrar transients en WordPress?
Sí, si se hace con control. Los transients caducados suelen poder borrarse sin problema, pero algunos sostienen caché, sesiones o procesos temporales de plugins.
En una agencia, la regla práctica es probar primero en staging y revisar WooCommerce, membresías o reservas antes de tocar producción. Si un plugin regenera esos datos al momento, la limpieza no se quedará estable.
¿Cada cuánto conviene limpiar la base de datos?
Depende del tipo de sitio. Una corporativa con pocos cambios puede revisarse cada pocos meses, mientras que una tienda o un medio con mucha edición pide más frecuencia.
Lo sensato es limpiar cuando haya señales claras: muchas revisiones, tablas grandes, transients viejos o backend lento. Limpiar por calendario sin mirar el estado real suele gastar tiempo de más.
¿Qué plugin usar para optimización de base de
El mejor plugin es el que enseña bien qué borra y permite revisar antes de ejecutar. Para agencias, conviene uno con opciones claras, respaldo de seguridad y control sobre tareas programadas.
No hay uno válido para todo. En sitios simples, un plugin cómodo ayuda. En proyectos críticos, WP-CLI o SQL controlado suelen dar más precisión.
¿Cómo afecta la limpieza al rendimiento y al SEO?
Afecta de forma indirecta, pero real. Una base de datos más ligera suele responder antes, y eso mejora el trabajo del panel, del editor y de las páginas con carga pesada.
En SEO, la mejora suele llegar por velocidad, mejor experiencia y menos fricción técnica. No mueve rankings por arte de magia, pero sí quita obstáculos que frenan el sitio.
¿Se pueden borrar revisiones sin perder contenido?
Sí, si primero se revisa qué páginas de verdad necesitan histórico. Las revisiones antiguas ayudan en editoriales y en sitios con correcciones frecuentes, pero en muchas páginas corporativas sobran.
La mejor práctica es fijar un límite por tipo de entrada. Así se conserva margen de recuperación sin arrastrar un archivo inmenso de versiones viejas.
¿Qué pasa si borro transients que WooCommerce usa?
Puede fallar el carrito, retrasarse el cálculo de precios o reiniciarse alguna sesión temporal. No siempre ocurre, pero el riesgo existe si se borra sin distinguir qué transient hace qué.
Por eso WooCommerce exige más cuidado que una web normal. Primero se identifica el origen, luego se limpia y después se comprueba compra, carrito y checkout.
¿Se puede automatizar esta limpieza en varias webs?
Sí, y suele ser la mejor forma de trabajar en una agencia. Lo normal es fijar reglas distintas por tipo de sitio y programar solo lo que se entiende bien.
La automatización ahorra tiempo cuando el patrón se repite. Si no hay reglas claras, solo automatiza el error.
Qué hacer ahora
La ruta sensata es corta. Primero se mide. Luego se limpia. Y al final se comprueba que todo sigue estable.
Si el sitio tiene pocas señales de saturación, no se toca. Si la base de datos crece, el backend se arrastra o hay revisiones y transients de sobra, la limpieza sí compensa.
En agencias, el mejor resultado suele venir de un proceso fijo: backup, staging, limpieza controlada, validación y registro. Eso da velocidad sin jugar con fuego.
La limpieza correcta no es la más agresiva. Es la que deja la web más ligera y el cliente más tranquilo.
- Por qué tu WordPress falla en Black Friday y pierdes ventas
- Consigue backups diarios, SLA 24h y mantenimiento WordPress
Josu Barrios
Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.