Preventing Sitemap Conflicts Between Yoast and Other Plugins

A WordPress site's XML sitemap can come from Yoast SEO, another plugin, WordPress itself, or a static file on the server. The sitemap is a machine-readable list of site URLs that helps search engines find content. Choose one source for the site's general sitemap and confirm that it serves the live URL.

A site can have several sitemap files without a conflict. A sitemap index is an XML file that links to smaller sitemap files. One generator can create an index and several child sitemaps. Google also allows site owners to submit multiple sitemap files. A conflict occurs when two generators try to serve the same general sitemap route, or when a file or cached response keeps an outdated sitemap available.

Identify which generator serves the sitemap

Check plugin settings and the XML returned by the live sitemap URL. The URL path can suggest which plugin serves it, but it does not prove who produced the XML. Yoast notes that /sitemap.xml, for example, is not generated by Yoast and may come from WordPress core or another plugin.

In Yoast, check Yoast SEO → Settings → Site features → Technical SEO → XML sitemaps. The settings include a link to view Yoast’s sitemap. WordPress core’s sitemap index is commonly at /wp-sitemap.xml. Other SEO plugins, such as Rank Math, have their own sitemap controls; check the installed plugin’s current settings rather than relying on a menu path that may have changed.

Open the sitemap links shown in the plugin settings and inspect the XML. An index lists child sitemap URLs; each child sitemap lists site URLs. Compare those URLs and content types with the features enabled in each plugin. If the settings and sitemap contents do not show which plugin owns the sitemap, test one sitemap feature at a time on a staging site, a separate copy used to test changes, or during a planned maintenance window. After each change, request the sitemap URL and account for any page cache or content delivery network (CDN) cache, which could return an older response.

Also check whether the sitemap is a physical file stored on the server. Yoast documents that a physical sitemap file can block its dynamically generated sitemap. Its guidance is to remove the file or choose to use that file and disable Yoast’s sitemap feature.

Disable the competing sitemap feature

Choose the generator that should own the general sitemap, then turn off the competing plugin’s sitemap feature. You usually do not need to deactivate an entire SEO plugin if you still rely on its other features.

If Yoast will provide the sitemap, enable its XML sitemap feature and disable the sitemap feature in the other plugin. Yoast specifically advises disabling other sitemap plugins and resolving physical sitemap files before using its sitemap. If you prefer another plugin’s sitemap, use that plugin’s control to disable its sitemap generation in Yoast.

WordPress core needs a separate check when you change settings. Yoast says that enabling its sitemap automatically disables the default WordPress sitemap. Disabling Yoast’s sitemap does not disable WordPress core’s sitemap, so /wp-sitemap.xml may still return a sitemap after you turn off Yoast.

A physical sitemap is another possible owner. If you keep one, confirm it is updated when the site’s URLs change. Otherwise, the file can continue listing outdated URLs even after you disable a plugin.

Verify the live sitemap routes

After changing settings, check the live site rather than relying only on the WordPress admin toggles. Request the selected sitemap URL and confirm that the server returns XML. An error or unexpected redirect means the check has failed. Also confirm that the returned content is current. If the sitemap is an index, open its child links and confirm that they list the content types you intend to include.

Then check the competing routes. If Yoast owns the general sitemap, test /wp-sitemap.xml and any sitemap URL previously exposed by the other plugin. An unexpected sitemap response does not by itself identify its source, so compare the response with plugin settings and check for a physical file or cached copy. Review the live robots.txt as another clue: WordPress core’s sitemap documentation says core references its sitemap index there, but robots.txt does not inventory every possible sitemap.

Finally, review sitemap submissions in Google Search Console. Remove outdated or invalid submissions and submit the current index. Google permits multiple sitemap submissions, so keep more than one only when each serves a deliberate purpose. A specialized sitemap, such as one for video or news content, may supplement the general sitemap rather than duplicate it.

Choose one owner for the general sitemap and make sure no other plugin, physical file, or stale response competes for the same route.

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