# WordPress 7.1 te promete diseño responsive sin CSS: lo que no te cuentan antes del martes
**Categoría:** CMS
**Estilo:** crítico
**Fecha:** 2026-08-17
—
El martes 19 de agosto WordPress 7.1 sale oficialmente, coincidiendo con el cierre de WordCamp US en Phoenix. Si sigues el ecosistema desde fuera, parece el lanzamiento que llevamos pidiendo años: estilos responsive por bloque, estados hover y focus en el editor, breakpoints configurables en theme.json y una Abilities API que por fin deja de sonar a promesa vacía para integraciones con IA. Suena bien. Demasiado bien. Y en mi experiencia, cuando WordPress anuncia que ya no necesitas CSS para algo, lo primero que hago es abrir el inspector del navegador.
Llevo la beta en un par de entornos de prueba desde que salió RC1, y te cuento lo que he visto porque creo que hay una distancia considerable entre el titular de marketing y lo que te vas a encontrar el lunes por la mañana en un proyecto real con veinte plugins, un theme hijo y tres años de CSS acumulado en el customizer.
Responsive en el editor: útil, pero no mágico
La gran novedad son las claves @mobile y @tablet dentro de Global Styles y de cada bloque. Puedes definir tipografía, colores, espaciado y bordes distintos según viewport, con breakpoints por defecto en 480px y 782px que el theme puede redefinir vía settings.viewport en theme.json. Isabel Brison lo explica con claridad en la nota de desarrollo de Make/Core: el estilo base aplica en todos los viewports y los estados responsive lo sobreescriben dentro de su rango.
En la práctica, esto resuelve el 80% de los casos que antes obligaban a meter CSS en el theme hijo: un heading más pequeño en móvil, un padding distinto en tablet, un botón que en desktop tiene borde y en móvil no. Para agencias que mantienen decenas de webs con Gutenberg puro, es un alivio real. Lo digo sin ironía.
Pero —y aquí empieza lo que nadie te resume en el changelog— todo lo que no sea un bloque nativo con soporte completo de estilos sigue fuera del circuito. Tienes un bloque de un plugin de terceros que no expone sus controles de diseño al sistema de estilos? Sigue igual que ayer. Tienes un shortcode legacy incrustado en un bloque HTML? Ni lo mires. Tienes un theme clásico sin theme.json bien montado? Vas a pasar horas migrando antes de sacar partido a esto. WordPress no te lo dice en grande, pero 7.1 asume que ya vives en el ecosistema block-first. Si no es tu caso, el lanzamiento te importa poco.
Los pseudoestados: bienvenidos, con matices
Poder definir hover, focus y active desde el editor es algo que llevábamos pidiendo desde que Gutenberg empezó a parecerse a un page builder serio. Ya no necesitas escribir .wp-block-button__link:hover en un archivo suelto para cambiar el color al pasar el ratón. Bien.
El problema es el mismo de siempre: consistencia entre bloques. Algunos bloques de la comunidad implementan sus propios estados con clases propietarias que no pasan por el sistema unificado. Resultado: defines hover en Global Styles para botones core y tu formulario de contacto sigue con el hover feo del plugin de formularios que instalaste en 2023. No es culpa de WordPress 7.1, pero tampoco desaparece con la actualización.
Abilities API: la apuesta IA que sí importa (y que casi nadie probará)
Para mí, lo más interesante de 7.1 no es el responsive sino la evolución de la Abilities API: ciclo de ejecución filtrable, validación custom y pipeline de descubrimiento compartido. El Field Guide lo deja claro: deja de ser infraestructura y pasa a ser toolkit. Si estás montando integraciones con agentes, automatizaciones o adaptadores de protocolo, aquí es donde WordPress intenta posicionarse frente a headless y frente a soluciones SaaS que te venden «IA para tu web» como plugin de suscripción.
WP Engine ya ha metido Smart Search AI y su servidor MCP en beta abierta. Coincidencia? Seguro que no. El mensaje es claro: quien controle la capa de abilities en WordPress controlará cómo los agentes externos interactúan con tu contenido. Y yo me pregunto —como muchos en foros de desarrollo estos días— si esto abre la puerta a un ecosistema sano de herramientas interoperables o simplemente a otro monopolio donde dos o tres proveedores hosteados se reparten el mercado mientras tu pyme sigue sin saber qué es un MCP.
Media, uploads y la toolbar persistente: mejoras silenciosas
Menos ruido pero más impacto diario: soporte HEIC, AVIF, WebP y UltraHDR; cola de subidas que pausa y reanuda si se cae la conexión; procesamiento de imágenes más orientado al cliente para aligerar el servidor. En hosting compartido barato, esto puede marcar diferencia real. La toolbar de admin que ya no desaparece al entrar en el editor también parece un detalle menor hasta que llevas tres años perdiendo el acceso a «Ver sitio» cada vez que editas una página.
Detalles honestos, bien ejecutados. No venden keynotes, pero sí mejoran el día a dia de quien mantiene webs.
Lo que haría antes del martes
Si mantienes sitios WordPress —y supongo que si lees esto, sí— tienes una ventana estrecha. RC2 ya salió; el feature set está cerrado. Mi checklist es corta:
- Actualiza un staging a 7.1 RC y revisa los bloques críticos en los tres viewports del preview.
- Abre Global Styles y comprueba si tu theme define
settings.viewporto te quedas con los defaults de 480/782px que pueden no encajar con tu diseño. - Revisa plugins de formularios, sliders y ecommerce: son los primeros en romper estilos responsive heredados.
- Si tienes CSS custom para hover/focus en botones o enlaces, anota qué puedes migrar al editor y qué no.
- No toques producción el día 19. Nunca toques producción el día del lanzamiento. Lo aprendí a las malas con 7.0.
WordPress 7.1 no es un salto revolucionario como lo fue 7.0 con la reescritura del admin. Es un release de madurez editorial: cierra carencias que llevábamos arrastrando desde la era «Gutenberg es el futuro, confía». Y precisamente por eso me genera más confianza que muchos anuncios de IA del sector: hacen cosas concretas, documentadas, con trac tickets y field guide. Lo que no hacen es eliminar la necesidad de saber CSS, entender tu theme o auditar plugins de terceros.
Si tu cliente te pregunta el lunes si con 7.1 ya no hace falta diseñador, la respuesta honesta es no. Lo que sí puedes decirle es que el editor deja de ser el cuello de botella para cambios responsive sencillos, y eso —en proyectos con presupuesto ajustado— se traduce en horas facturables que antes se iban en pelear con el customizer.
¿Migrarías mañana un theme clásico sin block theme solo por los estilos responsive de 7.1, o esperarías a que tu stack de plugins confirme compatibilidad antes de tocar producción?