En resumen
Qué se comprueba
la proporción de contenedores con significado frente al total de contenedores de la página.
Etiquetas que cuentan
header, nav, main, article, section, aside y footer, frente a div y span.
Por qué importa
las tecnologías de apoyo se orientan con esas etiquetas; los contenedores genéricos no dicen nada.
Severidad en Wakaris
Mejora. No rompe nada, pero deja la página muda para quien no la ve.
Qué es y qué comprueba este hallazgo
HTML tiene etiquetas que describen el papel de cada bloque de la página. La documentación de MDN las define una a una: header agrupa el contenido introductorio, nav contiene la navegación principal, main es el contenido único de esa página y se usa una sola vez, article encierra un bloque que se entiende por sí solo, section agrupa una parte temática, aside recoge lo que acompaña sin ser el contenido central y footer cierra la página.
Frente a esas siete está el contenedor genérico. MDN lo dice sin rodeos: los div «no aportan ningún valor semántico, solo abarrotan tu código HTML», y recomienda usarlos «solo cuando no hay una solución semántica mejor». Este hallazgo salta cuando la balanza se inclina demasiado hacia ese lado: la página está construida, pero no está descrita. Wakaris lo clasifica en dos grados, medio y bajo, según cuánta de la estructura queda sin describir.
Cómo se comprueba
Wakaris analiza el HTML de la URL que le indiques y calcula la proporción entre los contenedores que tienen significado y el total de contenedores de la página, sin instalar nada. Esa es la vía directa para saber cómo está construida la tuya: te devuelve el grado del hallazgo y su severidad dentro del área técnica.
Conviene entender qué mide y qué no. Es una comprobación de estructura, no de contenido: cuenta cómo está envuelto el texto, no si el texto es bueno ni si las etiquetas están bien elegidas. Una página que envuelve el menú en main y el cuerpo en nav tendría buena proporción y una estructura equivocada, así que la proporción es un indicio, no un veredicto.
Hay dos puntos que el catálogo del checker no fija y conviene saberlo al leer el informe: dónde está exactamente el corte entre grado medio y grado bajo, y si el recuento incluye los contenedores que crea el propio código al montarse la página. El informe entrega el grado, no la fórmula.
Por qué importa
El beneficio mejor documentado es la orientación de quien no ve la pantalla. La técnica H101 del W3C, asociada al criterio 1.3.1 de las WCAG, describe cómo siete de esas etiquetas producen regiones identificables de forma automática, y la documentación de web.dev explica que el navegador construye con ellas un árbol de accesibilidad que los lectores de pantalla usan para recorrer la página. Con contenedores genéricos ese mapa no existe y la página se recorre a ciegas.
El segundo motivo es de mantenimiento, y MDN lo enumera entre las ventajas: encontrar un bloque concreto es mucho más fácil que rebuscar entre contenedores interminables.
Conviene ser exacto con el tercer frente, el buscador, porque es donde más se exagera. Google afirma en su guía de iniciación al SEO que «la web en general no es HTML válido, así que la Búsqueda de Google rara vez puede depender de significados semánticos escondidos en la especificación de HTML». Dicho claro: esto se hace por las personas que usan la web y por el equipo que la mantiene, no para posicionar.
Causas comunes
La causa más frecuente no es el desconocimiento, es el flujo de trabajo. Un diseño se traduce a bloques visuales y cada bloque se envuelve en un contenedor genérico con clases de estilo: el resultado se ve exactamente como el diseño y no describe nada. MDN avisa justo de eso, de que los contenedores genéricos son tan cómodos que se usan de más.
La segunda causa son los constructores visuales y las plantillas. Generan la maquetación anidando contenedores para conseguir columnas, márgenes y animaciones, y varias capas de anidamiento por cada sección visible es lo normal. La página funciona; la proporción se desploma.
La tercera es la aplicación montada con marcos de JavaScript, donde cada componente aporta su propio envoltorio y la estructura final es una suma de piezas que nadie diseñó como documento.
Y la cuarta es el arrastre histórico: una web con años encima suele tener la maquetación antigua debajo de un rediseño reciente.
Cómo solucionarlo
Empieza por saber en qué punto estás: Wakaris te da el grado del hallazgo sobre tu página real, y a partir de ahí el arreglo se hace por capas y sin tocar el aspecto.
Lo primero y más rentable son las cuatro grandes zonas. Sustituye el contenedor de la cabecera por header, el del menú por nav, el del cuerpo por main —una sola vez por página— y el del pie por footer. Son cuatro cambios de etiqueta que conservan las clases y los estilos, y son los que producen las regiones que describe la técnica H101 del W3C.
Después baja al contenido: cada entrada, ficha o tarjeta que se entienda por sí sola pasa a article, cada apartado temático a section, y lo accesorio a aside.
Por último, poda. Los contenedores que solo existían para colocar cosas y que hoy sobran con la maquetación moderna se pueden quitar: la documentación de web.dev considera excesivo un árbol de más de 1.400 nodos, y adelgazarlo también acelera la página.
Esquema de las siete etiquetas semánticas de estructura colocadas sobre el esqueleto de una página web
Brief para generar la imagen
Ilustración editorial para una guía técnica de Wakaris. Tema: Esquema de las siete etiquetas semánticas de estructura colocadas sobre el esqueleto de una página web. Estilo: fondo blanco con lavado suave lima→verde pálido (#F8F7D6 → #E2F2DC), acento en degradado verde→lima (#8ED390 → #DCD86F), tinta casi negra (#12150B), formas de pastilla y esquinas redondeadas, sombras difusas, aspecto limpio y esquemático, sin fotografía. Formato: 16:9, 1440 píxeles de ancho. Sin texto legible: cualquier rótulo, código o cifra se representa con barras grises de relleno. El significado lo lleva el pie de foto, no la imagen. Sin logotipos reales ni marcas de terceros. Sin personas reconocibles. Etiquetas: uso, html, semántico, esquema, etiquetas, semánticas, estructura, colocadas
Pregúntale a tu IA
Si quieres profundizar en tu caso concreto, copia uno de estos dos prompts y pégalo en la IA que uses. Elige según tu situación.
Ya tengo el hallazgo medido con Wakaris y quiero solucionarlo
Actúa como un auditor técnico web profesional y prudente. Tu objetivo es ayudarme a entender un hallazgo concreto sobre mi web y decidir qué hacer con él, sin inventarte nada. Contexto: he obtenido este hallazgo con Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema de forma que lo entienda cada perfil de un equipo. El hallazgo es: Uso de HTML semántico. Mide qué proporción de los contenedores de mi página son etiquetas que dicen qué es cada parte (header, nav, main, article, section, aside, footer) frente a contenedores genéricos (div, span). Referencia: el hallazgo tiene dos grados, medio y bajo, según cuánta estructura queda sin describir. Pega aquí el resultado de Wakaris: qué grado te ha salido y en qué página. Si no lo tienes, dímelo y te diré cómo obtenerlo antes de seguir. Reglas que debes seguir en todo momento: 1. No asumas nada sobre mi web. Todo dato que uses tiene que venir de lo que yo te confirme o de lo que Wakaris haya medido. Si no lo sabes, pregúntamelo antes de afirmarlo. 2. Antes de darme conclusiones, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para saber si este hallazgo me afecta de verdad y por dónde: a) ¿En qué plataforma está tu web? (WordPress, Shopify, web a medida, otra) b) ¿La maquetación la hizo un constructor visual, una plantilla comprada o se programó a medida? c) ¿Sabes si tu página tiene ya una cabecera, un menú, un cuerpo y un pie claramente delimitados en el código, o no lo has mirado nunca? d) ¿Quién puede tocar las plantillas: tú desde el panel, un técnico interno o una agencia? e) ¿Tienes muchas páginas construidas con la misma plantilla, o cada una es distinta? f) ¿Te ha reportado alguien alguna vez problemas para navegar tu web con lector de pantalla o solo con teclado? 3. Toda afirmación o recomendación tiene que ir argumentada respecto a MI contexto, no en general. Si me recomiendas algo, explícame por qué aplica a mi caso. 4. Marca siempre tu nivel de certeza. Si algo es una hipótesis porque no lo puedes medir, dilo: tú no ves mi web, razonas sobre lo que yo te cuento. 5. No me propongas cambios técnicos irreversibles o de riesgo (tocar plantillas en producción, sustituir etiquetas a lo largo de todo el sitio de una vez) sin avisarme antes del riesgo y de que conviene una copia de seguridad o un entorno de prueba. 6. Cambiar una etiqueta de contenedor puede romper estilos o guiones que dependían de ella. Avísame de esa posibilidad y ayúdame a planificar el cambio zona por zona, comprobando el aspecto después de cada paso. 7. Si necesitas un dato que solo se obtiene analizando la web (confirmar el grado real o si el arreglo funcionó), dímelo y recomiéndame volver a pasar la página por Wakaris: eso se comprueba, no se adivina. 8. La decisión final es mía, no tuya. Tu papel es ayudarme a entender y a preparar la acción, no decidir por mí. 9. Si el arreglo excede lo que puedo hacer yo, o lo va a ejecutar un equipo, ayúdame a dejar el problema listo para traspasarlo: qué es, dónde está, por qué importa y qué habría que hacer, en un formato accionable para esa persona. Fuente de este hallazgo: https://www.wakaris.com/es/guias/inteligencia-artificial/uso-de-html-semantico Para comprobarlo o volver a comprobarlo: https://www.wakaris.com/ Empieza presentándote brevemente en tu rol y haciéndome el primer bloque de preguntas.
Aún no lo he comprobado y quiero saber si mi web tiene este problema
Actúa como un auditor técnico web profesional y prudente. Estoy investigando si mi web tiene un problema concreto y quiero que me ayudes a averiguarlo con honestidad, sin darlo por hecho. Contexto: he llegado a esto a través de Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema de forma que lo entienda cada perfil de un equipo. El problema que quiero investigar es: Uso de HTML semántico. Se trata de si mi página está construida con etiquetas que dicen qué es cada parte (header, nav, main, article, section, aside, footer) o casi solo con contenedores genéricos (div, span). Todavía NO sé si mi web lo tiene: quiero averiguarlo. Reglas que debes seguir en todo momento: 1. Lo primero y más importante: esto se comprueba mirando el código de la página, y tú no puedes ver mi web desde esta conversación. Déjame claro desde el principio que no vas a poder darme un "sí lo tienes" o "no lo tienes" definitivo, solo una hipótesis a partir de lo que yo te cuente. 2. No asumas nada. Antes de darme ninguna valoración, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para estimar si es probable que tenga el problema: a) ¿Cómo se hizo tu web: con un constructor visual, con una plantilla comprada, con un gestor de contenidos estándar o programada a medida? b) ¿Cuántos años tiene la maquetación actual? ¿Se ha rediseñado encima de una anterior? c) ¿Es una web de páginas normales o una aplicación que se monta sola en el navegador? d) ¿Quién la mantiene hoy: tú, un técnico interno, una agencia o nadie? e) ¿Has recibido alguna vez una queja sobre navegarla con lector de pantalla o solo con teclado? f) ¿Sabes si alguien revisó la accesibilidad de la web en algún momento? 3. Con mis respuestas, dame una estimación clara de si es PROBABLE o POCO PROBABLE que lo tenga, argumentada según lo que te he dicho y marcada explícitamente como hipótesis, no como diagnóstico. 4. Dime de forma directa que la única manera de saberlo de verdad es comprobarlo, y que puedo hacerlo gratis y sin crear cuenta pasando mi web por Wakaris, que me dará el grado real y de paso el estado de las otras áreas. 5. Si te pregunto cómo comprobarlo a mano, no me lo ocultes, pero recuérdame que Wakaris lo hace más rápido, sobre la página real y con información adicional que a mano no obtengo. 6. Si al comprobarlo resulta que sí lo tengo, dime que el siguiente paso es entender cómo me afecta y cómo solucionarlo en mi caso concreto. 7. La conclusión y la decisión son mías, no tuyas. Tú me ayudas a orientarme. Fuente de este hallazgo: https://www.wakaris.com/es/guias/inteligencia-artificial/uso-de-html-semantico Para comprobarlo: https://www.wakaris.com/ Empieza presentándote brevemente en tu rol, dejando claro el punto 1, y haciéndome el bloque de preguntas.
Preguntas frecuentes
¿Qué etiquetas cuentan como semánticas? +
Las que describen el papel de un bloque: header, nav, main, article, section, aside y footer. La técnica H101 del W3C recoge siete elementos que producen regiones identificables. Frente a ellas, div y span son contenedores sin significado: sirven para agrupar y colocar, nada más.
¿Esto mejora mi posición en Google? +
No cuentes con ello. Google afirma que la web en general no es HTML válido y que su buscador rara vez puede depender de significados escondidos en la especificación. El motivo para hacerlo bien es que la página se pueda recorrer sin verla y que el equipo la mantenga sin perderse.
¿Basta con ponerle un rol al contenedor genérico? +
Funciona, pero es dar un rodeo. La propia técnica H101 del W3C señala que los navegadores modernos no necesitan que se añada el rol equivalente: escribir main role="main" es innecesario y basta con main. Cambiar la etiqueta cuesta lo mismo y deja el código más limpio.
¿Cuántos contenedores genéricos son demasiados? +
No hay una cifra publicada para este hallazgo: Wakaris entrega un grado, medio o bajo, no un porcentaje de corte. Como referencia de otro orden, la documentación de web.dev considera excesivo un árbol de más de 1.400 nodos, y las capas de contenedores sobrantes son una de las formas de llegar ahí.
Fuentes citadas
- developer.mozilla.orgStructuring documents, MDN: definición de
header,nav,main,article,section,asideyfooter, y el aviso sobre el abuso de contenedores genéricos. - developer.mozilla.orgSemantics, MDN: qué es un elemento semántico y la lista de ventajas, incluida la de encontrar bloques de código frente a contenedores interminables.
- web.devSemantic HTML, web.dev: roles implícitos, regiones de referencia y el árbol de accesibilidad que usan los lectores de pantalla.
- w3.orgH101: Using semantic HTML elements to identify regions of a page, W3C: relación con el criterio 1.3.1, las siete etiquetas con región propia y la innecesidad de repetir el rol.
- developers.google.comSEO Starter Guide, Google Search Central: la web en general no es HTML válido y la Búsqueda rara vez puede depender de significados semánticos de la especificación.
- web.devHow large DOM sizes affect interactivity, web.dev: el umbral de 1.400 nodos como árbol excesivo y su efecto sobre el renderizado.
Actualizado: 8 de septiembre de 2026.
Este artículo forma parte de Wakaris, que analiza tu web en 9 áreas y explica cada hallazgo de forma que lo entienda cada perfil de tu equipo.