How to Tell Which Plugin Generates Your XML Sitemap

On a WordPress site, an XML sitemap is a file that lists pages for search engines to discover. A sitemap index is a file that points to other sitemap files, such as separate lists for posts and pages. To find what creates a sitemap, check its URL and contents, then check which sitemap features WordPress has enabled. The URL alone rarely identifies the plugin that produced it.

Yoast SEO, other plugins, and WordPress itself can provide sitemap output. The URL paths they use can overlap, and one index can include sitemaps from more than one source. Compare the live sitemap with plugin settings and the site’s active code to narrow down which source generates it.

Read the sitemap URL and its contents

Open the sitemap URL in a browser and record the exact address, including any redirect. Then inspect the XML. Note the links to separate sitemap files, their names, and the content types they list.

Yoast documents /sitemap_index.xml as its sitemap index, with child files such as post-sitemap.xml and page-sitemap.xml. Those names are useful clues, but they do not identify Yoast conclusively. Rank Math also documents /sitemap_index.xml, and a sitemap index can include external files. Yoast, for example, provides a way to add an external sitemap to its index.

The URL /wp-sitemap.xml points toward WordPress core’s sitemap feature, introduced in WordPress 5.5. A plugin, a WordPress rule that maps URLs, or a server setting can change what appears at a URL. Check the settings and live response to confirm which route serves the sitemap. Likewise, /sitemap.xml does not identify a specific generator. Yoast’s documentation says that address is likely generated by another plugin or WordPress core, rather than Yoast’s documented default route. See the WordPress sitemap reference and Yoast’s sitemap settings.

The XML can provide clues, but no universal “generated by” field reliably names its producer. Treat filenames, content types, and last-modified details as clues, not proof.

Check which sitemap features are enabled

In WordPress admin, open Yoast SEO’s settings and check the XML sitemap control. Yoast’s documented path is Yoast SEO → Settings → Site features → Technical SEO → XML sitemaps. When the feature is enabled, use View the XML sitemap to see the URL Yoast opens. Dashboard labels and locations can vary by plugin version.

Check other installed SEO or sitemap plugins in the same way. The plugin’s presence does not prove that its sitemap feature is active. For example, Rank Math documents its controls under Rank Math → Sitemap Settings. All in One SEO (AIOSEO) provides an Enable Sitemap setting and an Open Sitemap control. Jetpack places its sitemap toggle under Jetpack → SEO → Sitemaps. Their Rank Math, AIOSEO, and Jetpack documentation describes these controls.

Yoast documents that enabling its sitemap feature automatically disables the default WordPress XML sitemap. Turning off Yoast’s feature does not disable the core sitemap. So if a sitemap remains available after you turn off Yoast, that alone does not show that another plugin took over. Check the core route and other plugin settings before drawing that conclusion. See Yoast’s explanation of site features.

Check active plugins and code outside the plugin screen

Open Plugins → Installed Plugins and check which plugins are marked active. The list also shows inactive plugins, which cannot generate the sitemap while inactive. The WordPress plugin management documentation explains the distinction.

The standard plugin screen does not show must-use plugins, which WordPress calls mu-plugins. WordPress loads them automatically, and they typically reside in wp-content/mu-plugins. If the visible plugin settings do not explain the sitemap, check that directory and review relevant custom code or server rules. WP-CLI can help inventory plugin activation status with wp plugin list, but the inventory alone cannot prove which code served a particular URL.

Confirm the generator when evidence conflicts

When the URL, XML, and settings point to different generators, test on a staging site, a copy of the live site used for testing. Change one sitemap setting at a time, clear relevant caches for plugins, the server, and the content delivery network (CDN), then request the same URL again. Compare the status code, redirects, index contents, and child files. Changing several settings at once makes it harder to identify which change affected the response.

A stale response can hide the effect of a setting change. Yoast documents caching as a cause of sitemap output appearing not to update, so clear the applicable caches before treating an unchanged file as evidence. Its sitemap troubleshooting guidance describes this issue. Avoid toggling sitemap features on a live site just to test them; if staging is unavailable, preserve the existing configuration and schedule a controlled test.

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