HTML es un lenguaje indulgente, y precisamente por eso los errores de marcado sobreviven: el navegador repara en silencio lo que escribiste, así que la página se ve bien mientras el documento no es lo que crees. Esta guía cubre la estructura que un documento necesita de verdad, las partes opcionales que importan y los errores que producen diferencias de maquetación semanas después.

Puedes probar cada ejemplo en la herramienta HTML online de UrsaKit, que renderiza tu marcado en una vista aislada mientras escribes.

01El navegador es indulgente, y ese es el problema

Dale a un navegador un <div> sin cerrar, una tabla con celdas descuadradas o un párrafo dentro de otro párrafo y no dará error: adivinará. El algoritmo de análisis de HTML está especificado con todo detalle precisamente porque esas conjeturas deben ser consistentes entre navegadores.

El inconveniente práctico es que el DOM que obtienes no siempre es el DOM que escribiste. Un <p> dentro de un <p> cierra el primer párrafo, un <div> dentro de <table> se mueve fuera de la tabla y el anidamiento inválido en <ul> se convierte en nodos de texto.

La única forma fiable de ver lo que has producido es inspeccionar el DOM renderizado, no el archivo de origen. Las herramientas de desarrollo de cualquier navegador muestran el árbol analizado.

02Las cinco líneas que necesita todo documento

<!doctype html>
<html lang="es">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>Título de la página</title>
  </head>
  <body>
    <h1>Un encabezado que describe la página</h1>
  </body>
</html>

Cada línea tiene una función invisible hasta que falta:

• <!doctype html> saca al navegador del modo quirks. Sin él, el box sizing, las alturas en porcentaje y la altura de línea siguen reglas antiguas.
• lang indica al lector de pantalla qué pronunciación usar y permite partir palabras correctamente. Usa una etiqueta real como es o zh-Hant.
• charset debe ir primero en el head. Si falta o llega tarde, cada carácter no ASCII se convierte en mojibake.
• viewport es lo que hace que la página sea usable en móvil; sin él, los teléfonos renderizan con un ancho simulado de 980 píxeles.
• title es la etiqueta en pestañas, marcadores y resultados de búsqueda.

Un solo h1 por página.

El h1 es el tema de la página. Si cada sección empieza con un h1, ni los buscadores ni los usuarios de lectores de pantalla pueden saber de qué trata. Usa h2 para las secciones y h3 para las subsecciones.

03head frente a body

El head contiene información sobre el documento; el body contiene lo que ve el usuario. Mezclarlos es una de las fuentes de confusión más habituales.

El contenido colocado en el head no se renderiza; el marcado que pertenece al head y aparece en el body se mueve o se ignora. Si un enlace a una hoja de estilos parece no hacer nada, comprueba si acabó en el body.

04Elementos vacíos y escapes

Algunos elementos no tienen contenido ni etiqueta de cierre. Se llaman elementos vacíos, y escribir </img> es un error de análisis aunque los navegadores lo toleren.

<img src="/logo.png" alt="Logotipo de UrsaKit" width="1161" height="389" />
<input type="email" name="email" required />
<br />
<hr />
<meta charset="utf-8" />

Dos reglas cubren casi todos los errores de escape:

• El ampersand inicia una entidad. Escribe & para un & literal; de lo contrario puede empezar una referencia de carácter y cambiar el texto.
• Comillas dentro de atributos. Envuelve los valores entre comillas dobles y escapa las internas como ", o cambia ese atributo a comillas simples.

Define siempre width y height en las imágenes. El navegador reserva el espacio antes de que el archivo cargue, lo que evita el desplazamiento de maquetación que arruina la posición de lectura y los Core Web Vitals.

05Qué cambian de verdad los elementos semánticos

section, article, nav y div se renderizan como bloques sin estilo por defecto. Elegir entre ellos no cambia un píxel, así que muchos equipos usan div para todo. Ese intercambio tiene costes reales:

• Los lectores de pantalla solo pueden saltar entre regiones si el marcado las define.
• Los rastreadores usan encabezados y regiones para deducir qué parte es el contenido principal.
• Tu propio CSS y tus pruebas obtienen selectores como nav ul en lugar de .wrapper-3 ul.

06Siete errores de marcado que conviene corregir

07Probar marcado sin compilar nada

1. Pega un documento completo o un fragmento — La herramienta HTML acepta ambos. Un fragmento se envuelve en un documento mínimo para revisar un componente aislado.
2. Mira la vista previa mientras escribes — Se renderiza en un marco aislado, así que los scripts se ejecutan sin tocar la página de la herramienta.
3. Compara con el DOM, no con tu código — Cuando algo se vea mal, inspecciona el elemento en la vista previa. Los navegadores reparan el marcado y solo el árbol analizado te dice qué construiste.
4. Pasa al estilo — Con la estructura correcta, lleva el mismo marcado al playground de CSS para trabajar la maquetación, o ejecuta comportamiento con el ejecutor de JavaScript.

Mantener la estructura correcta desde el principio sale más barato que descubrir después que un bug de maquetación era un bug de HTML.