HTML Validation Errors Example
My ode to the horn froze halfway through its closing tags, and thawed, disastrously, at dinner.
The short answer
- What it is
- HTML validation errors are places where a page breaks the rules of the HTML standard. Stray end tags, duplicate id values, and misplaced elements are typical examples.
- Why it matters
- Browsers repair most mistakes, but they may not repair them the way you intended. Some errors move or hide important tags, so search engines read the page differently.
- How a crawler should report it
- Report the error count and warning count from the validator, with the message, line, and column for each one. Note the sampled URL and its template, since one template can repeat a fault.
- Live examples
/lab/html-validation/a/b/c/d/e/f/g/h/i/j/(positive)/lab/html-validation/a/b/c/d/e/f/g/h/i/j/k/(near miss)
Which Markup Mistakes Are Worth Fixing and Which Can Wait
HTML validation errors tend to come from templates and third-party code. A CMS plugin might print a closing tag twice. An editor might paste in markup with old attributes. Two widgets on one page may use the same id. Some teams also place a div inside a p, which looks harmless in the source. The parser will close the paragraph early, so the real structure is not what the author wrote.
The HTML standard defines how browsers must handle bad markup, so pages rarely collapse. They recover and move on. Google has said that a page does not need valid HTML to rank. Some errors still matter. If an element that does not belong in the head appears there, the parser ends the head early. Any canonical or robots tag after that point may be ignored. Duplicate IDs can also break labels and scripts.
The usual tool is the W3C Nu HTML Checker, which you can run on a URL or on pasted source. It lists each error with a line number. Since most sites use a few templates, you only need to test one page per template. Start at the top of the list, because one early mistake can set off many later messages. Ignore the count at first, and read the first few messages closely.
Fix errors in order of risk. Start with anything that breaks the head, then move to unclosed elements and duplicate IDs. Correct the template or component so the fix reaches each page. Leave harmless warnings until later, because they rarely affect anyone. For code you do not control, report the bug to the vendor or replace the widget. Add a validator step to your build process so that new faults are caught early.