A Tag Meta Charset
O que <meta charset="utf-8"> faz, por que a especificação HTML exige que ela esteja nos primeiros 1024 bytes, como uma codificação errada causa mojibake, e por que é uma questão de renderização correta e não um fator de ranqueamento.
Idiomas
1 sinal de evidência nesta página
- Ferramenta relacionada ativaHTTP Header Checker
A tag meta charset — <meta charset="utf-8"> — declara a codificação de caracteres da sua página para que navegadores e rastreadores convertam bytes brutos nos caracteres corretos. A especificação HTML exige que ela esteja nos primeiros 1024 bytes do documento, e a melhor prática é que seja o primeiro filho literal de <head>. Se você errar (ausente, tardia ou com codificação incompatível), você terá mojibake: letras acentuadas, aspas curvas, travessões, scripts não latinos e emojis renderizados como lixo — o que pode corromper o que é exibido e indexado. NÃO é um fator de ranqueamento direto; a única orientação do Google é 'use Unicode/UTF-8 quando possível'. UTF-8 é a codificação quase universal e exigida pela especificação para HTML5 hoje. Um cabeçalho Content-Type enviado pelo servidor com charset substitui a tag na página, o que é uma fonte comum de bugs de migração. Esta é uma das tags voltadas para o navegador no cluster de meta tags.
TL;DR — A tag
Evidence for this claim For HTML documents, the charset declaration must identify UTF-8. Scope: Modern HTML conformance requirements. Confidence: high · Verified: WHATWG HTML: Character encoding declaration Evidence for this claim The complete character-encoding declaration must occur within the first 1024 bytes of the document. Scope: HTML serialization requirement intended to make encoding available early to parsers. Confidence: high · Verified: WHATWG HTML: Specifying the document's character encoding<meta charset="utf-8">é uma linha de HTML que diz ao navegador como ler o texto da sua página. Se você errar ou omitir, caracteres especiais (acentos, aspas curvas, emojis) podem virar uma bagunça ilegível. Isso não ajuda você a ranquear, mas texto com aparência quebrada é ruim para todos, inclusive para o Google. Coloque-a primeiro no seu<head>e useutf-8. Pronto.
O que a tag faz
Toda página web é armazenada como bytes brutos. Esses bytes só se tornam as letras que você lê quando algo decide qual caractere cada byte (ou grupo de bytes) representa. A tag meta charset é como sua página diz ao navegador — e aos rastreadores de mecanismos de busca — qual sistema usar:
<meta charset="utf-8">utf-8 é a codificação que você quer em quase todos os casos. Ela pode representar
praticamente todos os caracteres e escritas em uso hoje, além de emojis, tudo em um
único sistema.
O que dá errado sem ela
Se você não declarar uma codificação, o navegador tem que adivinhar. Quando ele
erra, você tem mojibake — texto embaralhado onde um apóstrofo curvo vira algo
como ’, ou café aparece como café. Letras acentuadas, travessões, aspas
“inteligentes”, escritas não latinas (árabe, cirílico, chinês, japonês) e emojis
são as vítimas comuns. Inglês simples sem acentos pode parecer normal mesmo com a
codificação errada, que é exatamente por que o bug passa despercebido.
Onde colocar
Duas regras simples:
- Coloque
<meta charset="utf-8">primeiro dentro do seu<head>, antes do título ou de qualquer outra coisa. - Use
utf-8, não alguma codificação mais antiga.
É só isso. A maioria dos modelos de site e CMSs já faz isso por você — se o seu não faz, adicione.
Isso afeta o SEO?
Não diretamente. A tag charset não é um fator de ranqueamento. Mas se uma codificação errada embaralhar seu texto, esse conteúdo quebrado é o que os usuários veem e o que o Google pode acabar indexando e mostrando — então vale a pena acertar mesmo que isso não mova você para cima nos resultados por si só.
Quer os detalhes da especificação — a regra dos “primeiros 1024 bytes”, por que a sintaxe antiga ainda persiste e como um cabeçalho do servidor pode silenciosamente substituir sua tag? Mude para a aba Avançado.
Verifique a codificação declarada pela linha de comando
Substitua a URL e compare o cabeçalho da resposta com a tag perto do início do
HTML. Um charset no cabeçalho HTTP Content-Type tem precedência sobre a
declaração no documento.
url="https://example.com/"
curl -sSI "$url" | grep -i '^content-type:'
curl -sS "$url" | head -c 1024 | grep -oiE '<meta[^>]+charset[^>]*>'No console do navegador, isso relata a codificação analisada, a tag declarada e se
essa tag é o primeiro elemento no <head>:
const charset = document.querySelector('meta[charset]');
console.table({
documentCharacterSet: document.characterSet,
declaredCharset: charset?.getAttribute('charset') ?? 'missing',
firstHeadElement: document.head.firstElementChild?.outerHTML ?? 'missing',
charsetIsFirst: document.head.firstElementChild === charset,
});O console reflete o documento analisado pelo navegador. Use também a verificação
com curl quando precisar provar o que o servidor realmente enviou.
Inspecione a resposta antes de depurar a marcação
Use o Verificador de Cabeçalho HTTP para inspecionar
o cabeçalho de resposta Content-Type ao vivo. Se ele declarar um charset, compare
esse valor com <meta charset="utf-8">; um conflito pode explicar mojibake mesmo
quando a tag HTML parece correta.
Para a colocação, use Ver Código-fonte em vez de apenas o painel Elementos.
Confirme que a declaração de charset é o primeiro filho do <head> e aparece
nos primeiros 1 024 bytes do documento.
Valide uma correção de charset
Teste 1 — Cabeçalho e tag concordam
- Hipótese: A resposta ao vivo e o HTML declaram UTF-8.
- Método: Verifique o cabeçalho
Content-Typeda resposta e inspecione o código-fonte para<meta charset="utf-8">. - Condição de aprovação: Não existe charset conflitante declarado pelo servidor.
- Condição de falha: O cabeçalho declara outra codificação ou a tag está ausente.
- Próxima ação: Corrija o cabeçalho do servidor primeiro e depois teste novamente a resposta ao vivo.
Teste 2 — A declaração é cedo o suficiente
- Hipótese: O navegador vê a tag antes de precisar adivinhar uma codificação.
- Método: Buscar os primeiros 1 024 bytes e inspecionar o início de
<head>. - Condição de aprovação: A tag charset completa está dentro desses bytes e é o
primeiro elemento em
<head>. - Condição de falha: Comentários, scripts injetados ou outra marcação a empurram para depois.
- Próxima ação: Mover a tag para antes de toda marcação não essencial do head.
Teste 3 — Caracteres reais são renderizados corretamente
- Hipótese: A correção elimina mojibake em texto visível ao usuário e indexável.
- Método: Verificar um caractere acentuado, aspas curvas, travessão, texto não latino e emoji na página ao vivo e no View Source.
- Condição de aprovação: Cada caractere é renderizado como foi escrito após uma atualização forçada.
- Condição de falha: Glifos de substituição ou sequências de bytes corrompidas permanecem.
- Próxima ação: Reverter a mudança de codificação se ela introduziu corrupção e, em seguida, rastrear o arquivo de origem, o modelo, o banco de dados e o cabeçalho de resposta separadamente.
TL;DR —
Evidence for this claim For HTML documents, the charset declaration must identify UTF-8. Scope: Modern HTML conformance requirements. Confidence: high · Verified: WHATWG HTML: Character encoding declaration Evidence for this claim The complete character-encoding declaration must occur within the first 1024 bytes of the document. Scope: HTML serialization requirement intended to make encoding available early to parsers. Confidence: high · Verified: WHATWG HTML: Specifying the document's character encoding<meta charset="utf-8">declara a codificação de caracteres do documento. A especificação HTML do WHATWG exige que a declaração seja serializada completamente dentro dos primeiros 1024 bytes do documento, e para HTML5 o valor deve corresponder autf-8; a melhor prática é colocá-la como o primeiro filho literal de<head>. Uma codificação ausente, tardia ou incompatível produz mojibake — caracteres acentuados corrompidos, aspas curvas, scripts não latinos e emoji — o que é um problema de renderização e correção de indexação, não um sinal de ranqueamento. A única declaração pública do Google é “use Unicode/UTF-8 quando possível.” Um cabeçalhoContent-Typeenviado pelo servidor com charset sobrepõe a tag no documento, o que é um bug clássico de mojibake pós-migração. Apenas um elemento meta charset é permitido por documento, e ele não tem efeito em XML. Uma marca de ordem de byte (BOM) UTF-8, se presente, vence tudo; caso contrário, o cabeçalho HTTP vence a tag na página — ordem de precedência completa abaixo.
O que é a tag
A declaração de charset informa ao parser qual codificação de caracteres usar ao converter
os bytes do documento em texto. O WHATWG HTML Living Standard diz claramente: “The
charset attribute specifies the character encoding used by the document. This is a
character encoding declaration.” (tradução) «O atributo charset determina a codificação de caracteres empregada pelo documento; esta é a declaração dessa codificação.» A abordagem da MDN é a versão prática: “This
attribute declares the document’s character encoding.” (tradução) «Esse atributo declara qual codificação de caracteres o documento utiliza.»
A sintaxe moderna é a forma curta:
<meta charset="utf-8">Há também uma forma legada pré-HTML5 que você ainda verá em modelos mais antigos:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">Ambas declaram a mesma coisa. Em um documento HTML5 moderno, você só precisa da forma curta
<meta charset="utf-8"> — usar ambas é redundante, não prejudicial, e a especificação permite
apenas um elemento meta que declara charset por documento. (A forma http-equiv é melhor
considerada legada do que algo a adicionar do zero; se você estiver auditando uma página
que a tenha, ela não está quebrada, apenas antiga.)
Os requisitos da especificação que você realmente precisa saber
UTF-8 é efetivamente obrigatório para HTML5. A MDN afirma diretamente: o
“value must be an ASCII case-insensitive match for the string utf-8, because UTF-8
is the only valid encoding for HTML5 documents.” (tradução) «valor deve ser uma correspondência ASCII sem diferenciar maiúsculas de minúsculas para a string utf-8, porque UTF-8 é a única codificação válida para documentos HTML5.» A especificação WHATWG vai além e exige
que a codificação real do documento seja UTF-8, independentemente do que é declarado.
UTF-8 cobre praticamente todos os scripts além de emoji, por isso a era de codificações por região
ISO-8859-1 / Windows-1252 / Shift-JIS acabou para novos trabalhos — elas
sobrevivem apenas como casos de compatibilidade legada.
Ele deve estar nos primeiros 1024 bytes do documento. Este é um requisito
rígido da especificação, não uma sugestão branda. MDN: “<meta> elements which declare a character
encoding must be located entirely within the first 1024 bytes of the document.”
(tradução) «Elementos <meta> que declaram uma codificação de caracteres devem estar localizados inteiramente dentro dos primeiros 1024 bytes do documento.» A
razão é mecânica — o parser fareja o fluxo de bytes em busca de uma codificação antes de
poder interpretar o restante com segurança. Se a sua declaração aparecer tarde demais, o parser pode
já ter se comprometido com uma codificação adivinhada (ou ter que reiniciar, o que custa
performance). Observe o enquadramento com cuidado: são os primeiros 1024 bytes do documento
inteiro, não apenas do <head>.
A melhor prática supera o mínimo da especificação: torne-o o primeiro filho de <head>. Não se
contente com “em algum lugar nos primeiros 1024 bytes” — coloque <meta charset="utf-8"> antes
do seu <title>, <link>, <script>, <style> e de todas as outras tags. Este é o
posicionamento que as ferramentas modernas verificam. Há uma
issue aberta no Lighthouse (#10023)
propondo uma auditoria que verifica especificamente se <meta charset> é igual a
document.head.firstElementChild — ou seja, sinalizando a tag quando ela não é o literal
primeiro elemento no head, não apenas quando está ausente. A direção das ferramentas é no sentido de
verificar o posicionamento, não apenas a presença.
Apenas um elemento meta charset por documento, e o atributo charset não tem
efeito em documentos XML/XHTML (é permitido lá apenas para facilitar a migração de e
para XML). Vale uma ressalva se você estiver trabalhando com conteúdo servido como XHTML ou
modelos adjacentes a RSS/Atom.
BOM, cabeçalho HTTP, meta tag — a ordem de precedência
Os navegadores não leem apenas a meta tag isoladamente; o algoritmo de detecção de codificação verifica três fontes em uma ordem fixa, e a primeira que fornecer uma resposta vence:
- Uma marca de ordem de byte UTF-8 (BOM) — alguns bytes bem no início do arquivo. Se o navegador detectar uma BOM, isso determina a codificação com certeza; nada mais é consultado.
- O charset do cabeçalho HTTP
Content-Type, se o servidor enviar um e não houver BOM. Isso tem precedência sobre a declaração meta no documento. - A declaração
<meta charset>(ouhttp-equivlegada) no documento, verificada somente se nenhuma das opções acima forneceu uma codificação.
Na prática, BOMs são raras em HTML escrito à mão (são mais comuns como um artefato
de certos editores de texto ou ferramentas de exportação de arquivos), então o conflito entre cabeçalho e tag é o que
mais afeta: uma página que declara corretamente <meta charset="utf-8">
ainda pode renderizar com caracteres corrompidos se um CDN, proxy reverso ou servidor mal configurado enviar um
charset diferente no cabeçalho. É um sintoma clássico logo após uma migração de servidor ou CDN
— o HTML não mudou, mas o cabeçalho mudou, e agora o cabeçalho está
lutando contra a tag. Ao depurar mojibake, verifique a BOM e o charset do cabeçalho
de resposta, não apenas o código-fonte da página.
Meta charset é um fator de ranqueamento para SEO?
Não — e vale ser direto porque o texto de ferramentas de auditoria baseado em medo às vezes sugere o contrário. Este é um pré-requisito de correção de renderização e indexação, não um sinal de ranqueamento.
A orientação do Google aqui é escassa e indireta em comparação com as tags que ele discute constantemente (title, meta description, robots e canonical). Não há uma página dedicada do Google Search Central sobre codificação de caracteres — o tema aparece na referência geral de meta tags compatíveis, na seção sobre Content-Type e charset. A única declaração registrada do Google é uma recomendação, não uma afirmação de ranqueamento: “We recommend using Unicode/UTF-8 where possible.” (tradução) «O Google recomenda usar Unicode/UTF-8 sempre que possível.» Nenhuma declaração literal de Mueller, Illyes, Splitt ou Canel que mencione especificamente meta charset ou mojibake aparece na imprensa especializada ou nos arquivos do Search Off the Record — charset é tratado como higiene básica dos padrões da web, assim como marcação válida, e não como um tópico que exija comentários específicos sobre SEO.
O Bing também não tem uma posição pública distinta sobre a tag on-page; sua documentação referencia UTF-8 apenas para seus próprios formatos de API/feed (arquivos de chave do IndexNow, cabeçalhos de solicitação da Webmaster API), não como orientação sobre o <meta charset> HTML em suas páginas. Como o Bingbot é um parser HTML padrão, a implicação prática é a mesma: siga a regra de UTF-8 / 1024 bytes da especificação HTML.
Então, onde pode te prejudicar? Indiretamente, e somente quando a codificação está genuinamente quebrada: texto ilegível é um problema de qualidade de conteúdo e UX, pode corromper o que aparece nos snippets, e saída severamente quebrada pode parecer quebrada para os sistemas de indexação do Google também. O consenso da indústria, como o próprio guia de meta tags da Ahrefs (por Joshua Hardwick) coloca, é que “a menos que sua página esteja severamente quebrada como resultado de problemas de charset (o que é improvável), o impacto será bastante mínimo.” Corrija porque texto quebrado é ruim, não porque você espera um aumento de ranqueamento.
Como verificar e corrigir
Um caminho de diagnóstico rápido quando você suspeita de um problema de codificação:
- Ver código-fonte / DevTools. Confirme que
<meta charset="utf-8">existe e é o primeiro filho de<head>. No DevTools, verifique o cabeçalho de respostaContent-Typepara um valor de charset — se ele discordar da tag, o cabeçalho vence e é o provável culpado. Descarte também um BOM: é mais raro, mas se presente, ele supera tanto o cabeçalho quanto a tag. - Validadores e rastreadores sinalizam. O validador W3C e verificadores baseados em regras (por exemplo, a regra “charset após os primeiros 1024 bytes” do Rocket Validator) apontarão uma declaração tardia ou ausente. Auditorias de site no Ahrefs Site Audit e no Screaming Frog revelam problemas de charset em todo um site.
- Corrija a camada certa. Se a colocação estiver errada, mova a tag para o topo do head. Se a codificação estiver errada (os bytes em si não são UTF-8, ou o cabeçalho envia um charset conflitante), corrigir apenas a meta tag não ajudará — você precisa recodificar o arquivo como UTF-8 e/ou corrigir o cabeçalho
Content-Typedo servidor para que o cabeçalho e a tag concordem.
A correção é quase sempre trivial depois que você identifica qual camada está com defeito. Esta é uma parte estável e há muito estabelecida da especificação HTML — não há depreciação recente ou mudança de comportamento de plataforma para acompanhar; a única nuance em evolução é que as ferramentas verificam cada vez mais a colocação, não apenas a presença.
Onde isso se encaixa
A tag charset é um dos elementos de head voltados para o navegador — como a tag viewport, é sobre renderização, não ranqueamento, o que a coloca em um balde diferente das tags ativas para SEO no cluster de meta tags (o elemento title, a meta description e a família robots). É adjacente ao trabalho de internacionalização no qual passo muito tempo: a codificação é a camada por baixo de hreflang e conteúdo multi-script — hreflang diz ao Google qual versão de idioma/região servir, mas se a codificação estiver errada, o texto nessa versão fica ilegível independentemente. Para o mapa completo dos elementos de head agrupados pelo trabalho que fazem, veja o hub de meta tags.
Resumo de IA
Uma visão condensada da versão Avançada:
- O que é:
<meta charset="utf-8">declara a codificação de caracteres do documento para que navegadores e rastreadores mapeiem bytes brutos para os caracteres corretos. - Regras da especificação: a declaração deve estar dentro dos primeiros 1024 bytes do documento
inteiro; o HTML5 exige que o valor seja
utf-8(e que a codificação real seja UTF-8). Melhor prática: o literal primeiro filho de<head>. Apenas um elemento meta de charset por documento; não tem efeito em XML/XHTML. - Sintaxe legada:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">é a forma mais antiga, pré-HTML5 — redundante em páginas modernas; use a forma curta. Você não precisa de ambas. - Ordem de precedência: um BOM UTF-8, se presente, vence tudo; caso contrário, um
Content-Typeenviado pelo servidor sobrepõe a tag na página — um clássico bug de mojibake pós-migração. Depure o cabeçalho (e verifique se há BOM), não apenas o código-fonte. - Por que importa: uma codificação ausente/tardia/incompatível causa mojibake (acentos distorcidos, aspas curvas, scripts não latinos, emoji) — um problema de renderização/correção de indexação, não um fator de ranqueamento.
- O que o Google diz: apenas uma linha indireta — “We recommend using Unicode/UTF-8 where possible.” (tradução) «Recomendamos usar Unicode/UTF-8 quando possível.» Nenhum documento dedicado, nenhuma citação de representante sobre charset/mojibake. O Bing não tem uma posição distinta na página. Enquadramento do setor (Ahrefs): o impacto é mínimo, a menos que a página esteja “gravemente quebrada.”
- Diagnóstico: view-source/DevTools para a tag e o charset do cabeçalho de resposta; validadores (W3C, Rocket Validator) e auditorias de site (Ahrefs, Screaming Frog) sinalizam declarações tardias ou ausentes. Corrija a camada certa — posicionamento vs. codificação/cabeçalho reais.
Documentação oficial
Documentação de fonte primária e especificação.
Padrões (WHATWG / MDN)
- HTML Standard (WHATWG) — Especificando a codificação de caracteres do documento — as regras normativas: a declaração de charset, o requisito dos primeiros 1024 bytes, UTF-8, o limite de um por documento e a exceção XML.
- HTML Standard (WHATWG) — Determinando a codificação de caracteres — o algoritmo de detecção de codificação: detecção de BOM primeiro, depois o
Content-Typeno nível HTTP, depois a declaração meta no documento. - MDN —
<meta>: o elemento de metadados — referência em linguagem simples: somenteutf-8para HTML5, a regra de 1024 bytes e a forma legadahttp-equiv.
- Meta tags e atributos HTML compatíveis com o Google — a única orientação do Google sobre charset, na seção sobre Content-Type e charset: as formas aceitas de
http-equivecharsete a recomendação “use Unicode/UTF-8 where possible” (tradução) «O Google recomenda usar Unicode/UTF-8 quando possível.»
Bing / Microsoft
- IndexNow — primeiros passos — o Bing referencia UTF-8 apenas para seus próprios formatos de API/arquivo de chave, não como orientação HTML na página. Não há um documento dedicado do Bing sobre a tag
<meta charset>.
Ferramentas
- Lighthouse issue #10023 — avisar sobre
<meta charset>tardio ou ausente — a auditoria proposta que verifica se a tag de charset édocument.head.firstElementChild.
Citações da fonte
Declarações oficiais da especificação HTML, MDN e Google. Cada link é um link profundo que salta para a passagem citada quando a fonte suporta isso.
WHATWG HTML Standard — o que é a tag
- “The
charsetattribute specifies the character encoding used by the document. This is a character encoding declaration.” (tradução) «O atributocharsetespecifica a codificação de caracteres usada pelo documento. Esta é uma declaração de codificação de caracteres.» — HTML Living Standard (WHATWG). Fonte
MDN — as regras de codificação e posicionamento
- “This attribute declares the document’s character encoding. If the attribute is present, its value must be an ASCII case-insensitive match for the string
utf-8, because UTF-8 is the only valid encoding for HTML5 documents.<meta>elements which declare a character encoding must be located entirely within the first 1024 bytes of the document.” (tradução) «Este atributo declara a codificação de caracteres do documento. Se o atributo estiver presente, seu valor deve ser uma correspondência ASCII sem diferenciar maiúsculas de minúsculas para a stringutf-8, porque UTF-8 é a única codificação válida para documentos HTML5. Elementos<meta>que declaram uma codificação de caracteres devem estar localizados inteiramente dentro dos primeiros 1024 bytes do documento.» — MDN Web Docs, “<meta>: o elemento de metadados.” Ir para a citação
Google — a posição oficial (tênue)
- “These tags define the page’s content type and character set respectively. Make sure that you surround the value of the
contentattribute in thehttp-equivmetatag with quotes—otherwise thecharsetattribute may be interpreted incorrectly. We recommend using Unicode/UTF-8 where possible.” (tradução) «Essas tags definem o tipo de conteúdo e o conjunto de caracteres da página, respectivamente. Certifique-se de envolver o valor do atributocontentna tagmetahttp-equivcom aspas — caso contrário, o atributocharsetpode ser interpretado incorretamente. Recomendamos usar Unicode/UTF-8 quando possível.» — Google Search Central, “Meta tags and attributes that Google supports.” (tradução) «Título em português: “Meta tags e atributos compatíveis com o Google”.» Ir para a citação
Indústria — o enquadramento honesto do impacto em SEO
- “Unless your page is severely broken as a result of charset issues (which is unlikely), the impact is going to be quite minimal.” (tradução) «A menos que sua página esteja severamente quebrada como resultado de problemas de charset (o que é improvável), o impacto será bastante mínimo.» — Blog da Ahrefs, “Meta Tags para SEO: Um Guia Simples para Iniciantes” (Joshua Hardwick). Fonte
Auditoria de meta charset — lista de verificação
Uma passagem rápida para confirmar que suas páginas declaram e renderizam a codificação corretamente:
- Cada página tem
<meta charset="utf-8">no<head>. - A tag charset é o primeiro filho de
<head>— antes de<title>,<link>,<script>,<style>e qualquer outro<meta>. - A declaração está dentro dos primeiros 1024 bytes do documento (estará se for o primeiro filho do head).
- O valor é
utf-8— não ISO-8859-1, Windows-1252 ou uma página de código por região. - O arquivo em si está realmente salvo/servido como UTF-8 (a declaração e a codificação real de bytes devem concordar).
- Apenas um elemento meta charset por página.
- O cabeçalho de resposta
Content-Typedo servidor concorda com a tag (o cabeçalho vence a tag se houver conflito) — verifique no DevTools, especialmente após qualquer migração de CDN ou servidor. - Sem marca de ordem de byte (BOM) UTF-8 perdida no início do arquivo — raro, mas se presente, ela supera tanto o cabeçalho quanto a tag.
- Verifique por amostragem páginas com conteúdo não ASCII (acentos, aspas curvas, scripts não latinos, emoji) — inglês simples pode parecer correto mesmo quando a codificação está quebrada.
- Execute a página no validador W3C / em um rastreador (Ahrefs Site Audit, Screaming Frog) para detectar declarações tardias ou ausentes em escala.
- Não adicione a forma legada
http-equiv="Content-Type"em trabalho novo — o<meta charset="utf-8">curto é suficiente.
Folha de referência de meta charset
As duas sintaxes
| Forma | Sintaxe | Usar? |
|---|---|---|
| Moderna (HTML5) | <meta charset="utf-8"> | Sim — é isso que você quer |
| Legada (pré-HTML5) | <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> | Não para trabalho novo; redundante, apenas uma é necessária |
As regras que importam
| Regra | Detalhe |
|---|---|
| Valor | Deve ser utf-8 para HTML5 (a especificação exige que a codificação real também seja UTF-8) |
| Posicionamento (mínimo da especificação) | Dentro dos primeiros 1024 bytes do documento |
| Posicionamento (melhor prática) | O primeiro filho literal de <head> |
| Quantidade | Um elemento meta charset por documento — nada além disso |
| XML/XHTML | O atributo charset não tem efeito em documentos XML |
| Precedência | Um BOM UTF-8 vence tudo; caso contrário, um cabeçalho Content-Type do servidor com charset substitui a tag na página |
Fatos rápidos
- Codificação errada/ausente/tardia → mojibake (acentos embaralhados, aspas curvas, scripts não latinos, emojis). Texto ASCII simples em inglês ainda pode parecer correto — o bug fica oculto.
- Não é um fator de ranqueamento. A única orientação do Google: “use Unicode/UTF-8 where possible.” (tradução) «use Unicode/UTF-8 quando possível.»
- O impacto é mínimo, a menos que a página esteja gravemente quebrada (Ahrefs) — mas texto quebrado ainda vale a pena corrigir para usuários e indexação.
- Depurando mojibake? Verifique um BOM primeiro, depois o charset do cabeçalho de resposta, não apenas o código-fonte — o BOM vence o cabeçalho, e o cabeçalho vence a tag.
- As ferramentas estão caminhando para verificar o posicionamento (primeiro filho do head), não apenas a presença (veja Lighthouse #10023).
Teste-se: A Tag Meta Charset
Cinco perguntas rápidas sobre codificação de caracteres e a tag charset. Escolha uma resposta para cada, depois confira.
Registro de alterações
Atualizado em 13 de ago. de 2026.
Resumo editorial e detalhes registrados da alteração.Detalhes da alteração
-
As notas detalhadas sobre as alterações estão disponíveis atualmente em inglês.
-
As notas detalhadas sobre as alterações estão disponíveis atualmente em inglês.
Não é possível fazer a comparação completa — nenhum instantâneo anterior foi arquivado para esta revisão.
Atualizado em 18 de jul. de 2026.
Resumo editorial e detalhes registrados da alteração.Detalhes da alteração
-
As notas detalhadas sobre as alterações estão disponíveis atualmente em inglês.
Não é possível fazer a comparação completa — nenhum instantâneo anterior foi arquivado para esta revisão.