Skip to content

Multilingual SEO on WordPress, hreflang and sitemaps

WP Provider Translate takes care of multilingual SEO on your WordPress site without any setup. Every language gets its own address that search engines can index, with hreflang tags, a canonical URL in that language, translated slugs and language versions in your XML sitemap. It works alongside your SEO plugin and follows its settings, so a page you keep out of search results stays out in every language.

What search engines see

For every translated page, WP Provider Translate makes sure search engines get:

WhatWhat WP Provider Translate does
Title and meta descriptionTranslated, like the rest of the page
Its own addressEach language lives at its own address, such as yoursite.com/de/ or its own domain
hreflang tagsEvery version of a page links to all its other language versions
Canonical URLPoints to the page in its own language, not to the original
Translated slugs/de/uber-uns/ instead of /de/about-us/, with a redirect from the old address
XML sitemapEvery page is listed in every language it exists in
Page languageThe page, its share preview and its structured data name the right language
404 pagesAn address that doesn’t exist is a 404 in every language

There is nothing to switch on. It starts the moment a page goes live in a language.

An address per language

Search engines can only show a translated page if it has its own address. WP Provider Translate gives each language its own folder (/de/, /fr/) or, if you want, its own domain. Your original addresses never change, so nothing moves for the pages search engines already know.

Visitors are never redirected by their browser language or location. That matters for SEO: search engine crawlers usually visit from one country with one browser language, and an automatic redirect could hide your other languages from them. Visitors choose with the language switcher instead.

hreflang tags in WordPress

hreflang tags tell search engines which pages are versions of each other, so a German searcher gets your German page and a French searcher your French one. WP Provider Translate adds them to the head of every page:

  • One tag per language the page exists in, including your site’s own language, named by the language code (de, fr, pt-br).
  • x-default points to the page in your site’s own language: the version for searchers whose language you don’t offer.
  • On every version. The original page and each translation all carry the same full set, so every link is confirmed in both directions, as search engines require.
  • Only languages the page really exists in. A page that is not translated yet, or that you keep out of a language, is left out of that language’s tags until it is live. See How translation runs.

Some pages get no hreflang tags, on purpose:

  • Search results and 404 pages.
  • Addresses with a query (?color=red, a filtered shop page), since those are variations, not pages of their own.
  • Pages that are in only one language. There is nothing to link to.

hreflang follows your canonical and noindex settings

Search engines ignore hreflang on a page that says it is a copy of another page, or that asks not to be indexed, and conflicting signals can hurt. So WP Provider Translate reads what your page itself says, whatever SEO plugin set it:

  • The canonical points to another page. The page lists no language versions; the page it points to does.
  • The page is set to noindex (in your SEO plugin, or a robots meta tag). The page lists no language versions, in any language.

You don’t need to do anything for this: set canonical and noindex in your SEO plugin as you always do.

Canonical URL per language

Each translated page’s canonical URL points to the page in its own language: the German page says its canonical address is the German one. Without this, search engines would treat the translations as copies of the original and leave them out of results.

WP Provider Translate translates the canonical tag your SEO plugin or WordPress already prints. If you point a page’s canonical to another page, the translation’s canonical points to that other page in the same language.

Translated URLs (slugs)

Addresses are translated too, so a German visitor sees /de/uber-uns/ rather than /de/about-us/. Words in the address help searchers recognise a result, and they help search engines understand the page.

  • Made from the translated title. As soon as a page’s or category’s title is translated, its address in that language is made from it. This works for pages, posts, products and every other public content type, and for categories, tags, product categories and other public taxonomies that have content.
  • The untranslated address redirects. /de/about-us/ moves to /de/uber-uns/ with a permanent (301) redirect, so links and bookmarks keep working and search engines pass on the value.
  • It doesn’t change later. Correcting the title translation afterwards keeps the address as it is, so links never break.
  • More after the address is kept, such as a second page of a list (/page/2/) or WooCommerce’s order received page.
  • Coming from WPML or TranslatePress? Your existing translated slugs are imported. See Switching from WPML and Switching from TranslatePress.

Multilingual XML sitemap

Your sitemap lists every page in every language it exists in, in the format search engines use for multilingual sites: each address with all its language versions as alternates (hreflang in the sitemap).

  • Your existing sitemap, extended. It works with the sitemap WordPress makes itself, Yoast SEO’s and Rank Math’s, and other SEO plugins whose sitemap addresses end in sitemap….xml. You keep submitting the same sitemap address.
  • One sitemap for all languages. Opening it on a language address (/de/sitemap_index.xml) redirects to the one sitemap that holds every language.
  • Only pages that are live in a language are listed in that language.
  • Sitemap indexes stay as they are; the language versions are added inside each sitemap they list.
  • A domain per language? Each domain gets its own sitemap. See Sitemaps with a domain per language.

Social share previews (Open Graph)

When someone shares a translated page on social media or in a chat app, the preview shows that language:

  • og:url points to the page in its own language, so the shared link opens the right version.
  • og:locale names the page’s language (such as de_DE), with your other languages as og:locale:alternate.
  • Share image per language. If you chose a replacement image for a language, the preview uses it. See Images and content per language.
  • Title and description in the preview are translated like the rest of the page.

These tags are added by your SEO plugin or theme; WP Provider Translate adjusts the ones that are there. Without an SEO plugin that adds Open Graph tags, there are none to adjust.

Structured data (schema) in every language

Structured data (JSON-LD) is translated with the page, and its inLanguage is set to the page’s language (such as de-DE), so rich results describe the page in the right language. Names of people, organisations and brands stay as they are. See What gets translated.

404 pages stay 404 in every language

An address that doesn’t exist returns a real 404 “not found” in every language, just as it does on your original site. It never redirects to a home page, which search engines would see as a “soft 404”. So broken links show up in your SEO tools as they should.

A page that exists but is not live in a language yet is different: its address leads to that language’s home page with a temporary redirect, and switches to the translated page the moment it is ready.

Works with your SEO plugin

WP Provider Translate reads and adjusts what your SEO plugin prints, so you keep using it as before: titles, descriptions, canonical, noindex and sitemaps are set once, in your own language, and carried into every language. This works with Yoast SEO, Rank Math, All in One SEO, SEOPress, The SEO Framework and Slim SEO. See SEO plugins for the details per plugin.

Check it on your site

  1. Open a translated page on your site, such as yoursite.com/de/, in a private browser window.
  2. View the page source (right-click, View page source) and search for hreflang. You see one line per language, plus x-default.
  3. Search the same source for canonical. It points to the page you are looking at, in its own language.
  4. Open your sitemap (for example yoursite.com/wp-sitemap.xml, or yoursite.com/sitemap_index.xml with Yoast SEO or Rank Math) and open one of the sitemaps it lists. Each page appears once per language, with its language versions under it.
  5. In Google Search Console, you don’t need to add anything for languages in folders: the sitemap you already submitted now holds every language.

Troubleshooting

  • A page has no hreflang tags. Check whether it is live in more than one language on WP Provider Translate → Pages, whether it is set to noindex, and whether its canonical points to another page. Addresses with a ? and search results never get them.
  • A translated page is missing from the sitemap. Only pages that are live in a language are listed. Once all of a page is translated, it appears. If you use a caching plugin, clear its cache so the sitemap is rebuilt. See Caching plugins.
  • The translated address still shows the original slug. The address is made once the title translation has arrived; give it a few minutes after the page goes live. Pages kept out of a language don’t get one.
  • The share preview shows the original language. Social networks keep old previews for a while. Most have a tool to fetch a link again, which picks up the new preview.
For developers
  • wp wpprovider-translate sync collects finished translations and makes translated slugs straight away, without waiting for the next background run. See WP-CLI commands.
  • The wppt_output filter gets the finished translated page and its language code, for a last change to the head or body. See Developer filters and actions.