El HTML semántico es la capa de significado que un extractor lee antes de que cualquier modelo piense: main delimita el contenido real, article lo declara como pieza autónoma, los encabezados arman el esquema y una tabla de verdad conserva sus relaciones de datos. El schema declara hechos; las etiquetas estructuran el documento. Cuando faltan, los sistemas reciben una sopa de divs y adivinan. Aquí están las etiquetas que importan, la prueba de extracción y cómo no perderlas con un constructor visual.
Tabla de Contenidos
- 1 ¿Qué lee un extractor antes de que el modelo piense?
- 2 Las etiquetas estructurales y su trabajo
- 3 Tablas reales contra divs disfrazados
- 4 Listas, encabezados y énfasis con significado
- 5 ¿Qué entiende un parser en cada caso? La prueba de extracción
- 6 ¿Cómo mantener la semántica si usas Elementor?
- 7 Semántica y schema: cómo se reparten el trabajo
- 8 Errores comunes que ensucian la extracción
- 9 Preguntas frecuentes
¿Qué lee un extractor antes de que el modelo piense?
Entre tu página y cualquier modelo hay un paso poco glamoroso: la extracción. Un parser descarga tu HTML y decide qué es contenido y qué es envoltorio, qué es título y qué es párrafo, qué celdas se relacionan con qué columnas. Los modelos no leen tu diseño: leen el resultado de esa extracción. Si el parser confunde tu menú con tu contenido o aplana tu tabla en frases sueltas, el modelo trabaja con escombros por más brillante que sea.
El HTML semántico es la forma de mandarle instrucciones claras a ese paso. Es la capa cero de la legibilidad que desarrollamos en la guía de GEO para aparecer en ChatGPT, Gemini, Claude y Perplexity: antes del schema, antes del contenido citable, está el documento bien construido. En las auditorías del servicio de posicionamiento GEO, esta capa es de las primeras que revisamos porque sus fallas degradan todo lo demás.
Las etiquetas estructurales y su trabajo
| Etiqueta | Qué declara | Error típico |
|---|---|---|
| main | El contenido principal de la página, una sola vez | No existir: todo flota en divs al mismo nivel |
| article | Una pieza autónoma con sentido propio | Usarlo como caja decorativa repetida |
| section | Un bloque temático dentro de la pieza, idealmente con su encabezado | Secciones sin encabezado que no agrupan nada |
| header y footer | Cabecera y pie, del sitio o de la pieza | Meter contenido sustantivo en el footer |
| nav | Bloques de navegación | No marcarla, y que el parser mezcle menú con contenido |
| aside | Contenido tangencial: sidebar, relacionados | Poner ahí información que el artículo necesita |
La lógica conjunta: un extractor que encuentra main con un article adentro, secciones encabezadas y la navegación marcada como nav puede separar el grano de la paja sin heurísticas. Cada etiqueta correcta es una adivinanza menos.
Tablas reales contra divs disfrazados
La tabla es el caso donde la semántica más se nota. Una tabla real, table con thead, th y tbody, conserva las relaciones: cada celda sabe a qué columna y fila pertenece, y un sistema puede responder cuánto cuesta el plan intermedio leyendo la estructura. La imitación visual con divs alineados por CSS se ve idéntica en pantalla y se extrae como una lista plana de frases sin relación: plan, precio, plan, precio, sin manera confiable de emparejarlos.
La regla es directa: datos tabulares van en table, siempre, con encabezados de columna en th que se expliquen solos. Y la inversa también: la tabla no es herramienta de maquetación; lo que no son datos relacionados no va en tabla. Esa disciplina viene del HTML clásico y hoy paga doble, porque las tablas bien hechas son de los fragmentos más citados en respuestas con datos.
Listas, encabezados y énfasis con significado
Tres familias completan la base. Los encabezados h1 a h3 son el esqueleto que los extractores usan para fragmentar: jerarquía real, un solo h1, sin saltos de nivel ni títulos que son estilo visual aplicado a un párrafo. Las listas ul y ol declaran enumeración y orden: cinco pasos en ol son un procedimiento; los mismos pasos en párrafos separados por saltos de línea son cinco frases sueltas. Y el énfasis semántico, strong para lo importante, em para el acento, le indica al parser qué destacaste, mientras que el color y el tamaño aplicados por CSS no le dicen nada.
Suma dos etiquetas menores que rinden: blockquote para citas reales, que los extractores reconocen como voz ajena, y figure con figcaption para imágenes con leyenda, que asocia la descripción a la imagen de forma explícita.
¿Qué entiende un parser en cada caso? La prueba de extracción
No tienes que creer: puedes mirar. Tres pruebas en orden de esfuerzo. La vista de lector del navegador: ábrela en tu página clave y observa qué sobrevive; si el modo lectura pierde tu tabla o mezcla el menú, los extractores sufren igual. El volcado de texto plano: copia tu página desde el navegador a un editor de texto sin formato y revisa si la estructura se sostiene. Y la prueba con asistente: pídele a un modelo con navegación que extraiga los datos clave de tu URL, y compara contra lo que la página dice de verdad.
Haz la prueba A/B cuando dudes de una sección: la misma información maquetada con divs y con etiquetas semánticas, y las mismas tres pruebas sobre ambas. La diferencia en lo extraído suele cerrar la discusión con el equipo de diseño en cinco minutos, porque deja de ser una opinión de SEO contra una de estética y pasa a ser evidencia.
¿Cómo mantener la semántica si usas Elementor?
Los constructores visuales no condenan tu semántica, pero la dejan en tus manos. Las prácticas que usamos en KOM con Elementor Pro: define la etiqueta correcta en cada widget de encabezado, porque el constructor te deja elegir entre h1 y h6 y la tentación de elegir por tamaño visual es el origen de la mitad de los esqueletos rotos; usa el widget de tabla o un bloque HTML para datos tabulares en lugar de columnas decorativas; y revisa qué etiqueta envuelve cada sección del template, que en los temas y constructores serios puede configurarse.
El control de calidad es la misma prueba de extracción de arriba, corrida sobre el resultado final publicado. El constructor produce el HTML que le pidas: la diferencia entre sopa y estructura es quién configura.
Semántica y schema: cómo se reparten el trabajo
Conviene cerrar la confusión frecuente entre ambas capas. El schema declara hechos sobre las cosas: este es un artículo, este es su autor, este producto cuesta tanto. El HTML semántico declara la estructura del documento: esto es el contenido principal, esto es una sección, estas celdas se relacionan. Un schema impecable sobre un documento ilegible es una etiqueta de lujo en una caja rota; una estructura impecable sin schema es una caja perfecta sin etiqueta. Los sistemas serios leen ambas capas y las cruzan.
En la práctica, el orden de trabajo correcto va de adentro hacia afuera: primero el documento bien construido, porque beneficia a todos los lectores sin excepción, y encima los datos estructurados que formalizan los hechos. Cuando una auditoría muestra problemas en las dos capas, empezamos siempre por la semántica: es la corrección con efecto más transversal.
Errores comunes que ensucian la extracción
Los cinco de siempre en las auditorías. Encabezados elegidos por tamaño visual, con h4 antes que h2 y varios h1 decorativos. Datos tabulares en columnas de constructor que se extraen como frases sueltas. Contenido sustantivo en asides y footers, donde los extractores lo descartan por diseño. Texto importante dentro de imágenes, invisible para el parser. Y el DOM inflado de divs anidados sin función, que no rompe la extracción pero la degrada: mientras más ruido estructural, más heurística y más error.
Preguntas frecuentes
¿El div ya no sirve para nada?
Sirve para lo que siempre debió: agrupar con fines de estilo y layout cuando ninguna etiqueta semántica corresponde. El problema nunca fue el div sino el div como única herramienta. La estructura del documento la declaran main, article, section y los encabezados; el div decora alrededor sin estorbar.
¿El orden del contenido en el código importa?
Importa: los extractores leen el DOM en orden, y un contenido principal que aparece después de trescientas líneas de menús y banners depende de que el parser lo encuentre. Con main bien usado el riesgo baja, pero la práctica sana se mantiene: lo importante temprano en el documento, la decoración después.
¿Tener dos h1 en la misma página es grave?
No es catástrofe, es ambigüedad gratuita: el h1 declara el tema del documento y dos declaraciones compiten. Los sistemas modernos lo toleran, igual que toleran tanta imperfección, pero cada ambigüedad suma adivinanza. Un h1 único con jerarquía limpia debajo es gratis: no hay razón para no tenerlo.
¿Los atributos ARIA reemplazan a las etiquetas semánticas?
No: la regla de oro de accesibilidad es usar la etiqueta nativa cuando existe, y reservar ARIA para lo que el HTML no cubre. Un div con role de navegación es un parche de algo que nav resuelve solo. Para extractores y lectores de pantalla por igual, la semántica nativa es la señal más confiable.
Tu siguiente paso: corre la vista de lector sobre tus tres páginas más importantes hoy mismo. Lo que el modo lectura pierda o mezcle es tu lista de correcciones de esta semana, y cada arreglo mejora a la vez accesibilidad, SEO clásico y legibilidad para los modelos.
