El problema empezó como empiezan casi todos los problemas “invisibles” de SEO, con una sensación rara: la página se veía bien en escritorio y en móvil, pero las herramientas me avisaban de que había dos H1. Mi caso era muy concreto. Había creado un bloque para escritorio y tablet, y otro distinto para móvil. Los dos llevaban su propio H1, porque el diseño, el orden de elementos y la jerarquía visual no eran iguales. En pantalla solo se mostraba uno, pero el código fuente tenía los dos.
TOC
En Avada es muy fácil construir una cabecera “doble” para resolver necesidades de diseño. Se crea un contenedor para escritorio, se duplica, se adapta para móvil y se usa la opción de visibilidad para que cada uno se muestre donde toca. En el editor queda impecable y el resultado se ve correcto.
El problema aparece cuando el elemento que duplicas contiene un H1. Aunque el bloque de móvil esté oculto en escritorio, y el de escritorio esté oculto en móvil, ambos existen en el HTML que se entrega al navegador. De cara a SEO, eso suele contarse como H1 duplicado, porque el robot no “ve” como un humano. El robot lee el código.
Avada tiene un sistema de visibilidad muy cómodo para mostrar u ocultar elementos según el tamaño de pantalla. Ese sistema, aplicado a contenedores, columnas o elementos, suele funcionar con CSS. El resultado es que el elemento puede quedar con display:none o similar en determinadas resoluciones, así que no se muestra.
El matiz importante es que ocultar con CSS no elimina el elemento del HTML. El contenido sigue existiendo en el DOM, solo que está escondido. Si ese contenido incluye un H1, el H1 está en el código y puede contarse como duplicado. Esto no es un fallo “tuyo”, es el comportamiento normal de la visibilidad basada en CSS cuando se usa para responsive.
La forma de salir de dudas es mirar la página como la mira un crawler. Los avisos de plugins, extensiones o auditorías ayudan, pero lo que te da la certeza es comprobar el código que se entrega.
Estas son las comprobaciones que más claras me resultaron para detectar el duplicado y asegurarme de que no era una falsa alarma por caché o por el constructor.
<h1.Un H1 duplicado no suele hundir una página por sí solo, pero sí introduce ruido. La etiqueta H1 debería representar el tema principal, y ayuda a que Google y otros sistemas entiendan la estructura. Dos H1 distintos, o dos H1 repetidos, pueden diluir ese foco semántico.
También hay una parte de accesibilidad. Lectores de pantalla y tecnologías asistivas usan la estructura de headings para navegar. Cuando la jerarquía se repite o se contradice, la navegación se vuelve más confusa. En proyectos donde el contenido se consume con rapidez o se usa como referencia, una estructura limpia se nota.
La salida buena, la que deja el código limpio, es usar la lógica de renderizado de Avada. En Avada suele aparecer como Rendering Logic o dentro de Conditional Rendering, según versión y elemento. El principio es el mismo: en vez de ocultar por CSS, Avada decide si ese contenedor se renderiza o no. Si no se renderiza, no existe en el HTML.
Ese matiz es el que elimina el H1 duplicado sin obligarte a rehacer la maqueta. Tu diseño sigue igual, con dos bloques separados. Lo único que cambia es la forma en la que Avada decide si el bloque debe “nacer” en el HTML, en vez de nacer siempre y luego ocultarse.
Documentación oficial de Avada sobre Conditional Rendering
En mi caso no era un “escritorio vs móvil” clásico. El bloque de escritorio también me servía para tablet, y el de móvil era distinto. Eso obliga a pensar la lógica en tres estados, no en dos. Si te limitas a “Desktop” en un lado y “Mobile” en otro, te dejas tablet en tierra de nadie o, peor, haces que tablet cargue dos bloques.
La solución fue plantearlo como dos grupos. Un grupo para Desktop OR Tablet con su H1, y otro grupo para Mobile con su H1. Así tablet se comporta como escritorio, y móvil mantiene su diseño específico, sin que el HTML cargue dos H1 a la vez.
Los nombres exactos pueden variar ligeramente según la versión de Avada, pero el flujo es estable. Lo importante es que lo apliques en el nivel correcto, normalmente el Container o, si te encaja mejor, la Column que contiene el H1. Aplicarlo al contenedor suele ser más robusto, porque te evita que se renderice todo el bloque, no solo el heading.
Este fue mi procedimiento, tal cual lo hice, sin tener que rehacer el diseño ni mover el H1 fuera de su bloque.
Cuando cambias lógica de renderizado, es fácil pensar que no ha funcionado si sigues viendo los dos H1 en una primera revisión. El 80 por ciento de esos sustos vienen de caché, de minificación o de que estás viendo una versión guardada en el navegador.
Lo que me funcionó para comprobarlo con seguridad fue hacer la verificación en condiciones, con una secuencia simple, sin mezclar herramientas a medias.
<h1 otra vez.Hay un escenario en el que no hace falta tener dos H1. Si el texto del H1 es idéntico en todos los dispositivos y solo cambian tamaño, saltos de línea o espaciados, un enfoque más limpio es dejar un solo H1 y ajustar el diseño con opciones responsive. Avada permite ajustar tipografías, márgenes y tamaños por breakpoints, y con eso puedes conseguir que un único H1 funcione en todas las resoluciones.
Esta alternativa no me valía porque mi bloque móvil era distinto, no era solo un cambio de tamaño. Aun así, merece la pena mencionarla, porque evita duplicar contenido y reduce complejidad. Cuando se puede, un único H1 con ajustes responsive suele ser el camino más simple.
La lógica de renderizado es potente, pero se puede usar mal. En mi caso, el error más probable habría sido olvidarme de tablet o dejar tablet en ambos bloques. Eso vuelve a crear el problema original, solo que de otra manera.
Estos son los fallos que conviene vigilar cuando aplicas esta solución, sobre todo si estás construyendo layouts distintos por dispositivo.
Al terminar, quise asegurarme de que no solo había “arreglado el aviso”, sino que el HTML quedaba coherente. En páginas donde tienes muchos módulos y variantes por dispositivo, una revisión rápida evita que un detalle se cuele.
Esta es la lista que yo seguiría si tuviera que repetirlo mañana en otra página hecha con Avada.
La lección aquí no va de “tener o no tener dos diseños”, sino de entender la diferencia entre ocultar y no renderizar. Avada te deja hacer ambas cosas, y las dos tienen su sitio. Cuando entra en juego la semántica del HTML, el rendimiento y el SEO, la lógica de renderizado deja de ser un extra y se convierte en una herramienta básica.
Si estás construyendo layouts distintos para móvil y para escritorio o tablet, el enfoque de dos bloques sigue siendo válido. La clave es que el bloque que no toca no debe estar en el HTML. En mi caso, el cambio de Visibility a Rendering Logic, sumando el OR para Desktop y Tablet, fue la diferencia entre una página “que se ve bien” y una página con código limpio.
Leave a Comment