This check fires when a page ships no character encoding declaration — no <meta charset> in the head and no charset in the Content-Type HTTP header. Without it, the browser and Googlebot have to guess the encoding, and when they guess wrong you get mojibake: curly quotes turn into ’, accented names break, emoji become question marks. Garbled text hurts readability, can distort how Google parses your content, and looks broken to anyone who lands on the page.
Note the near-duplicate slug on this site, Missing Charset — same underlying issue. If both surface in your audit, treat them as one fix.
What breaks when encoding is undeclared
Modern browsers default to UTF-8 in many cases, but "many" isn't "all," and you don't control every client or proxy in the chain. When no charset is declared, the parser falls back to sniffing bytes or applying a locale-dependent default like Windows-1252. Any multi-byte character — an em dash, a smart quote, a é or an ü — then renders as garbage.
Here's a page with no declaration anywhere. The content is UTF-8 on disk, but nothing tells the client that:
<!DOCTYPE html>
<html>
<head>
<title>Café Menu — Crème Brûlée</title>
<!-- no charset declared, no header charset either -->
</head>
<body>
<h1>Crème Brûlée — £7.50</h1>
</body>On a client that defaults to Windows-1252, the heading can render as Crème Brûlée — £7.50. Ugly, and Google may index the mangled version.
The fix: declare UTF-8, first thing in the head
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8"> <!-- must be within the first 1024 bytes -->
<title>Café Menu — Crème Brûlée</title>
</head>The <meta charset> must appear inside the first 1024 bytes of the document, which in practice means it should be the very first thing in the head, before the <title>. Belt and braces: also send it in the header — Content-Type: text/html; charset=utf-8. The HTTP header wins over the meta tag when both are present, so make sure they agree.
Charset declaration methods, ranked
| Method | Example | Precedence | Notes |
|---|---|---|---|
| HTTP header | Content-Type: text/html; charset=utf-8 | Highest | Overrides the meta tag; set at the server |
| Meta charset (HTML5) | <meta charset="utf-8"> | Used if no header | Must be in first 1024 bytes |
| Legacy meta | <meta http-equiv="Content-Type" ...> | Works but verbose | The short form is preferred |
| BOM (byte-order mark) | Invisible UTF-8 BOM | Fallback signal | Can cause its own issues; avoid relying on it |
| Nothing declared | — | Guesswork | Mojibake risk |
How to detect it
- Screaming Frog. After a crawl, this shows in the page-level data — check the Content tab and the response headers for each URL. Frog surfaces the declared encoding; pages with none flagged, or a mismatch between the header charset and the meta charset, are your targets. Use Bulk Export to pull the full list.
- View Source. Ctrl+U and search for
charset. If there's no match, or the tag sits deep in the head after a lot of other markup (pushing it past the 1024-byte window), flag it. Then open DevTools → Network, click the document request, and read the Content-Type response header to see if the server declares one. - Google Search Console. URL Inspection → View crawled page. If the rendered HTML shows garbled characters where accents or symbols should be, Google is parsing the wrong encoding. Compare against how the page looks in your own browser with the encoding forced to UTF-8.
How to fix it
- Set the server header to
text/html; charset=utf-8for all HTML responses. This is the most reliable single fix because it wins precedence. - Add
<meta charset="utf-8">as the first element inside<head>, before the title, so it's inside the 1024-byte window even if the header is missing. - Make sure the file is actually saved as UTF-8. Declaring UTF-8 while the bytes are Windows-1252 just relocates the problem. Check your editor's encoding and your database/connection collation.
- Keep header and meta in agreement. A header saying
iso-8859-1with a meta sayingutf-8will render as the header says — and probably wrong. - Re-crawl and spot-check pages with accented content, currency symbols, and smart quotes to confirm the garbling is gone.
FAQ
Won't browsers just default to UTF-8 now?
Many will, but not universally, and not through every proxy or CDN. Relying on defaults means gambling on the client. Declare it and stop guessing.
Does a missing charset actually hurt rankings?
Not directly as a ranking factor, but garbled text degrades how Google reads your content and tanks the experience for users, which shows up in engagement. Mangled titles and headings can also look broken in the SERP.
Header charset or meta charset — which should I use?
Use both, and make them match. The header takes precedence, so if you can only fix one, fix the header. The meta tag is your safety net when the header is absent.
Where exactly does the meta charset need to go?
Inside the first 1024 bytes of the document, which means the very top of the head, before the title and any other metadata. If you bury it, the browser may have already started sniffing.
Could this be related to a broken head structure?
Yes — if the head is malformed or closes early, your charset tag can end up outside it and get ignored. Validate the head; see Missing Head Tag. For encoding on other document types, the HTTP header optimization guide covers server-side declarations.
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!
