Non-UTF-8 character encoding: when to switch and how to do it safely

What it looks like in the HTML

Before

<meta charset="ISO-8859-1">

After

<meta charset="UTF-8">

Why it matters

ISO-8859-1 and Windows-1252 were designed for Western European languages and hold a couple of hundred characters. UTF-8 covers every character in Unicode. When a page declares an old encoding but contains characters it cannot represent, browsers show replacement characters or mojibake, the jumbled sequences like é in place of é.

It also causes problems between systems. Feeds, APIs, email tools and search snippets expect UTF-8, and a mismatch between what the page declares and what the bytes actually are produces errors that are hard to trace. The HTML standard requires UTF-8 for new documents.

Why a WordPress site declares another encoding

• An old blog_charset setting. WordPress stores the site's charset in the blog_charset option, and themes print it with bloginfo( 'charset' ). Old versions of WordPress let you change it in the Reading settings; that field was removed long ago, but sites set up years ago can still carry an old value.
• A hardcoded charset in the theme. A theme that writes <meta charset="ISO-8859-1"> directly instead of using the setting.
• Server configuration that adds an old charset in the Content-Type header, which browsers prioritize over the HTML.
• A label written differently. Some sites declare utf8 without the hyphen. Browsers accept it as UTF-8, but this check looks for the exact form utf-8; changing the tag to UTF-8 clears it with no risk.

How to fix it in WordPress

1. Back up the site and database first. If content was stored in the old encoding, changing the declaration alone can garble it.
2. Check what is declared where. View source for the meta tag, and run curl -I https://example.com/ to see the Content-Type header.
3. Check the setting. With WP-CLI, wp option get blog_charset shows the stored value. If it is not UTF-8, set it with wp option update blog_charset UTF-8.
4. Check the content on staging. On a staging copy, change the setting and review posts with accented or special characters. If they break, the database text itself is stored in the old encoding and needs converting; this is a job for a careful database migration, often with your host's help. Also check the DB_CHARSET value in wp-config.php, which should be utf8mb4 on current installs.
5. Fix hardcoded values in your theme so it prints <?php bloginfo( 'charset' ); ?> instead of a fixed string.
6. Fix the server header if it sends an old charset.

Hydrogen SEO does not change the charset.

When you can ignore this warning

If the declared value is just utf8 or another spelling of UTF-8, browsers already treat it correctly; change the spelling when convenient. If the site genuinely uses an old encoding and shows no broken characters, the fix is still worth planning, but schedule it as a careful migration rather than a quick edit.

How to check the fix

In the browser console, document.characterSet should return UTF-8. Review pages with accented letters, curly quotes and symbols, including older posts. Check that your RSS feed validates and displays correctly. Rerun the free SEO audit to confirm the declared charset.