`<head>`, Meta Tags, and Document Security

TL;DR

The <head> configures rendering, SEO, social sharing, and security. Know the essential meta tags (charset, viewport, theme-color, referrer policy), how Open Graph/Twitter cards drive link previews, how JSON-LD structured data feeds rich search results, and the security-relevant attributes: CSP (best via HTTP header, possible via <meta>), SRI (integrity) for third-party scripts, crossorigin, and nonce for inline-script allowlisting. The frontend angle on security is mostly here and in ../17_security/.

Interview Q&A

Q: Which meta tags are non-negotiable?

<meta charset="utf-8" />                                  <!-- first; encoding -->
<meta name="viewport" content="width=device-width, initial-scale=1" />  <!-- responsive -->
<title>Page title</title>                                 <!-- SEO + tab + a11y -->
<meta name="description" content="…" />                   <!-- search snippet -->
<meta name="theme-color" content="#0b0b0b" />             <!-- browser UI tint -->

charset must be in the first 1024 bytes. viewport is mandatory for mobile. theme-color (with media for light/dark) tints the mobile browser chrome. viewport-fit=cover handles notches/safe areas.

Q: How do Open Graph and Twitter cards work?

A: Meta tags read by social platforms/crawlers to build link previews:

<meta property="og:title" content="…" />
<meta property="og:description" content="…" />
<meta property="og:image" content="https://…/preview.png" />
<meta property="og:type" content="website" />
<meta name="twitter:card" content="summary_large_image" />

They must be server-rendered — most crawlers don’t run JS, so a pure CSR SPA shows no preview. This is a concrete reason to SSR/prerender (../19_rendering_modes/). og:image should be an absolute URL.

Q: What is JSON-LD and why use it over microdata?

A: JSON-LD is structured data (schema.org) in a <script type="application/ld+json"> block — it tells search engines what the page is (Article, Product, FAQ, BreadcrumbList) to enable rich results:

<script type="application/ld+json">
{ "@context": "https://schema.org", "@type": "Product", "name": "…", "offers": { "@type": "Offer", "price": "29.00" } }
</script>

Preferred over inline microdata/RDFa because it’s decoupled from the markup (one block, no attribute clutter) and Google recommends it.

Q: How do you set a Content Security Policy, and meta vs header?

A: CSP restricts where resources can load from, mitigating XSS. Prefer the HTTP header (Content-Security-Policy) — it supports the full feature set including frame-ancestors and reporting. The <meta http-equiv="Content-Security-Policy"> form works for some directives but can’t use frame-ancestors/report-uri and applies only after parsing begins.

<meta http-equiv="Content-Security-Policy"
      content="default-src 'self'; script-src 'self' 'nonce-abc123'; img-src 'self' data:;" />

Full CSP treatment: ../17_security/.

Q: What are SRI, `crossorigin`, and `nonce`?

SRI (integrity) — a hash that the browser verifies before executing a third-party script/style; if the CDN file was tampered with, it’s blocked. Requires crossorigin:
```
<script src="https://cdn.example/lib.js"
        integrity="sha384-…" crossorigin="anonymous"></script>
```
crossorigin — controls CORS mode for the request (anonymous = no credentials); needed for SRI and for readable cross-origin errors/fonts.
nonce — a per-response random token; CSP allows only inline scripts carrying the matching nonce, so injected inline scripts (XSS) are blocked. The nonce must be unique per response and never reused.

Q: What does the referrer policy control?

A: <meta name="referrer" content="strict-origin-when-cross-origin"> (or the referrerpolicy attribute / header) controls how much of the URL is sent in the Referer header on outbound requests — a privacy/leak control (don’t leak query strings/paths to third parties). strict-origin-when-cross-origin is a sane default (full URL same-origin, only origin cross-origin, nothing on downgrade).

Gotchas / edge cases

og:/Twitter tags in a CSR SPA don’t work — crawlers see the empty shell. SSR/prerender for shareable pages.
CSP via <meta> is limited — no frame-ancestors, no report-uri, and it can’t protect resources requested before the meta tag is parsed; use the header for real security.
SRI without crossorigin silently fails (the resource loads but integrity isn’t enforced, or it’s blocked) — always pair them.
Reused/predictable nonces defeat the purpose — generate per request, server-side.
theme-color ignored on some browsers/desktop — progressive enhancement, not guaranteed.
Duplicate/oversized og:image — platforms cache previews aggressively; changing the image may need a re-scrape.
Missing charset early can cause a re-parse or mojibake — put it first.

What a senior is expected to say

“charset first, viewport for mobile, theme-color for chrome. OG/Twitter cards must be server-rendered or crawlers see nothing — a real reason to SSR shareable pages.”
“JSON-LD over microdata for structured data — decoupled and Google-recommended.”
“CSP belongs in an HTTP header (meta can’t do frame-ancestors/reporting); nonce allowlists my inline scripts so injected ones are blocked.”
“SRI hashes pin third-party scripts and need crossorigin; referrer policy limits URL leakage to third parties.”

Cross-references

CSP, XSS, CORS in depth: ../17_security/
Why SSR matters for OG/SEO: ../19_rendering_modes/
Resource hints in <head> (preload/preconnect): ../15_performance/
Backend security headers: ../../backend/25_security/

<head>, Meta Tags, and Document Security