ResilientLang
Get started

WordPress Multilingual SEO: Setup and Checks

By the ResilientLang team · Published · 7 min read

Multilingual SEO on WordPress comes down to five outputs being correct on every translated page: a unique URL, a self-referencing canonical, hreflang links to every other language version, a matching lang attribute, and an entry in an XML sitemap. WordPress core does not provide multilingual features, so these come from whichever translation setup and SEO plugin you use, and the only reliable test is reading the page source. This guide lists what to check and why.

What does WordPress core do for multilingual SEO?

Very little, by design. The WordPress developer documentation describes internationalization as preparing strings for translation, and the Site Language setting is documented as the dashboard language. Core does, however, provide some building blocks that a multilingual setup relies on:

  • Permalinks. The Settings → Permalinks screen lets you choose a structure such as Post name or a custom structure, and sets category and tag bases.
  • Canonical tags. Core has a function, wp_get_canonical_url(), used by rel_canonical() to output a canonical link for singular pages, and the result can be changed with the get_canonical_url filter.
  • XML sitemaps. Since WordPress 5.5 core serves a sitemap index at /wp-sitemap.xml, covering public post types, taxonomies and author archives, with filters to adjust entries.
  • Language attribute. The language_attributes() function prints the language attributes for the <html> tag, based on the locale in use.

Everything else, such as storing translations, assigning a language to a URL and generating hreflang, is added by your multilingual setup. If you have not chosen one yet, start with how to make WordPress multilingual.

Google asks for a separate URL per language version rather than relying on cookies or browser settings. It describes subdirectories (example.com/fr/), subdomains (fr.example.com) and country-code domains as the usual options, and advises against URL parameters. Most WordPress multilingual setups use subdirectories because they are simple to run on one host.

Decide these points once, before publishing:

  1. Pretty permalinks. Use a readable structure, such as Post name, so that language prefixes and slugs form clean paths.
  2. Whether to translate slugs. example.com/fr/a-propos/ instead of example.com/fr/about/. This is a user and keyword-research choice, not a Google requirement. See translating URLs and slugs for SEO.
  3. Slug consistency. If slugs are translated, every translated page needs its own slug, and changing one later needs a redirect from the old URL.
  4. Character handling. Non-Latin slugs are valid but are percent-encoded in links and sitemaps, so test that the encoded and displayed forms resolve to the same page.

After changing permalink settings or language URL formats, visit Settings → Permalinks. The WordPress documentation notes that visiting that screen flushes rewrite rules, and that saving is not required for that purpose.

What hreflang output should WordPress pages have?

Google's documentation lists the rules: each version must link to every other version and to itself, the links must be reciprocal, URLs must be absolute with the protocol, and x-default can name a fallback such as a language selector. Language codes are ISO 639-1, optionally with an ISO 3166-1 Alpha-2 region; a region on its own is invalid. For an English page with a French translation, both pages should contain:

<link rel="alternate" hreflang="en" href="https://example.com/about/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/a-propos/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/about/" />

Google treats the three delivery methods (HTML tags, HTTP headers, XML sitemap) as equivalent, so choose one and keep it consistent. What matters most on WordPress is that only one component generates hreflang. If both a translation setup and an SEO plugin output tags, you can end up with duplicates or conflicting sets. Compare the methods in hreflang implementation methods.

Common WordPress-specific faults are tags that point to the wrong translation after a slug change, tags for pages that do not exist in the other language, and tags pointing to redirected or non-canonical URLs.

How should sitemaps work on a multilingual WordPress site?

Every language URL should appear in a sitemap, because Google's guidance allows sitemaps as the hreflang method and sitemaps help discovery in any case. In the WordPress 5.5 announcement, the core sitemap's documented fields are the URL plus optional entries such as lastmod, and hooks like wp_sitemaps_posts_entry and wp_sitemaps_posts_query_args let developers change entries and queries. The announcement does not mention alternate-language links.

That leaves two practical situations:

  • Your translation setup or SEO plugin replaces the core sitemap with its own, and may add xhtml:link alternates. Open it and check.
  • You use the core sitemap and rely on page-level hreflang tags. Then confirm the translated URLs are included at all. Some setups store translations in a way that the default sitemap queries do not list.

If you add alternates to a sitemap, Google's format requires the xhtml namespace and an entry for every variant, including the page itself:

<url>
  <loc>https://example.com/about/</loc>
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/about/"/>
  <xhtml:link rel="alternate" hreflang="fr" href="https://example.com/fr/a-propos/"/>
</url>

Avoid running two sitemap generators at once, and avoid publishing a plugin sitemap and the core sitemap with different URL lists. See multilingual XML sitemaps for structure options.

Which canonical tags should translated pages use?

Each translated page should normally carry a canonical link pointing to itself. Google's canonicalization documentation recommends including a rel="canonical" link on the canonical page itself, and says that when you use hreflang the canonical should be a page in the same language where one exists. Pointing every translation at the original is therefore a risk: in our reading, it tells Google to treat the translation as a duplicate rather than as a language alternate.

On WordPress, the canonical is often produced by core or an SEO plugin, and a translation layer may or may not adjust it. After setup, check a translated page: the canonical should be its own absolute URL, with no tracking parameters, and should match the URL in its hreflang self-reference. Also note that paginated and filtered archives need their own consideration. More detail is in canonical tags on multilingual sites.

How do SEO plugins interact with translation setups?

SEO plugins typically control titles, meta descriptions, canonicals, Open Graph tags and sometimes sitemaps and hreflang. Translation setups control language, URLs and the content itself. The overlap creates the most frequent problems, so describe it generically as an ownership question:

  • Titles and descriptions. Are the SEO title and meta description fields translated per language, or does every language fall back to the original text? A French page with an English description is a missed opportunity.
  • Canonical and hreflang. Decide which component owns each, and disable the other.
  • Sitemaps. One generator, one set of URLs.
  • Social tags and structured data. Make sure og:locale and the language-dependent properties of structured data match the page language.

Treat the answer as configuration to verify, not a promise from any product.

What should I verify in the page source?

Open a translated page, use View Source (not the browser inspector, which shows the DOM after JavaScript), and check:

  1. <html lang="fr-FR"> or similar matches the visible language.
  2. One rel="canonical" tag, pointing to itself.
  3. A complete hreflang set, with itself, all alternates and (if used) x-default.
  4. The visible body text is in the HTML, not injected later.
  5. The language switcher uses ordinary <a href> links to the translated URLs. Google recommends visible links to other language versions, and warns against redirecting visitors by guessed language, since crawlers usually do not send language preferences. Our guide to automatic redirects by language or location covers the safe patterns.
  6. The same URL appears in the sitemap, the canonical and the hreflang self-reference.

Then, in Google Search Console, use URL Inspection on a few translated pages, and monitor indexing reports after launch.

Key takeaways

  • WordPress core provides permalinks, canonical output, a basic sitemap and a language attribute, but no multilingual or hreflang feature in the documentation reviewed.
  • Give every language its own URL, a self-referencing canonical and reciprocal hreflang with absolute URLs.
  • Let exactly one component generate hreflang and one generate the sitemap.
  • Translated slugs are a choice, not a Google requirement; whichever you choose, apply it consistently and redirect old URLs.
  • Verify with View Source and Search Console instead of trusting plugin settings.

Sources

Frequently asked questions

Does WordPress add hreflang tags by itself?

In the core documentation we reviewed, WordPress has no multilingual feature and no hreflang output. Hreflang normally comes from the translation setup you use, from an SEO plugin, or from custom code. Always confirm what your own pages output by viewing the source rather than assuming.

Should I translate my URL slugs?

It is optional. Google requires distinct, crawlable URLs per language, not translated words. Translated slugs can help users read the URL and match local search terms, but they add redirect and consistency work. Pick one rule per site and apply it everywhere.

Does the WordPress core sitemap include hreflang?

WordPress core generates a sitemap at /wp-sitemap.xml, and the announcement describes only standard fields such as the URL. It does not mention alternate-language links, so hreflang in a sitemap would come from a plugin or custom code. You can use hreflang in page tags instead.

Why do my translated pages show as duplicates in Search Console?

Common causes are a canonical tag pointing every translation at the original, pages that are still mostly untranslated, or language versions that are not reachable as separate URLs. Check the canonical, the page text and the hreflang annotations of an affected URL with the URL Inspection tool.

Keep reading