HTML Checker Fixes: Valid, Robust Markup for Every Template
Browsers are very good at displaying broken HTML. They guess where a missing closing tag should go, ignore attributes they do not recognise and fall back to older rendering rules when the doctype is wrong. That forgiveness hides problems that screen readers, crawlers and scripts do not forgive so easily.
Our HTML Checker validates your markup against W3C standards and reports errors and warnings covering the doctype, character encoding, tag nesting, deprecated elements, duplicate IDs, ARIA attributes, form semantics and the language attribute. This page explains what each one means and which guide fixes it.
Why valid HTML still matters
A page does not have to pass a validator to rank or to work in a browser, and Google has long said it does not reward validation for its own sake. So why fix the errors at all?
- Different parsers recover differently. When markup is broken, each program that reads it has to guess what you meant. Browsers follow the HTML parsing rules closely, but crawlers, social preview fetchers, email clients and older assistive technology may guess differently, and content can end up in the wrong place or disappear.
- Scripts and styles depend on structure. A stray closing tag can move a block outside
the container your CSS expects. A duplicate ID means
getElementByIdreturns the wrong element. - Accessibility depends on semantics. Screen readers announce headings, lists, form labels and landmarks from the markup. Broken nesting and invalid ARIA give disabled visitors a confusing or unusable page.
- Metadata can be lost. If a stray element in the head makes the parser decide the body has started, tags that follow it, such as the canonical link or structured data, may be treated as part of the body and ignored by some consumers.
WCAG 2.2, the current version of the Web Content Accessibility Guidelines, removed the old success criterion about parsing, because modern browsers handle most syntax errors consistently. That does not make errors harmless: the consequences they cause, such as a form field with no accessible name or an ARIA reference to a missing ID, still fail other criteria.
The error categories at a glance
| Category | Typical message | Real-world effect |
|---|---|---|
| Doctype | Start tag seen without seeing a doctype first | Browser uses quirks mode; box sizes and spacing behave like very old browsers |
| Encoding | Legacy encoding or charset declared too late | Pound signs, apostrophes and accented letters display as garbage characters |
| Nesting | End tag seen but there were open elements; stray end tag | Content moves out of its container; layouts and landmarks break |
| Deprecated elements | The center element is obsolete | Presentation mixed into content; harder to restyle; some support may disappear |
| Duplicate IDs | Duplicate ID found | Anchor links, label associations, ARIA references and scripts target the wrong element |
| ARIA | Bad value for attribute role; attribute not allowed on element | Assistive technology announces the wrong thing or nothing at all |
| Language | Consider adding a lang attribute | Screen readers may use the wrong voice and pronunciation; translation prompts misfire |
| Forms | Element has no label; button missing type | Unlabelled fields for screen reader users; buttons that submit forms unexpectedly |
One root cause can produce a long list of messages. A single unclosed <div> near
the top of a template can make the validator report errors on dozens of later lines. Always fix the first
error in a cluster, then re-run the check before working through the rest; many of them will disappear.
Fix the template, not the page
Almost every website builds its pages from a small set of templates, partials and components: a header, a footer, a product card, an article layout. When the checker finds the same error on every page, it nearly always comes from one of these shared pieces. Fixing it once in the template clears it everywhere.
How to trace an error to its source
- Note the element and surrounding markup the checker reports, not just the line number. Line numbers refer to the generated page, which rarely matches any single source file.
- Search your theme or codebase for a distinctive class name or piece of text near the error.
- Check whether the markup comes from your own template, a plugin, an app embed or content entered in the editor. Each has a different owner and a different fix.
- For repeated components such as product cards in a loop, check for hard-coded IDs, which become duplicates as soon as the component appears twice.
Content entered by editors
Some errors come from the content itself: HTML pasted from a word processor, embed codes copied from other sites, or old posts written with presentational tags. These are best cleared with a search across the database or content files, followed by guidance for editors so the same markup is not pasted again.
The fix guides
Each guide covers one category of checker error, with before-and-after markup.
Document foundations
Fixing a missing or wrong doctype
covers putting <!DOCTYPE html> at the very top of every page and what quirks mode
does to layouts. Fixing character encoding
errors covers declaring UTF-8 early in the head, making the server's Content-Type header
agree, and finding files saved in a different encoding. Fixing
a missing or wrong lang attribute covers choosing a valid language code such as en-GB
and marking passages in other languages.
Structure and markup
Fixing unclosed and mismatched tags
covers forgotten closing tags, list items outside lists, and block elements placed inside paragraphs.
Fixing deprecated HTML elements covers
replacing <font>, <center>, <marquee> and presentational
attributes with CSS. Fixing duplicate id
attributes covers finding repeated IDs and generating unique ones in loops and components.
Accessibility semantics
Fixing invalid ARIA covers invalid
role values, references to IDs that do not exist, and redundant roles on native elements, following the
principle that no ARIA is better than bad ARIA. Fixing
form markup errors covers labels, name attributes, explicit button types and correct
autocomplete values.
By platform
WordPress covers theme templates, plugin output and block markup, and overriding theme files safely. Shopify covers Liquid templates, app embeds and duplicate IDs from looped product cards. React and Next.js covers JSX quirks, hydration mismatches and fragments. Static site generators covers Hugo, Jekyll, Eleventy and Astro partials and Markdown conversion.
Which errors to fix first
- Doctype and encoding. They affect the whole page, are usually fixed in one place, and can make text unreadable or layouts unpredictable.
- Errors in the head. Anything that could stop the title, meta description, canonical, hreflang or structured data being read correctly deserves early attention.
- Nesting errors in shared templates. Fix the first error in each cluster in the header, footer and main layouts, then re-check.
- Form and ARIA errors. These directly affect whether disabled visitors can use the site, particularly on contact, checkout and account pages.
- Duplicate IDs. Prioritise the ones used by labels, ARIA references, anchor links or scripts.
- Language attribute. Usually a single change to the root template.
- Deprecated elements and warnings. Clear these as part of routine maintenance.
Google has said it works out a page's language mainly from the visible content, so the lang
attribute matters more for browsers and assistive technology than for search. It is still worth fixing,
because it is quick and helps screen readers pronounce your content correctly.
Order of work
- Validate a sample. Run the HTML Checker on one page from each template: home, category, product or service, article, contact.
- Group the errors. Separate site-wide errors, which appear on every sample, from template-specific and content-specific ones.
- Fix the foundations. Doctype, charset,
langand anything in the head. - Work through templates. Fix the first error in each cluster, re-validate, and repeat until the template is clean.
- Fix forms and ARIA on the pages where visitors enter information.
- Clean up content. Search for deprecated tags and pasted markup in posts and pages.
- Check with assistive technology. Tab through key pages with the keyboard and try a screen reader to confirm the fixes work in practice.
- Prevent regressions. Add validation to your build or a regular audit.
For the full reference, read the HTML Checker Guide, the example validation report or the beginner tutorial. For a broader accessibility review, see the accessibility fixes.
1. Does HTML validation affect Google rankings?
Not directly. Google has said for many years that it does not use W3C validation as a ranking factor, and most of the web contains some invalid markup. Errors matter when they change how the page is understood: a broken head that hides the canonical or structured data, content pushed outside its container, or links that crawlers cannot follow. Fix the errors that change meaning or accessibility, and do not worry about achieving a perfect validator score.
2. What happens if a page has no doctype?
Without a doctype, browsers switch to quirks mode, a compatibility mode that imitates how very old browsers calculated sizes and spacing. Box widths, table layouts and some CSS behave differently, so the design can look broken in ways that are hard to explain. The fix is simple: make sure every page starts with the HTML5 doctype as the first thing in the file. In templating systems, check that nothing is output before it, such as blank lines or debugging text.
3. Why do I see strange characters like £ instead of a pound sign?
That is a character encoding mismatch. Text saved as UTF-8 is being read as a different encoding, or the reverse, so each multi-byte character turns into two or three odd ones. Declare UTF-8 with a meta charset tag near the top of the head, make sure the server's Content-Type header also says UTF-8, and check that your template and database files are saved in UTF-8. Content already stored wrongly may need converting as well.
4. Is a duplicate ID really a problem?
Yes, when anything relies on that ID. Anchor links jump to the first match only. JavaScript that looks up the element by ID gets the first match and ignores the others. Labels, aria-labelledby and aria-describedby references can point at the wrong element, so screen reader users hear the wrong label or none. Duplicate IDs usually come from components rendered in a loop with a hard-coded ID, and the fix is to generate a unique ID for each one.
5. Should I add ARIA roles to make my site more accessible?
Only where native HTML cannot do the job. Elements such as button, nav, main, header and ul already carry the correct meaning, so adding a role to them is redundant at best. Incorrect ARIA can make things worse by announcing the wrong thing to screen reader users. Use native elements first, and when you do build a custom widget, follow the patterns in the WAI-ARIA Authoring Practices and test it with a keyboard and a screen reader.
6. Why does the checker say my button needs a type attribute?
A button inside a form submits that form by default. If the button is meant to do something else, such as open a menu or show a password, clicking it can submit the form unexpectedly and reload the page. Setting type to button for these, and type to submit for real submit buttons, makes the behaviour explicit. The validator suggests it because the default is a common source of bugs, especially in forms built from reusable components.
7. Which language code should a UK website use?
Use en-GB on the html element for pages written in British English. The plain en code is also valid, but en-GB tells browsers and screen readers the regional variety, which can affect pronunciation and spell-checking. If part of a page is in another language, such as a Welsh greeting or a French quotation, add a lang attribute to the element containing it. For telling search engines about alternative language versions of a page, use hreflang, which is separate.
The HTML Checker runs your page through a W3C-equivalent validator and reports every error, warning and accessibility concern, from the doctype and encoding to nesting, ARIA, forms and language, so you can fix each template at its source.
Run the HTML Checker →