How to Verify Yoast Sitemap Changes After Settings Updates

After you change a Yoast SEO setting in WordPress, check that WordPress saved it and that the sitemap visitors see reflects it. An XML sitemap is a machine-readable list of URLs that helps search engines discover site content. Yoast’s sitemap index lists smaller, section-specific sitemaps, called child sitemaps.

To verify the change, compare the setting with the live sitemap index and the child sitemap it affects. If you monitor Google, check Search Console separately. Your site can serve a sitemap correctly before Google fetches and processes it.

Check the setting you changed

In current Yoast settings, the site-wide sitemap switch is at WordPress Dashboard → Yoast SEO → Settings → Site features → Technical SEO → XML sitemaps. When the feature is enabled, Yoast provides a View the XML sitemap link. Yoast says enabling its sitemap feature disables WordPress’s built-in sitemap; disabling Yoast’s feature does not disable WordPress’s sitemap. See Yoast’s Site features settings for details.

If you changed one section, check its setting:

• Content types: Open Yoast SEO → Settings → Content types. A content type's appearance in search results also controls its inclusion in Yoast's sitemap.
• Categories and tags: Open Yoast SEO → Settings → Categories & tags and check the relevant category or tag settings.
• One post or page: Check its noindex setting, which tells search engines not to index the page, its canonical URL, and any redirect. A canonical URL tells search engines which URL should represent a page. These settings can explain why a specific URL is absent.

Yoast’s sitemap customization guidance describes how these settings affect sitemap inclusion. Older WordPress or Yoast versions may use different menu labels. Follow the labels in your dashboard, then leave and reopen the setting to confirm that the value was saved.

Compare the sitemap before and after

Before editing a setting, save the current sitemap index and the relevant child sitemap, or record their contents. Write down what you expect to change. For example, disabling a public content type should remove its child sitemap from the index. Enabling a section makes it eligible for inclusion, but Yoast may not create a child sitemap if the section has no eligible content.

After saving the setting, open the sitemap from Yoast’s dashboard link or request your site’s /sitemap_index.xml address. Confirm that the response shows XML sitemap content rather than an error page, login screen, or ordinary HTML page. Then compare the index’s <loc> entries, which point to child sitemap URLs, with your baseline. Open the affected child sitemap and check a few representative URLs. The index alone does not show every page URL.

Yoast’s functional specification describes what affects which URLs appear. URLs can be excluded when the content is private or password-protected, has a noindex setting, or has a manually set canonical URL that differs from the default. Non-public archives, categories, or tags can also exclude URLs. So an enabled section does not guarantee that every item in it will appear.

Check whether the index entries and page URLs match the expected changes. An unchanged <lastmod> value, which records a modification time, does not by itself mean the change failed. Yoast may set an index entry’s value to the latest modification time among the URLs in its child sitemap.

Use a repeatable verification checklist

For each settings change:

1. Record the WordPress and Yoast SEO versions. Note the setting you plan to change and its current value.
2. Save the sitemap index and affected child sitemap, and note representative URLs that should appear or disappear.
3. Change the setting, save it, then reopen the dashboard setting to confirm that the new value persisted.
4. Request /sitemap_index.xml and compare its child sitemap links with your expected result.
5. Open the affected child sitemap and check the representative URLs.
6. If Google monitoring is in scope, check the submitted sitemap in Search Console.

These steps compare the saved setting with the sitemap WordPress serves. Your saved copy also gives you a baseline for investigating unexpected results.

Troubleshoot a sitemap that looks unchanged

If the dashboard shows the new value but the public sitemap still shows the old one, check the caches first. Yoast lists caches in plugins and themes, as well as server caches, as possible causes. Clear the caches that apply to your hosting setup, then request the sitemap again in a fresh browser session. Yoast’s sitemap troubleshooting guidance also recommends checking cache-related response headers and excluding sitemap URLs from caching where appropriate.

If a URL is missing, check its noindex and canonical settings. Also check whether its content type, category, or tag is visible, and whether the URL redirects. If the sitemap address returns the wrong content or an error, find out which sitemap generator serves it. WordPress core can serve output separately from Yoast. Another plugin or a physical sitemap file can serve it separately too. Yoast’s guidance on common XML sitemap errors covers malformed output, including cases where a server returns HTML instead of XML. Server rewrite rules can also affect the readable sitemap URL; Yoast documents Apache-specific checks.

Check Google’s report separately

If you submitted the sitemap to Google Search Console, open its Sitemaps report and review the status and last read. Then check the discovered pages and reported errors. Google describes “Success” as a submitted sitemap that it fetched and read without errors in its Sitemaps report documentation.

That status confirms Google processed the submitted sitemap; it does not confirm that Google crawled or indexed every listed URL. Google uses sitemaps as hints for finding URLs; it crawls and indexes pages separately. The Google Search crawling guidance also cautions that sitemap updates do not produce immediate crawling or indexing.

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