Abre el listado de plugins de cualquier WordPress corporativo con tres o cuatro años de vida y encontrarás el mismo patrón: un plugin de iconos SVG que alguien instaló para poner tres pictogramas en la home, otro de migas de pan que arrastra su propio CSS, un lightbox de galería que carga una librería JavaScript de 40 KB en todas las páginas y un plugin de fuentes que duplica lo que ya hace el tema. Ninguno es crítico. Todos hay que actualizarlos, todos son superficie de ataque y todos aparecen en el informe de rendimiento como peso muerto.
WordPress 7.0 «Armstrong», publicado el 20 de mayo de 2026, mete en el core una parte de ese trabajo. No lo hace con una funcionalidad estrella, sino con los bloques nuevos de WordPress 7 y un puñado de capacidades de medios que, sumados, cambian la conversación cuando revisas la pila de plugins de un cliente. Hay un bloque de iconos con colección de SVG en el core y una API para registrar las tuyas. Hay un bloque de migas de pan nativo. El redimensionado y la compresión de imágenes pasan a ejecutarse en el navegador antes de subir el archivo. Las galerías traen lightbox sin dependencias externas. La Font Library deja de ser exclusiva de los temas de bloques. Y cada bloque individual puede llevar su propio CSS personalizado, para bien y para mal.
Este artículo forma parte de nuestra guía completa para actualizar a WordPress 7 en un entorno empresarial, y se centra en un ángulo concreto: qué te ahorran realmente los bloques nuevos de WordPress 7 en licencias, en mantenimiento y en carga de servidor, y dónde el ahorro es solo aparente.
1. Bloque de iconos: SVG en el core y una API para tus propias colecciones
El bloque de iconos resuelve algo que llevaba años resolviéndose mal. Hasta ahora, meter un icono en una página de WordPress implicaba una de tres opciones: pegar el SVG en línea dentro de un bloque HTML personalizado, instalar un plugin de iconos, o depender de que el tema o el maquetador trajera su propia librería. Las tres tienen costes. El SVG en línea es ingobernable a escala porque el marcado queda enterrado en el contenido y nadie lo encuentra cuando hay que cambiar el trazo o el color. El plugin añade una dependencia. La librería del tema te ata al tema.
WordPress 7 incorpora una colección de iconos SVG en el propio core y un bloque para insertarlos con los controles habituales de tamaño, color y alineación. Para un sitio corporativo estándar, esa colección cubre lo que se usa el 90 % del tiempo: flechas, redes sociales, checks, teléfono, correo, ubicación. Si esa era la única razón por la que tenías un plugin de iconos instalado, ese plugin se puede retirar el mismo día de la actualización.
La parte interesante está en la API de colecciones
Lo relevante para una agencia no es la colección de serie, sino la posibilidad de registrar colecciones propias. En un proyecto con tema a medida, esto permite empaquetar el set de iconos de la marca dentro del tema y exponerlo al editor con la misma interfaz que los iconos del core. El cliente elige del selector de iconos, ve los suyos, y no tiene forma de pegar un SVG aleatorio descargado de internet que no case con el sistema de diseño.
Ese detalle vale más de lo que parece. En los sitios que mantenemos, la deriva visual casi nunca viene de un rediseño: viene de la acumulación de pequeñas decisiones de un editor con prisa. Un icono de otra familia aquí, un color fuera de paleta allá. Cuando el set de la marca está registrado en el core del editor y es lo primero que aparece, la opción por defecto es la correcta. Gobernanza por diseño, no por documento de normas que nadie lee.
Un apunte de seguridad, porque conviene tenerlo presente: los SVG siguen siendo XML y siguen pudiendo contener scripts. Que ahora haya un bloque de iconos nativo no significa que debas abrir la subida de SVG a los editores. La colección del core y las colecciones que registres tú desde código están controladas; el archivo que sube un usuario desde su escritorio, no. Esa política no cambia con WordPress 7.
2. Migas de pan nativas: qué aportan y qué no resuelven
El bloque de migas de pan genera la ruta de navegación automáticamente a partir de la jerarquía del contenido. Detecta si estás en una entrada, una página hija, un archivo de taxonomía o un resultado de búsqueda, y construye el rastro correspondiente. Se comporta como cualquier otro bloque: tiene controles de separador, de tipografía y de espaciado, y hereda los estilos globales del tema.
Donde de verdad se nota es en el editor del sitio. Hasta ahora, poner migas de pan en una plantilla de archivo o en la plantilla de entrada única obligaba a bajar a PHP, a usar el shortcode del plugin de SEO metido dentro de un bloque, o a mantener un bloque personalizado propio. Con el bloque nativo lo colocas en la plantilla desde la interfaz, lo ves renderizado con datos reales y se propaga a todas las entradas que usan esa plantilla. Para un equipo que trabaja con temas de bloques y quiere que el cliente pueda tocar plantillas sin abrir un editor de código, esto elimina una fricción real.
El ángulo SEO, con criterio
Aquí conviene bajar las expectativas. Las migas de pan aportan dos cosas a la experiencia y al posicionamiento: mejoran la navegación interna para el usuario, sobre todo en móvil y en sitios con jerarquías profundas, y añaden enlaces internos contextuales que refuerzan la relación entre una página y sus ascendentes en la arquitectura del sitio. Eso es útil y es real.
Lo que el bloque nativo no hace por sí solo es garantizarte los breadcrumbs enriquecidos que Google muestra en los resultados de búsqueda. Esa presentación depende del marcado de datos estructurados BreadcrumbList, y ese marcado lo suele generar tu plugin de SEO como parte del grafo JSON-LD del sitio. Sustituir el bloque de migas del plugin de SEO por el bloque nativo sin comprobar qué pasa con el JSON-LD es la clase de cambio que se hace un martes y se detecta tres semanas después en Search Console.
La recomendación práctica: si tu plugin de SEO sigue emitiendo el BreadcrumbList de forma independiente al shortcode visual, puedes usar el bloque nativo para la parte visible sin perder nada. Si el marcado va acoplado al componente visual del plugin, quédate como estás o valida el resultado con la herramienta de prueba de resultados enriquecidos antes de tocar nada en producción. Esta clase de comprobaciones son parte del trabajo de fondo que describimos en nuestra guía de SEO técnico para ecommerce, donde las jerarquías de categorías y el rastro de navegación pesan mucho más que en un sitio corporativo de veinte páginas.
Un matiz adicional: en catálogos grandes, las migas generadas automáticamente a partir de la jerarquía no siempre coinciden con la ruta que el usuario ha seguido ni con la categoría canónica del producto. Un producto que pertenece a cuatro categorías tiene cuatro rutas posibles y el bloque elegirá una. Si tu arquitectura de información depende de eso, revísalo producto a producto en una muestra representativa antes de dar el cambio por bueno.
3. Procesamiento de medios en el navegador: el servidor deja de sudar
Esta es, con diferencia, la novedad con más impacto medible de todo el paquete. Hasta WordPress 7, el flujo de subida de una imagen era: el navegador envía el archivo original completo al servidor, PHP lo recibe, y a continuación GD o ImageMagick generan todos los tamaños intermedios registrados por el tema y los plugins. En un sitio típico eso son entre seis y doce derivados por imagen, cada uno con su ciclo de decodificación, redimensionado y recompresión.
WordPress 7 mueve buena parte de ese trabajo al navegador. El redimensionado y la compresión se ejecutan en el cliente antes de que el archivo salga de la máquina del editor. Al servidor llega una imagen ya ajustada, y el trabajo pesado de PHP se reduce de forma sustancial.
Por qué esto importa tanto en hosting compartido
En un servidor dedicado con CPU de sobra, procesar imágenes es una molestia. En un hosting compartido es un problema serio, y por una razón que se suele pasar por alto: los límites del plan no son solo de espacio, son de procesos PHP concurrentes, de memoria por proceso y de tiempo máximo de ejecución. Cuando un editor sube quince fotos de una feria a 6.000 píxeles de ancho desde una cámara moderna, cada una de esas subidas ocupa un worker de PHP durante varios segundos generando derivados.
Mientras eso ocurre, esos workers no están sirviendo páginas. El resultado es el clásico «la web va lentísima justo cuando el equipo de marketing está actualizando el blog», que hasta ahora se explicaba mal y se atribuía al hosting en general. También es la causa habitual del error de memoria agotada a mitad de subida, que deja el archivo en la biblioteca con algunos tamaños generados y otros no, produciendo esas imágenes rotas que aparecen solo en ciertos contextos.
Con el procesamiento en el navegador, ese pico de carga se distribuye entre las máquinas de los editores, que están ociosas de todos modos. En sitios con subidas masivas —medios de comunicación, catálogos de producto, portales inmobiliarios, agencias de viajes— el efecto sobre la carga media del servidor es notable, y se nota especialmente en las horas en que el equipo editorial trabaja.
Lo que cambia para quien está delante del editor
Conviene explicar bien esto a los clientes porque la experiencia percibida cambia de forma. El tiempo total de subida suele bajar, sobre todo con conexiones asimétricas: comprimir una imagen de 8 MB a 900 KB antes de enviarla ahorra mucho más tiempo del que cuesta comprimirla. Pero la naturaleza de la espera es distinta. Ahora hay un momento de trabajo local antes de que empiece la transferencia, y en equipos antiguos o con una subida de treinta imágenes de golpe, el navegador puede notarse pesado durante ese proceso.
Dicho de otro modo: has trasladado el cuello de botella del servidor al portátil del editor. En la mayoría de escenarios es un cambio excelente, porque el portátil del editor solo tiene que atender a una persona y el servidor atiende a todas las visitas. Pero si el equipo editorial trabaja con máquinas de hace ocho años, mídelo antes de venderlo como una mejora.
Hay un efecto secundario positivo que suele pasar desapercibido: al llegar imágenes más razonables al servidor, la biblioteca de medios crece mucho más despacio. Eso abarata las copias de seguridad, acelera las migraciones y reduce el coste de almacenamiento en los planes que lo facturan. En sitios con años de acumulación, la diferencia entre guardar el original de 8 MB y guardar una versión ya ajustada se nota en la factura.
Nada de esto sustituye a una estrategia de imágenes bien planteada: formatos modernos, atributos de dimensiones correctos, carga diferida por debajo del pliegue y una CDN delante. Si el objetivo es mover la aguja del LCP, el procesamiento en cliente ayuda al servidor pero no dibuja la imagen antes en la pantalla del visitante. Para eso sigue haciendo falta el trabajo que detallamos en nuestra guía sobre Core Web Vitals y rendimiento web para Google.
¿Cuántos plugins te sobran después de actualizar a WordPress 7?
Revisamos tu instalación bloque a bloque: qué plugins duplican ahora funcionalidad del core, cuáles puedes retirar sin romper nada y qué impacto real tiene todo ello en el tiempo de respuesta de tu servidor.
4. Galerías con lightbox nativo
El bloque de galería incorpora navegación tipo lightbox sin plugins: se abre la imagen a pantalla completa y se puede pasar a la siguiente y a la anterior desde el propio visor. Es una funcionalidad modesta y llevaba años siendo motivo de instalación de plugins que hacían eso y treinta cosas más que nadie usaba.
El beneficio no está tanto en la funcionalidad como en lo que deja de cargarse. Un plugin de lightbox típico encola su JavaScript y su CSS en todas las páginas del sitio, incluidas las que no tienen ni una sola galería, porque detectar la presencia del bloque antes de encolar requiere un cuidado que muchos plugins no ponen. En un sitio con cincuenta páginas y galerías en tres, estás sirviendo esa librería cuarenta y siete veces de más.
El comportamiento nativo se activa por galería, se integra con el sistema de bloques y no arrastra dependencias. Para portfolios, fichas de proyecto, catálogos visuales y páginas de producto con varias fotos, cubre el caso estándar. Si necesitas zoom con lupa, vídeo dentro del visor, subtítulos enriquecidos o comportamientos de comercio muy específicos, seguirás necesitando una solución dedicada. Pero merece la pena revisar si la solución dedicada que tienes instalada está ahí porque hacía falta o porque en su día fue lo más rápido.
5. Font Library para todos los temas, no solo los de bloques
La Font Library llegó con los temas de bloques y se quedó ahí, lo que dejaba fuera a una parte enorme del parque instalado. WordPress 7 la extiende a todos los temas, incluidos los clásicos.
Esto desbloquea algo concreto en proyectos heredados. Un sitio con un tema clásico a medida, de esos que llevan seis años funcionando bien y que nadie quiere reconstruir sin motivo, ahora puede gestionar fuentes desde la interfaz de administración: subirlas, activarlas, desactivarlas y servirlas localmente. Antes eso implicaba tocar el functions.php, encolar los archivos a mano, escribir las declaraciones @font-face y hacer un despliegue cada vez que el cliente cambiaba de opinión sobre la tipografía.
Hay además una dimensión legal que en Europa importa. Servir fuentes desde un CDN externo implica transferir la dirección IP del visitante a un tercero, y ha habido resoluciones en distintos países europeos que lo han considerado problemático sin consentimiento previo. Alojar las fuentes localmente resuelve el asunto de raíz, y con la Font Library disponible en temas clásicos, hacerlo deja de requerir intervención de desarrollo en la mayoría de casos.
La contrapartida es de gobierno del proyecto, no técnica: si dejas la Font Library abierta a los editores, alguien acabará subiendo una tipografía. Nuestra práctica habitual es cargar las fuentes de marca desde la biblioteca durante el arranque del proyecto y limitar después esa capacidad por rol. La herramienta es buena; el acceso indiscriminado a ella, no.
6. CSS personalizado por bloque: herramienta fina y desastre potencial
WordPress 7 permite añadir CSS personalizado a un bloque individual, desde el propio panel del bloque. Es una funcionalidad genuinamente útil y también la que más problemas nos va a dar en sitios ajenos dentro de dos años. Merece la pena separar las dos caras.
Cuándo es la herramienta correcta
Es razonable para excepciones puntuales y localizadas. Una landing de campaña que vive tres semanas y necesita un degradado que no está en el sistema de diseño. Un ajuste de un bloque concreto en una página concreta que no justifica tocar la hoja de estilos del tema ni desplegar. Una prueba rápida antes de decidir si ese ajuste merece subir al sistema de diseño de verdad. En esos escenarios, el CSS por bloque evita el clásico «para cambiar esto necesito un desarrollador y una semana».
Cuándo es el principio del problema
El riesgo es estructural: ese CSS vive en la base de datos, dentro del contenido del post, no en el repositorio. No pasa por revisión de código. No aparece en el control de versiones. No se puede buscar con un grep sobre los archivos del tema. No se despliega ni se revierte con el resto del código. Y cuando alguien pregunte por qué ese botón se ve distinto solo en esa página, la respuesta estará escondida en el panel lateral de un bloque que hay que encontrar primero.
Multiplica eso por un sitio de cuatrocientas páginas y tres años de rotación de personas de marketing. Lo que tienes es una capa de estilos invisible, dispersa y sin dueño, que se contradice con el sistema de diseño y que aparecerá como deuda técnica en la siguiente auditoría. Es exactamente el mismo patrón que produjeron durante años los campos de «CSS adicional» de los maquetadores, y sabemos cómo termina.
El criterio que aplicamos en Keliam
Tres reglas, y las escribimos en el documento de entrega del proyecto:
- Si el ajuste se va a repetir, no va aquí. A la segunda vez que necesitas el mismo CSS en otro bloque, deja de ser una excepción y pasa a ser un estilo de bloque o una variación registrada en el tema.
- Restringe la capacidad por rol. El acceso al CSS por bloque debería estar limitado a administradores o a quien mantenga el sitio, no abierto a cualquier editor.
- Audítalo cada trimestre. En los contratos de mantenimiento incluimos una revisión periódica del CSS disperso: se consolida en el tema lo que ha llegado para quedarse y se elimina el resto.
Dicho sin rodeos: es una función pensada para quien sabe lo que hace, y estará disponible para quien no. La decisión de si la dejas abierta es de arquitectura del proyecto, no de preferencia personal.
7. Impacto conjunto de los bloques nuevos de WordPress 7: qué plugins puedes retirar y cuáles no
Toca hacer el recuento honesto, porque el discurso de «el core ya lo hace todo» se repite en cada versión y casi nunca resiste el contacto con una instalación real.
Candidatos serios a desinstalar
El plugin de iconos SVG, si solo lo usabas para insertar pictogramas en el contenido. El plugin de lightbox, si su único trabajo era abrir imágenes de galería a pantalla completa. El plugin de fuentes, si su función era encolar tipografías locales en un tema clásico. Y, con matices, el plugin de optimización de imágenes en subida: si estaba ahí para redimensionar y comprimir lo que llegaba desde el escritorio, el procesamiento en cliente cubre buena parte de ese caso.
Los que no se van
El plugin de SEO no se va, y no solo por las migas de pan: el marcado de datos estructurados, los mapas del sitio, la gestión de canónicas, los metadatos sociales y las redirecciones siguen fuera del core. Los plugins de conversión a formatos modernos y de servicio adaptativo desde CDN tampoco: el procesamiento en cliente ajusta lo que subes, no reescribe los diez años de biblioteca que ya tienes ni sirve el formato óptimo según el navegador que pide la imagen. La caché de página, el firewall, las copias de seguridad y la capa de comercio siguen exactamente donde estaban.
Cómo abordarlo sin romper nada
El orden importa. Actualiza primero en staging, con una copia real de producción. Comprueba después qué sigue haciendo cada plugin candidato, porque muchos hacen más de lo que recuerdas: ese plugin de iconos igual también registra un tipo de contenido o un shortcode que alguien usó en 2022. Retira de uno en uno, con una semana entre cada retirada, y ten a mano el listado de páginas que dependían de esa funcionalidad.
Y mide antes y después. Sin una línea base de tiempo de respuesta del servidor, número de peticiones y peso de página, la sensación de que «va más rápido» no vale nada en una reunión con dirección. Los métodos y las herramientas para hacer esa medición bien están en nuestra guía de auditoría de rendimiento web y métricas clave.
Un aviso de compatibilidad que aplica a todos los bloques nuevos de WordPress 7: el editor usa iframes internos, y eso da conflictos con maquetadores como Elementor, Divi o Bricks. Si tu sitio depende de uno de ellos, la prueba en staging no es opcional. Lo mismo vale para WooCommerce, que tenía actualizaciones de compatibilidad pendientes: no actualices una tienda en producción sin haberla probado antes. También merece la pena revisar la visibilidad por dispositivo, la otra novedad que más cambia el día a día del editor, porque interactúa directamente con los bloques de medios y con cómo se muestran las galerías en móvil.
Conviene tener presente también el estado de la versión: WordPress 7.0.1, publicado el 9 de julio de 2026, corrigió 31 fallos en el core y en el editor de bloques, entre ellos una regresión en wp_kses() que corrompía las declaraciones background-image: url(...) dejándolas como style=")", una incompatibilidad con PHP 8.5 en una función de adjuntos de imagen y un fallo del bloque de navegación con Page List dentro de submenús. Si vas a actualizar ahora, ve directo a la 7.0.1. Y sobre PHP: el mínimo requerido sigue siendo 7.4, aunque el recomendado es 8.3. Por debajo de PHP 8 estás en territorio sin soporte de seguridad, así que lo sensato es actualizar la versión de PHP antes de tocar el core.
Conclusión
Ninguna de estas novedades es titular de nota de prensa. Sumadas, son de las cosas más rentables que trae WordPress 7 para quien mantiene sitios en producción: menos plugins que actualizar, menos JavaScript de terceros en cada página, menos carga de PHP en las horas en que el equipo editorial trabaja y menos dependencia del tema para cosas que deberían ser del core.
El procesamiento de medios en el navegador es, de todo el paquete, lo que más se nota en un servidor real. Los bloques de iconos y migas de pan son ahorro de dependencias con matices que hay que verificar, sobre todo en el lado del SEO. Y el CSS por bloque es la única función del lote que aconsejamos tratar con desconfianza: útil en manos de quien mantiene el sitio, problemática en cuanto se abre a todo el equipo.
La recomendación operativa no cambia respecto a cualquier salto de versión mayor: staging primero, PHP al día, inventario de plugins antes y después, y medición con números. La actualización no es el proyecto. El proyecto es la limpieza que la actualización te permite hacer.
Preguntas frecuentes
¿El bloque de migas de pan sustituye al de mi plugin de SEO?
Visualmente sí, en la mayoría de casos. Para los datos estructurados, no necesariamente. Comprueba si tu plugin de SEO emite el marcado BreadcrumbList de forma independiente al componente visual antes de sustituir nada, y valida el resultado con una herramienta de prueba de resultados enriquecidos.
¿El procesamiento de imágenes en el navegador funciona en todos los navegadores?
Depende de capacidades del navegador del editor. WordPress mantiene el flujo de procesamiento en servidor como alternativa cuando el cliente no puede encargarse, así que no perderás la subida. Lo que puede variar es dónde se hace el trabajo pesado.
¿Puedo desactivar el CSS personalizado por bloque para los editores?
Sí, se gestiona con capacidades de usuario. En proyectos con equipos editoriales amplios recomendamos limitarlo a administradores y a quien mantenga el sitio, y auditar periódicamente lo que se haya añadido.
¿Merece la pena actualizar solo por estas funcionalidades?
Por sí solas, no justifican actualizar una tienda con integraciones delicadas la semana antes de campaña. En un sitio corporativo con un tema de bloques y sin dependencias exóticas, el ahorro en pila de plugins y en carga de servidor sí compensa el trabajo de la actualización.
¿Qué pasa con la colaboración en tiempo real que se anunció?
No está en WordPress 7.0. Se retiró el 8 de mayo de 2026 por superficie de ataque, condiciones de carrera, carga de servidor y eficiencia de memoria, y la RC3 ya salió sin ella. Se pospone a la 7.1. Los artículos de abril de 2026 que la dan por incluida son anteriores al lanzamiento y están desactualizados.
