HTML semántico: por qué la estructura importa para SEO y accesibilidad

Hay un ejercicio que hacemos en el estudio cuando auditamos una web y que siempre sorprende al cliente: desactivamos todos los estilos y le enseñamos la página tal y como la lee una máquina. De repente desaparecen los colores, las columnas y las tipografías, y queda solo la estructura. En algunas webs se lee como un documento ordenado, con su título, sus apartados y sus listas. En otras aparece una sopa de textos sueltos donde el menú, el contenido y el pie se confunden.

Las dos webs, con estilos, se veían igual de bien. La diferencia está en algo que no se ve: las etiquetas HTML que alguien eligió al construirla. Eso es el HTML semántico, y es una de esas decisiones pequeñas que sostienen mucho. Le cuenta a Google qué es importante, le permite a una persona ciega moverse por la página en segundos y hace que el código sea más fácil de mantener años después.

Esta guía va de esas etiquetas: cuáles importan, por qué y cómo comprobar si tu web las usa bien.

01Qué significa «semántico» en una página web

HTML es el lenguaje con el que se escribe el contenido de una web. Cada fragmento va envuelto en una etiqueta: <p> para un párrafo, <h2> para un título de sección, <nav> para la navegación. Semántico quiere decir que la etiqueta describe qué es el contenido, no cómo se ve.

Con CSS, cualquier etiqueta puede tener cualquier aspecto. Un <div> puede parecer un botón, un <span> puede parecer un titular enorme. A la vista da igual. Pero el navegador, los buscadores y las tecnologías de apoyo (lectores de pantalla, controles por voz, lectores de modo lectura) no miran el aspecto: leen la etiqueta. Si un titular está marcado como <div class="titulo-grande">, para ellos es un texto más.

La idea de fondo es sencilla: elegir siempre el elemento que mejor describe el significado, y dejar el aspecto para el CSS. Cuando se hace así, la misma página funciona bien vista, escuchada, leída en modo lectura, traducida automáticamente o rastreada por un buscador.

02Los landmarks: el mapa de la página

Los landmarks o regiones son las grandes zonas de una página. HTML tiene elementos específicos para cada una:

Para alguien que usa un lector de pantalla, estas regiones son atajos. Con una tecla salta directamente al contenido principal, sin escuchar otra vez el menú entero en cada página. Para un buscador, son pistas claras de qué parte de la página es la que importa y cuál se repite en todo el sitio.

Lo que funciona: un único <main> por página, el menú dentro de <nav> y cada <section> con su propio encabezado. Si una sección no tiene título, probablemente sea un <div> y no pasa nada: el <div> sigue siendo perfecto para agrupar cosas con fines de diseño.

03Encabezados: el índice que nadie ve y todos usan

Si tuviera que quedarme con una sola parte del HTML semántico, serían los encabezados, de <h1> a <h6>. Forman el índice de la página.

Las encuestas que WebAIM realiza periódicamente a usuarios de lectores de pantalla llevan años señalando lo mismo: la forma más habitual de encontrar información en una página larga es saltar de encabezado en encabezado. Es como hojear un libro por sus títulos. Si los encabezados están bien, la persona entiende la página en diez segundos. Si los títulos visuales están marcados como párrafos en negrita, esa persona tiene que escuchar todo de corrido.

A Google le pasa algo parecido: los encabezados le ayudan a entender los temas de la página y cómo se relacionan. Y desde que los resultados con IA citan fragmentos concretos, una sección bien titulada es también un fragmento más fácil de extraer y citar.

Reglas que funcionan

• →Un <h1> que diga de qué va la página, normalmente el título visible principal.
• →<h2> para cada sección principal y <h3> para subsecciones dentro de ellas.
• →Niveles en orden: de un <h2> se baja a un <h3>, no a un <h5> porque «tenía el tamaño que queríamos».
• →El tamaño visual se controla con CSS; el nivel lo decide la estructura.
• →Textos de encabezado que informen por sí solos («Precios y horarios») mejor que ingeniosos sin contexto («Hablemos de números»).

El criterio de WCAG 2.2 relacionado es el 1.3.1 (Información y relaciones): lo que se transmite visualmente con la presentación tiene que estar también en la estructura.

04Botones, enlaces y la diferencia que más se nota

Esta es la confusión más frecuente que encontramos en auditorías, y la que más afecta a personas que navegan con teclado.

• →Un enlace (<a href>) lleva a otro sitio: otra página, otra sección, un archivo.
• →Un botón (<button>) hace algo en la página actual: abre un menú, envía un formulario, añade al carrito.

Cuando se usa el elemento correcto, el navegador regala muchas cosas: el elemento recibe el foco con el tabulador, se activa con Intro (y el botón también con la barra espaciadora), el lector de pantalla anuncia «botón» o «enlace» y su estado. Cuando se fabrica un botón con un <div> y un poco de JavaScript, todo eso hay que reconstruirlo a mano, y casi siempre se queda algo por el camino.

Compara estas dos versiones del mismo componente:

<!-- Se ve igual, pero el teclado y el lector de pantalla no lo entienden -->
<div class="btn" onclick="abrirMenu()">
  <img src="menu.svg">
</div>
<!-- Versión semántica: enfocable, anunciada y con nombre -->
<button type="button" aria-expanded="false" aria-controls="menu-principal">
  <img src="menu.svg" alt="">
  <span class="visually-hidden">Abrir menú</span>
</button>

La segunda versión tiene un nombre accesible («Abrir menú»), un estado que se puede actualizar al abrir y cerrar, y funciona con teclado desde el primer momento. Esto conecta con el criterio 4.1.2 de WCAG (Nombre, función, valor).

05Listas, tablas, formularios e imágenes

Más allá de las grandes estructuras, el HTML semántico se juega en los detalles del contenido.

Listas

Un grupo de elementos del mismo tipo es una lista: <ul> si el orden no importa, <ol> si sí (pasos, rankings). El lector de pantalla anuncia «lista, 5 elementos», y la persona sabe qué le espera. Los menús de navegación también son listas de enlaces.

Tablas

Las tablas son para datos tabulares: horarios, tarifas, comparativas. Con <th> en las cabeceras y un <caption> que diga qué contienen, un lector de pantalla puede leer cada celda con su contexto («Martes, horario de tarde: 17:00 a 20:30»). Para maquetar columnas está CSS Grid.

Formularios

Cada campo necesita su <label> asociada, no solo un texto de ejemplo dentro que desaparece al escribir. Los grupos de opciones (por ejemplo, «¿Cómo prefieres que te contactemos?») van en un <fieldset> con su <legend>. Y el tipo de campo correcto (type="email", type="tel") hace que el móvil muestre el teclado adecuado. Si te interesa la parte de diseño, lo contamos en formularios web que convierten.

Imágenes

El atributo alt describe la imagen para quien no la ve y para los buscadores. Una imagen informativa necesita un texto que transmita lo que aporta («Terraza del restaurante al atardecer, con vistas al puerto»). Una imagen decorativa lleva alt="" vacío, para que el lector de pantalla la ignore. Y cuando una imagen es contenido con pie de foto, <figure> y <figcaption> la unen a su descripción.

El idioma

Un detalle pequeño con efecto grande: <html lang="es">. Le dice al lector de pantalla con qué voz y pronunciación leer, y al navegador qué ofrecer al traducir. Si una frase está en otro idioma, se marca con su propio lang. Es el criterio 3.1.1 de WCAG.

06Cómo ayuda al SEO, sin exagerar

Conviene ser preciso, porque se dicen muchas cosas sobre esto. Google no da puntos extra por usar <article> en vez de <div>. Lo que hace el HTML semántico es facilitar tres cosas que sí importan:

1. 01Entender la página. Un <main> claro, un <h1> que coincide con la intención de búsqueda y secciones bien tituladas ayudan a que el buscador identifique el tema y los subtemas.
2. 02Aprovechar los enlaces. Los enlaces reales con href se rastrean; los «enlaces» hechos con JavaScript sobre un <div> a menudo no. Y un texto de enlace descriptivo («ver nuestra carta de temporada») le dice a Google de qué va la página de destino.
3. 03Preparar fragmentos citables. Listas, tablas y respuestas bajo un encabezado claro son el tipo de contenido que se convierte en fragmento destacado o en cita dentro de un resumen generado.

Sobre esta base encaja después el marcado de datos estructurados con schema.org, que añade una capa explícita (esto es un restaurante, este es su horario, esta es una pregunta frecuente). Pero los datos estructurados funcionan mejor sobre un HTML que ya es coherente.

Clave: el HTML semántico no es una capa extra que se añade al final; es la forma correcta de escribir la página desde el principio, y cuesta lo mismo hacerlo bien que hacerlo mal.

07Una revisión de diez minutos para tu web

No hace falta saber programar para hacer una primera comprobación. Esto es lo que proponemos:

1. 01Mira el esquema de encabezados. Extensiones como HeadingsMap muestran el índice de la página. Comprueba que hay un <h1> y que los niveles bajan en orden.
2. 02Navega solo con el teclado. Pulsa Tab desde el principio. Deberías poder llegar a cada enlace y botón, ver siempre dónde está el foco y abrir el menú con Intro.
3. 03Pasa una herramienta automática. Lighthouse (en Chrome, dentro de las herramientas de desarrollo), WAVE o axe detectan imágenes sin alt, campos sin etiqueta o saltos de encabezados.
4. 04Escucha la página. Activa VoiceOver en Mac o iPhone, TalkBack en Android o NVDA en Windows y recorre la portada durante cinco minutos. Es la prueba más humana y la que más enseña.
5. 05Revisa el modo lectura. Si el modo lectura de Safari o Firefox muestra bien tu artículo, es buena señal de que el contenido principal está bien marcado.

Las herramientas automáticas detectan solo una parte de los problemas de accesibilidad; la revisión manual completa el diagnóstico. Si quieres ver el panorama general más allá del código, lo tienes en nuestra guía sobre qué es la accesibilidad web. Y ten presente que desde junio de 2025 la Ley 11/2023, que traslada a España el Acta Europea de Accesibilidad, exige requisitos de accesibilidad a muchos servicios digitales de comercio electrónico, banca o transporte.

08Por qué en SIMA lo cuidamos desde el primer componente

En nuestros proyectos el HTML semántico forma parte del diseño, no de una revisión final. Cuando diseñamos un componente en Figma ya decidimos qué será en código: este titular es un <h2>, esta tarjeta es un <article> con su enlace, este icono es un botón con nombre accesible. Así, cuando la web se construye, la estructura sale correcta de serie y se mantiene igual de ordenada cuando crece.

Tiene también una ventaja menos evidente: un código semántico es más fácil de leer para quien venga después. Dentro de tres años, otra persona del equipo o de otro estudio abrirá ese archivo y entenderá en un vistazo qué es cada cosa.

Si quieres que revisemos la estructura de tu web o estás pensando en construir una nueva con esta base, en nuestro servicio de desarrollo web y apps trabajamos así desde el primer componente. Escríbenos y le echamos un vistazo juntos.