Your page never tells browsers what character encoding it uses, so declare UTF-8 in two places: the HTTP Content-Type header (charset=utf-8) and a <meta charset="utf-8"> tag placed within the first 1024 bytes of the HTML.
What this check flags
This audit item fires when a page declares its character encoding nowhere a browser can reliably find it: no charset parameter on the HTTP Content-Type response header, and no <meta charset> declaration early in the HTML source. Either one passes, but the safe, spec-blessed setup is both, and both saying the same thing: UTF-8.
Character encoding is the map between raw bytes and actual letters. If you do not hand the browser that map, it has to guess.
Why it matters
When no encoding is declared, the browser guesses, by byte-pattern sniffing or by falling back to a legacy default like Windows-1252. When the guess is wrong, you get mojibake: garbled junk where real characters should be. The French word "détail" becomes "détail", and an innocent apostrophe turns into "’".
This bites accented languages hard. English mostly survives a bad guess because plain ASCII decodes the same way under nearly every encoding. French does not: é, è, ç, à and friends all live outside ASCII, so every accented character is a potential casualty. Same story for umlauts, ñ, ã, and anything Cyrillic, Greek, or CJK, where entire pages turn to soup.
For SEO, the damage shows up in the worst possible place: the SERP. Search engines render what they parse, and if your title tag or meta description contains bytes that got decoded under the wrong map, your snippet on the results page reads "Réservez votre séjour dès maintenant". Oh Merde! That is your storefront window, and it now looks like the site was assembled by a fax machine. Users do not click garbage snippets. And structured data, hreflang labels, and OpenGraph text all ride on the same encoding, so one missing declaration can corrupt all of them at once.
The two declaration points
1. The HTTP Content-Type header
The server can declare encoding before a single byte of HTML is parsed. This is the highest-priority signal: a charset in the HTTP header wins over anything inside the document.
# Bad: no charset, browser must guess
Content-Type: text/html
# Good: encoding settled before parsing starts
Content-Type: text/html; charset=utf-82. The meta tag, within the first 1024 bytes
Inside the document, the WHATWG HTML standard requires the encoding declaration to be serialized completely within the first 1024 bytes of the file. Browsers only prescan that opening window before committing to a decoder, so a meta charset buried after a fat inline script may as well not exist. Everything counts toward the budget: doctype, comments, whitespace, all of it.
<!-- Bad: missing entirely, or pushed below 200 lines of head bloat -->
<head>
<script>/* 5 KB of tag manager */</script>
<meta charset="utf-8"> <!-- too late, outside 1024 bytes -->
</head>
<-- Good: first thing inside head -->
<head>
<meta charset="utf-8">
<title>Réservez votre séjour</title>
</head>The legacy http-equiv="Content-Type" form still works, but use the short modern form. The spec also requires the document to actually be encoded as UTF-8: do not declare an encoding you are not using.
How to diagnose
Two checks, thirty seconds. First the header:
curl -I https://www.example.com/page/
# Look for this line:
content-type: text/html; charset=utf-8If charset is absent from that line, the header half is failing. Then the document half: open the page in a browser, hit view-source, and confirm <meta charset="utf-8"> sits near the very top of <head>. If you have to scroll to find it, check that everything from the first byte of the file through the end of the tag fits under 1024 bytes. While you are there, scan visible text for "é" style artifacts, which signal content that is already double-encoded, a deeper problem than a missing declaration.
How to fix
Meta tag first. Make <meta charset="utf-8"> the first child of <head>, before the title, before any script or style. In WordPress themes this lives in header.php; most modern themes emit it correctly, but page builders and minification plugins sometimes reorder the head, so verify in the rendered source, not the template.
Then the server header. On Apache or LiteSpeed, one line in .htaccess handles it: AddDefaultCharset UTF-8. On Nginx, set charset utf-8; in the server block. In PHP, header('Content-Type: text/html; charset=utf-8'); before any output does the same job.
Mind the BOM. Some editors prepend a UTF-8 byte order mark, three invisible bytes at the start of the file. A BOM acts as an encoding signal that overrides your meta tag, and one emitted from an included PHP file can break headers or inject phantom characters before your doctype. Save files as UTF-8 without BOM, and check included templates too, because that shit hides in files nobody has opened since 2019.
Common mistakes
Declaring UTF-8 while the file is actually saved as ISO-8859-1, which makes the garbling worse. Header and meta tag disagreeing, where the header wins and the meta silently loses. A meta charset pushed outside the 1024-byte window by a giant inline script. And fixing the template while old database content stays double-encoded, which a declaration alone will never repair.
FAQ
A: Usually yes, if it sits within the first 1024 bytes and the file really is UTF-8. But the header is parsed earlier, costs one line of server config, and protects every page at once, so set both.
A: Only until a curly quote, a trademark symbol, or a pasted-in name like François lands in your content. The fix takes minutes; the snippet damage when it bites is not worth the gamble.
A: The text itself was corrupted before it reached the page, typically saved double-encoded in the database or in a file with the wrong encoding. The declaration tells browsers how to read the bytes; it cannot repair bytes that were written wrong. Fix the stored content, then keep the declaration.
Need a full technical audit?
SEO ProCheck runs deep crawls that catch issues like this across your whole site.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
