Almost nothing in a page's head is for the person reading the page. The title shows in a tab; everything else is addressed to software, and not to one piece of software but to several, each with its own rulebook. The browser reads the character encoding and the viewport. A search crawler reads the description, the robots rules and the canonical link. A social platform reads the properties when the page is shared, and X reads its own twitter:* names. A search engine's structured-data pipeline reads the JSON-LD blocks. None of these parties reads the others' lines, and each has a different idea of what counts as a mistake. The meta, Open Graph & JSON-LD inspector reads a head the way each of them does and quotes the sentence behind every finding; this article is the map of who reads what. Every source was read on 2026-10-05 and is quoted as it stands.

What the HTML Standard requires

The HTML Living Standard is the only rulebook here that can call something an error, and it is sparing with the word. On the title: "The title element represents the document's title or name. Authors should use titles that identify their documents even when they are used out of context, for example in a user's history or bookmarks, or in search results." Then the one hard rule: "There must be no more than one title element per document." A page with two titles is non-conforming; a page whose title is its first heading repeated is merely unhelpful, and the standard says why: "The document's title is often different from its first heading, since the first heading does not have to stand alone when taken out of context."

On the encoding, the standard is strict in three ways at once (4.2.5.4). The encoding must be : "The Encoding standard requires use of the UTF-8 character encoding and requires use of the "utf-8" encoding label to identify it." It must be declared: "If an HTML document does not start with a BOM, and its encoding is not explicitly given by Content-Type metadata, and the document is not an iframe srcdoc document, then the encoding must be specified using a meta element with a charset attribute or a meta element with an http-equiv attribute in the Encoding declaration state." And it must be declared early: "The element containing the character encoding declaration must be serialized completely within the first 1024 bytes of the document." The reason for the limit is the browser's prescan for the encoding, which the standard says to keep short: "User agents are encouraged to only prescan the first 1024 bytes." A meta charset after a kilobyte of comments and scripts can be declared too late to be seen. The inspector reports the byte at which the declaring element ends.

On the meta element itself: "Exactly one of the name, http-equiv, charset, and itemprop attributes must be specified. If either name, http-equiv, or itemprop is specified, then the content attribute must also be specified." A <meta content="..."> with nothing to say what it is, or a <meta name="keywords"> with no content, is an error. The Open Graph form, <meta property="og:title" content="...">, uses none of the four; it is conforming through a different document, HTML+RDFa 1.1, whose section 4 says RDFa's attributes "MUST be allowed and validate as conforming when used in an HTML4, HTML5 or XHTML5 document". That is why a validator accepts it and why the inspector lists property as a fifth kind rather than an error.

The standard defines eight metadata names (4.2.5.1): application-name, author, description, generator, keywords, referrer, theme-color and color-scheme, and says "Names are case-insensitive, and must be compared in an case-insensitive manner." Three of them come with a once-only rule; for description: "There must not be more than one meta element where the name attribute value is an ASCII case-insensitive match for description per document." Everything else, viewport included, is an extension: "Anyone can create and use their own extensions to the predefined set of metadata names. There is no requirement to register such extensions." The place to register them is the WHATWG wiki's MetaExtensions page, last edited on 12 October 2023, which is where viewport, robots, the site-verification names and the whole twitter:* family are described. The inspector classifies every name as standard, registered or unknown, and quotes the standard's or the registry's sentence for the ones it knows.

Then there are the pragma directives, http-equiv, which the standard describes with unusual candour (4.2.5.3): "Despite the name http-equiv, pragma directives are almost entirely unrelated to HTTP headers. Implementers and web developers are best off thinking of them as entirely separate, and the name as being a historical accident." Seven states are defined. content-type is "just an alternative form of setting the charset attribute". refresh "acts as a timed redirect". default-style sets the preferred stylesheet set. x-ua-compatible "encourages Internet Explorer to more closely follow the specifications" and its content "must have a value that is an ASCII case-insensitive match for the string "IE=edge"". content-security-policy "enforces a on a Document", with a placement rule that silently disarms it elsewhere: "If the meta element is not a child of a head element, return." And two are kept only to be condemned: content-language ("This feature is non-conforming. Authors are encouraged to use the lang attribute instead") and set-cookie ("This pragma is non-conforming and has no effect. User agents are required to ignore this pragma").

The canonical link and the alternates

<link rel="canonical"> is not the HTML Standard's invention; the standard lists canonical among its link types and points to 6596 (April 2012), which defines it in one sentence: "The canonical link relation specifies the preferred IRI from resources with duplicative content." The RFC says what a consumer may do with it, "Index content only from the target IRI", "Consolidate IRI properties, such as link popularity, to the target IRI", "Display the target IRI as the representative IRI", and what the target may be: it "MAY: Specify a relative IRI ... Be self-referential ... Exist on a different hostname or domain ... Have different scheme names". So a relative canonical is allowed, a self-referential one is normal, and a cross-host one is legitimate. What the RFC does not define is what happens when a page declares two; it speaks of "the preferred IRI", singular, and the inspector flags a second one as a warning because which of the two a consumer honours is anyone's guess.

hreflang alternates are plainer: rel="alternate" is an HTML link type, and the hreflang attribute names the language of the alternate document. Which pages should list which alternates, and whether an x-default is wanted, is the consumer's documentation, not the standard's; the inspector lists what is there and whether an x-default is among them, and stops.

Open Graph: a graph written in meta elements

The Open Graph protocol, published at ogp.me, turns a page into an object in a graph of shareable things. Its rules are few and quotable. "The four required properties for every page are: og:title ... og:type ... og:image ... og:url - The canonical URL of your object that will be used as its permanent ID in the graph". Optional properties include og:description ("A one to two sentence description of your object"), og:site_name, og:locale ("Of the format language_TERRITORY. Default is en_US") and og:locale:alternate. Some properties have structure: an og:image may be followed by og:image:url, og:image:secure_url, og:image:type, og:image:width, og:image:height and og:image:alt, and the protocol is pointed about the last one: "A description of what is in the image (not a caption). If the page specifies an og:image it should specify og:image:alt."

Two rules govern repetition and order. "If a tag can have multiple values, just put multiple versions of the same <meta> tag on your page. The first tag (from top to bottom) is given preference during conflicts." And: "Put structured properties after you declare their root tag." The second rule is where real pages go wrong: an og:image:width placed above its og:image attaches to nothing, and a consumer reading top to bottom sees a width for an image that does not exist yet. The inspector attaches each structured property to the nearest root above it and reports the orphans.

Types are the protocol's vocabulary: website, article, book, profile, the music and video types, payment.link, each with its own namespace of properties (article:published_time, book:isbn, profile:username, and so on), and the default when nothing is said: "Any non-marked up webpage should be treated as og:type website." A page without any Open Graph at all is not wrong; it is a website whose share card will be whatever the platform scrapes.

Cards, and a registry that outlived the documentation

The twitter:* names are an interesting case of where the rules live. They were proposed in the WHATWG MetaExtensions registry, which still describes them: twitter:card is "The card type, which will be one of "summary", "photo", "app", or "player"", twitter:description is "A description of the content in a maximum of 200 characters", twitter:image is "A URL to the image representing the content". X's own card markup reference, however, now redirects to a general documentation page (checked on 2026-10-05) and the markup documentation is not published there any more. So the only citable description of twitter:card in 2026 is a wiki entry last edited in 2023, which does not list summary_large_image, the type most pages use, nor twitter:image:alt. The inspector says exactly that: it reports summary_large_image as a type in common use that the registry does not list, and an unregistered name as unregistered, rather than inventing a rule.

Robots: rules read by the party that wrote them

<meta name="robots"> has no standard behind it; the MetaExtensions registry describes it as "A comma-separated list of operators explaining how search engine crawlers should treat the content", and the operators are each crawler's own. Google publishes its list (last updated 2026-03-24): all, noindex ("Do not show this page, media, or resource in search results"), nofollow, none ("Equivalent to noindex, nofollow"), nosnippet, indexifembedded, max-snippet, max-image-preview, max-video-preview, notranslate, noimageindex and unavailable_after, plus three that remain in many templates and do nothing: noarchive ("no longer used by Google Search to control whether a cached link is shown in search results, as the cached link feature no longer exists"), nocache and nositelinkssearchbox. Two details matter for reading a head. The name may be robots for every crawler or googlebot for Google alone, and when they disagree, "In the case of conflicting robots rules, the more restrictive rule applies." And placement is forgiven: "Google Search doesn't enforce placement of meta robots in the HTML head and will respect robots meta tags in the body section of an HTML document as well", which says nothing about any other consumer.

JSON-LD: the data block

Structured data for search engines is, in practice, schema.org vocabulary carried as JSON-LD. The schema.org project describes itself as "a collection of shared vocabularies webmasters can use to mark up their pages in ways that can be understood by the major search engines: Google, Microsoft, Yandex and Yahoo!", used "along with the Microdata, RDFa, or JSON-LD formats". JSON-LD 1.1 (W3C Recommendation, 16 July 2020) says how the carrying works, in section 7: "JSON-LD content can be easily embedded in HTML by placing it in a script element with the type attribute set to application/ld+json. Doing so creates a data block." Several blocks combine into one dataset. The type attribute is the whole contract: a script of type application/json that happens to contain @context is not a data block, and the inspector reports it as a look-alike.

Inside a block, four keywords carry the structure. @context maps the short names to IRIs; without it, "name" and "Organization" are just strings. @type: "A node type specifies the type of thing that is being described." @id identifies a node with an IRI and lets another node refer to it. @graph "collects such nodes in an array and allows the use of a shared context", which is how a page describes its organisation, its website, the page itself and a breadcrumb list in one block. One more rule comes from the fact that the block sits inside HTML: section 7.2 asks authors to "avoid using character sequences in scripts embedded in HTML which may be confused with a comment-open, script-open, comment-close, or script-close", because </script inside a JSON string ends the script element before the JSON does. The inspector parses each block with the ordinary JSON parser and reports the parser's own error message when it fails, which is more useful than "invalid": a trailing comma is named as a trailing comma.

What a head reader cannot know

A tool that reads a head without fetching anything knows what is declared, not what is true. It cannot say whether og:image exists or how large it is, whether the canonical target answers, whether a noindex is honoured, or how a particular platform will lay out a card. It can say that og:image is relative, which a consumer must resolve against a page URL the tool does not have, and that two canonical URLs disagree. The inspector keeps to that line, and where a rule belongs to another tool it says so: a Content Security Policy delivered in a meta element is reported with the standard's sentence and handed to the CSP evaluator, the parser's repairs to the markup are the HTML structure explainer's subject, and the HTTP headers that should accompany a head are the secure headers checker's.

Sources