Don't deactivae sitemaps for private sites

[knutsp]

Description

When the WordPress option to discourage search engines to index the site is ticked, wp-sitemaps deactivates sitemaps completely.

Sitemaps should still be active for testing and inspection. Sites not in production typically are "private" to avid early indexing a test/staging site. This does not remove he need to see what's being put into sitemaps, especially in case of many CPT's. Some themes/plugins create a lot of CPT's as "public", like templates and more internal things. Even if this is wrong, this need to be filtered out from sitemaps before procuction.

Sitemaps is really just another way of presenting links to content, as HTML archives, RSS and Atom feeds and the API's. Google even treats feeds as partial sitemaps. If you submit a feed or a sitemap (index) to Google you will receive feedback that the links lead to noindexed pages, not forcing indexing.

When site is "private" , there should be no link to it in robots.txt, otherwise work as normal. Sitemaps MAY also be consumed by other parties that search engines, for whatever purpose.

Those who don't need/want sitemaps, or want to modify the content, should filter it. To check the sitemap of plain WordPress, temporarily private, should be as simple as pointing the browser to it.

This also removes the need to inform the user that sitemaps are deactivated (in dashboard and reading options), in case "private".

See https://core.trac.wordpress.org/ticket/50400#comment:16

[swissspidy]

We had some discussions on Slack about this:

https://wordpress.slack.com/archives/CTKTGNJJW/p1592319614495500

[pbiron]

Sitemaps should still be active for testing and inspection. Sites not in production typically are "private" to avid early indexing a test/staging site. This does not remove he need to see what's being put into sitemaps, especially in case of many CPT's. Some themes/plugins create a lot of CPT's as "public", like templates and more internal things. Even if this is wrong, this need to be filtered out from sitemaps before procuction.

I hear you here. I've several times discovered CPTs and custom taxonomies that were incorrectly public only by seeing them in a sitemap (in both my own plugins and those written by others).

But as mentioned in the Slack discussion referenced above, I think the current behavior of disabling sitemaps when get_option( 'blog_public' ) is false is right thing to do...and that a simple 1 line plugin can be used for the kind of testing you describe:

add_filter( 'wp_sitemaps_is_enabled', '__return_true' );

[knutsp]

Since sitemaps are not submitted to search enhines just because they exist, this is the wrong way, as it would be wrong if feeds was also disabled, not to mention ant html output. I don't see other relevant differences than format (and intended purpose).

Filters are fine, but not to make WordPress do the correct thing.

In this case we are being to "nanny", We are also mixing two things that should mostly be unrelated at this level.

One cant deduce out of principle, which you normally can, that sitemaps are available regardless of private site setting. "Oh, the team that made this feature decided opposite than established philosophy -- so we have to filter this -- but not that." Logic is broken, harder to teach WordPrsss -- and learn -- inconsistencies.

It may sound grumpy, but the next team, like making a JSON feed, may decide to disable that in case X (debug/staging/private/singleuser/havecpts/whatever) and things get gradually worse.