Cómo usar y optimizar las revisiones en WordPress

Actualización (29/08/2026): WordPress 7.1 ya está disponible y trae mejoras clave al sistema de revisiones visuales que revolucionó la versión 7.0. Te resumimos lo más importante.

WordPress 7.1 (19/08/2026): Ahora podés compartir enlaces directos a revisiones individuales y navegar el historial de ediciones con un selector rediseñado, facilitando la colaboración en equipo.
Revisiones visuales nativas: Desde WordPress 7, el editor de bloques compara visualmente los cambios renderizados, reemplazando el viejo diff de texto plano para auditar ediciones es mucho más intuitivo.
Limpiá revisiones viejas: Si tenés sitios con mucho historial, usá plugins como WP-Optimize o consultas SQL directas a la base para borrar revisiones innecesarias y ganar rendimiento (fuente: Axarnet, 06/08/2026).

Actualización (15/08/2026): WordPress 7 revolucionó las revisiones con cambios importantes para editores.

Revisiones visuales integradas en WordPress 7: El editor de bloques ahora muestra comparación visual de bloques renderizados directamente sin pantallas separadas, reemplazando el diff de texto plano tradicional.
WordPress 7.1 llega el 19 de agosto: Nuevos refinamientos al sistema de revisiones visuales mejorarán aún más la experiencia de colaboración y auditoría de cambios.

Actualizado el 06/08/2026 — Este artículo fue actualizado con información reciente y secciones nuevas.

Las revisiones en WordPress son copias automáticas del contenido que se guardan cada vez que editás una entrada, página o tipo de contenido personalizado. Funcionan como un historial de cambios que te permite recuperar versiones anteriores si cometés un error, colaborás en equipo o necesitás auditar quién editó qué y cuándo. Sin embargo, acumular demasiadas revisiones puede inflar la base de datos y ralentizar tu sitio si no las gestionás adecuadamente.

Las revisiones son esenciales para la recuperación de contenido y la colaboración editorial. WordPress guarda una revisión completa cada vez que clickeás «Guardar borrador» o «Actualizar», más autoguardados parciales cada 60 segundos mientras escribís. Esto crea un registro inmutable de todos los cambios. Cada revisión incluye metadatos como el autor, fecha y hora exacta. El sistema funciona automáticamente sin que vos tengas que hacer nada: está ahí desde la versión 2.6 de WordPress. La comparación entre versiones te muestra en verde lo que se agregó y en rojo lo que se borró. El costo es que sin límites configurados, la tabla de posts crece indefinidamente.

En 30 segundos

Las revisiones son automáticas: WordPress guarda una copia cada vez que actualizás contenido sin que vos hagas nada.
Límita la cantidad en wp-config.php: Agregá define('WP_POST_REVISIONS', 5); para mantener solo las últimas 5 versiones de cada post.
Limpiar es seguro: Podés borrar revisiones antiguas con WP-CLI o plugins sin afectar el contenido publicado.
El autoguardado drena recursos: Si tenés muchos editores simultáneos, subí el intervalo de autoguardado con define('AUTOSAVE_INTERVAL', 300); (5 minutos).
No desactives sin motivo: Desactivar las revisiones solo tiene sentido en staging o development con control de versiones externo.

Qué son exactamente las revisiones en WordPress y por qué existen

Una revisión es una instantánea completa del contenido de un post en un momento específico del pasado. Cuando guardás cambios en WordPress, el sistema no sobrescribe la entrada anterior: crea un nuevo registro en la base de datos (en la tabla wp_posts) marcado como «revision». El post original —el que está publicado— sigue intacto y sigue siendo la versión «parent». Las revisiones son huérfanas: existen solo para comparación y recuperación, no aparecen en el frontend ni en feeds, y los usuarios finales nunca las ven.

WordPress implementó esto porque los editores de contenido necesitaban una red de seguridad. Antes de las revisiones, un click accidental o un navegador que se crasheaba significaba perder media hora de escritura. Hoy, con sitios manejados por múltiples redactores, editores, y programadores, las revisiones se volvieron críticas para auditar quién cambió qué.

Las revisiones ocurren en dos formas: completas (cuando clickeás «Guardar borrador» o «Actualizar») y autoguardados (cada 60 segundos mientras editás). Los autoguardados son parciales porque no guardan cada campo de la entrada, solo el contenido principal. Pero desde la UI de revisiones, los ves listados igual.

Cómo acceder, comparar y restaurar revisiones paso a paso

El acceso a las revisiones es sencillo pero a veces se oculta por defecto. Acá te muestro cómo hacerlo en el editor clásico de Gutenberg.

Paso 1: Abrí la entrada o página que querés revisar

En el panel de administración, andá a Entradas o Páginas y clickeá en la que querés editar. Se abre en el editor de bloques Gutenberg.

Paso 2: Activa el panel de revisiones si está escondido

Mirá la parte superior derecha de la pantalla. Hay un botón de tres puntitos (⋮). Clickeá ahí y buscá la opción «Revisiones». Si aparece con una tilde, está activo. Si no está, clickeá para activarlo. El panel «Historial» también es útil; es una barra lateral que muestra todos los cambios en tiempo real mientras escribís.

Paso 3: Mirá el listado de revisiones

En el panel lateral derecho verás un listado con fechas, horas y nombres de los autores. Cada línea es una revisión diferente. Las más recientes están arriba. El autoguardado más nuevo aparece con un relojito pequeño.

Paso 4: Compará dos versiones deslizando

Clickeá en una revisión vieja (por ejemplo, de hace 2 horas) y luego en la actual. WordPress te muestra un split view: a la izquierda la versión antigua, a la derecha la nueva. Los cambios se resaltan: verde para lo que se agregó, rojo para lo que se borró. Podés deslizar la barra del medio para comparar línea a línea si querés ver algo específico.

Paso 5: Restaurá la versión que querés

Si decidís que esa versión vieja era mejor, clickeá en el botón «Restaurar esta revisión» debajo de la fecha. WordPress carga todo el contenido de esa revisión en el editor. Vos seguís editando desde ahí, y cualquier cambio que hagas genera una revisión nueva. No hay punto de no retorno: si restaurás algo y después te arrepentís, volvés a comparar y restaurás la otra versión.

Cómo el autoguardado genera revisiones y drena base de datos

El autoguardado es silencioso pero constante. Cada 60 segundos, mientras vos escribís, WordPress envía lo que llevas escrito al servidor y lo guarda como una revisión parcial. Si tenés 5 redactores editando simultáneamente durante 2 horas, eso genera 600 registros de autoguardado en la tabla de posts (5 personas × 120 minutos ÷ 60 segundos = 600). Multiplicado por 50 entradas en edición a la vez, son 30.000 filas nuevas por ciclo. Eso no pasa en la mayoría de los sitios, pero en redacciones medianas o agencias de contenido es real.

El costo es doble: crecimiento de la tabla (más espacio en disco, backups más lentos) y lentitud en consultas (cada GET a wp_posts tiene que saltear reviiones para traer solo posts publicados).

El intervalo de autoguardado se puede configurar en wp-config.php:

define( 'AUTOSAVE_INTERVAL', 300 );

Eso sube el intervalo de 60 a 300 segundos (5 minutos). La mayoría de los sitios no notan la diferencia (escribís 5 minutos entre autoguardados automáticos), pero el tráfico a la base de datos baja un 80%.

También podés desactivar los autoguardados por completo —aunque no lo recomendamos—:

define( 'AUTOSAVE_INTERVAL', false );

Sin autoguardado, los editores ven un aviso «cambios sin guardar» y pueden clickear «Guardar borrador» a mano. El riesgo: si el navegador se cierra sin guardar, ese tiempo de edición se pierde para siempre.

Limitar revisiones en wp-config.php: la forma correcta

El lugar central para controlar revisiones es el archivo wp-config.php, en la raíz de tu instalación WordPress. Esta es la única configuración que aplica desde el momento 0, sin plugins ni consultas manuales a la base de datos.

Abrí wp-config.php con un editor de texto (no Word, no Notepad++; usá un editor de código o el file manager de tu hosting). Buscá la línea que dice:

/* That's all, stop editing! */

ANTES de esa línea, agregá esto:

define( 'WP_POST_REVISIONS', 5 );

Guardá el archivo. A partir de ese momento, WordPress guardará únicamente las últimas 5 revisiones de cada entrada o página. Las más viejas se borran automáticamente.

El número 5 es un buen punto de partida. Si trabajás en equipo o querés más margen de recuperación, usá 10. Si tienes un blog personal y hacés cambios puntuales, 3 alcanza. El máximo común es 10-15 en redacciones medianas.

Para desactivar las revisiones completamente (no recomendado):

define( 'WP_POST_REVISIONS', false );

Ten en cuenta que esto SOLO frena las revisiones nuevas. Las que ya están en la base de datos siguen ahí. Por eso conviene primero limpiar lo acumulado (paso que viene después) y recién entonces fijar el límite.

Borrar revisiones existentes con WP-CLI o base de datos

Una vez que configuraste el límite en wp-config.php, WordPress solo crea revisiones dentro de ese techo para futuras ediciones. Pero todo lo que ya existe sigue en la base de datos. Si tenés un sitio con 2 años de contenido y ningún límite configurado, pueden ser miles de registros acumulados.

Opción A: WP-CLI (recomendado para usuarios técnicos)

Si tu hosting soporta WP-CLI (la mayoría lo hace), podés acceder por SSH y ejecutar:

wp post delete $(wp post list --post_type=revision --format=ids) --force

Ese comando lista todos los posts cuyo tipo es «revision» y luego los borra. Es rápido y seguro. Perderás el historial pasado pero no afecta el contenido publicado.

Opción B: Plugins de limpieza (para quienes no confían en WP-CLI)

WP-Optimize es el clásico. Tiene una sección «Limpiar base de datos» donde podés marcar «Borrar todas las revisiones de posts» y ejecutar con un click. El plugin te muestra cuántas revisiones va a borrar antes de hacerlo.

Optimize Database after Deleting Revisions es más específico: solo borra revisiones. Ambos son seguros porque trabajan sobre una copia de la tabla (no tocan el post en vivo).

Opción C: Consulta SQL manual (solo si sabés qué hacés)

En phpMyAdmin, ejecutá:

DELETE FROM wp_posts WHERE post_type = 'revision';

Eso borra todas las revisiones de una vez. El riesgo: si algo sale mal, necesitás un backup manual para recuperar. Hacé un backup completo de la base de datos ANTES de ejecutar esto.

Gestionar revisiones por tipo de contenido (productos, CPT, etc)

A veces no querés revisions en TODO, solo en ciertos tipos. Por ejemplo, en WooCommerce la revisión de un producto no aporta tanto valor como la revisión de un artículo del blog. En esos casos, podés desactivar las revisiones solo para ese tipo de contenido.

Desactivar revisiones en WooCommerce

WooCommerce ya viene con revisiones desactivadas por defecto en productos. Pero si algún plugin las activó, podés agregar esto en wp-config.php:

if ( defined( 'WOOCOMMERCE_VERSION' ) ) {
    define( 'WP_POST_REVISIONS', 5 );  // para posts normales
    add_filter( 'wp_revisions_to_keep', function( $num, $post ) {
        if ( $post->post_type === 'product' ) {
            return 0;  // sin revisiones para productos
        }
        return $num;
    }, 10, 2 );
}

Ese código dice «guardá 5 revisiones de posts normales, pero 0 de productos».

Desactivar revisiones en tipos de contenido personalizados

Si tenés un CPT (Custom Post Type) personalizado, como «testimonios» o «eventos», podés quitarle revisiones en el registro del tipo:

register_post_type( 'testimonios', array(
    'label'      => 'Testimonios',
    'supports'   => array( 'title', 'editor' ),  // sin 'revisions'
) );

Nota que no incluimos ‘revisions’ en el array de ‘supports’. Eso desactiva las revisiones para ese CPT sin tocar el resto.

Caso de uso: colaboración en equipo y auditoría de cambios

Las revisiones brillan en equipos editoriales donde múltiples personas tocan el mismo post. Imaginá que tres redactores colaboran en un artículo sobre «Tendencias de marketing digital 2026». Ana escribe la introducción y la envía como borrador. Brenno agrega dos secciones. Clara revisa y modifica el tono. Pero después de que Clara guarda, el artículo aparece con datos incompletos en ciertos párrafos.

Con el historial de revisiones, Ana puede:

Abrir el artículo y clickear en «Revisiones».
Ver la lista de cambios: su versión original, los de Brenno, los de Clara.
Comparar la revisión de antes de Clara con la actual.
Identificar exactamente qué párrafos se perdieron y quién los borró.
Restaurar la revisión anterior si fue un error, o pedirle a Clara que vea qué pasó.

Todo esto sin emails, sin «¿quién tocó esto?», sin mensajería. Es auditoría en vivo.

Impacto en performance: cuándo las revisiones ralentizan el sitio

La pregunta que se hacen muchos administradores es: ¿realmente afectan el performance las revisiones? La respuesta es sí, pero depende de escala.

Sitios pequeños (hasta 500 posts)

Sin límites de revisiones configurados, un sitio con 500 posts y 10 revisiones promedio por post tiene 5.500 registros en la tabla. La tabla total es más grande (7-8 MB en lugar de 700 KB), pero las queries siguen siendo rápidas. El impacto es mínimo porque las revisiones se filtran fácilmente en SQL (WHERE post_type != ‘revision’).

Sitios medianos (500-5.000 posts)

Acá el impacto empieza a notarse. Si cada post tiene 30 revisiones promedio (típico después de 3 años sin límite), tenés 150.000 registros. La tabla pesa 200-300 MB. Los backups tardan más. Las queries a la tabla (aunque filtren revisiones) tienen que saltear más filas. Los sitios con mucho tráfico pueden ver un lag de 10-50ms en operaciones de base de datos.

Sitios grandes (5.000+ posts con coedición)

En redacciones medianas o agencias con múltiples usuarios editando simultáneamente, sin límites configurados la tabla crece 500-1.000 registros por día (autoguardados + cambios reales). En 3 años eso es 500.000 + registros. La tabla crece a 500+ MB. Las consultas se vuelven notoriamente lentas. Los dumps de base de datos (backups) pueden tardar 2-3 minutos en lugar de 30 segundos. El overhead es evidente.

Ahí es donde límites y limpieza periódica hacen diferencia.

Políticas recomendadas: qué elegir según tu sitio

Blog personal o pequeño (1 persona, hasta 200 posts)

Configurá WP_POST_REVISIONS = 3. Eso es suficiente para recuperarse de 2-3 errores consecutivos. Sin plugin de limpieza necesario.

Blog empresarial o mediano (2-5 editores, 500-2.000 posts)

Configurá WP_POST_REVISIONS = 10 y AUTOSAVE_INTERVAL = 300. Ejecutá una limpieza de revisiones antiguas una vez por trimestre (3 meses). Eso da cobertura de 2-3 semanas de historial sin que la base de datos explote.

Redacción grande o agencia (5+ editores, 5.000+ posts)

Configurá WP_POST_REVISIONS = 5 (o menos) y AUTOSAVE_INTERVAL = 300. Instalá WP-Optimize y programá una limpieza automática cada viernes a las 23:00 (cuando hay menos ediciones). Revisá el tamaño de la tabla de posts una vez al mes.

Preguntas frecuentes sobre revisiones en WordPress

¿Puedo ver quién hizo cada cambio en una revisión?

Sí. Cada revisión guarda el ID del usuario que la creó. En el panel de revisiones verás el nombre del usuario (o «Guest» si fue un autoguardado sin usuario logueo específico). Sin embargo, WordPress no guarda el MOTIVO del cambio o un comentario asociado. Para eso necesitás un plugin como Revisions Extended, que agrega un campo de comentario a cada revisión.

¿Las revisiones se cuentan en la cuota de almacenamiento del hosting?

No directamente. El almacenamiento del hosting incluye archivos (wp-content/uploads) y la base de datos (wp_posts, wp_postmeta, etc). Las revisiones son registros en la tabla wp_posts, así que sí ocupan espacio en la base de datos. Si tenés muchas revisiones, tu backup de base de datos será más grande y tardará más en transferirse.

¿Qué pasa si borro una revisión accidentalmente?

Si borrás una revisión individual (no un post), simplemente desaparece del historial. El contenido publicado no se ve afectado. Es una operación segura. Si usás WP-CLI o SQL para borrar todas las revisiones de una vez, tampoco afecta los posts en vivo. El único riesgo es perder el historial de cambios pasados, pero el contenido actual sobrevive intacto.

¿Las revisiones funcionan en Custom Post Types (CPT)?

Sí, siempre que el CPT esté registrado con ‘revisions’ en el array de ‘supports’. Si el desarrollador no las incluyó, no van a existir. Podés agregarlas editando la función register_post_type() o usando un plugin como CPT UI que expose esa opción.

¿Cómo limito revisiones solo para páginas pero no para entradas?

Necesitás código personalizado o un plugin. En wp-config.php no hay forma de diferenciar tipos. La solución es un plugin como WP Revisions Control, que tiene UI para configurar límites por tipo de post. Alternativamente, usás un hook en functions.php que filtré el número de revisiones según post_type.

¿Las revisiones ralentizan el editor Gutenberg?

No directamente. El editor no carga todas las revisiones al abrir un post. Gutenberg solo carga la versión actual en RAM. El panel de revisiones es lazy-loaded (se carga solo cuando lo clickeás). El impacto es en la base de datos (consultas más lentas si hay miles de revisiones), no en la velocidad del editor.

¿Cómo programo limpieza automática de revisiones?

La forma más fácil es usar WP-Optimize, que tiene una opción para programar limpiezas automáticas cada X días. Habilítala en Configuración y elige la frecuencia (semanal, mensual). Si no usás plugins, necesitás crear un evento de WordPress (con do_action hook) en functions.php y programarlo con un cron job del servidor (cURL contra una URL específica).

¿Conviene usar Revisionize en lugar de las revisiones nativas?

Revisionize es un complemento, no un reemplazo. Las revisiones nativas son para recuperar cambios puntuales. Revisionize crea un borrador clon de un post publicado para hacer cambios mayores sin afectar la versión en vivo. Ambos coexisten: usás Revisionize para grandes redesigns y las revisiones nativas para arreglos rápidos del mismo post.

Resumen: estructura ideal de configuración para revisiones

Si querés un setup limpio sin complicaciones, acá va la configuración recomendada en wp-config.php:

// Limita revisiones a las últimas 5 versiones
define( 'WP_POST_REVISIONS', 5 );

// Autoguardado cada 5 minutos (en lugar de 60 segundos)
define( 'AUTOSAVE_INTERVAL', 300 );

// Vacía la papelera automáticamente después de 30 días
define( 'EMPTY_TRASH_DAYS', 30 );

Guardá eso en wp-config.php antes de /* That's all, stop editing! */. Luego, ejecutá una limpieza de revisiones existentes (WP-CLI o WP-Optimize) y tu base de datos arranca liviana. De ahí en adelante, WordPress automaticamente borra revisiones antiguas cuando supera el límite de 5, y el autoguardado drena menos recursos.

Lo que no deberías hacer con revisiones

No desactives revisiones en producción sin motivo

Desactivar revisiones (define( 'WP_POST_REVISIONS', false );) tiene sentido en entornos de staging o testing donde tenés Git. En un sitio en vivo con múltiples editores, es un riesgo innecesario. Los editores necesitan esa red de seguridad.

No borres revisiones sin hacer backup primero

Si vas a ejecutar una consulta SQL para borrar todas las revisiones, hacé un backup completo de la base de datos primero. Si algo sale mal, recuperas el backup. Las herramientas como WP-Optimize son más seguras porque hacen un checkpoint antes de borrar.

No ignores el autoguardado

Si tu sitio tiene mucho tráfico de edición y notas lag en la UI, antes de aumentar recursos considera subir el intervalo de autoguardado. Es configuración de una línea y resuelve el problema muchas veces.

¿Cuánto espacio ocupan las revisiones en la base de datos?

Las revisiones se guardan como registros separados en la tabla wp_posts. Dependiendo de cuántos posts tengas y cuántas ediciones, pueden ocupar el 20-50% del tamaño total de tu BD. Por eso es crítico fijar un límite en wp-config.php (recomendado: 5-10 revisiones por post) para evitar que se dispare el tamaño de backups.

¿Las revisiones ralentizan WordPress?

Las revisiones no afectan la velocidad del frontend (los visitantes no las ven), pero sí ralentizan la administración y las consultas a la base de datos. El autoguardado genera tráfico innecesario cada 60 segundos. Aumentar el intervalo a 300 segundos (5 minutos) en wp-config.php reduce el impacto un 80% sin perder funcionalidad.

¿Puedo recuperar una revisión si la borro?

No. Una vez que eliminas las revisiones de la base de datos, desaparecen para siempre (no hay papelera). Por eso la recomendación es primero fijar el límite en wp-config.php para futuras ediciones y luego borrar lo acumulado. Siempre hacé un backup antes de limpiar revisiones, porque no hay marcha atrás.

¿Cuántas revisiones guarda WordPress por defecto?

No hay un límite predeterminado: si no definís ninguno, WordPress guarda todas las revisiones que se van generando. La excepción es el autoguardado, del que existe una sola copia por usuario que se sobrescribe constantemente. Para ponerle techo, agregá define(‘WP_POST_REVISIONS’, 5); en wp-config.php.

¿Qué diferencia hay entre una revisión y un autoguardado en WordPress?

Una revisión es una copia completa que se crea cada vez que clickeás «Guardar borrador» o «Actualizar». El autoguardado, en cambio, es una copia parcial que se sobrescribe sola cada 60 segundos mientras escribís, por eso no se acumula como las revisiones.

¿Las revisiones de WordPress guardan también las imágenes?

Guardan el código de las imágenes insertadas en el contenido, pero no duplican los archivos de la biblioteca multimedia. Al restaurar una revisión vieja pueden reaparecer imágenes que habías sacado del texto, siempre que esos archivos sigan existiendo en la biblioteca.

¿Puedo borrar revisiones sin perder mi post publicado?

Sí, es completamente seguro. Las revisiones son copias históricas independientes del contenido publicado. Si borrás revisiones, el post sigue intacto. Algunos sitios limpian revisiones antiguas con WP-CLI o plugins para optimizar la base de datos sin riesgo alguno.

¿Cuántas revisiones debería guardar en WordPress?

Depende de tu sitio. WordPress guarda ilimitadas por defecto. Para blogs pequeños, 3-5 revisiones es suficiente. En redacciones con muchos editores, 10-20 versiones permiten auditar cambios sin inflar demasiado la base de datos. Configurá en wp-config.php con WP_POST_REVISIONS.

¿Dónde se guardan las revisiones en WordPress?

En la tabla wp_posts de tu base de datos. Cada revisión es un registro con post_type=’revision’ apuntando al post original. Podés verlas en el editor gráfico desde el panel lateral o consultar la BD directamente si necesitás una limpieza manual avanzada.

Volver a

Guias