How Changing Post Visibility Affects Yoast XML Sitemaps

When you change a WordPress post or page from public to private or password-protected and save it, Yoast SEO removes its URL from that content type’s sitemap. An XML sitemap lists URLs for search engines to find. Yoast’s sitemap index links to these files. Each individual sitemap is called a child sitemap, and a change to one post usually affects its child sitemap, not the index.

To check the result, follow the index to the child sitemap for that content type and look for the post’s URL. The sitemap shows which URLs Yoast publishes for search engines to find. It does not confirm whether a search engine has indexed the URL or removed it from search results.

How WordPress visibility affects sitemap eligibility

WordPress handles private and password-protected content in different ways. A private post has the private status and is visible only to users with the necessary permissions. A password-protected post has a password saved on it; password protection is separate from the post’s status, as WordPress’s documentation explains.

Yoast’s XML sitemap specification excludes private and password-protected pages, as well as content that cannot be indexed for other reasons. So when you change an otherwise eligible public post to either setting, Yoast excludes its URL from the relevant sitemap. Changing the post back to public makes it eligible again unless another exclusion applies.

Visibility is only one part of eligibility. A public post can still be absent if it is set to noindex, has a non-default manual canonical URL, or belongs to a content type excluded from search results. Yoast describes these and other reasons a page may be excluded.

What changes in the sitemap index

You change the post’s visibility setting and save it. WordPress stores the setting, then Yoast checks whether the post qualifies for the sitemap. Yoast adds or removes the post’s URL in the child sitemap for that content type.

The sitemap index links to child sitemaps, which list individual post URLs. If other eligible posts remain, the posts sitemap stays in the index when one post becomes private or password-protected. The index changes only when a child sitemap no longer qualifies for inclusion, such as when its content type has no valid entries left.

This single-post change differs from excluding an entire post type in Yoast. When you remove a post type from search results in Yoast settings, Yoast also removes that post type’s sitemap from the index, as its sitemap customization documentation describes.

How to verify the result

Save the visibility change before testing. Then open the Yoast sitemap index, normally available at /sitemap_index.xml, and follow the link to the child sitemap for the post’s content type. Yoast documents how to view its XML sitemaps and describes the index as a collection of individual sitemaps. Search the child sitemap’s XML for the post’s canonical URL.

First, confirm that an otherwise eligible public post appears in its child sitemap. Change it to private or password-protected, save it, and check the same sitemap again. The URL should be gone. Restore public visibility and check again. The URL should return if Yoast’s other settings still allow the post.

If the old URL remains, check the post’s noindex and canonical settings. Also check the content type’s search-results setting and any custom sitemap filters. Clear relevant caches in your plugin, with your hosting provider, or on the server. If the site uses a CDN or proxy, clear its cache too. Then reload the sitemap. Yoast lists caching as one reason sitemap output does not update. Its sitemap update troubleshooting guidance explains this issue. If the site uses a different sitemap URL, find out which plugin or file generates it before drawing conclusions about Yoast’s 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