Cualquiera que haya mantenido una web de WordPress en producción durante los últimos años conoce esta escena. El cliente pide algo aparentemente trivial: que un banner que funciona muy bien en escritorio desaparezca en móvil porque empuja el contenido importante por debajo del pliegue. Nadie discute que sea razonable. El problema es que, hasta ahora, esa petición de dos minutos se convertía en una decisión de arquitectura. O escribías CSS a medida con una media query y una clase que había que recordar seis meses después, o instalabas un plugin de visibilidad responsive, o —lo más habitual— asumías que ya que ibas a necesitar esto una y otra vez, mejor montar la web entera sobre Elementor o Divi.
WordPress 7.0 «Armstrong», publicada el 20 de mayo de 2026, cierra ese agujero. El editor de bloques incorpora control de visibilidad por dispositivo de forma nativa: escritorio, tableta y móvil, de manera independiente, sin escribir una línea de CSS y sin instalar nada. Fernando Tellado, una de las voces más veteranas del ecosistema WordPress en español, sostiene que este es el cambio más relevante del día a día de toda la versión, por encima de las novedades que ocuparon más titulares. Coincidimos, y no por entusiasmo: coincidimos porque es el tipo de funcionalidad que elimina deuda técnica acumulada en cientos de instalaciones reales.
Este artículo forma parte de nuestra guía completa para actualizar a WordPress 7 en entornos de empresa, y se centra en una sola cosa: qué permite exactamente el nuevo control, cómo usarlo con criterio y —esto es lo que más nos importa— dónde están los límites. Porque una herramienta que permite ocultar contenido con dos clics es también una herramienta que permite hacerse daño en rendimiento, en SEO y en accesibilidad con la misma facilidad.
1. El agujero que tenía el editor de bloques
El editor de bloques nació en 2018 con una promesa clara: maquetar sin código. Durante siete años cumplió esa promesa a medias, porque le faltaba una pieza que cualquier maquetador comercial daba por hecha desde el primer día. Podías construir una portada entera arrastrando bloques, ajustar espaciados, tipografías y colores desde la interfaz, y luego chocabas contra un muro en cuanto necesitabas que esa portada se comportara distinto en un móvil.
La respuesta oficial durante todo ese tiempo fue que el diseño debía ser fluido y adaptarse solo. En teoría es la postura correcta. En la práctica, cualquiera que haya diseñado una página comercial sabe que hay elementos que no se adaptan: se estorban. Un carrusel de logotipos de clientes que en escritorio da credibilidad y en móvil son ocho pantallas de scroll. Una tabla comparativa de seis columnas que en móvil se convierte en una barra de desplazamiento horizontal que nadie usa. Un vídeo de fondo decorativo que en escritorio queda bien y en una conexión móvil se come el presupuesto de datos del visitante antes de que lea el titular.
Las tres salidas y lo que costaba cada una
La primera salida era el CSS a medida. Añadías una clase adicional al bloque desde los ajustes avanzados y escribías una media query en el hijo del tema o en el personalizador. Funciona, es limpio y es lo que hemos hecho en agencia durante años. El coste no está en escribirlo, está en mantenerlo. Ese CSS vive en un archivo que el cliente no ve, referenciado por una clase que el cliente puede borrar sin querer al editar el bloque. Cuando alguien duplica la sección para crear una página nueva, la clase viaja con ella y el comportamiento se replica sin que nadie lo haya decidido. Y cuando dos años después el cliente cambia de agencia, el nuevo equipo se encuentra con doscientas líneas de reglas de ocultación sin documentar y no se atreve a tocar ninguna.
La segunda salida era el plugin de visibilidad. Hay varios buenos y resuelven el problema en cinco minutos. El coste aquí es distinto: has añadido una dependencia de terceros a la capa de presentación de tu web. Ese plugin tiene que seguir mantenido, tiene que seguir siendo compatible con cada versión del editor, y si un día deja de actualizarse te quedas con un sitio donde las reglas de visibilidad están guardadas en un formato propietario dentro de los atributos de los bloques. Desinstalarlo no devuelve la web a su estado anterior: devuelve una web donde todo se ve en todas partes y nadie recuerda qué debía ocultarse.
La tercera salida, y la más común, era rendirse y montarlo todo sobre un maquetador. Elementor y Divi llevan años ofreciendo interruptores de visibilidad por dispositivo en cada elemento, y para mucha gente esa fue una razón de peso —a veces la razón principal— para instalar un maquetador completo en un sitio que no lo necesitaba para nada más. El coste de esa decisión es el mayor de los tres: una licencia anual, una capa de abstracción sobre el contenido, marcado HTML considerablemente más pesado, y un acoplamiento tan profundo que migrar fuera del maquetador equivale a rehacer la web. Hemos visto proyectos donde toda esa carga se arrastraba durante años por dos secciones que había que ocultar en móvil.
2. Qué permite exactamente la visibilidad por dispositivo
Lo que llega en WordPress 7.0 es deliberadamente simple, y esa simplicidad es una virtud. Cada bloque puede marcarse como visible u oculto de forma independiente en tres contextos: escritorio, tableta y móvil. Los tres controles son independientes entre sí, así que puedes mostrar un bloque solo en móvil, solo en escritorio, en escritorio y tableta pero no en móvil, o cualquier otra combinación. No hay que crear clases, no hay que recordar nombres y no hay que abrir un archivo CSS.
El control se aplica a cualquier bloque, incluidos los contenedores. Esto último es lo que lo hace realmente útil: al poder ocultar un grupo o una columna completa, no estás gestionando visibilidad elemento a elemento, sino a nivel de sección. Puedes construir una cabecera pensada para escritorio y otra pensada para móvil como dos grupos hermanos, cada uno visible solo donde corresponde, y editarlas por separado sin que una interfiera con la otra.
La configuración se guarda como parte de los atributos del bloque, en el mismo contenido del post. Esto tiene una consecuencia práctica importante que conviene entender antes de empezar: la información de visibilidad viaja con el contenido. Si exportas, si migras, si duplicas una página, las reglas van dentro. No dependen de un archivo de tema ni de un plugin activo. Es, en términos de mantenimiento, exactamente lo contrario de las tres salidas del apartado anterior.
Los puntos de corte
El sistema trabaja con las tres categorías estándar del ecosistema —escritorio, tableta y móvil— y no con puntos de corte arbitrarios que definas tú bloque a bloque. Para el noventa y cinco por ciento de los casos reales esto es suficiente y además es sano: obliga a pensar en tres escenarios en lugar de inventar seis. Si tu diseño necesita un comportamiento en un ancho concreto que no encaja en esas tres categorías, sigues necesitando CSS. La diferencia es que ahora ese CSS será la excepción documentada y no la norma, que es justo donde debe estar.
3. Cómo se usa en la práctica
La visibilidad por dispositivo se entiende mejor con casos concretos que con descripciones abstractas. Estos son cuatro patrones que aparecen una y otra vez en proyectos reales y que hasta ahora resolvíamos con apaños.
Cabeceras distintas para móvil y escritorio
Es el caso más limpio y probablemente el que más tiempo ahorra. En escritorio quieres una cabecera con logotipo, menú horizontal completo, buscador visible y un botón de contacto. En móvil quieres logotipo, icono de menú y un botón de llamada directa. Intentar que la misma estructura haga las dos cosas mediante CSS siempre acaba en un compromiso feo donde ninguna de las dos versiones queda del todo bien.
Con el nuevo control construyes dos bloques de cabecera completos dentro de la plantilla, cada uno con sus propios elementos y su propio diseño, y marcas uno como visible solo en escritorio y otro solo en móvil y tableta. Cada versión se edita de forma autónoma. Cuando el cliente pide cambiar el texto del botón móvil, se cambia el botón móvil, no se toca una regla global que podría afectar a otra cosa.
Tablas que se convierten en listas
Las tablas comparativas son el enemigo natural del diseño responsive. Una tabla de precios de cinco planes por ocho características es perfectamente legible en un portátil e ilegible en un teléfono. Las soluciones habituales —scroll horizontal, reducir la tipografía, colapsar columnas con JavaScript— van desde lo mediocre hasta lo directamente hostil para el usuario.
El patrón que recomendamos es mantener la tabla real para escritorio y tableta, y crear una versión en formato lista o tarjetas apiladas para móvil, con la misma información reorganizada. Cada visitante recibe el formato que su pantalla puede sostener. Es más trabajo de edición inicial, sí, pero es la única manera honesta de resolverlo, y ahora ese trabajo no requiere ni un plugin ni un desarrollador.
CTA de escritorio y CTA de móvil
Un formulario de contacto de seis campos incrustado a media página convierte razonablemente bien en escritorio. En móvil, ese mismo formulario es un muro. Muchos negocios prefieren en móvil un botón de llamada o de WhatsApp, porque el usuario que está en el teléfono quiere hablar, no rellenar campos.
Aquí el control de visibilidad permite algo que antes exigía lógica de servidor o duplicar la página entera: servir la llamada a la acción adecuada al contexto del dispositivo. Es probablemente el uso con retorno más directo de todos, y merece la pena medirlo con datos antes y después en lugar de darlo por bueno.
Retirar decoración que solo penaliza en móvil
Vídeos de fondo, ilustraciones a pantalla completa, animaciones de scroll, carruseles de logotipos. En escritorio aportan una sensación de calidad que el cliente valora. En móvil pesan, empujan el contenido hacia abajo y en muchos casos son la razón directa de que las métricas de rendimiento se hundan. Poder ocultarlos en móvil desde la interfaz, sin discutir con nadie ni tocar código, elimina una fricción que en la práctica hacía que esos elementos se quedaran ahí para siempre.
Ahora bien, sobre este caso concreto hay una advertencia importante que merece su propio apartado, porque es donde más gente se equivoca.
¿Cuánto CSS de apaño arrastra tu WordPress?
Auditamos tu instalación, identificamos las reglas de visibilidad y los plugins que ya no necesitas, y planificamos la migración al control nativo sin romper páginas en producción.
4. Lo que hay que entender antes de abusar
Este es el apartado que separa usar la funcionalidad de usarla bien. La visibilidad por dispositivo es un control de presentación, y eso significa que hay tres cosas que no hace, tres cosas que la mayoría de la gente asume que sí hace.
Ocultar no es dejar de cargar
La confusión más extendida y la más cara. Cuando marcas un bloque como oculto en móvil, ese bloque sigue existiendo en el HTML que recibe el navegador del visitante. Lo que ocurre es que no se pinta en pantalla. El marcado se descarga, se procesa y ocupa memoria. Si dentro de ese bloque hay imágenes, la carga diferida puede evitar que se descarguen realmente, pero no puedes darlo por hecho. Si hay un iframe de vídeo, un mapa incrustado o un script de terceros, hay muchas probabilidades de que se cargue igualmente y de que su coste aparezca íntegro en tus métricas.
Traducido a consecuencias: si estás ocultando un carrusel pesado en móvil pensando que con eso has arreglado tu rendimiento móvil, es probable que no hayas arreglado nada. Has quitado el impacto visual y el desplazamiento de contenido, que ya es algo, pero el peso de descarga y el trabajo del hilo principal pueden seguir ahí. Para eliminar el coste de verdad hay que no generar el contenido, y eso sigue siendo territorio de servidor: carga condicional, plantillas distintas o directamente no incluir el elemento. Antes de decidir qué ocultar, conviene medir con datos reales siguiendo una auditoría de rendimiento web con métricas y herramientas concretas, y comprobar después si el número se ha movido.
El impacto en Core Web Vitals es real, pero no siempre el que esperas
Ocultar elementos por encima del pliegue sí puede mejorar el LCP, porque cambias cuál es el elemento más grande que se pinta. Reducir contenido que se inserta tarde sí ayuda al CLS. Pero ocultar contenido que estaba abajo del todo y que nunca competía por el hilo principal no va a mover ninguna aguja. Y en el caso contrario, duplicar secciones —una versión escritorio y una versión móvil de la misma cabecera— aumenta el tamaño del documento HTML para todos los visitantes, porque ambas viajan en la respuesta.
Es un intercambio, no una mejora gratuita. En una cabecera es despreciable. Si empiezas a duplicar secciones largas por toda la web, el documento engorda y acabas pagando en tiempo de respuesta lo que ganas en experiencia. Si el rendimiento es una prioridad en tu proyecto, merece la pena entender cómo se relacionan estas decisiones con las Core Web Vitals y su efecto en el posicionamiento antes de generalizar el patrón.
Contenido distinto para Google
Google rastrea principalmente con un agente móvil. Esto tiene una implicación directa que mucha gente pasa por alto: el contenido que ocultas en móvil sigue estando en el HTML, así que Google lo ve, pero un contenido oculto por CSS históricamente ha recibido menos peso que el contenido visible. No es una penalización ni nada parecido, es una cuestión de relevancia percibida.
El riesgo serio no es ese, sin embargo. El riesgo serio es acabar con versiones sustancialmente distintas del mismo contenido según dispositivo. Si tu descripción de producto completa solo se muestra en escritorio y en móvil sirves un resumen de dos frases, estás en terreno resbaladizo. La regla práctica que aplicamos en agencia es sencilla: la visibilidad por dispositivo es para presentación, no para contenido sustantivo. Oculta decoración, oculta duplicados de navegación, oculta versiones alternativas del mismo mensaje. No ocultes información que solo existe en una versión.
Accesibilidad: el punto ciego
Si ocultas un bloque con las técnicas correctas, un lector de pantalla tampoco lo anuncia, y eso normalmente es lo que quieres. El problema aparece con los duplicados. Cuando tienes dos cabeceras, dos menús o dos llamadas a la acción con el mismo destino, tienes elementos repetidos en el documento. Si la ocultación se implementa mal —o si un usuario navega con CSS desactivado, algo más común de lo que parece en entornos corporativos con navegadores restringidos— ese usuario se encuentra dos menús idénticos seguidos.
Hay un segundo detalle que casi nadie revisa: el orden de tabulación. Un elemento oculto visualmente pero todavía enfocable con teclado crea un salto invisible, donde el foco desaparece de la pantalla y el usuario no sabe dónde está. Cuando montes patrones de duplicación, prueba la página con el teclado de arriba abajo. Es un minuto de trabajo y detecta el noventa por ciento de estos fallos. La accesibilidad, además, fue una de las áreas que WordPress 7.0.1 reforzó el 9 de julio de 2026 en la interfaz de revisiones visuales, señal de que el equipo de core sigue tratándola como algo que se corrige, no como algo opcional.
Y una nota sobre gobernanza
Un control tan accesible se usa mucho. En un equipo de marketing de cinco personas editando páginas, en seis meses puedes tener docenas de bloques ocultos en algún dispositivo sin que nadie tenga una visión de conjunto. Recomendamos documentar una norma interna desde el principio: qué se puede ocultar, qué no, y quién revisa. Sin eso, la deuda que acabas de eliminar del CSS reaparece dentro del contenido, que es un sitio bastante peor para tenerla.
5. Comparativa honesta con Elementor y Divi
La pregunta que nos llega desde que se publicó la versión es siempre la misma: ¿puedo cancelar la licencia del maquetador? La respuesta honesta es que depende, y conviene ser preciso sobre qué cubre ya el core y qué no.
Lo que el core iguala es el caso de uso más frecuente. Mostrar y ocultar por dispositivo, en cualquier bloque, incluidos contenedores, sin código y guardado en el propio contenido. Si esa era la razón principal por la que tenías un maquetador instalado, ahora esa razón ha desaparecido. Y el resultado es mejor, porque el marcado que genera el editor de bloques es sensiblemente más ligero que el de un maquetador y no arrastra el andamiaje de divs anidados que caracteriza a estas herramientas.
Lo que los maquetadores siguen ofreciendo por encima del core es una lista concreta y no despreciable. Puntos de corte personalizables, que permiten definir anchos propios en lugar de tres categorías fijas. Condiciones de visualización más allá del dispositivo: por rol de usuario, por fecha, por estado de sesión, por parámetros de URL. Valores responsive para cada propiedad de diseño, no solo visibilidad, de modo que puedes dar un tamaño de fuente distinto por dispositivo sin ocultar nada. Y ecosistemas de widgets y plantillas que aceleran mucho el trabajo de un equipo que no toca código.
| Capacidad | WordPress 7 core | Elementor / Divi |
|---|---|---|
| Ocultar por dispositivo (3 categorías) | Sí, nativo | Sí |
| Puntos de corte personalizados | No | Sí |
| Visibilidad por rol, fecha o sesión | No | Sí (según versión) |
| Valores de diseño distintos por dispositivo | Parcial | Sí, completo |
| Dependencia de licencia anual | Ninguna | Sí |
| Peso del marcado generado | Bajo | Alto |
Nuestra recomendación práctica: si tu web es un sitio corporativo, un blog o una landing y usabas el maquetador básicamente para maquetar y ocultar cosas en móvil, es buen momento para planificar la salida. Si dependes de condiciones de visualización avanzadas, de un ecosistema de widgets concreto o tienes cientos de páginas ya construidas, no canceles nada: la migración costaría más que la licencia durante varios años. Conviene además tener presente que Elementor está en plena transición hacia su nuevo motor, y merece la pena entender qué cambia con el editor atómico de Elementor 4 antes de tomar una decisión en cualquiera de las dos direcciones.
Un aviso técnico añadido, que aplica tengas o no maquetador: el editor de WordPress 7 pasa a usar iframes internos, y eso ha generado conflictos con Elementor, Divi y Bricks. No actualices una web que dependa de un maquetador sin probarlo antes en un entorno de pruebas. Lo mismo vale para tiendas WooCommerce, que tenían actualizaciones de compatibilidad pendientes cuando salió la versión.
6. Migrar los apaños que ya tienes
Si llevas años manteniendo la web, tienes tres capas de apaños superpuestas y probablemente no sepas del todo cuáles siguen activas. Este es el orden de trabajo que seguimos nosotros.
Primero, inventario. Busca en el CSS del tema hijo y en el CSS adicional del personalizador todas las reglas que contengan display: none dentro de una media query. Anota el selector de cada una y localiza dónde se aplica. Es habitual encontrar reglas que apuntan a clases que ya no existen en ninguna página, restos de rediseños antiguos. Esas se pueden eliminar sin más, pero documenta lo que borras.
Segundo, plugins. Revisa qué plugins de visibilidad o de control responsive tienes activos y cuántos bloques dependen realmente de ellos. Aquí hay una trampa clásica: desactivar el plugin no revierte las reglas, deja el sitio con todo visible en todas partes. La forma segura de comprobarlo es desactivar en un clon de la web y recorrer las páginas principales en los tres tamaños, no en producción un viernes por la tarde.
Tercero, migración por lotes. No conviertas trescientas páginas de golpe. Empieza por las plantillas globales —cabecera, pie, barras laterales—, porque ahí es donde está concentrado el mayor volumen de reglas y donde el retorno es inmediato. Luego las páginas de mayor tráfico. El contenido antiguo del blog puede esperar indefinidamente; en muchos casos no merece la pena tocarlo nunca.
Cuarto, verificación. Después de cada lote, revisa las páginas afectadas en los tres tamaños y comprueba que las métricas no se han movido en la dirección equivocada. Un error muy típico de estas migraciones es dejar activos simultáneamente el CSS antiguo y el control nuevo sobre el mismo bloque, con lo que acabas con un elemento oculto por dos mecanismos distintos y nadie entiende por qué no aparece cuando lo activa desde el editor.
Quinto, retirada. Solo cuando todo lo anterior esté verificado, elimina el CSS obsoleto y desinstala el plugin. Y déjalo escrito en algún sitio: qué se retiró, cuándo y por qué. El próximo que abra ese proyecto lo agradecerá, aunque el próximo seas tú.
Si en el mismo movimiento vas a actualizar la instalación, aprovecha para revisar el resto de cambios de la versión: el nuevo escritorio basado en DataViews altera bastante los flujos de trabajo de los editores de contenido, y conviene que el equipo lo vea antes en un entorno de pruebas y no el lunes por la mañana en producción.
Conclusión
La visibilidad por dispositivo no es la novedad más vistosa de WordPress 7, pero es la que más veces vas a usar. Cierra un hueco que llevaba siete años obligando a los equipos a elegir entre mantener CSS a mano, depender de un plugin o instalar un maquetador completo por una necesidad que debería haber sido trivial. Que ahora se resuelva desde la interfaz, sin dependencias y guardado en el propio contenido, es una mejora de mantenimiento tan grande como de diseño.
Dicho eso, es una herramienta de presentación y solo eso. No reduce lo que se descarga, no arregla el rendimiento por sí sola y usada sin criterio genera contenido duplicado, problemas de accesibilidad y discrepancias entre lo que ve el usuario y lo que ve Google. La diferencia entre una web que mejora con esta funcionalidad y una que empeora está enteramente en el criterio con que se aplique.
Nuestra recomendación es la de siempre con cualquier cambio de core: prueba en staging, migra por lotes, mide antes y después, y documenta lo que retiras. La actualización 7.0.1 del 9 de julio de 2026 corrigió 31 errores en core y editor, así que si estás planificando el salto ahora, parte de esa versión o posterior.
Preguntas frecuentes
¿Un bloque oculto en móvil se descarga igualmente?
Sí. El marcado viaja en el HTML de la respuesta y el navegador lo procesa aunque no lo pinte. Las imágenes con carga diferida pueden llegar a no descargarse, pero los scripts, iframes e incrustaciones de terceros normalmente sí lo hacen. Si tu objetivo es reducir peso real, necesitas carga condicional en servidor, no visibilidad en cliente.
¿Puedo definir mis propios puntos de corte?
No con el control nativo. WordPress 7 trabaja con escritorio, tableta y móvil. Para anchos específicos sigues necesitando CSS con media queries, aunque ahora será un caso puntual y no la mecánica habitual de todo el sitio.
¿Esto perjudica al SEO?
No por sí mismo. Ocultar elementos decorativos o versiones alternativas de la navegación es una práctica normal y aceptada. El problema aparece cuando ocultas contenido sustantivo, porque acabas sirviendo versiones distintas de la página según dispositivo y Google rastrea principalmente con agente móvil. Como norma: presentación sí, contenido no.
¿Puedo desinstalar ya mi plugin de visibilidad?
No de golpe. Desactivarlo deja todo visible en todas partes, no revierte al estado anterior. Migra primero los bloques al control nativo, verifica en un clon del sitio en los tres tamaños, y solo después retira el plugin.
¿Merece la pena dejar Elementor o Divi por esto?
Si el maquetador estaba ahí sobre todo por la maquetación y el control responsive, sí merece la pena estudiarlo, y ganarás en peso de marcado y en ausencia de licencias. Si dependes de condiciones avanzadas de visualización, de widgets concretos o tienes un volumen grande de páginas ya construidas, el coste de migrar supera al de mantener la licencia. Es una decisión de números, no de preferencia.
¿Afecta esto a mi tema actual?
El control funciona sobre bloques, así que su encaje es natural en temas de bloques. En temas clásicos con áreas construidas fuera del editor, el alcance es menor. Y en cualquier caso, el cambio a iframes internos del editor puede generar conflictos con maquetadores y con WooCommerce: prueba en staging antes de actualizar producción.
