Managing Yoast SEO Sitemaps on Multilingual WordPress Sites

On a multilingual WordPress site, Yoast SEO creates XML sitemaps that show search engines which site URLs it includes for discovery. An XML sitemap lists those URLs in a file. A sitemap index lists the smaller sitemap files that hold the URL lists. Yoast’s settings decide whether each WordPress entry appears in a sitemap. The multilingual plugin manages translated entries and links each language version to the others.

This division of work helps you find missing or unexpected URLs. First check Yoast’s site-wide settings and the settings for the individual entry. Then inspect the live sitemap index and the sitemap files it lists. If a URL appears in more than one language, check that the multilingual plugin links the entries correctly and adds language annotations as configured.

Which Yoast settings include URLs

Yoast’s sitemap feature must be enabled before it publishes a sitemap index. In current Yoast settings, the control is under Yoast SEO → Settings → Site features → Technical SEO → XML sitemaps. The settings page also provides a way to view the sitemap. Yoast updates its sitemap index and child files as content changes. See Yoast’s XML sitemap settings.

The Content types and Categories & tags settings control whether groups of entries appear in search results. Yoast uses those same choices to decide what goes in the sitemap. If a post type or taxonomy, such as a category or tag, is excluded from search results, Yoast leaves it out of the sitemap. Some non-public types do not appear in these settings, so a developer must use a code filter to control them. Yoast describes the relevant controls in its guidance on customizing the sitemap index.

Each post or page also has its own setting for whether search engines can index it. In Yoast’s Advanced panel, an editor can set an entry to noindex, which keeps it out of the sitemap. A different canonical URL, the URL Yoast treats as the preferred version of the page, or a redirect can also explain why an expected URL is missing. Check the translated entry itself as well as its post-type setting. The source-language entry’s settings do not determine whether the translation qualifies for the sitemap. Yoast lists these cases in its guidance on excluded posts and pages.

Developers can add code filters that leave out post types, taxonomies, or individual entries. If a URL’s inclusion does not match the dashboard settings, check these code rules too. Yoast’s sitemap functional specification describes sitemap entries as canonical permalinks for content eligible for indexing.

Verify the index and the relevant child file

Open the site’s Yoast sitemap index, usually at /sitemap_index.xml, or use the view control in Yoast settings. The index links to smaller sitemap files rather than listing every page itself. Each file lists URLs in <loc> elements and, when available, gives each URL’s modification date in a <lastmod> value.

Open the relevant sitemap file from the index. It may be the post or page sitemap, or the sitemap for a custom post type. Search for the expected translated URL. Check that the <loc> points to the entry’s intended canonical permalink, or preferred URL. If it points to the source-language URL, a redirect target, or another URL, check the configuration.

Yoast’s default limit is 1,000 entries per sitemap file. The wpseo_sitemap_entries_per_page filter changes that limit, so check the later sitemap files before deciding that a URL is missing. If the browser’s formatted view hides language annotations, inspect the raw XML.

Also check what generates the sitemap address you opened. Another plugin, WordPress core, or a stored sitemap file can serve content that does not reflect Yoast’s settings. When the sitemap looks wrong, Yoast advises checking for other sitemap generators and outdated files.

Check translation relationships and language annotations

First check the site’s URL structure. Multilingual plugins place sitemaps differently depending on whether languages share one domain or use separate domains or subdomains. Polylang documents one sitemap for all languages on a single domain. When languages use separate domains or subdomains, it documents a sitemap on each one. WPML’s Yoast integration documentation also describes one sitemap for all languages unless the site uses separate domains. Check the live index because installations do not all use the same layout. See Polylang’s Yoast sitemap guidance and WPML’s Yoast integration notes.

Next, confirm that the multilingual plugin links each entry to its translations and that each entry is published in the intended language. In WPML, check whether the post type is set up for translation and whether each translation is complete. WPML also has a fallback option that displays default-language content when a translation is missing. Check this setting if a language URL unexpectedly shows source-language content. Its documentation on translating posts and custom post types explains these translation settings.

A URL in a sitemap does not prove that the site links it correctly to its versions in other languages. hreflang annotations identify language or regional alternatives. Canonical URLs identify the preferred URL for a page. Yoast explains that complete hreflang relationships link all language versions to one another in its hreflang guidance.

WPML’s Yoast integration places hreflang annotations in the sitemap XML by default, with an option to put them in the page’s <head> instead. Check the configured location and inspect the raw output before treating annotations missing from a formatted sitemap view as an error. Polylang documents sitemap behavior that depends on the domain, but do not assume its hreflang output works the same way as WPML’s.

A sitemap can include several language URLs when they represent legitimate translations. Their presence helps search engines find them, but does not guarantee that a search engine will index them. Check each URL’s canonical setting, whether it can be indexed, its translation relationship, and its language annotations.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com