Hay una llamada que cualquier agencia recibe tarde o temprano. Un cliente escribe un viernes por la tarde diciendo que la página de precios «se ve rara», que alguien ha tocado algo y que nadie sabe quién. Tú abres el sitio, confirmas que efectivamente falta una columna en la tabla comparativa, y empieza el trabajo detectivesco: mirar la fecha de modificación, preguntar en el grupo, abrir la pantalla de revisiones de WordPress y encontrarte con dos columnas de texto plano donde el marcado de bloques aparece como un churro ilegible. Media hora después has reconstruido el cambio a ojo y has vuelto a maquetar la sección a mano. Nadie ha aprendido nada y el problema se repetirá.
Ese escenario es el que vienen a cerrar las revisiones de WordPress 7: la 7.0 «Armstrong» se publicó el 20 de mayo de 2026. Entre todo lo que trae la versión que abre la Fase 3 de Gutenberg —y que repasamos en detalle en nuestra guía para actualizar a WordPress 7 en entornos de empresa— el rediseño del sistema de revisiones es el cambio que menos titulares se ha llevado y más impacto tiene en equipos con varias personas escribiendo sobre el mismo sitio. Las revisiones dejan de vivir en una pantalla aparte y pasan a formar parte del editor, con comparación visual de bloques y no solo de texto.
En este artículo vamos a mirarlo desde donde nos toca mirarlo: el de quien mantiene sitios en producción y responde cuando algo se publica mal. Qué resuelve realmente, qué flujo editorial habilita, qué te permite demostrar ante un cliente y, sobre todo, qué coste tiene en base de datos si lo dejas correr sin control. Porque las revisiones son gratis hasta que tu tabla wp_posts pesa cuatro veces más de lo que debería.
1. El problema de siempre: una pantalla de revisiones que nadie usaba
La pantalla clásica de revisiones de WordPress lleva prácticamente igual desde 2012. Funcionaba con una lógica muy concreta: el contenido era texto, el editor era una caja de texto, y comparar dos versiones significaba hacer un diff línea a línea como el de cualquier control de versiones. Para el WordPress de aquella época era razonable. Para el WordPress de 2026 dejó de serlo hace bastante.
El primer problema era la ruptura del contexto. Al pulsar «Revisiones» salías del editor y aterrizabas en una pantalla completamente distinta, con su propia barra de navegación y su propio deslizador. Comparabas, decidías, restaurabas y volvías. Si querías ver tres versiones seguidas, repetías el viaje tres veces. En la práctica esto significaba que la gente no lo hacía: revisar era caro en tiempo y en atención, así que se optaba por rehacer el cambio a mano.
El segundo problema, mucho más grave, era qué se comparaba. Desde que Gutenberg convirtió el contenido en una estructura de bloques serializados, el diff de texto muestra el marcado de los comentarios HTML de los bloques. Cuando alguien cambia una columna de ancho, o mueve un grupo dentro de otro, o ajusta el espaciado de una sección, lo que ves en la pantalla de revisiones es una avalancha de líneas modificadas que no te dice absolutamente nada sobre lo que ha cambiado visualmente. El diff era técnicamente correcto y humanamente inservible.
El tercero era el ruido. WordPress guarda revisiones con bastante alegría, y sin una política de limpieza acabas con cuarenta entradas para un mismo post donde treinta y cinco son autoguardados de la misma sesión. Encontrar la versión buena entre ellas era, literalmente, ir probando.
El resultado combinado es que en la mayoría de proyectos que auditamos, el historial de revisiones existía, ocupaba espacio, y no lo consultaba nadie. Un sistema de control de versiones que nadie usa no es un sistema de control de versiones: es una tabla que crece.
2. Qué traen las revisiones de WordPress 7
El cambio de fondo es de ubicación: las revisiones de WordPress 7 pasan a estar dentro de la pantalla de edición. No abandonas el editor, no pierdes el contexto, y el propio lienzo se convierte en la superficie donde se muestra la versión anterior. Eso, que parece un detalle de interfaz, cambia por completo la frecuencia con que la función se usa.
Código de colores sobre el propio contenido
Los cambios se señalan directamente sobre el contenido renderizado con un código de color convencional: verde para lo añadido, rojo para lo eliminado. No estás leyendo un diff textual en dos columnas, estás viendo la página con las adiciones y las supresiones marcadas encima. Para un redactor que no sabe qué es un comentario de bloque, esto es la diferencia entre poder revisar su propio trabajo o no.
Deslizador temporal
El deslizador que ya existía en la pantalla clásica se mantiene, pero ahora opera sin sacarte de sitio. Recorres el historial de la entrada moviendo el control y el lienzo se actualiza mostrando el estado del contenido en ese punto. La utilidad real aparece cuando buscas «el momento en que esto se rompió»: vas hacia atrás hasta encontrar la última versión sana y ya tienes acotado el intervalo y el autor.
Minimapa lateral
En entradas largas —una guía de 3.000 palabras, una landing con quince secciones— el problema no es ver el cambio, es encontrarlo. El minimapa lateral resuelve eso: te da una vista comprimida del documento con las zonas modificadas marcadas, y saltas directamente a ellas. Sin minimapa, revisar una página larga significa hacer scroll buscando manchas de color.
El botón cambia cuando estás en modo revisión
Este es el detalle que más agradece un equipo con gente poco técnica. Cuando estás visualizando una revisión, el botón principal deja de decir «Actualizar» y pasa a ofrecer restaurar esa versión. Es una decisión de diseño que elimina una clase entera de errores: la de alguien que estaba mirando una versión antigua, se despista, pulsa el botón de siempre y publica contenido de hace tres semanas. Si has gestionado sitios con varios editores, sabes que eso pasa.
El conjunto encaja con la dirección general de la versión, que también reorganiza el área de administración. Si aún no has visto el nuevo panel, conviene leer cómo funciona el nuevo escritorio de WordPress 7 basado en DataViews, porque la lógica de interfaz es la misma: menos pantallas separadas, más trabajo dentro de una vista unificada.
3. Visual Diff: comparar estructura, no solo palabras
La parte técnicamente interesante es que el diff ya no opera únicamente sobre cadenas de texto. Compara la estructura del documento de bloques. Eso significa que el sistema puede distinguir entre «se ha cambiado el texto de este párrafo» y «este párrafo se ha movido dentro de otro contenedor», que en un diff textual son cambios indistinguibles y producen el mismo desastre visual.
Los tipos de cambio que ahora se detectan como tales incluyen la sustitución de un bloque por otro, la reordenación de bloques dentro de un contenedor, cambios en la disposición de columnas y grupos, y modificaciones de atributos de diseño como espaciado, alineación o colores aplicados a un bloque concreto. En el modelo anterior todo eso caía en el mismo saco de «líneas de HTML modificadas».
Por qué esto importa más de lo que parece: desde que existe el editor de bloques, WordPress tiene un modelo de contenido estructurado y una herramienta de comparación pensada para contenido no estructurado. Era una incoherencia arquitectónica de años. Cada vez que un cliente nos preguntaba «¿puedo ver qué cambió exactamente en el diseño de esta página?», la respuesta honesta era que no, que podíamos ver el HTML anterior y restaurarlo entero, pero no aislar el cambio. Visual Diff cierra ese hueco.
Conviene ser preciso sobre el alcance. Esto compara versiones del contenido de una entrada. No es un control de versiones del sitio: no cubre cambios en plantillas de bloques globales, en configuración del tema, en plugins ni en la base de datos de opciones. Si alguien te rompe la cabecera desde el editor de sitios, el historial de revisiones de una entrada no te va a contar nada. Para eso sigues necesitando copias de seguridad y, en proyectos serios, control de versiones sobre el código del tema.
La convivencia con maquetadores
Hay un matiz que en agencia no podemos ignorar. WordPress 7 cambia el editor a un modelo con iframes internos, y eso ha dado conflictos con maquetadores externos como Elementor, Divi o Bricks. Si el contenido de una página no vive en bloques nativos sino en la estructura interna de un maquetador, el Visual Diff no tiene mucho que comparar: verá un contenedor grande y poco más. Quien esté valorando este flujo como argumento para consolidar en bloques nativos tiene aquí un punto real, y el movimiento del ecosistema va en esa dirección, como se ve en el nuevo editor atómico de Elementor 4.
4. El flujo editorial real: tres redactores y un revisor
Vamos a bajarlo a un caso concreto, porque es donde se ve si una funcionalidad sirve o es una demo bonita. Imagina un equipo de contenidos con tres redactores, un revisor que valida antes de publicar y un responsable de marketing que a veces entra a «solo cambiar una frase». Es una configuración habitual en cualquier empresa mediana.
Antes, el flujo de revisión funcionaba por fuera de WordPress. El redactor avisaba por Slack o por correo de que había terminado, el revisor abría la entrada, la leía entera y comentaba en otro canal. Si el revisor quería saber qué había cambiado desde la última vez que la leyó, no tenía forma práctica de averiguarlo: releía todo. El coste de revisar era proporcional a la longitud del post, no a la magnitud del cambio.
Con las revisiones de WordPress 7 dentro del editor, el revisor abre la entrada, activa el modo revisión, y ve exactamente qué se ha tocado desde la última vez. Si son dos párrafos reescritos y un bloque de imagen movido, lo ve en segundos. El coste de revisar pasa a ser proporcional al cambio. Esa es la diferencia entre un equipo que revisa siempre y uno que revisa cuando tiene tiempo.
El segundo escenario es la reversión. Alguien ha reescrito la introducción de una página de servicio y ha quedado peor que antes. En el modelo clásico, restaurar significaba volcar toda la entrada a un estado anterior, perdiendo de paso las correcciones legítimas que hubiera hecho otra persona después. Ahora puedes localizar el cambio, verlo aislado y decidir con criterio si restauras esa versión o si simplemente copias el texto anterior de vuelta manteniendo el resto.
El tercero es la auditoría previa a campaña. Antes de lanzar tráfico de pago a una landing, alguien tiene que confirmar que la página está exactamente como se aprobó. Recorrer el historial con el deslizador y comprobar que no hay cambios posteriores a la validación es un control de cinco minutos que evita quemar presupuesto contra una página con el precio equivocado. Suena obvio; hasta ahora era caro de hacer, así que casi nadie lo hacía.
Dónde este flujo se queda corto
Seamos honestos con las limitaciones, porque es lo que diferencia una recomendación de agencia de una nota de prensa. Esto no es un flujo de aprobación: no hay estados de «pendiente de validar», no hay comentarios asociados a un cambio concreto, no hay notificación al revisor. Sigues necesitando una capa encima —roles bien configurados, un plugin de flujo editorial, o simplemente disciplina de equipo— si tu proceso requiere aprobación formal.
Tampoco es colaboración en tiempo real. Merece la pena decirlo con claridad porque hay mucha confusión: la edición colaborativa en tiempo real no está en WordPress 7.0. Matt Mullenweg la retiró el 8 de mayo de 2026 por preocupaciones de superficie de ataque, condiciones de carrera, carga de servidor y eficiencia de memoria, y la RC3 de ese mismo día ya salió sin ella. Queda pospuesta a la 7.1. Si has leído artículos de abril anunciándola, eran previos al lanzamiento y están desactualizados. Dos personas editando la misma entrada a la vez siguen pisándose exactamente igual que antes.
5. Trazabilidad: qué puedes demostrar cuando algo sale mal
Aquí está, en nuestra experiencia, el valor menos comentado y más rentable. En proyectos con varias manos —agencia, cliente, freelance de contenidos, becario de marketing— la pregunta que aparece cuando algo se publica mal no es técnica, es de responsabilidad. Y sin datos, esa conversación se resuelve por volumen de voz.
Un historial de revisiones legible cambia el tono de esa conversación. Puedes abrir la entrada, mostrar la secuencia de cambios con autor y fecha, y señalar el momento exacto en que se introdujo el problema. No para señalar culpables, que rara vez ayuda, sino para dos cosas mucho más útiles: acotar el alcance del incidente y ajustar el proceso para que no se repita. Si resulta que el error entró por alguien con rol de administrador que debería tener rol de editor, ya sabes qué corregir.
En proyectos donde firmamos un mantenimiento con SLA, esto tiene una lectura contractual directa. La distinción entre «esto se rompió por una actualización que gestionamos nosotros» y «esto se rompió porque alguien editó el contenido el martes a las 18:40» determina quién asume el coste de arreglarlo. Antes esa distinción se sostenía sobre logs de acceso y buena voluntad. Ahora se sostiene sobre el propio historial de la entrada, en la interfaz que el cliente puede abrir él mismo.
Hay un beneficio adicional que aparece a los pocos meses: la gente edita con más cuidado cuando sabe que queda registro visible. No es un efecto que se pueda medir, pero es real y cualquiera que haya introducido trazabilidad en un equipo lo ha visto.
Dicho esto, no confundas trazabilidad de contenido con seguridad. El historial de revisiones te dice qué usuario guardó qué versión; no te dice si esa sesión estaba comprometida, ni te protege de nada. Si el vector de entrada fue una credencial robada o un plugin vulnerable, el registro de revisiones es una pista, no una defensa. Para la parte que sí es defensa, el enfoque está en nuestra guía de seguridad de WordPress para empresas.
¿Tu WordPress crece sin control de versiones ni política de revisiones?
Auditamos la configuración de revisiones, limpiamos el histórico acumulado, ajustamos roles editoriales y dejamos el mantenimiento con trazabilidad real de quién toca qué.
6. Límites y mantenimiento: las revisiones pesan
Ahora la parte que no sale en las notas de lanzamiento. Cada revisión de una entrada es una fila completa en la tabla wp_posts, con su propio contenido íntegro, más sus filas asociadas en wp_postmeta. No se guarda un diff: se guarda una copia entera. Si una página de 4.000 palabras acumula treinta revisiones, tienes 120.000 palabras almacenadas para servir una sola URL.
En un blog corporativo con cincuenta entradas eso es irrelevante. En un sitio con tres mil entradas y un equipo activo, no lo es. Hemos visto instalaciones donde las revisiones representaban más del 60% de las filas de wp_posts. El efecto no es solo espacio en disco, que es barato: es tamaño de la tabla, tiempo de las copias de seguridad, duración de las importaciones y exportaciones, y peor comportamiento de las consultas que no filtran bien por post_type. Cualquier plugin mal escrito que haga un SELECT amplio sobre wp_posts te lo va a hacer notar.
Controlar el número de revisiones
WordPress expone esto con una constante en wp-config.php. La opción por defecto es guardar revisiones sin límite, que es la peor de las tres posibles para un sitio grande. Las alternativas son desactivarlas por completo —mala idea si te importa la trazabilidad— o fijar un número máximo por entrada, que es lo que recomendamos casi siempre.
// wp-config.php
// Colocar SIEMPRE antes de la línea:
// require_once ABSPATH . 'wp-settings.php';
// Limitar a 10 revisiones por entrada (recomendado en la mayoría de sitios)
define( 'WP_POST_REVISIONS', 10 );
// Desactivar por completo las revisiones (no recomendado si hay varios editores)
// define( 'WP_POST_REVISIONS', false );
// Intervalo de autoguardado en segundos: por defecto 60.
// Subirlo reduce el ruido de autoguardados en sesiones largas.
define( 'AUTOSAVE_INTERVAL', 120 );
// Vaciado de la papelera cada 15 dias en lugar de 30
define( 'EMPTY_TRASH_DAYS', 15 );
Un matiz importante sobre WP_POST_REVISIONS: el límite se aplica al guardar. Definir la constante no borra retroactivamente lo que ya tienes acumulado. Si llegas a un sitio con años de historial, primero limpias y después configuras. Y si necesitas afinar más —por ejemplo, mantener treinta revisiones en páginas comerciales y cinco en entradas de blog— la constante se puede complementar con el filtro wp_revisions_to_keep, que recibe el objeto de la entrada y permite decidir por tipo de contenido.
Cuánto conservar: criterio, no dogma
Nuestra regla práctica es sencilla. En sitios con un único responsable de contenido, cinco revisiones sobran. En equipos de tres a diez personas, entre diez y veinte es un buen punto de equilibrio entre trazabilidad y peso. En sitios con requisitos de auditoría formal, no toques el límite y en su lugar plantea una estrategia de archivado externo, porque la base de datos de producción no es un sistema de registro de cumplimiento normativo.
La limpieza inicial conviene hacerla con cabeza. Un borrado directo con SQL sobre wp_posts es rápido y deja huérfanos en wp_postmeta y en las tablas de relaciones si no lo acompañas de las eliminaciones correspondientes. Usa WP-CLI, hazlo primero en staging, y saca una copia antes. Después de la limpieza, optimiza las tablas: el espacio no se recupera solo. Este tipo de trabajo entra de lleno en lo que revisamos en una auditoría de rendimiento web, donde el tamaño de la base de datos suele explicar más problemas de los que la gente espera.
Un apunte final sobre entorno. WordPress 7 mantiene el mínimo de PHP en 7.4 y recomienda 8.3. No exige PHP 8, pese a lo que se ha repetido. Ahora bien, por debajo de PHP 8 estás en territorio sin soporte de seguridad, y en sitios con tablas grandes la diferencia de rendimiento entre 7.4 y 8.3 es perfectamente visible. Si vas a actualizar, actualiza también la pila: tiene sentido revisar la configuración de PHP-FPM y php.ini para PHP 8 en el mismo movimiento.
7. Lo que corrigió la 7.0.1
WordPress 7.0.1 se publicó el 9 de julio de 2026 como versión de mantenimiento, con 31 correcciones repartidas entre el core y el editor de bloques. Entre ellas hay una que afecta directamente a lo que estamos tratando: mejoras de accesibilidad en la interfaz de revisiones visuales.
No es un detalle menor. Una interfaz que comunica información mediante color —verde para añadido, rojo para eliminado— tiene un problema de accesibilidad evidente si el color es el único canal. Para usuarios con daltonismo o navegando con lector de pantalla, un diff que solo se distingue por tono es un diff inutilizable. Que estas correcciones llegaran en la primera minor sugiere que el feedback fue rápido y que el equipo lo priorizó, que es exactamente lo que uno quiere ver en una funcionalidad nueva.
El resto del paquete de la 7.0.1 refuerza el argumento de no ir a producción con la .0. Se corrigió una regresión en wp_kses() que corrompía declaraciones background-image: url(...) dejándolas convertidas en style=")", un fallo con potencial de romper visualmente contenido ya publicado sin que nadie lo tocara. También se resolvió una incompatibilidad con PHP 8.5 en una función core de adjuntos de imagen, un fallo en el callback de copiar al portapapeles y un bug del bloque de navegación con Page List dentro de submenús.
Nuestra recomendación operativa no cambia respecto a lo que decimos en cada ciclo: probar en staging, esperar a la primera minor, y en tiendas ser aún más conservador. WooCommerce tenía actualizaciones de compatibilidad pendientes con WordPress 7, y actualizar un ecommerce sin validar antes es asumir un riesgo que no compensa. Si tu caso es ese, empieza por la parte de compatibilidad que tratamos en el análisis de WooCommerce en 2026.
Conclusión
Las revisiones visuales de WordPress 7 no son la funcionalidad que va a aparecer en la portada de nadie, y precisamente por eso merecen atención. Resuelven un problema que llevaba abierto desde que Gutenberg convirtió el contenido en bloques: tener un modelo de contenido estructurado y una herramienta de comparación pensada para texto plano. Comparar dentro del editor, sobre el contenido renderizado y con la estructura de bloques como unidad de diff, es lo que faltaba.
El valor real de las revisiones de WordPress 7 aparece en proyectos con varias manos. Un equipo donde tres personas editan y una revisa gana un flujo de trabajo que antes no tenía coste asumible. Una agencia que mantiene el sitio de un cliente gana la capacidad de demostrar qué pasó y cuándo, que es lo que separa una conversación técnica de una discusión sobre responsabilidades. Y cualquiera que haya tenido que revertir a mano una maquetación destrozada entiende el ahorro sin necesidad de que se lo expliquen.
La contrapartida está en la base de datos, y es la parte que casi nadie configura hasta que duele. Define WP_POST_REVISIONS con un número razonable, limpia lo acumulado antes de fijar el límite, y revisa el tamaño de wp_posts con la misma periodicidad con la que revisas cualquier otra métrica de infraestructura. Una funcionalidad que ahora sí se va a usar es una funcionalidad que ahora sí va a generar volumen.
Preguntas frecuentes
¿Las revisiones visuales funcionan con contenido creado con Elementor o Divi?
De forma limitada. El Visual Diff compara la estructura de bloques nativos de WordPress. Si el contenido real vive dentro de la estructura interna de un maquetador, el sistema verá poco más que un contenedor y no podrá aislar cambios de diseño. Los maquetadores suelen ofrecer su propio historial de versiones; conviene usar el suyo en ese caso. Además, el paso del editor a iframes internos en WordPress 7 ha dado conflictos con varios maquetadores, así que valida en staging antes de actualizar.
¿Cuántas revisiones debería guardar en un sitio corporativo?
Entre diez y veinte cubre la mayoría de escenarios con equipo editorial. Con un único responsable de contenido, cinco es suficiente. Desactivarlas del todo solo tiene sentido en sitios donde el contenido lo genera un proceso automático y nadie edita a mano. Recuerda que el límite se aplica al guardar y no borra el histórico previo.
¿Puedo restaurar solo un bloque en lugar de la entrada completa?
La restauración sigue operando sobre la versión completa de la entrada. Lo que sí cambia es que ahora identificas visualmente el cambio concreto, así que puedes optar por copiar manualmente el contenido anterior de ese bloque en lugar de revertir todo el documento y perder las correcciones posteriores de otras personas.
¿Esto sustituye a las copias de seguridad?
No, y confundirlo es un error caro. Las revisiones cubren el contenido de entradas y páginas. No cubren plantillas, configuración del tema, plugins, opciones ni base de datos completa. Viven además en la misma base de datos que quieres proteger: si esa base de datos se corrompe, se van con ella. Sistema de trazabilidad editorial sí; sistema de recuperación ante desastres, en absoluto.
¿Está ya disponible la edición colaborativa en tiempo real?
No. Se retiró el 8 de mayo de 2026 antes del lanzamiento por motivos de superficie de ataque, condiciones de carrera, carga de servidor y eficiencia de memoria, y queda pospuesta a WordPress 7.1. Los artículos de abril que la anuncian son anteriores a esa decisión. Lo que sí llega en 7.0 es el resto de la Fase 3 de Gutenberg, incluidas estas revisiones, junto con el nuevo escritorio, la visibilidad por dispositivo y la capa de infraestructura de IA que repasamos en las novedades de WordPress 7.0 Armstrong para desarrolladores.
¿Merece la pena actualizar solo por esta funcionalidad?
Por sí sola, en un sitio de un único editor, no. En un sitio con equipo editorial y varias personas con permisos de edición, es uno de los argumentos más sólidos de toda la versión, junto con la visibilidad por dispositivo. En cualquier caso, actualiza sobre la 7.0.1 o posterior, prueba en staging, y si tienes tienda, valida la compatibilidad de WooCommerce antes de tocar producción.
