Accessibility May 7, 2026

html lang Attribute in WordPress: Language for Screen Readers and SEO

Without lang="en", screen readers mispronounce content and SEO loses context. Here is how to ensure the attribute is correct on every page.

The lang attribute on the <html> tag tells every consumer of the page - browser, screen reader, Google, translation services - what the primary language is. It is one short attribute that controls how a blind user hears the site and how Google ranks it.

Why this matters

Screen readers like NVDA and VoiceOver use lang to choose the correct pronunciation engine. A page written in English with <html lang="en"> is read with English phonetics; without the attribute (or worse, defaulted to a different language), the same text is mispronounced into noise. For a Hebrew site without lang="he", Hebrew letters can be pronounced with Latin phonetics - rendering the page unintelligible to blind users.

This is a international accessibility guidelines Level A requirement, 3.1.1 Language of Page. 3.1.2 Language of Parts covers language switches inside content (<span lang="fr"> around French quotes inside an English page). For SEO, Google uses lang as a language targeting signal - a page with lang="en-GB" tends to appear for British English searches. Translation tools (Google Translate, dictionary popups) also rely on lang to identify the source language.

How to detect

View source on the home page. The first line of HTML should be:

<html lang="en-US">

Or for a Hebrew site:

<html lang="he-IL" dir="rtl">

If you see <html> with no attribute, or lang="", or the wrong language, there is a problem. Tools: axe DevTools, Lighthouse and WAVE all flag this. RankPlus reads the home page DOM and checks the lang value.

How to fix

  1. Visit Settings > General > Site Language. Confirm the right language is set. This drives what language_attributes() in PHP returns.
  2. Inspect header.php in the active theme (wp-content/themes/THEME/header.php). The opening line must be:
    <html <?php language_attributes(); ?>>
    not just <html>.
  3. For block themes (FSE) on WordPress 6.0+: edit via Appearance > Editor > Templates > Header.
  4. Verify no functions.php or plugin removes the filter:
    grep -rn "language_attributes" wp-content/themes/ wp-content/plugins/
    If a remove_filter or empty return appears, locate and remove it.
  5. Flush page cache (W3 Total Cache, WP Rocket, LiteSpeed) after the change - cached pages still ship the old language.
  6. For multilingual sites (WPML, Polylang, TranslatePress): the plugin handles lang per language version. Verify the plugin is active and that every page has a valid locale.
  7. For inline foreign-language text (a Hebrew quote inside an English post), wrap with <span lang="he">...</span>.

Common mistakes

  • An aggressive minifier stripping attributes: some optimisation plugins drop lang. Check the rendered HTML.
  • Removing language_attributes() for "cleaner code": disables the entire mechanism.
  • Using legacy codes like lang="iw" for Hebrew (IANA deprecated this in favour of he).
  • Forgetting dir="rtl" on Hebrew/Arabic: even with lang="he", the browser also needs dir="rtl" to render text correctly. language_attributes() emits both.
  • An out-of-date multilingual plugin: a stale WPML can render the default lang on all pages.

Verifying the fix

View source on home, single post and category pages. All should start with <html lang="..."> matching the actual content language. Run Lighthouse - the Accessibility item "document has a valid lang attribute" should pass. RankPlus turns green.

Tip: If you maintain separate-language versions of the site, also set hreflang alongside lang - it tells Google there are language alternatives of the same content. <link rel="alternate" hreflang="en" href="...">.
More in this category ← Back to all docs