Quase nada no head de uma página é para a pessoa que lê a página. O title aparece numa aba; todo o resto é endereçado a software, e não a um só software, mas a vários, cada um com o seu livro de regras. O navegador lê a codificação de caracteres e o viewport. Um rastreador de busca lê a description, as regras de robots e o link canonical. Uma plataforma social lê as propriedades quando a página é compartilhada, e o X lê os seus próprios nomes twitter:*. O pipeline de dados estruturados de um mecanismo de busca lê os blocos JSON-LD. Nenhuma dessas partes lê as linhas das outras, e cada uma tem uma ideia diferente do que conta como erro. O inspetor de meta, Open Graph e JSON-LD lê um head do modo como cada uma delas lê e cita a frase por trás de cada achado; este artigo é o mapa de quem lê o quê. Cada fonte foi lida em 2026-10-05 e é citada como está.

O que o HTML Standard exige

O HTML Living Standard é o único livro de regras aqui que pode chamar algo de erro, e é parcimonioso com a palavra. Sobre o 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." Depois, a única regra dura: "There must be no more than one title element per document." Uma página com dois titles é não conforme; uma página cujo title é o primeiro título repetido é apenas pouco útil, e o padrão diz por quê: "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."

Sobre a codificação, o padrão é estrito de três modos ao mesmo tempo (4.2.5.4). A codificação deve ser : "The Encoding standard requires use of the UTF-8 character encoding and requires use of the "utf-8" encoding label to identify it." Deve ser declarada: "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." E deve ser declarada cedo: "The element containing the character encoding declaration must be serialized completely within the first 1024 bytes of the document." A razão do limite é a pré-varredura do navegador em busca da codificação, que o padrão manda manter curta: "User agents are encouraged to only prescan the first 1024 bytes." Um meta charset depois de um quilobyte de comentários e scripts pode ser declarado tarde demais para ser visto. O inspetor reporta o byte em que o elemento declarante termina.

Sobre o elemento meta em si: "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." Um <meta content="..."> sem nada que diga o que ele é, ou um <meta name="keywords"> sem content, é um erro. A forma do Open Graph, <meta property="og:title" content="...">, não usa nenhum dos quatro; ela é conforme por meio de outro documento, o HTML+RDFa 1.1, cuja seção 4 diz que os atributos do RDFa "MUST be allowed and validate as conforming when used in an HTML4, HTML5 or XHTML5 document". É por isso que um validador a aceita e que o inspetor lista property como um quinto tipo e não como erro.

O padrão define oito nomes de metadados (4.2.5.1): application-name, author, description, generator, keywords, referrer, theme-color e color-scheme, e diz "Names are case-insensitive, and must be compared in an case-insensitive manner." Três deles vêm com uma regra de uso único; para 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." Todo o resto, viewport incluído, é extensão: "Anyone can create and use their own extensions to the predefined set of metadata names. There is no requirement to register such extensions." O lugar para registrá-las é a página MetaExtensions da wiki do WHATWG, editada pela última vez em 12 de outubro de 2023, que é onde viewport, robots, os nomes de verificação de site e toda a família twitter:* estão descritos. O inspetor classifica cada nome como padrão, registrado ou desconhecido, e cita a frase do padrão ou do registro para os que conhece.

Há ainda as diretivas pragma, http-equiv, que o padrão descreve com franqueza incomum (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." Sete estados são definidos. content-type é "just an alternative form of setting the charset attribute". refresh "acts as a timed redirect". default-style define o conjunto de folhas de estilo preferido. x-ua-compatible "encourages Internet Explorer to more closely follow the specifications" e o seu 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", com uma regra de posição que a desarma em silêncio em qualquer outro lugar: "If the meta element is not a child of a head element, return." E duas são mantidas só para serem condenadas: content-language ("This feature is non-conforming. Authors are encouraged to use the lang attribute instead") e set-cookie ("This pragma is non-conforming and has no effect. User agents are required to ignore this pragma").

O link canonical e os alternates

<link rel="canonical"> não é invenção do HTML Standard; o padrão lista canonical entre os seus tipos de link e aponta para a 6596 (abril de 2012), que o define numa frase: "The canonical link relation specifies the preferred IRI from resources with duplicative content." A RFC diz o que um consumidor pode fazer com ele, "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", e o que o alvo pode ser: ele "MAY: Specify a relative IRI ... Be self-referential ... Exist on a different hostname or domain ... Have different scheme names". Então um canonical relativo é permitido, um autorreferente é normal, e um em outro host é legítimo. O que a RFC não define é o que acontece quando uma página declara dois; ela fala de "the preferred IRI", no singular, e o inspetor sinaliza um segundo como aviso porque qual dos dois um consumidor honra é um chute.

Os alternates hreflang são mais simples: rel="alternate" é um tipo de link do HTML, e o atributo hreflang nomeia a língua do documento alternativo. Quais páginas devem listar quais alternates, e se um x-default é desejado, é documentação do consumidor, não do padrão; o inspetor lista o que há e se um x-default está entre eles, e para por aí.

Open Graph: um grafo escrito em elementos meta

O protocolo Open Graph, publicado em ogp.me, transforma uma página num objeto de um grafo de coisas compartilháveis. As suas regras são poucas e citáveis. "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". As propriedades opcionais incluem 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") e og:locale:alternate. Algumas propriedades têm estrutura: um og:image pode ser seguido de og:image:url, og:image:secure_url, og:image:type, og:image:width, og:image:height e og:image:alt, e o protocolo é direto quanto ao último: "A description of what is in the image (not a caption). If the page specifies an og:image it should specify og:image:alt."

Duas regras governam repetição e ordem. "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." E: "Put structured properties after you declare their root tag." A segunda regra é onde páginas reais erram: um og:image:width colocado acima do seu og:image não se liga a nada, e um consumidor lendo de cima para baixo vê uma largura para uma imagem que ainda não existe. O inspetor liga cada propriedade estruturada à raiz mais próxima acima dela e reporta as órfãs.

Os tipos são o vocabulário do protocolo: website, article, book, profile, os tipos music e video, payment.link, cada um com o seu próprio namespace de propriedades (article:published_time, book:isbn, profile:username, e assim por diante), e o padrão quando nada é dito: "Any non-marked up webpage should be treated as og:type website." Uma página sem Open Graph algum não está errada; é um website cujo card de compartilhamento será o que a plataforma raspar.

Cards, e um registro que sobreviveu à documentação

Os nomes twitter:* são um caso interessante de onde as regras moram. Eles foram propostos no registro MetaExtensions do WHATWG, que ainda os descreve: twitter:card é "The card type, which will be one of "summary", "photo", "app", or "player"", twitter:description é "A description of the content in a maximum of 200 characters", twitter:image é "A URL to the image representing the content". A referência de marcação de cards do próprio X, porém, agora redireciona para uma página geral de documentação (verificado em 2026-10-05) e a documentação de marcação não está mais publicada ali. Então a única descrição citável de twitter:card em 2026 é um verbete de wiki editado pela última vez em 2023, que não lista summary_large_image, o tipo que a maioria das páginas usa, nem twitter:image:alt. O inspetor diz exatamente isso: reporta summary_large_image como um tipo de uso comum que o registro não lista, e um nome não registrado como não registrado, em vez de inventar uma regra.

Robots: regras lidas pela parte que as escreveu

<meta name="robots"> não tem padrão por trás; o registro MetaExtensions o descreve como "A comma-separated list of operators explaining how search engine crawlers should treat the content", e os operadores são de cada rastreador. O Google publica a sua lista (última atualização em 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 e unavailable_after, mais três que permanecem em muitos templates e não fazem nada: 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 e nositelinkssearchbox. Dois detalhes importam para ler um head. O nome pode ser robots para todo rastreador ou googlebot só para o Google, e quando discordam, "In the case of conflicting robots rules, the more restrictive rule applies." E a posição é perdoada: "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", o que nada diz sobre qualquer outro consumidor.

JSON-LD: o bloco de dados

Dados estruturados para mecanismos de busca são, na prática, vocabulário do schema.org carregado como JSON-LD. O projeto schema.org se descreve como "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!", usado "along with the Microdata, RDFa, or JSON-LD formats". O JSON-LD 1.1 (Recomendação do W3C, 16 de julho de 2020) diz como o transporte funciona, na seção 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." Vários blocos se combinam num só conjunto de dados. O atributo type é o contrato inteiro: um script de type application/json que por acaso contenha @context não é um bloco de dados, e o inspetor o reporta como parecido.

Dentro de um bloco, quatro palavras-chave carregam a estrutura. @context mapeia os nomes curtos para IRIs; sem ele, "name" e "Organization" são só strings. @type: "A node type specifies the type of thing that is being described." @id identifica um nó com um IRI e deixa outro nó referir-se a ele. @graph "collects such nodes in an array and allows the use of a shared context", que é como uma página descreve a sua organização, o seu site, a própria página e uma lista de breadcrumbs num só bloco. Mais uma regra vem do fato de o bloco estar dentro de HTML: a seção 7.2 pede aos autores que "avoid using character sequences in scripts embedded in HTML which may be confused with a comment-open, script-open, comment-close, or script-close", porque </script dentro de uma string JSON encerra o elemento script antes que o JSON acabe. O inspetor analisa cada bloco com o parser JSON comum e reporta a mensagem de erro do próprio parser quando ele falha, o que é mais útil do que "inválido": uma vírgula sobrando é nomeada como vírgula sobrando.

O que um leitor de head não pode saber

Uma ferramenta que lê um head sem buscar nada sabe o que está declarado, não o que é verdade. Não pode dizer se og:image existe ou qual o seu tamanho, se o alvo canonical responde, se um noindex é honrado, ou como uma plataforma em particular vai montar um card. Pode dizer que og:image é relativo, o que um consumidor precisa resolver contra uma URL de página que a ferramenta não tem, e que duas URLs canônicas discordam. O inspetor fica nessa linha, e onde uma regra pertence a outra ferramenta ele diz: uma Content Security Policy entregue num elemento meta é reportada com a frase do padrão e encaminhada ao avaliador de CSP, os reparos do parser à marcação são assunto do explicador de estrutura HTML, e os cabeçalhos HTTP que deveriam acompanhar um head são do verificador de cabeçalhos de segurança.

Fontes