HTML semántico para SEO

TL;DR — El HTML semántico significa usar etiquetas que describen lo que el contenido es — <article>, <nav>, <main>, <header> — en lugar de envolver todo en <div>s simples. Ayuda a los motores de búsqueda y a los lectores de pantalla a entender tu página, pero no es un factor de ranking. Usar <article> no hará que rankees más alto. La misma regla aplica más allá de los landmarks: <a href> para enlaces, <button> para acciones, <table> para datos tabulares, texto alt real en imágenes. Usa la etiqueta correcta para el trabajo y estarás casi listo.

Qué es el HTML semántico

Cada parte de una página web está construida con elementos HTML. El HTML semántico simplemente significa elegir el elemento que coincide con lo que el contenido realmente es, en lugar de usar un contenedor genérico para todo.

Compara estas dos versiones de la misma estructura de página:

<!-- Non-semantic: "div soup" -->
<div class="top"> ... </div>
<div class="menu"> ... </div>
<div class="content"> ... </div>
<div class="sidebar"> ... </div>
<div class="bottom"> ... </div>

<!-- Semantic: the tags describe the roles -->
<header> ... </header>
<nav> ... </nav>
<main> ... </main>
<aside> ... </aside>
<footer> ... </footer>

Ambas pueden verse idénticas en pantalla — el CSS maneja el estilo. La diferencia es que la segunda versión le dice a una máquina (un motor de búsqueda, un lector de pantalla, un rastreador de IA) cuál parte es la navegación, cuál es el contenido principal y cuál es una barra lateral. La primera versión hace que todos adivinen.

Los elementos que realmente usarás

• <header> — contenido introductorio en la parte superior de la página (o de una sección).
• <nav> — un bloque de enlaces de navegación.
• <main> — el contenido principal y único de la página. Uno por página.
• <article> — una pieza autocontenida que podría mantenerse por sí sola (una entrada de blog, una tarjeta de producto, un comentario).
• <section> — una agrupación temática de contenido que tiene su propio encabezado.
• <aside> — contenido tangencial al contenido principal (una barra lateral, una nota destacada).
• <footer> — contenido de cierre (copyright, enlaces secundarios).

La misma idea de “usa la etiqueta correcta” aplica también por debajo del nivel de diseño de página: <a href> para enlaces, <button> para acciones en la página, <table> para datos tabulares reales y texto alt basado en el propósito en las imágenes. Los enlaces falsos construidos con <div>s estilizados son el fallo de accesibilidad más común — consulta la pestaña Avanzado para la lista completa.

Lo que la mayoría de la gente entiende mal

Envolver tu contenido en <article> no mejora tus rankings. John Mueller, de Google, ha dicho que el elemento <article> tiene “no particular effect” (traducción) «ningún efecto particular» en Google Search y que el HTML semántico es “not a magical multiplier.” (traducción) «no es un multiplicador mágico». El HTML semántico ayuda a los motores de búsqueda a entender tu página — simplemente no es una palanca que tiras para rankear más alto.

El valor es real, simplemente no son “puntos de ranking.” Un marcado semántico limpio facilita que los motores de búsqueda distingan tu contenido principal del texto repetitivo (menús, pies de página, anuncios), hace que tu página funcione correctamente para personas que usan lectores de pantalla y es más fácil de leer para las herramientas de IA. Todas esas son buenas razones para hacerlo — ninguna de ellas es “es un factor de ranking.”

Una trampa más: El HTML semántico no es lo mismo que el “SEO semántico.” El HTML semántico se trata de la estructura del marcado. El SEO semántico se trata de temas y entidades en tu contenido. La misma palabra, algo totalmente diferente.

¿Quieres el panorama completo — qué señala cada elemento, qué dicen realmente Google y Bing, cómo encaja en la extracción del contenido principal y una lista de verificación para modernizar? Cambia a la pestaña Avanzado.

TL;DR — El HTML semántico utiliza elementos para su significado estructural previsto (<main>, <article>, <section>, <nav>, <header>, <aside>) para que el marcado comunique qué es el contenido, no cómo se ve. No es un factor de ranking — Mueller: “not a magical multiplier,” (traducción) «no es un multiplicador mágico», y <article> tiene “no particular effect.” (traducción) «ningún efecto particular». Lo que hace es reducir la ambigüedad: la anotación de pieza central de Google separa el contenido principal del boilerplate mediante NLP, ya sea que tu marcado sea semántico o no, pero una semántica limpia hace que esa tarea sea más fiable. Fabrice Canel de Bing lo plantea con más fuerza (“an advantage in SEO” (traducción) «una ventaja en SEO») — señalo esa diferencia con honestidad en lugar de armonizarla. La propia Guía de inicio de Google dice que la mayor parte de la web no es HTML válido, por lo que rara vez depende de la semántica de la especificación. El uso correcto supera a la presencia: un <main>, <article> para contenido autocontenido, <section> para un grupo temático con un encabezado — no un sustituto de <div>. La misma prueba se extiende a <a href> frente a <button> (navegar frente a actuar), <table> reales para datos tabulares, texto alternativo de imágenes basado en el propósito y <details>/<summary> para widgets de divulgación — y no confíes en el anidamiento de <section> para implicar un nivel de encabezado; ese “algoritmo de esquema de documento” nunca se implementó y la especificación ya no define los esquemas de esa manera. No confundas el HTML semántico con el SEO semántico.

Qué es realmente el HTML semántico

El HTML semántico es la práctica de elegir elementos HTML por el significado estructural que fueron diseñados para transmitir, en lugar de recurrir a <div> y <span> para todo. <article>, <section>, <nav>, <header>, <main>, <aside> y <footer> declaran cada uno un rol. El marcado describe qué es una parte de la página; CSS decide cómo se ve. La propia guía de estilo para desarrolladores de Google lo expresa de la manera más simple posible: “Use HTML elements for the purposes that they were designed for.” (traducción) «Usa los elementos HTML para los fines para los que fueron diseñados».

Una cosa que confunde a la gente: un nombre de clase no crea semántica. Nombrar un <div> class="article" o class="main-nav" no le da el modelo de contenido del elemento <article> ni el rol de navegación implícito del elemento <nav> — sigue siendo un <div> genérico en lo que respecta a un navegador, lector de pantalla o rastreador. La semántica vive en el elemento que eliges, no en cómo lo estilizas o etiquetas.

Este artículo trata específicamente sobre los elementos semánticos. El panorama más amplio de “cómo Google analiza tu HTML, jerarquía de encabezados, validez” pertenece al centro de SEO de HTML bajo el que se encuentra esta página — lo referenciaré en lugar de re-litigarlo aquí.

¿Ayuda realmente el HTML semántico al SEO?

Respuesta corta: ayuda a la comprensión, no es un factor de ranking, y los dos motores lo plantean de manera un poco diferente. Aquí está la versión honesta.

Qué dice Google

La postura de Google, repetida por John Mueller, es que el HTML semántico vale la pena hacerlo pero no es una palanca de ranking. Como Search Engine Journal informó, Mueller dijo “Semantic HTML does help to understand a page. However, it’s not a magical multiplier for making a website rank higher,” (traducción) «El HTML semántico sí ayuda a comprender una página. Sin embargo, no es un multiplicador mágico para hacer que un sitio web se posicione mejor», y por separado: “Please use semantic HTML. It’s not a ranking factor, but it can help our systems to understand your content better.” (traducción) «Usa HTML semántico. No es un factor de ranking, pero puede ayudar a nuestros sistemas a comprender mejor tu contenido».

En el elemento <article> específicamente — el que todos preguntan — Mueller fue contundente en una sesión de Office Hours: “The <article> HTML element does not have any particular effect in Google Search.” (traducción) «El elemento HTML <article> no produce ningún efecto específico en la Búsqueda de Google»; y añadió la razón para usarlo de todos modos: “Sometimes there are accessibility or semantic reasons to use a specific kind of markup, so don’t only focus on SEO.” (traducción) «A veces existen motivos de accesibilidad o semánticos para usar un tipo concreto de marcado, así que no te centres únicamente en el SEO».

Google también dice explícitamente que no depende de una semántica perfecta. Su Guía de inicio de SEO señala: “Having your headings in semantic order is fantastic for screen readers, but from Google Search perspective, it doesn’t matter if you’re using them out of order. The web in general is not valid HTML, so Google Search can rarely depend on semantic meanings hidden in the HTML specification.” (traducción) «Para los lectores de pantalla es fantástico que los encabezados sigan un orden semántico, pero a la Búsqueda de Google no le importa que estén desordenados. La web, en general, no es HTML válido, así que Google Search rara vez puede apoyarse en significados semánticos ocultos en la especificación HTML». Eso es un matiz importante, no una contradicción: el HTML semántico ayuda en los márgenes, no requiere perfección y no es una señal puntuada.

Cómo encaja en que Google encuentre tu contenido principal

Aquí está el mecanismo que hace útil el HTML semántico aunque no sea un factor de clasificación. Google tiene que separar el contenido principal de una página del material repetitivo (nav, cabecera, pie de página, barras laterales, anuncios) antes de poder decidir de qué trata una página. Martin Splitt ha descrito la maquinaria: “We have a thing called the Centerpiece Annotation, for instance, and there’s a few other annotations that we have where we look at the semantic content.” (traducción) «Contamos, por ejemplo, con algo llamado Centerpiece Annotation y con algunas anotaciones más en las que examinamos el contenido semántico». La forma en que Google descubre el tema es mediante el procesamiento del lenguaje natural sobre el contenido, no los nombres de las etiquetas: “This looks like from all the natural language processing that we did on this entire text content here that we got, it looks like this is primarily about topic A, dog food.” (traducción) «Según todo el procesamiento del lenguaje natural aplicado al texto obtenido, parece que el tema principal es el tema A: comida para perros». Y resta peso al resto: “We figure out what looks like boilerplate and then, that gets weighted differently as well.” (traducción) «Identificamos lo que parece contenido repetitivo y también lo ponderamos de otra manera».

El punto clave: esa extracción funciona tanto si tu marcado es semántico como si no. Google puede desenredar una página construida enteramente con <div>s. Pero al preguntarle directamente si el HTML5 semántico ayuda, la respuesta de Splitt fue “It does help us, but it’s not the only thing that we look for. Yes.” (traducción) «Nos ayuda, aunque no es el único aspecto que examinamos. Sí». Así que el HTML semántico no te puntúa más alto — reduce la incertidumbre en un paso que Google ya hace, que es exactamente por qué es una señal de confianza y eficiencia en lugar de una de clasificación. Para ser precisos sobre lo que no hace: un marcado semántico correcto tampoco garantiza ninguna presentación específica en la búsqueda — es una capa separada de las reglas de elegibilidad que rigen los resultados enriquecidos (más sobre eso a continuación).

Qué dice Bing (y por qué difiere)

Bing lo plantea con más fuerza que Google, y voy a dejar esa diferencia intacta en lugar de disimularla. Fabrice Canel, de Microsoft, ha dicho que las páginas con HTML5 semántico correctamente implementado tienen “una ventaja para el SEO” sobre las que no lo tienen. Esa es una afirmación más fuerte que la de Google de “nos ayuda a entender” — Bing vincula el HTML5 semántico directamente con una ventaja en SEO. Ambos motores coinciden en que “ayuda mecánicamente”, pero no usan las mismas palabras, y deberías saberlo cuando leas guías que compiten entre sí. Ninguno, para ser claros, lo describe como un factor de clasificación puntuado de la misma manera que los enlaces o la relevancia.

Los elementos semánticos principales y cómo usarlos correctamente

La presencia no es el punto — el uso correcto lo es. El modo de fallo más común es esparcir etiquetas semánticas como decoración, o cambiar <div> por <section> sin pensar en qué significa cada elemento.

<header> y <footer>

<header> contiene contenido introductorio y <footer> contiene contenido de cierre — y ambos son contextuales. A nivel de documento, <header> es el banner de tu sitio y <footer> es el pie de página de tu sitio. Pero también pueden anidarse dentro de un <article> o <section> para marcar la introducción y el cierre propios de ese bloque (el título/firma de un artículo en un <header>, sus etiquetas en un <footer>). Puedes tener muchos de ellos; solo asegúrate de que cada uno envuelva contenido introductorio o de cierre para su contexto, no cajas arbitrarias.

<nav>

<nav> es para bloques principales de enlaces de navegación — tu menú primario, la ruta de migas de pan, o el índice de contenidos de la página. No es para cada grupo de enlaces de la página (una lista de publicaciones relacionadas en el cuerpo no necesita ser un <nav>). Envolver cada conjunto de enlaces en <nav> diluye la señal; resérvalo para la navegación genuina.

<main>

<main> envuelve el contenido principal y único de la página — la parte que no se repite en todo el sitio. La regla que confunde a la gente: debería haber exactamente un <main> por página, y no debería estar anidado dentro de <article>, <aside>, <header>, <footer> o <nav>. Es la señal más clara que puedes dar sobre “este es el contenido que importa aquí”.

<article> vs <section> (la que todos se equivocan)

Esta es la distinción que hay que acertar:

• <article> es para contenido autocontenido e independientemente distribuible — algo que seguiría teniendo sentido si se sacara de la página y se pusiera en un feed. Una publicación de blog, una noticia, una tarjeta de producto, una publicación de foro, un comentario de usuario. Si pudiera sindicarse por sí solo, es un <article>.
• <section> es una agrupación temática de contenido que debería tener su propio encabezado. Un bloque de “Reseñas”, un bloque de “Especificaciones”, un capítulo. La prueba: si el contenido no tiene sentido con un encabezado, probablemente no es una <section> — y si solo lo usas para colgar algo de CSS, debería ser un <div>.

<section> no es un contenedor genérico. Cuando necesitas un gancho de estilo sin significado semántico, usa <div> — para eso está exactamente. Recurrir a <section> porque “se siente más moderno” es el uso incorrecto más común.

<aside>

<aside> marca contenido que es tangencial al contenido circundante — una barra lateral, una cita destacada, una caja de enlaces relacionados, un conjunto de anuncios. Señala “esto está relacionado pero no es el hilo principal”, que es precisamente la distinción entre contenido repetitivo y contenido principal que Google intenta hacer de todos modos. No lo uses solo porque algo se ve visualmente a un lado; úsalo cuando el contenido sea genuinamente secundario.

Acertar con los roles de referencia (y el mito del esquema)

Cada elemento de referencia se asigna a un rol ARIA implícito específico que la tecnología de asistencia lee directamente — esta es la misma estructura calculada por la que navega un usuario no visual, y vale la pena conocer la asignación real en lugar de asumir:

Una pieza de folclore que vale la pena retirar: anidar una <section> no otorga a sus encabezados un rango inferior implícito. El HTML5 temprano definió un algoritmo de esquema de documento que habría calculado el nivel efectivo de un encabezado según la profundidad de anidamiento dentro de elementos de seccionamiento — así que un <h1> anidado podría teóricamente “actuar como” un <h2>. Ningún navegador o lector de pantalla implementó jamás ese algoritmo, y la especificación WHATWG lo ha eliminado desde entonces en favor de una definición mucho más simple: el esquema es simplemente todos los encabezados del documento, en orden de árbol. Escribe tus niveles <h1>–<h6> explícitamente y en el orden en que realmente quieres que se lean — la profundidad de anidamiento no hace ese trabajo por ti.

Enlaces frente a botones: la prueba de acción frente a navegación

Este no es un elemento de punto de referencia, pero es el error semántico más común en la web: usar un <div> o <span> con estilo (o un <button>) donde corresponde un <a href>, o viceversa. La especificación WHATWG es específica: <a> con un atributo href es el mecanismo nativo de hiperenlace, y el elemento <button> es un control interactivo etiquetado para desencadenar una acción. La prueba es simple: ¿esto lleva al usuario a algo (una nueva URL, una nueva página, un fragmento)? Usa <a href>. ¿Hace algo en la página actual (enviar un formulario, abrir un modal, alternar una configuración)? Usa <button>. Dar estilo a uno para que parezca el otro no cambia lo que es nativamente: un <div> con un controlador de clic no obtiene ni activación nativa del teclado ni el rol accesible correcto a menos que reconstruyas todo eso tú mismo con role, tabindex y controladores de teclas. Simplemente usa el elemento correcto.

Las tablas son para datos tabulares, no para maquetación

Si el contenido tiene genuinamente filas y columnas — una tabla comparativa, una cuadrícula de precios, un conjunto de datos — usa una <table> real, no una cuadrícula de <div>s con estilo. La especificación de tablas WHATWG define un modelo de datos real: <caption> nombra la tabla, y las celdas de encabezado <th> (con scope) establecen las relaciones de fila/columna que permiten a la tecnología de asistencia anunciar “precio, $49” en lugar de solo un muro de números. Una cuadrícula visualmente similar a una tabla construida con <div>s no lleva ninguno de esos datos de relación — se ve bien, pero no se lee bien. Tampoco uses <table> para la maquetación de la página; ese es el mal uso más antiguo que esta práctica reemplazó.

El texto alternativo depende de para qué sirve la imagen

<img> necesita un atributo alt, pero los requisitos de la especificación WHATWG dependen del propósito, no son una talla única: una foto de producto necesita una descripción de lo que se muestra; una imagen puramente decorativa debería tener alt="" (vacío, no ausente) para que la tecnología de asistencia la omita en lugar de anunciar un nombre de archivo; una imagen que también es un enlace necesita texto alternativo que describa el destino o la acción del enlace, no solo la imagen. No recurras por defecto a texto alternativo repleto de palabras clave en cada imagen “por SEO” — esa es la prueba incorrecta. La prueba correcta es: ¿qué necesita saber un usuario de lector de pantalla que de otra manera se perdería?

Widgets de divulgación nativos: <details> y <summary>

Para el contenido de «clic para expandir» — preguntas frecuentes, hojas de especificaciones, texto oculto — el par <details>/<summary> es un widget de divulgación nativo: <summary> es la etiqueta siempre visible, y el contenido dentro de <details> se muestra u oculta según el estado open del elemento, sin necesidad de JavaScript. Viene con soporte de teclado integrado y la semántica accesible correcta de forma gratuita — recurrir a un acordeón personalizado de <div> más JavaScript significa reimplementar un comportamiento que el navegador ya te ofrece. Pruébalo en tus navegadores objetivo y lectores de pantalla reales antes de publicarlo, sin embargo — la representación y la exposición del árbol de accesibilidad para <details>/<summary> han variado históricamente según la combinación de navegador y tecnología de asistencia, así que no asumas una paridad que no has verificado.

Mitos comunes sobre el HTML semántico y el SEO

1. «Envolver contenido en <article> mejora los rankings.» No — Mueller: el elemento <article> «no tiene ningún efecto particular en la Búsqueda de Google.»
2. «El HTML semántico es un factor de ranking.» No — «no es un multiplicador mágico» y «No es un factor de ranking, pero puede ayudar a nuestros sistemas a entender mejor tu contenido.»
3. «Google requiere HTML semántico válido/estricto.» No — según la Guía de inicio, la mayor parte de la web no es HTML válido y Google «rara vez puede depender de significados semánticos ocultos en la especificación HTML.»
4. «El orden de los encabezados tiene que ser perfecto para el SEO.» A los lectores de pantalla les importa; el ranking de Google no (misma línea de la Guía de inicio). El tratamiento más profundo de la jerarquía de encabezados pertenece al centro de SEO de HTML — esto es solo la versión breve.
5. «El HTML semántico y el SEO semántico son lo mismo.» No — uno es estructura de marcado, el otro es estrategia de contenido temático/de entidades. Confundirlos es la razón por la que tantos resultados de búsqueda para consultas «semánticas» tratan sobre el tema equivocado.
6. «Los datos estructurados hacen innecesario el HTML semántico.» No — son complementarios. El HTML semántico le da a tus datos estructurados una base más confiable; no lo reemplaza, y JSON-LD no arregla la sopa de divs. Y ninguno garantiza un resultado: la introducción a datos estructurados de Google es explícita en que usar marcado compatible no garantiza un resultado enriquecido — la elegibilidad para una característica de búsqueda específica es un conjunto de reglas separado de si tu marcado (HTML semántico o JSON-LD) es técnicamente válido.
7. «Anidar un <section> da a sus encabezados un rango implícito inferior — no necesitas bajar de <h1> a <h2> dentro de una sección anidada.» No — esto es un resto del antiguo algoritmo de esquema de documento de HTML5, que habría calculado un rango de encabezado implícito a partir del anidamiento de elementos de sección. Ningún navegador o lector de pantalla lo implementó jamás, y la especificación HTML de WHATWG ya no define el cálculo de esquema de esa manera — el esquema hoy es simplemente «todos los encabezados del documento, en orden de árbol». Usa <h1>–<h6> explícitos y correctamente ordenados independientemente de cuán profundo sea tu anidamiento de <section>/<article>; no confíes en el anidamiento para hacer el trabajo de nivel de encabezado por ti.

HTML semántico vs. SEO semántico — no los confundas

Debido a que comparten una palabra, estos se confunden constantemente, y eso contamina los resultados de búsqueda para ambos:

• HTML semántico = el markup — qué elementos usas para estructurar una página.
• SEO semántico = una estrategia de contenido — construir autoridad temática en torno a entidades y conceptos relacionados (el tipo de cosas que vive bajo los pilares de Búsqueda con IA y contenido, no aquí).

Si llegaste aquí desde una consulta de “SEO semántico” esperando modelado de temas, ese es un artículo diferente. Este trata estrictamente sobre los elementos.

HTML semántico y rastreadores de IA/LLM

Aquí es donde el HTML semántico está ganando silenciosamente más relevancia, y lo señalaré como opinión de la industria más que como declaración de un motor. Muchos rastreadores de LLM y motores de respuestas con IA no renderizan JavaScript — analizan el HTML que reciben. Un marcado semántico limpio es mucho más fácil de procesar para ellos que una sopa de <div> profundamente anidados. Como dice Barry Adams, “It’s much simpler for ChatGPT to parse a few dozen semantic HTML tags rather than several hundred (or even thousand) nested <div> tags,” (traducción) «Para ChatGPT es mucho más sencillo analizar unas pocas docenas de etiquetas HTML semánticas que varios cientos —o incluso miles— de etiquetas <div> anidadas», y, de manera más amplia, “Semantic HTML markup on your webpages can help machine systems better understand your content and its value.” (traducción) «El marcado HTML semántico de tus páginas puede ayudar a los sistemas automáticos a comprender mejor el contenido y su valor». Jono Alderson presenta el mismo argumento prospectivo: un sitio es “an interface. An API. A dataset,” (traducción) «una interfaz, una API, un conjunto de datos», no solo una experiencia visual; y su frase contundente resume el argumento para un uso correcto: “If everything is a <div> or a <span>, then nothing is meaningful.” (traducción) «Si todo es un <div> o un <span>, nada tiene significado». Trata todo esto como una buena razón direccional para mantener tu marcado limpio, no como una promesa de Google o Bing.

Cómo auditar y modernizar páginas existentes

La mayoría de los sitios reales ya son sopa de divs, y no los reconstruyes de la noche a la mañana. Un orden pragmático de modernización:

• Establece primero los hitos. Asegúrate de que haya exactamente un <main>, un <header> de documento, <footer> y un <nav> para el menú principal. Estos elementos de hito hacen el mayor trabajo tanto para la extracción del contenido principal como para la accesibilidad.
• Convierte bloques autocontenidos en <article>. Publicaciones de blog, tarjetas de producto, comentarios — cualquier cosa que pueda mantenerse sola en un feed.
• Convierte grupos temáticos genuinos en <section> — pero solo donde haya un encabezado real. Si no lo hay, déjalo como <div>.
• Mueve barras laterales y cajas de contenido relacionado a <aside>.
• Corrige enlaces falsos y botones falsos. Un <div> estilizado con un manejador de clic debería convertirse en un <a href> (si navega) o un <button> (si actúa en la página) — este suele ser el arreglo individual de mayor valor para usuarios de teclado y lectores de pantalla.
• Convierte cuadrículas de <div> similares a tablas en <table> reales donde el contenido sea genuinamente tabular, con <caption> y <th> para las celdas de encabezado.
• No sobreconviertas. Un <div> usado puramente como gancho de estilo/diseño es correcto. No todo necesita un elemento semántico; forzar uno es su propio error.
• Verifica, no asumas. Revisa el árbol de accesibilidad en las DevTools de tu navegador — expone los roles de hito que produce tu marcado, que es la misma estructura que leen las máquinas.

Cómo encaja esto en el centro de SEO de HTML

Este artículo es una inmersión profunda bajo el centro de SEO de HTML padre, que cubre la pregunta más amplia de cómo los motores de búsqueda analizan y usan tu HTML — jerarquía de encabezados, validez del HTML y cómo los analizadores tolerantes manejan marcado desordenado. He mantenido deliberadamente esta página enfocada en los elementos semánticos en sí mismos y he dejado esos temas al centro y a sus artículos hermanos. El HTML semántico también se combina directamente con datos estructurados: el marcado le da a tu esquema una base confiable, y ambos hacen trabajos complementarios.

Preguntas frecuentes

¿El HTML semántico ayuda al SEO o es solo para accesibilidad? Ambos: ayuda a los motores de búsqueda a identificar tu contenido principal y es esencial para la accesibilidad. Pero no es un factor de clasificación.

¿Usar la etiqueta <article> mejora los rankings? No. Mueller: “no tiene ningún efecto particular en la Búsqueda de Google.” (traducción) «no tiene ningún efecto particular en la Búsqueda de Google»

¿Cuál es la diferencia entre <article> y <section>? <article> es contenido autocontenido que podría aparecer solo en un feed; <section> es una agrupación temática con su propio encabezado. Ninguno es un reemplazo de <div>.

¿Puedo tener más de un elemento <main> en una página? No: un <main> por página.

¿Google requiere HTML válido para clasificar una página? No: la mayor parte de la web no es HTML válido, y Google “rara vez puede depender de significados semánticos ocultos en la especificación HTML.” (traducción) «rara vez puede depender de significados semánticos ocultos en la especificación HTML»

¿El HTML semántico es lo mismo que el SEO semántico? No: uno es marcado, el otro es estrategia de contenido temático/de entidades.

¿Debería usar <a> o <button> para un elemento clicable? Depende de lo que haga. Si navega a una URL o fragmento, usa <a href>. Si realiza una acción en la página actual (enviar, alternar, abrir un modal), usa <button>. No finjas uno con un <div> estilizado y un manejador de clic.

¿Anidar <section> cambia el nivel de encabezado que debería usar? No. El antiguo algoritmo de esquema de documento de HTML5 —que habría calculado un rango de encabezado implícito a partir del anidamiento de secciones— nunca fue implementado por ningún navegador o lector de pantalla, y la especificación actual no define esquemas de esa manera. Usa <h1>–<h6> explícitos y correctamente ordenados independientemente de la profundidad del anidamiento.

¿El HTML semántico correcto o los datos estructurados garantizan un resultado enriquecido? No. La propia documentación de datos estructurados de Google dice que el marcado compatible no garantiza una presentación específica en la búsqueda: la elegibilidad para una función es independiente de si tu marcado es técnicamente válido.

Resumen de IA

Una versión condensada de la versión avanzada:

• HTML semántico = usar elementos para su significado previsto (<main>, <article>, <section>, <nav>, <header>, <aside>, <footer>) para que el marcado diga qué es el contenido. El CSS se encarga de la apariencia.
• No es un factor de ranking. Mueller lo niega como multiplicador mágico; el elemento <article> tampoco produce un efecto particular en la Búsqueda de Google. Úsalo para accesibilidad/claridad, no para puntos de ranking.
• Ayuda a la extracción del contenido principal. La anotación central de Google separa el contenido principal del texto repetitivo mediante NLP independientemente del marcado (Splitt), por lo que funciona también con sopa de divs — pero el marcado semántico reduce las conjeturas. Splitt confirma que ayuda, aunque Google también considera otras señales.
• Google no requiere HTML válido. Guía de inicio: la mayor parte de la web no es válida, por lo que Google rara vez puede depender de significados semánticos ocultos en la especificación HTML.
• Bing lo plantea con más fuerza. Fabrice Canel atribuye al HTML5 semántico una ventaja para el SEO. Nota la diferencia con honestidad: la redacción de Bing es más fuerte que la de Google; ninguno lo llama un factor de ranking puntuado.
• El uso correcto supera a la presencia: un solo <main>; <article> = autónomo; <section> = grupo temático con encabezado, no un sustituto de <div>; <nav> = solo navegación principal; <aside> = contenido tangencial.
• Los elementos de referencia se asignan a roles ARIA implícitos específicos (<header>→banner, <nav>→navigation, <main>→main, <aside>→complementary, <footer>→contentinfo — solo a nivel de documento; anidados dentro de una sección no son puntos de referencia). <section> solo es un punto de referencia (region) si tiene un nombre accesible; <article> no es un punto de referencia en absoluto.
• El mito del algoritmo de esquema del documento: anidar una <section> no da a sus encabezados un rango inferior implícito. Ese algoritmo nunca fue implementado por ningún navegador ni lector de pantalla, y la especificación WHATWG ya no define los esquemas de esa manera — escribe niveles explícitos de <h1>–<h6>.
• Más allá de los puntos de referencia: usa <a href> para navegación frente a <button> para acciones en la página; <table> reales (con <caption>/<th>) para datos tabulares, no cuadrículas de <div>; texto alt basado en el propósito en imágenes (alt="" para decorativas); <details>/<summary> para widgets de divulgación nativos — prueba la representación en navegador/TA antes de publicar.
• Ángulo IA/LLM (opinión de la industria): los rastreadores de LLM a menudo no renderizan JS, por lo que un HTML semántico limpio es más fácil de analizar que <div>s anidados (Adams, Alderson).
• No lo confundas con el SEO semántico (estrategia de entidades/temas) — misma palabra, cosa diferente. Los datos estructurados complementan el HTML semántico, no lo reemplazan, y ninguno garantiza un resultado enriquecido o una ganancia de ranking.

Documentación oficial

Documentación de fuentes primarias y guías de estilo de los motores de búsqueda y organismos de estándares.

Google

• Guía de inicio de SEO — la sección de “cosas en las que no deberías centrarte”, incluida la advertencia sobre el orden de encabezados / significados semánticos.
• Guía de estilo de documentación para desarrolladores de Google — HTML y etiquetado semántico — “Usa elementos HTML para los fines para los que fueron diseñados.”
• web.dev — Aprende HTML: HTML semántico — el propio módulo de aprendizaje de Google sobre elementos de referencia y sus roles de accesibilidad.

Estándares / referencia

• MDN — Semantics (glosario) — la definición canónica de elementos semánticos frente a envoltorios no semánticos.
• WHATWG HTML Living Standard — Secciones — definiciones de <article>, <section>, <nav>, <aside>, <header>, <footer>, modelos de contenido y la definición actual (no algorítmica) del esquema de un documento.
• WHATWG HTML Living Standard — Enlaces — el elemento <a> y la semántica de los hiperenlaces.
• WHATWG HTML Living Standard — El elemento button — semántica nativa de los controles interactivos.
• WHATWG HTML Living Standard — Datos tabulares — semántica de <table>, <caption>, celdas de cabecera y relaciones de datos.
• WHATWG HTML Living Standard — Imágenes — requisitos de texto alternativo de <img> según propósito/contexto.
• WHATWG HTML Living Standard — Los elementos details y summary — el widget de divulgación nativo.
• MDN — Referencia de roles ARIA — asignaciones implícitas de roles de referencia para los elementos de seccionamiento.
• W3C WAI — Tutorial de estructura de página — cómo las regiones nativas y los encabezados apoyan la navegación con tecnología de asistencia.

Bing / Microsoft

• Kalicube — Etiquetas semánticas HTML5 (Fabrice Canel) — la fuente de la posición de Canel sobre la “ventaja en SEO” del HTML5 semántico.

Citas de la fuente

Declaraciones públicas de Google y Bing. Cuando la página de origen lo permite, cada enlace es un enlace profundo que salta al pasaje citado.

Google — no es un factor de ranking (John Mueller)

• “Semantic HTML does help to understand a page. However, it’s not a magical multiplier for making a website rank higher.” (traducción) «El HTML semántico sí ayuda a entender una página. Sin embargo, no es un multiplicador mágico para hacer que un sitio web rankee más alto.» — John Mueller, Google, vía Search Engine Journal. Leer la cobertura
• “Please use semantic HTML. It’s not a ranking factor, but it can help our systems to understand your content better.” (traducción) «Por favor, usa HTML semántico. No es un factor de ranking, pero puede ayudar a nuestros sistemas a entender mejor tu contenido.» — John Mueller, Google, misma fuente. Leer la cobertura

Google — el elemento <article> específicamente (John Mueller)

• “The <article> HTML element does not have any particular effect in Google Search.” (traducción) «El elemento HTML <article> no tiene ningún efecto particular en la Búsqueda de Google.» — John Mueller, Google SEO Office Hours, vía Search Engine Journal. Leer la cobertura
• “Sometimes there are accessibility or semantic reasons to use a specific kind of markup, so don’t only focus on SEO.” (traducción) «A veces hay razones de accesibilidad o semánticas para usar un tipo específico de marcado, así que no te centres solo en el SEO.» — John Mueller, Google SEO Office Hours, misma fuente. Leer la cobertura

Google — extracción del contenido principal (Martin Splitt)

• “We have a thing called the Centerpiece Annotation, for instance, and there’s a few other annotations that we have where we look at the semantic content.” (traducción) «Tenemos algo llamado Centerpiece Annotation, por ejemplo, y hay algunas otras anotaciones en las que observamos el contenido semántico». — Martin Splitt, Google, vía Search Engine Journal. Leer la cobertura
• “We figure out what looks like boilerplate and then, that gets weighted differently as well.” (traducción) «Determinamos qué parece contenido repetitivo y eso también recibe una ponderación diferente». — Martin Splitt, misma fuente. Leer la cobertura
• “It does help us, but it’s not the only thing that we look for. Yes.” (traducción) «Sí nos ayuda, pero no es lo único que buscamos. Sí». — Martin Splitt, respondiendo directamente si el HTML5 semántico ayuda a Google. Ir a la cita

Google — no depende de la semántica válida/especificada (Guía de inicio de SEO)

• “Having your headings in semantic order is fantastic for screen readers, but from Google Search perspective, it doesn’t matter if you’re using them out of order. The web in general is not valid HTML, so Google Search can rarely depend on semantic meanings hidden in the HTML specification.” (traducción) «Tener tus encabezados en orden semántico es fantástico para los lectores de pantalla, pero desde la perspectiva de la Búsqueda de Google no importa si los usas fuera de orden. La web en general no es HTML válido, por lo que la Búsqueda de Google rara vez puede depender de significados semánticos ocultos en la especificación HTML». — Guía de inicio de SEO de Google. Ir a la cita

Google — usa los elementos para su propósito (Guía de estilo)

• “Use HTML elements for the purposes that they were designed for.” (traducción) «Usa los elementos HTML para los fines para los que fueron diseñados». — Guía de estilo de documentación para desarrolladores de Google. Leer la fuente

Bing / Microsoft (Fabrice Canel)

• Fabrice Canel de Microsoft Bing ha dicho que las páginas con HTML5 semántico correctamente implementado tienen una ventaja en SEO sobre las que no lo tienen: el enfoque de Bing es más fuerte que el de Google de “ayuda a la comprensión”, aunque todavía no se describe como un factor de clasificación puntuado. Parafraseado, no citado textualmente: esto se alcanza mediante una cita secundaria (Kalicube), no una fuente primaria de Bing obtenida; confirma la redacción exacta contra el original antes de tratarlo como una cita directa. Leer la fuente

¿Qué elemento necesita este bloque?

La pregunta de article-vs-section-vs-div (y el resto de las elecciones de landmarks) es una rama genuina, no una preferencia de estilo. Responde con honestidad en cada paso: la prueba siempre es “qué hace realmente este contenido”, no “qué se ve más moderno”.

Qué no hacer

Estos son los errores reales a los que apuntan los mitos anteriores: cada uno con por qué está mal y qué hacer en su lugar.

• Envolver contenido en <article> esperando un impulso de clasificación. Por qué está mal: Mueller ha dicho que el elemento no produce ningún efecto particular en la Búsqueda de Google. Fuente Qué hacer en su lugar: usa <article> cuando el contenido sea genuinamente autónomo (podría estar solo en un feed), por accesibilidad y claridad, no como una palanca de SEO.

• Tratar el HTML semántico en general como un factor de clasificación puntuado. Por qué está mal: no es un multiplicador mágico según Mueller fuente y no hay una señal puntuada que perseguir. Qué hacer en su lugar: presupuestar el trabajo como una inversión en comprensión/accesibilidad con un beneficio real (aunque no medible como clasificación), no un proyecto de clasificaciones con un aumento esperado.

• Obsesionarse con un orden perfecto de encabezados o una validez estricta por el bien de Google. Por qué está mal: la propia Guía de inicio de Google dice “the web in general is not valid HTML, so Google Search can rarely depend on semantic meanings hidden in the HTML specification.” (traducción) «la web en general no es HTML válido, por lo que Google Search rara vez puede depender de significados semánticos ocultos en la especificación HTML». Qué hacer en su lugar: corregir el orden de encabezados y la validez para lectores de pantalla y usuarios — ahí es donde realmente importa — no porque Google lo esté puntuando.

• Usar <section> como reemplazo de <div> porque “se siente más moderno.” Por qué está mal: <section> sin encabezado no es una agrupación temática, es decoración — este es el uso incorrecto más común del elemento. Qué hacer en su lugar: si el bloque no tiene sentido con su propio encabezado, usa <div>.

• Confundir HTML semántico con SEO semántico. Por qué está mal: uno es estructura de marcado, el otro es estrategia de contenido temático/entidad — confundirlos significa optimizar lo incorrecto para el objetivo que realmente tienes. Qué hacer en su lugar: mantener los dos separados; este artículo solo trata sobre los elementos.

• Omitir el HTML semántico porque ya existen los datos estructurados. Por qué está mal: JSON-LD no arregla la sopa de divs, y los datos estructurados no son un sustituto de la estructura del marcado. Qué hacer en su lugar: usa ambos — datos estructurados se asientan sobre una base semántica, no la reemplazan. Ninguno garantiza un resultado enriquecido tampoco — eso es una cuestión de elegibilidad separada de la validez del marcado.

• Anidar elementos <section> para que los encabezados “actúen como” un nivel inferior. Por qué está mal: esto se basa en el antiguo algoritmo de esquema de documento de HTML5, que ningún navegador o lector de pantalla implementó jamás y que la especificación actual de WHATWG ya no define de esa manera. Qué hacer en su lugar: escribe niveles explícitos y correctamente ordenados <h1>–<h6> — no dejes que la profundidad del anidamiento sustituya el rango de encabezado que realmente quieres decir.

• Usar un <div> con un manejador de clic en lugar de <a href> o <button>. Por qué está mal: pierdes la activación nativa del teclado y el rol accesible correcto a menos que reconstruyas manualmente ambos con role, tabindex y manejadores de teclas. Qué hacer en su lugar: usa <a href> cuando la acción navega a algún lugar, <button> cuando hace algo en la página actual — y obtén el comportamiento nativo gratis.

Elementos de referencia de un vistazo

Los siete elementos que cubre este artículo, para qué sirve cada uno realmente y el patrón de uso incorrecto a evitar.

Regla rápida: si un bloque podría sindicarse por sí solo, es <article>; si necesita un encabezado para tener sentido, es <section>; si no es ninguna de las dos, es un <div>.

Más allá de los landmarks: elementos interactivos y de datos

Indicaciones para modernizar el HTML

Indicaciones listas para copiar para la tarea específica que cubre este artículo: encontrar div soup y convertirlo en marcado semántico correcto. Pega el HTML de tu página (código fuente, no el DOM renderizado) en un asistente de IA con una de estas.

Señalar div soup y sugerir reemplazos

Here is the HTML for one of my pages. Identify every <div> or <span> that is standing
in for a semantic landmark, and suggest the correct replacement element from this list:
header, nav, main, article, section, aside, footer. For each suggestion, explain which
test it passes (e.g. "this could stand alone in a feed, so it's an <article>" or "this
has its own heading and one theme, so it's a <section>"). Flag any block that should
stay a <div> because it's purely a styling/layout hook.

[paste HTML here]

Comprobar errores estructurales de landmarks

Review this page's HTML for these specific structural mistakes: more than one <main>
element, a <main> nested inside <article>/<aside>/<header>/<footer>/<nav>, a <nav>
wrapping something that isn't major navigation, or a <section> with no heading. List
each problem found with the line/snippet and the fix.

[paste HTML here]

Priorizar un orden de modernización

Given this page's HTML, tell me which landmark to fix first for the biggest
accessibility and main-content-extraction benefit: establishing <main>/<header>/
<footer>/<nav>, converting self-contained blocks to <article>, converting themed
groups to <section>, or moving sidebars to <aside>. Order the fixes and say what
"done" looks like for each.

[paste HTML here]

Los landmarks coinciden con tu estructura prevista

Prueba a ejecutar: Abre el árbol de accesibilidad de las herramientas de desarrollo de tu navegador (Chrome/Edge: DevTools → Elements → panel Accessibility) en la página modernizada. Resultado esperado: Los roles de landmark enumerados (banner, navigation, main, complementary, contentinfo) coinciden con los elementos semánticos que realmente escribiste: un main/rol “main”, un banner, etc. Interpretación del fallo: Un rol de landmark faltante o duplicado significa que el marcado no produjo la estructura que pretendías (p. ej., un segundo <main>, o un <div> que debería haberse convertido). Ventana de monitoreo: Inmediata: compruébalo justo después de implementar la modernización. Disparador de reversión: Más de un landmark main/“main”, o un landmark anidado donde no debería (p. ej., main dentro de article), significa deshacer y volver a revisar el marcado.

Exactamente un <main> por página

Prueba a ejecutar: grep -o "<main" page.html | wc -l contra el HTML renderizado (o el código fuente), o busca <main en el panel Elements de DevTools. Resultado esperado: Exactamente una coincidencia. Interpretación del fallo: Cero coincidencias significa que no se estableció ningún landmark de contenido principal; más de una significa que la “señal más clara única” sobre el contenido principal ahora es ambigua. Ventana de monitoreo: Inmediata, en el momento de la implementación. Disparador de reversión: Cualquier recuento distinto de exactamente uno.

Los rastreadores que no renderizan aún ven la estructura

Prueba a ejecutar: Obtén la página con un cliente HTTP simple (curl o “ver código fuente de la página”, no el DOM renderizado) y confirma que los elementos semánticos están presentes en la respuesta sin procesar, no inyectados posteriormente por JavaScript del lado del cliente. Resultado esperado: <header>, <nav>, <main>, <article>/<section>, <aside> y <footer> aparecen todos en el payload HTML inicial. Interpretación del fallo: Si las etiquetas semánticas solo aparecen después de la ejecución de JS, los rastreadores que no renderizan JavaScript (según el punto sobre rastreadores de IA/LLM anterior) nunca ven la estructura en absoluto. Ventana de monitoreo: Inmediata: vuelve a comprobar cada vez que el templating o un framework JS cambie la forma en que la página se renderiza. Disparador de reversión: Los hitos semánticos presentes en el DOM renderizado pero ausentes en la respuesta HTML sin procesar.

Los niveles de encabezado son explícitos, no heredados del anidamiento

Prueba a ejecutar: En el árbol de accesibilidad de las DevTools de tu navegador (o en una extensión de verificación de esquemas), lista los niveles de encabezado en orden de documento y compáralos con las etiquetas <h1>–<h6> reales en el código fuente, independientemente de lo profundo que esté cada encabezado dentro de elementos <section>/<article> anidados. Resultado esperado: El nivel de encabezado informado para cada encabezado coincide con su etiqueta literal (un <h2> se informa como nivel 2 sin importar en cuántas secciones esté anidado): no hay degradación implícita por anidamiento. Interpretación del fallo: Si tu plantilla o una biblioteca de componentes se basa en el anidamiento de <section> para “bajar automáticamente” el rango de un encabezado, esa suposición no se cumple: el algoritmo antiguo de esquema de documento nunca se implementó y la especificación actual no calcula esquemas de esa manera. Corrige las etiquetas de encabezado reales. Ventana de monitoreo: Inmediata, y cada vez que un nuevo patrón de plantilla o componente introduzca secciones anidadas. Disparador de reversión: El nivel renderizado/anunciado de un encabezado no coincide con su etiqueta <h1>–<h6> literal.

Los enlaces falsos y los botones falsos son accesibles por teclado

Prueba a ejecutar: Navega por la página usando solo el teclado e intenta activar cada elemento clicable con Enter/Espacio; por separado, revisa el árbol de accesibilidad para el rol que informa cada elemento clicable. Resultado esperado: Los elementos que navegan informan link (<a href> nativo); los elementos que actúan sobre la página informan button (<button> nativo) y ambos son alcanzables y activables por teclado sin código adicional de role/tabindex/manejadores de teclas. Interpretación del fallo: Un <div> o <span> con un manejador de clic que no es alcanzable por teclado, o que informa un rol genérico en lugar de link/button, significa que debe convertirse al elemento nativo en lugar de parchearse con ARIA. Ventana de monitoreo: Inmediata: vuelve a comprobar después de cualquier cambio en la biblioteca de componentes o el sistema de diseño en elementos interactivos. Disparador de reversión: Cualquier control clicable que no pueda ser alcanzado o activado solo con el teclado.

Ponte a prueba: HTML semántico

Cinco preguntas rápidas sobre HTML semántico y lo que hace (y no hace) por el SEO. Elige una respuesta para cada una y luego comprueba.

Registro de cambios