Errores comunes en HTML que todo principiante comete (y cómo evitarlos)

Antes de nada: piensa el HTML como los cimientos (estructura sobre estética)

Cuando empecé, subestimé el HTML: quería “hacer páginas” sin dominar las etiquetas base. Fue un error. El HTML es la estructura; si esos cimientos están torcidos, ni CSS ni JavaScript salvan la casa. Hoy me obligo a responder: ¿por qué uso esta etiqueta y no otra? Si no tengo una razón clara, replanteo.

Principios de cimientos:

• Contenido primero: redacta el contenido crudo y trocéalo por significado.
• Semántica antes que estilo: elige etiquetas por rol, no por cómo “se ven”.
• Jerarquía: un flujo lógico con encabezados es media batalla ganada.

Mal vs. bien

<!-- MAL: usa divs por costumbre, sin semántica -->
<div class="titulo">Mi blog</div>
<div class="menu">Inicio | Artículos | Contacto</div>

<!-- BIEN: estructura con sentido -->
<header>
  <h1>Mi blog</h1>
  <nav>
    <ul>
      <li><a href="/">Inicio</a></li>
      <li><a href="/articulos">Artículos</a></li>
      <li><a href="/contacto">Contacto</a></li>
    </ul>
  </nav>
</header>

Idea clave que me cambió el chip: “piensa el HTML como los cimientos; primero estructura, luego estética”.

Sintaxis que rompe páginas: etiquetas sin cerrar, mal anidadas y comillas mezcladas

Nada frustra más que un <div> sin cerrar. HTML es tolerante, sí, pero los navegadores “adivinan” y acaban generando DOMs raros.

Errores clásicos:

1. Etiquetas sin cerrar o orden de cierre incorrecto.
2. Anidamiento inválido (p. ej., poner <p> envolviendo <div>).
3. Mezclar comillas en atributos (class="btn’…).
4. Mayúsculas/minúsculas inconsistentes en atributos (HTML5 es case-insensitive en etiquetas, pero los atributos en general no lo son y la consistencia importa).

Patrón “matrioska” (H3): lo que abres último, lo cierras primero.

<!-- MAL -->
<p><em><strong>Texto importante</em></strong></p>

<!-- BIEN -->
<p><em><strong>Texto importante</strong></em></p>

Mini-ejercicio #1 (5 min):
Corrige los errores de este bloque y explica qué cambiaste.

<section>
  <h2>Noticias recientes
  <article>
    <h3>Nueva versión</h4>
    <p>Se liberó la versión 2.0<p>
  </article>
</section>

Pista: cierra h2 y p, corrige el nivel de encabezado y el orden de cierre.

Semántica en serio: cuándo usar section, article, nav y encabezados H1–H6

Mi regla hoy: si no puedo explicar por qué uso una etiqueta, la replanteo. Un article es contenido independiente (una noticia, un post). section agrupa por tema dentro de algo más grande. nav es para grupos de enlaces de navegación principales. aside es contenido complementario.

Un H1 por página (H3): no por obligación técnica, sino por claridad de jerarquía; después, H2 → H3 según profundidad, sin saltos de nivel caprichosos.

<main>
  <h1>Guía de café</h1>
  <section>
    <h2>Molido</h2>
    <p>…</p>
  </section>
  <article>
    <h2>Reseña: prensa francesa</h2>
    <p>…</p>
  </article>
</main>

Antipatrones habituales:

• Usar section para todo “porque suena pro”.
• Poner varios h1 por estética en tarjetas.
• Meter navegación secundaria sin nav.

Texto, listas y enlaces: errores que confunden a usuarios y buscadores

Cuando no dominaba las etiquetas base, hacía listas con <br> y enlaces con “haz clic aquí”. Hoy priorizo significado:

• Párrafos: cada idea, su <p>.
• Listas: usa <ul>/<ol> y <li>.
• Enlaces: el anchor text debe describir el destino (“Guía de flexbox”), no la acción (“aquí”).

Anchor text descriptivo vs. “haz clic aquí” (H3)

<!-- MAL -->
<p>Para aprender flexbox, haz <a href="/flexbox">clic aquí</a>.</p>

<!-- BIEN -->
<p>Consulta la <a href="/flexbox">guía completa de flexbox</a>.</p>

Mini-ejercicio #2 (5 min):
Transforma este texto con <br> en una lista semántica.

<h2>Tareas</h2>
<p>Lavar<br>Planchar<br>Cocinar</p>

Imágenes y multimedia: alt, formatos y peso (sin caer en el <br> para “maquetar”)

• alt útil vs. alt vacío (H3): describe la imagen si aporta contenido; déjalo vacío si es puramente decorativa (y marca con CSS como role="presentation" si aplica).
• Formato: usa SVG para iconos/lineales; WebP/AVIF para fotos cuando sea posible.
• Peso: no subas un .jpg de 3 MB a la home; controla dimensiones y compresión.
• No uses <br> para crear “espacios”. Para separación, CSS.

<!-- MAL -->
<img src="grafica.png" alt="imagen">
<br><br>

<!-- BIEN -->
<img src="ventas.webp" alt="Gráfico de ventas Q4 2025">

HTML no es CSS ni JavaScript: separación de responsabilidades

En mis inicios metía estilos en línea y scripts por todas partes. Ahora, HTML = contenido y significado, CSS = presentación, JS = interacción.

• Evita estilos en línea salvo casos puntuales (emails, pruebas rápidas).
• Carga CSS en <head> y JS al final o con defer.
• No uses HTML para maquetar (tablas para layout, <br> para espacios).

<!-- MAL -->
<p style="color:red;font-size:24px">Alerta</p>

<!-- BIEN -->
<p class="alerta">Alerta</p>

Accesibilidad básica que los novatos olvidan (atributos, foco y orden de tabulación)

• Idioma del documento: <html lang="es">.
• Contraste y foco: asegúrate de que los elementos interactivos muestran foco visible.
• Formularios etiquetados: label + for (H3) une etiquetas con inputs.
• Orden de tabulación: estructura lógica; evita abusar de tabindex.

<label for="email">Correo</label>
<input id="email" name="email" type="email" required>

Error muy común: usar placeholder como sustituto de label. No lo es.

SEO on-page desde el marcado: metadatos, enlaces y estructura lógica

• <title> y <meta name="description"> claros y únicos por página.
• Encabezados coherentes: ayudan a buscadores y a lectores de pantalla.
• Enlaces internos: conectan contenidos relacionados (no los metas “porque sí”).
• Datos enriquecidos (cuando aplique): Schema.org con JSON-LD.

<head>
  <title>Errores comunes en HTML (y cómo evitarlos)</title>
  <meta name="description" content="Guía práctica con ejemplos para principiantes en HTML.">
</head>

Validación y depuración: cómo encontrar y corregir errores rápido

• Validador W3C para cazar sintaxis rota.
• Inspector del navegador: mira el DOM real, no lo que “crees” haber escrito.
• Vista sin CSS: revela si la estructura por sí sola se entiende.
• Lighthouse/PageSpeed: te chiva accesibilidad y mejores prácticas.

Mini-ejercicio #3 (10 min):

1. Escribe una página mínima con header/nav/main/article/footer.
2. Desactiva CSS (en DevTools) y comprueba si el contenido se entiende.
3. Pasa el HTML por un validador y corrige lo que salga.

Checklist final: 15 comprobaciones rápidas antes de publicar

1. Hay un H1 único y jerarquía clara H2→H3.
2. No hay etiquetas sin cerrar ni anidamientos incorrectos.
3. lang está definido en <html>.
4. Las imágenes tienen alt correcto (o vacío si decorativas).
5. No uso <br> para maquetar espacios.
6. No uso tablas para layout.
7. Nada de estilos en línea salvo necesidad real.
8. CSS enlazado en <head>, JS con defer si aplica.
9. Formularios con label asociado a cada input.
10. Enlaces con texto descriptivo.
11. Título y descripción únicos y útiles.
12. Navegación dentro de <nav> y lista semántica.
13. Listas con <ul>/<ol> y <li> (no <br>).
14. El documento valida sin errores graves.
15. Con CSS desactivado, el contenido se entiende.

Conclusión

Dominar las etiquetas principales me ordenó la cabeza (y el HTML). Hoy trabajo así: primero estructura, luego estilo, después interacción. Cuando dudo, reviso: “¿esta etiqueta aporta significado?” Si la respuesta es “no”, cambio. Con estos hábitos y la checklist, te ahorras horas de frustración y páginas quebradizas.

FAQs rápidas

¿Cuáles son los errores HTML que más rompen la estructura?
Etiquetas sin cerrar, anidamientos incorrectos y múltiples H1 sin criterio.

¿Qué etiquetas básicas debo dominar primero?
html, head, body, header, nav, main, section, article, aside, footer, h1–h6, p, ul/ol/li, a, img, form/label/input, button.

¿Es malo usar <br> para maquetar?
Sí. <br> es un salto de línea en contenido, no una herramienta de layout. Usa CSS para espacios.