Fixing og:locale Issues

The format og:locale expects

The Open Graph protocol defines og:locale as the locale the tags are marked up in, written as language_TERRITORY. If the tag is absent, the protocol says readers should assume en_US. That default is the reason the tag matters to a British site at all: without it, you are formally declaring American English.

• Language is a two-letter lower-case code from ISO 639-1: en, cy, fr, de, pl.
• Territory is a two-letter upper-case country code from ISO 3166-1: GB, IE, US, FR.
• The separator is an underscore, not a hyphen.

The United Kingdom's ISO code is GB. UK is reserved in the standard but is not the code assigned to the country, so a strict reader treats en_UK as unknown. The same code is used for every nation within the UK: English in Scotland is en_GB, Welsh is cy_GB, Scottish Gaelic is gd_GB. For the Republic of Ireland, English is en_IE and Irish is ga_IE.

How much it matters, honestly

A wrong og:locale will not usually break a link card. The title, description and image appear whatever the locale says. So it is fair to ask why a validator flags it.

• It is metadata other systems may read. Platforms, aggregators, feed readers and language tools can use the declared locale to classify content. A British recipe site declaring en_US is giving them wrong information, even if nobody sees it directly.
• It is a symptom. An en_US value on a UK site usually means the CMS language setting was never changed. The same setting often controls date formats, spelling in theme strings and the lang attribute, which screen readers use to pick a pronunciation. Fixing the locale often fixes those too.
• It matters more on multilingual sites. When a French page declares en_GB because the locale is hard-coded in a shared layout, every French card is labelled as English.

What og:locale does not do is tell Google which country to show a page in. Google uses hreflang annotations and other signals for that. Treat og:locale as accurate labelling for sharing platforms, not as a search targeting tool.

Where a wrong value comes from

Very few people type an og:locale value by hand. It is usually derived from a language setting somewhere else, and the error is in that setting or in the conversion.

A CMS language left on the default

WordPress installs in American English unless you choose otherwise, and SEO plugins such as Yoast and Rank Math build og:locale from the site language. If Settings → General → Site Language says English (United States), the tag says en_US. Switching it to English (UK) changes the tag to en_GB, and also changes the language of the admin screens and some theme text.

A hyphenated code passed straight through

Many systems store locales as en-GB, the BCP 47 form used by the lang attribute and hreflang. A template that prints that value straight into og:locale gives the hyphen form. The fix is a conversion, covered below, not a different setting.

A language with no country

Shopify, many headless CMSs and some translation plugins store just the language, en or fr, for each version of a site. Printing that alone gives a code with no territory. Combine it with the market's country code, or map it to a full code.

A hard-coded value in a shared layout

On multilingual sites, og:locale is sometimes written once in the base layout. Every language then declares the same locale. The value has to come from the language of the page being rendered.

Generating the right value in code

Keep one source of truth for a page's language, usually the BCP 47 form such as en-GB, because that is what lang and hreflang need. Derive the Open Graph form from it with a small conversion that also rejects the UK mistake.

function toOgLocale(tag, fallbackCountry = 'GB') {
  const [lang, region] = String(tag).replace('_', '-').split('-');
  let country = (region || fallbackCountry).toUpperCase();
  if (country === 'UK') country = 'GB';
  return `${lang.toLowerCase()}_${country}`;
}

toOgLocale('en-GB');   // en_GB
toOgLocale('en_uk');   // en_GB
toOgLocale('cy');      // cy_GB
toOgLocale('fr', 'FR'); // fr_FR

The same idea works in any template language. In PHP, str_replace('-', '_', $tag) followed by fixing the case does most of the work. The important part is that the fallback country is a decision you make for your site, not the protocol's US default.

Next.js

The Metadata API has dedicated fields. Set openGraph.locale in the root layout and override it in any route that serves another language.

export const metadata = {
  openGraph: {
    locale: 'en_GB',
    siteName: 'Harlow Street Bakery',
  },
};

Shopify

If your theme prints og:locale, build it from the storefront's language and market country rather than typing a value. The Liquid objects request.locale.iso_code and localization.country.iso_code give you the two parts; take only the language part of the first, join them with an underscore, and print the result.

{%- assign og_lang = request.locale.iso_code | split: '-' | first -%}
<meta property="og:locale" content="{{ og_lang }}_{{ localization.country.iso_code }}">

Check the output on each market you run, because a store selling to several countries in one language will then declare a different territory for each market, which is accurate.

The fix, step by step

When og:locale:alternate belongs in the block

The protocol describes og:locale:alternate as an array of other locales the page is available in. Read literally, that means the same address, not a translation somewhere else. It suits a small number of set-ups.

<meta property="og:locale" content="en_GB">
<meta property="og:locale:alternate" content="cy_GB">

Each alternate gets its own tag; do not put a comma-separated list in one content attribute. Order does not carry meaning, but keep the primary og:locale first so the block is easy to read.

Edge cases

• Content for several English-speaking countries. If one English page serves the UK, Ireland and Australia equally, pick the variety it is written in, usually en_GB. Do not list en_IE and en_AU as alternates; they are not different versions of the page.
• Machine-translated pages. Declare the language the visitor actually receives. A page translated in the browser by a script is still, as far as crawlers are concerned, the original language.
• Platform-specific codes. Some platforms keep their own list of locales and may not recognise every combination. Stick to common language and country pairs for the primary value rather than inventing combinations such as cy_US.
• Two sources printing the tag. A translation plugin and an SEO plugin may each print og:locale. Readers normally take the first, so the page can declare the wrong language even though a correct tag is further down. Keep one source.
• Staging and default installs. A fresh install or a restored backup can quietly reset the site language. Check the locale after migrations.

For the relationship between language versions in search, see fixing hreflang and canonical conflicts. Each language page's og:url should name that language's own address, as explained in fixing og:url and canonical mismatches.

Keeping the locale right

• Record the site language decision. Note the chosen primary locale and each language version's locale in your site documentation, so the next developer or agency does not reset it.
• Derive, never duplicate. Store the language once and let the lang attribute, hreflang and og:locale all be generated from it.
• Test a page per language after updates. Plugin and theme updates occasionally change how the locale is printed. A quick source check on one page per language after each update is enough.
• Include the locale in automated checks. If you already test for core Open Graph tags on deployment, add a rule that the locale matches the pattern of two lower-case letters, an underscore and two upper-case letters, and is not en_US on a British site.