¿Validar el HTML importa para el SEO?

Pasas tu página por el validador del W3C y te devuelve ciento cuarenta errores. La pregunta llega sola: ¿me está costando posiciones en Google?

La respuesta corta es que no por ser inválido, pero sí por algunos errores concretos. La mayoría de los mensajes de un informe de validación no cambian nada de lo que Google ve. Unos pocos, en cambio, hacen que Google ignore la etiqueta canonical, que un encabezado pierda su texto o que un lector de pantalla no sepa qué hay en una imagen. Saber distinguir unos de otros es lo que convierte un informe abrumador en una lista de tres tareas.

¿Qué es el validador del W3C?

HTML tiene una especificación: un documento que dice qué etiquetas existen, dónde puede ir cada una y qué atributos admite. Hoy la mantiene el WHATWG como estándar vivo, que se actualiza de forma continua. El validador Nu del W3C (en validator.w3.org) compara tu documento con esa especificación y devuelve tres tipos de mensajes:

• Errores: cosas que la especificación prohíbe. Una etiqueta sin cerrar, un elemento donde no puede ir, un atributo que no existe.
• Avisos: cosas permitidas pero desaconsejadas. Un atributo redundante, un role que ya está implícito.
• Notas informativas: detalles que no son problema, pero conviene saber.

Lo que sorprende al principio es que una página con cien errores se vea perfectamente. Es porque la especificación de HTML no solo dice cómo escribirlo bien: también define, con mucho detalle, cómo debe recuperarse el navegador de un documento mal escrito. Todos los navegadores aplican las mismas reglas de reparación, así que el error no se ve. Pero el documento que el navegador construye ya no es exactamente el que escribiste.

¿Google penaliza el HTML inválido?

No. Google ha dicho en repetidas ocasiones que la validez del HTML no es un factor de posicionamiento, y basta mirar los primeros resultados de cualquier búsqueda para comprobar que muy pocas páginas pasan la validación sin errores.

Lo que Google sí usa es el DOM: la estructura que construye al analizar tu página, después de aplicar esas reglas de reparación. Si un error cambia esa estructura, cambia lo que Google entiende. Ahí está el efecto real en el SEO: es indirecto, y depende de qué error sea.

Los errores que sí importan

Un head que se cierra antes de tiempo

En el <head> solo pueden ir unos pocos elementos: title, meta, link, script, style, base, noscript y template. Si aparece cualquier otra cosa (una imagen, un <div> que inyecta un plugin, un texto suelto), el navegador da el head por terminado en ese punto y todo lo que viene detrás pasa al <body>.

Google documenta exactamente ese comportamiento: cuando encuentra un elemento no válido en el head, deja de leer los que vienen después. Si tu canonical, tus hreflang o tu meta robots estaban por debajo de ese elemento, Google no los ve. Es el error de validación con más impacto en SEO, y suele llegar sin que nadie lo note, de la mano de un script de terceros o de una plantilla modificada.

Etiquetas de metadatos en el body

Relacionado con el anterior: una etiqueta canonical o un meta robots colocados en el <body> no se tienen en cuenta. El validador los marca como elementos fuera de sitio, y conviene leer esos mensajes con atención.

Etiquetas sin cerrar que se tragan el contenido

Un enlace <a> sin cerrar puede extenderse a todo lo que viene detrás y convertir un párrafo entero, o un encabezado, en texto de enlace. Un <div> dentro de un <p> hace que el navegador cierre el párrafo antes. El resultado son encabezados que acaban fuera de su sección, enlaces con un texto distinto del previsto y una jerarquía que no es la que diseñaste.

Atributos e identificadores duplicados

Cuando un elemento lleva el mismo atributo dos veces, el navegador se queda con el primero y descarta el segundo, sin avisar. Si el que se descarta es un alt o un href, se pierde. Los id repetidos en la página rompen los enlaces a una sección concreta, las etiquetas label de los formularios y las referencias de accesibilidad.

Errores de accesibilidad

El validador detecta varios problemas que afectan a quien navega con lector de pantalla: imágenes sin atributo alt, botones sin texto, atributos ARIA mal escritos. No son un factor de posicionamiento directo, pero sí lo son de calidad, y en muchos sectores también una obligación. Lo explicamos con más detalle en por qué importa la accesibilidad web.

La falta de doctype

Sin <!DOCTYPE html> en la primera línea, el navegador entra en «modo quirks», un modo de compatibilidad con páginas antiguas en el que las cajas se miden de otra forma. No afecta a Google directamente, pero sí a cómo se maqueta la página, y por tanto a la experiencia y a métricas como la estabilidad visual.

¿Qué errores pueden esperar?

Prioridad	Tipo de mensaje	Por qué
Alta	Elementos no válidos en el head, metadatos en el body	Google deja de leer canonical, hreflang o robots
Alta	Etiquetas sin cerrar o mal anidadas en el contenido	Cambian encabezados, enlaces y estructura
Alta	Falta de alt, botones sin texto, doctype ausente	Accesibilidad y maquetación
Media	Atributos e id duplicados	Se pierden datos sin aviso
Baja	Atributos redundantes, type innecesario en scripts	Ruido sin efecto
Baja	Barra final en elementos vacíos (<br />)	Nota informativa, no un problema

Muchos avisos de la parte baja vienen de herramientas que generan HTML de forma conservadora. Arreglarlos deja el informe más limpio, pero no cambia nada de lo que ve Google ni de lo que ve el usuario.

Un caso que merece atención aparte son los datos estructurados: si el bloque JSON-LD acaba en un sitio raro por culpa de un head roto, o el marcado de la página no coincide con lo que declara, el resultado enriquecido puede no aparecer. Está explicado en datos estructurados y resultados enriquecidos.

¿Cómo leer un informe de cien errores?

Casi nunca son cien problemas. Son tres o cuatro repetidos. Un error en el componente que pinta cada tarjeta de producto aparece tantas veces como productos hay en la página, y se arregla una sola vez, en la plantilla.

El orden que funciona: agrupa los mensajes por tipo, empieza por los que afectan al head, sigue por los de estructura y accesibilidad y deja los avisos para cuando los errores estén en cero. Después vuelve a validar, porque arreglar un cierre de etiqueta a veces hace desaparecer de golpe una docena de errores derivados.

¿Cómo validar la tuya?

El validador de HTML envía la página al validador oficial del W3C, ya sea por su URL publicada o pegando el documento entero si aún no está en línea. Devuelve los mensajes agrupados por tipo de problema, con cuántas veces aparece cada uno, una explicación en lenguaje corriente de los más frecuentes y un ejemplo con el extracto de código y la línea.

Empieza por tu página de inicio y por una plantilla de cada tipo: una ficha de producto, un artículo, una página de servicio. Lo que encuentres en una se repetirá en todas las de su tipo.

El validador revisa la estructura del documento, no lo que dice. Para las faltas de ortografía y gramática que se cuelan en la interfaz hicimos LintGrafía, una extensión de Chrome que revisa la página ya renderizada, también en localhost.

---

Un HTML perfectamente válido no te sube en Google, y uno con errores no te hunde. Lo que importa es que el documento que construye el navegador sea el que tú escribiste, sobre todo en el head. Validar de vez en cuando, y siempre después de añadir un script de terceros, es la forma barata de comprobarlo.