TL;DR: <head> holds nothing you can see, only instructions for the browser and crawlers reading your page. Six tags are non-negotiable — charset, viewport, title, description, canonical, favicon — a few more help with loading and language, and several once-common tags (meta keywords, X-UA-Compatible, duplicate charsets) do nothing in 2026 and should be deleted.
Most front-end review catches what's visible: layout, spacing, contrast. Almost nobody reviews <head>, because none of it renders. That's why it accumulates cruft — copy-pasted boilerplate, dead meta tags from an old starter template, a second charset nobody noticed. None of it throws an error; all of it quietly works against you. Teams offering disciplined web development services treat <head> hygiene as a baseline, not an afterthought.
This guide sorts every legitimate <head> element by purpose, explains why order matters, and calls out the tags safe to delete.
Nothing inside <head> renders as visible content — that's the point. It's the contract between your document and the two readers that matter before a human sees the page: the browser's rendering engine and the crawlers deciding whether to index it. The browser reads <head> to decode the bytes, size the viewport, and fetch what it needs before it can safely paint. A crawler reads it to decide what the page is about and what to show in a result or shared-link preview. Every tag here instructs one of those two audiences — never the reader.
Three tags are genuinely required on every production page. Skip any of them and you get a real, visible failure — not a theoretical best-practice violation.
<meta charset="utf-8"> tells the browser how to turn bytes into characters. Browsers scan only the first 1024 bytes for this declaration, since decoding starts before parsing finishes. Put it after a long <title> or a stack of Open Graph tags and the browser may already have guessed wrong — so charset goes first, before anything else.
<meta name="viewport" content="width=device-width,initial-scale=1"> tells mobile browsers to render at the device's actual width instead of a scaled-down desktop canvas. Skip it and your breakpoints never fire — the phone shows a tiny desktop layout to pinch-zoom into.
<title> rounds out the trio: the browser tab label, the default search-result heading, and the text people paste when sharing a link — all reasons to keep it specific and under roughly 60 characters, not the generic "Home" a template leaves behind.
This group doesn't change how the page renders — it changes how the page is understood and represented elsewhere: a search result, an AI answer, an autocomplete.
Engines use your description far more often when it's an accurate, specific summary than when it's generic or missing. One sentence answering "why click this" beats an auto-generated snippet. Keep it roughly 70–155 characters — useful, but short enough to avoid truncation.
If the same content is reachable at more than one URL — a tracking parameter, a trailing slash, http versus https — canonical tells crawlers which one is real. Without it, a wrong guess splits your ranking signals across duplicates instead of consolidating them.
The lang attribute lives on <html>, not <head>, but belongs in this group — read by the same audiences. <html lang="en"> tells screen readers which pronunciation rules to use and search engines which language edition this is. One word, real weight, easy to forget on a templated page.
<head> is also where you tell the browser what else it needs before finishing the page — stylesheets, fonts, sometimes scripts.
A <link rel="stylesheet"> in <head> is render-blocking by default: the browser won't paint until it has downloaded and parsed that CSS, to avoid a flash of unstyled content. That's usually right for your main stylesheet. A plain <script src="..."> in <head> blocks parsing of the rest of the document while it downloads and runs — so scripts that don't need to run before first paint should carry defer or async, or move to the end of <body>. Put only what first paint depends on in <head>.
<link rel="icon"> sets the favicon — the mark in the browser tab, bookmarks bar, and history. One modern SVG icon (<link rel="icon" href="/favicon.svg" type="image/svg+xml">) covers almost every current browser; the old multi-size PNG/.ico set is only needed for legacy platforms. The common failure isn't a missing tag, it's a wrong path — absolute, assuming the page lives at the site root when the URL is nested, silently serving no icon at all.
<base href="..."> is rarer: it sets the base URL every relative link, image src, and form action resolves against. Useful for syndicated content or single-page apps serving the same markup from multiple paths, but a source of confusing bugs if you forget it's there.
Open Graph tags (og:title, og:image, and friends) and Twitter's Card meta tags control how a link looks when pasted into Slack, X, or a messaging app — the preview card with a title, description, and image. They're a distinct category of head metadata with their own attribute set, deep enough for a treatment of their own rather than a quick summary here. The short version: skip them, and most platforms fall back to scraping <title> and the first image they find, rarely the preview you'd choose on purpose.
A few tags that used to be standard advice do nothing on a modern stack, surviving only because nobody deleted them.
<meta charset> tags from a merge or copy-pasted block. The second is ignored — a sign nobody has reviewed this <head> in a while.<meta charset="utf-8">. Redundant, not wrong.Strip away the cruft and a production-ready <head> for a typical content page is short:
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>Page Title — Site Name</title>
<meta name="description" content="One honest sentence about this page.">
<link rel="canonical" href="https://example.com/page">
<link rel="icon" href="/favicon.svg" type="image/svg+xml">
<link rel="stylesheet" href="/assets/site.css">
</head>Everything else — Open Graph, Twitter Card, structured data, preconnects — stacks on top of this baseline depending on what the page needs. Nothing below it is optional.
Mostly no, with one exception: charset must come first, within the first 1024 bytes, so the browser can correctly decode everything after. Beyond that, charset-then-viewport-then-title is convention, not an enforced rule.
No — the http-equiv version is the older syntax for the same thing. Keep <meta charset="utf-8">, not both.
No major engine uses it for ranking today — safe to delete from every page.
One SVG icon via <link rel="icon" href="/favicon.svg" type="image/svg+xml"> covers current browsers. Add a PNG and Apple touch icon only for older browsers or legacy home-screen icons.
Yes — it changes the resolution target for every relative URL on the page: links, images, form actions, and script/style sources alike.
Only scripts first render truly depends on belong in <head>, marked defer or async. Everything else — analytics, widgets, non-critical interactivity — is fine deferred or at the end of <body>.
It can hurt both: screen readers use it for pronunciation, search engines use it as a language signal. One attribute, outsized downside if missing.
Reference material worth bookmarking: MDN's head element documentation and the WHATWG HTML specification define exactly what's permitted inside <head> and what order is actually required.
None of this is exotic — a short, finite list of tags, each doing one job for one of two audiences that never see your page render. Get the six non-negotiables right, add only what the page needs beyond them, and delete anything left over from a template nobody's reviewed in years.