Limitando el Historial de Revisiones de WordPress

Mantener un rendimiento óptimo en un sitio de alta producción requiere prestar atención a la higiene de los datos almacenados. De forma nativa, el sistema gestiona las revisiones de WordPress sin un límite predefinido, lo que significa que cada guardado genera una fila nueva en la base de datos. En sitios con años de antigüedad, esto puede suponer que el 90% del contenido de la tabla principal sean copias obsoletas que ralentizan las consultas y aumentan innecesariamente el peso de los backups.

#El Impacto de las Revisiones en el Rendimiento

Cada vez que haces clic en «Guardar borrador» o actualizas una entrada, WordPress crea una fila en wp_posts con el post_type definido como ‘revision’. Aunque esto es útil para revertir cambios accidentales, la falta de control convierte la base de datos en un almacén de basura digital. Una tabla inflada aumenta el tiempo de respuesta del servidor al realizar búsquedas o indexaciones, afectando directamente al TTFB (Time to First Byte).

#Tutorial: Cómo Tomar el Control del Historial

Tiempo estimado: 10 minutos

#Requisitos Previos

• Acceso al archivo wp-config.php mediante FTP o Administrador de Archivos.
• Acceso a phpMyAdmin o una herramienta similar para ejecutar SQL.
• Copia de seguridad completa de la base de datos (Obligatorio).

#Paso 1: Limitar Revisiones Futuras

Para evitar que el problema vuelva a ocurrir, debemos definir un límite estricto en el archivo de configuración de nuestro sitio.

// Limitar a un máximo de 5 revisiones por entrada
define( 'WP_POST_REVISIONS', 5 );

// Alternativamente, para deshabilitarlas por completo (no recomendado)
// define( 'WP_POST_REVISIONS', false );

#Paso 2: Purgar Revisiones Existentes

Definir el límite no elimina las miles de revisiones que ya tienes. Para eso, utilizaremos una consulta SQL directa.

DELETE FROM wp_posts WHERE post_type = "revision";

#Caso Real: De 800MB a 120MB en la Base de Datos

Hace poco trabajé en un portal de noticias que publicaba 30 artículos diarios. El equipo de redacción solía guardar borradores cada dos minutos. Tras tres años, la base de datos pesaba casi 1GB y los backups diarios empezaban a fallar por timeout. Al analizar la tabla wp_posts, descubrimos que de 45.000 filas, solo 2.000 eran artículos reales; el resto eran revisiones. Tras aplicar el límite de 3 versiones y ejecutar la purga SQL, el tamaño de la base de datos bajó un 85% instantáneamente y la agilidad del panel de administración mejoró notablemente.

#Cuándo usar / Cuándo NO usar

• Cuándo usar: En cualquier instalación profesional de WordPress para prevenir el crecimiento descontrolado. Es vital en blogs de noticias y tiendas con descripciones dinámicas.
• Cuándo NO usar: En sitios de desarrollo legal o médico donde se necesite un rastro estricto de cada cambio realizado en el contenido para auditorías de cumplimiento.

#Pros y Contras

• Pros: Base de datos más ligera, backups más rápidos, mejor rendimiento de búsqueda y ahorro de espacio en el servidor.
• Contras: Menor margen de error para recuperar contenido borrado accidentalmente durante la redacción.

«Una base de datos limpia es el cimiento de una arquitectura web escalable. Ignorar las revisiones es dejar que WordPress se sabotee a sí mismo con el tiempo.»

Para aprender más sobre el mantenimiento de bases de datos, consulta la documentación oficial de Revisiones en WordPress o las mejores prácticas de optimización de tablas en MariaDB/MySQL.