Teams tend to think of doctype, lang, charset, viewport, and favicon as setup details you sort once and never revisit.
In practice, these are exactly the kind of low-level signals that drift during redesigns, framework migrations, or rushed releases. And when they drift, the failures are annoying:
- text renders strangely,
- mobile layout behaves inconsistently,
- assistive technology gets worse page-language hints,
- shared layouts stop feeling polished,
- browsers fall back to behavior you did not intend.
This is not glamorous work, but it is worth doing.
1. Doctype: keep the browser out of quirks mode
Modern HTML should start with:
<!doctype html>That small line tells the browser to render using the standards path instead of older compatibility behavior.
If it is missing or malformed, you are increasing the chance of layout weirdness for no good reason.
2. lang: give browsers and assistive tech the right language signal
Your root HTML element should declare the base language of the page:
<html lang="en">This matters because screen readers and other assistive technology use it to choose pronunciation and language handling. It also gives downstream systems a clearer machine-readable signal about the page.
If your site changes language per locale, make sure the rendered document actually changes the lang value too.
3. charset: make UTF-8 explicit and early
Modern HTML should declare UTF-8 near the top of the document head:
<meta charset="utf-8">This is one of those things you only notice when it breaks, usually via weird characters, punctuation, or imported content looking wrong.
MDN also notes the charset declaration should sit entirely within the first 1024 bytes of the document.
4. Viewport: stop breaking mobile by accident
For most sites, this is the sane default:
<meta name="viewport" content="width=device-width, initial-scale=1">Without a correct viewport tag, mobile browsers may render the page in a way that looks zoomed out or scaled oddly.
Also worth checking:
- avoid
user-scalable=no, - avoid low maximum zoom limits,
- make sure the actual responsive CSS matches the intent of the viewport setting.
5. Favicon: small file, big trust signal
Favicons are not just decorative. They help users recognize the correct site in tabs, bookmarks, and browser UI.
At minimum, make sure:
- the icon exists,
- the linked path returns HTTP 200,
- the type is sensible,
- the icon is not stale or broken after a redesign or deploy move.
It is a small trust signal, but people notice when it is missing.
A production-ready head baseline
This is the minimum baseline most marketing and product pages should get right:
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="icon" href="/favicon.ico">
</head>This is not the full head strategy, but it is the baseline that prevents a surprising amount of avoidable drift.
Where these usually break
The common causes are:
- migrating to a new layout or templating system,
- mixing app shells and static marketing layouts,
- multiple teams owning different head partials,
- framework defaults being silently overridden,
- one page using a different document shell than the rest of the site.
If one area of the site looks "mostly fine" but not quite right, this is worth checking.
The practical fix workflow
- Identify the canonical head/layout partial for each shell.
- Compare all public and app layouts against the baseline.
- Standardize the shared defaults.
- Re-check a few high-traffic pages manually on desktop and mobile.
Do not patch these one page at a time if the real problem is layout drift.
Owner checklist
- [ ] Every public and app shell starts with a valid HTML5 doctype.
- [ ] The root document language is explicitly declared.
- [ ] UTF-8 is declared correctly and early.
- [ ] Mobile viewport settings are present and not hostile to zoom.
- [ ] Favicon links resolve correctly after deploys and redesigns.
Where Scavo helps
Scavo checks these quiet technical signals continuously so layout and machine-readable drift gets caught before it turns into support noise or crawl weirdness.
This category matters precisely because the issues are easy to miss in normal release QA.
Sources
- MDN: Doctype glossary
- MDN: HTML
langglobal attribute - MDN:
<meta>element andcharset - MDN:
meta name=\"viewport\" - MDN:
rel=\"icon\"and favicon references
What to do next in Scavo
- Run a fresh scan on your main domain.
- Open the matching help guide in
/help, assign an owner, and ship the smallest safe fix. - Re-scan after deployment and confirm the trend is moving in the right direction.
