A Yoast SEO Sitemap Maintenance Checklist

For a WordPress site, Yoast SEO creates XML sitemaps that help search engines discover URLs. The sitemap index is the file that points to smaller sitemap files, called child sitemaps, which list URLs for parts of the site such as posts or pages. Yoast updates these files as content changes, so maintenance means checking that the generated URLs still match the site’s intended search visibility.

Check Yoast’s sitemap settings, the live index and its child files, and whether caching, URL settings, or custom code changed the output. These checks help you find missing content or broken sitemap links without expecting every content type to appear.

Check Yoast’s sitemap settings

In Yoast SEO, check Yoast SEO → Settings → Site features → Technical SEO → XML sitemaps and confirm that sitemap generation is enabled. Menu labels can vary by plugin version. Yoast uses settings to shape which sections appear in the index. Find those controls under Content types, Categories & tags, and Advanced, as described in its XML sitemap instructions.

Compare those settings with the content you want search engines to find. Posts, pages, products, and custom post types belong in the sitemap when they are public and intended to appear in search. Check categories, tags, other taxonomies (ways WordPress groups content), and author archives against the same goal. When you set a content type to stay out of search, Yoast also leaves it out of the sitemap.

If an individual URL is missing, inspect its page-level settings before changing the site-wide configuration. A noindex instruction tells search engines not to index that page. A canonical URL identifies the preferred URL when similar or duplicate pages exist. Yoast excludes pages with noindex, pages set to a different canonical URL, and private or password-protected content from relevant sitemaps. Its sitemap customization guidance also notes that some non-public content types do not appear as ordinary settings options.

Inspect the live index and child sitemaps

Open the Yoast sitemap index, normally at /sitemap_index.xml on your site’s preferred domain. The index should return XML. A 404 error, an HTML page, or a blank response means it is not returning the expected XML. Use the index as a table of contents and compare its child-sitemap links with the public content types and taxonomies you expect. An absent child file is not automatically a fault; Yoast may omit a section with no eligible content.

Open sample child files to confirm that each loads as XML and lists URLs you expect search engines to discover, then check that those URLs use the preferred protocol and host, such as HTTPS and either the www or non-www version of the domain. Yoast generates sitemap URLs using the WordPress Site URL, so compare the output with the WordPress and Site Address values when the format looks wrong. Yoast’s troubleshooting steps cover URL-format problems and other causes of blank-looking output.

Check that important pages eligible for search indexing appear. Do not expect redirected URLs or pages with a different canonical target to appear as the preferred entries. If a child sitemap includes lastmod, the date should reflect meaningful content changes. Google says it uses this value when it is consistently accurate; a trivial date change does not count as a substantive update. Google also limits each sitemap file to 50 MB uncompressed or 50,000 URLs, whichever limit is reached first, so larger URL sets need multiple files. See Google’s sitemap requirements.

The Search Console Sitemaps report shows the status of the latest request for a sitemap submitted through the report or API. Review new fetch or parsing errors, then compare the report with the live index. A successful report does not guarantee that Google indexed every listed URL, and the report does not necessarily show every sitemap Google discovered another way. The Search Console Sitemaps report explains its statuses and common errors.

Recognize configuration drift

Configuration drift means the sitemap output no longer matches the site’s intended settings or URL structure. The following symptoms point to specific checks:

Also check for competing sitemap sources. A sitemap file stored on the server or another plugin’s sitemap can conflict with Yoast’s dynamically generated output; Yoast describes the physical-file conflict. Disabling Yoast’s sitemap feature does not disable WordPress’s own sitemap, so check which sitemap remains available. Yoast explains this distinction in its site features documentation.

Make the checks part of maintenance

When you change SEO settings or content types, recheck the sitemap switch and any affected visibility settings. After changing plugins or custom code, or changing the site’s URL format, recheck those settings too. Then open the index and a relevant child file, confirm the URLs use the preferred host, and clear or bypass relevant caches if the output appears stale.

As a periodic check, compare the index with the site’s current public content, spot-check important pages for canonical and noindex consistency, and review new Search Console sitemap errors. Yoast and Google do not prescribe a universal maintenance schedule; choose an interval that fits how often the site changes, and repeat the check after changes that affect sitemap output.

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