Are custom post types included in the WordPress sitemap?

The rule core applies

The sitemap asks WordPress for every post type whose public setting is true, removes attachment, and then keeps only those that are viewable, meaning they have front-end URLs. Each surviving type gets a sitemap listing its published entries.

So whether a type appears is decided by the plugin or theme that registered it, not by a WordPress setting. If you added the type yourself with code or a custom post type plugin, look for the Public option.

Taxonomies follow the same idea: every taxonomy that is public and viewable gets a file, and only terms with at least one published post are listed. An unused genre or brand term stays out until something is assigned to it.

Checking your own site

Open /wp-sitemap.xml in a browser. The index lists one or more files per type, named after the type's internal key:

/wp-sitemap-posts-post-1.xml
/wp-sitemap-posts-page-1.xml
/wp-sitemap-posts-recipe-1.xml
/wp-sitemap-taxonomies-cuisine-1.xml

If a type is missing:

• It has no published entries. Empty types produce no file.
• It is not public, or not publicly queryable. Check its registration.
• An SEO plugin has replaced the core sitemap. Then /wp-sitemap.xml is not the file to look at; open the plugin's index instead.
• The site is set to discourage search engines, which disables the core sitemap altogether.

If a type appears in the sitemap but its URLs return 404, the rewrite rules are stale. Re-saving permalinks fixes that.

When a type should not be listed

Automatic inclusion is convenient and sometimes wrong. Page builders, slider plugins, testimonial and FAQ plugins often register their items as public post types so that each has a preview address. Those single-item pages, one testimonial on a bare template for example, are thin, and listing hundreds of them in a sitemap invites Google to crawl pages you never meant anyone to visit.

Decide per type:

• Real content with its own pages (products, courses, case studies, events): keep it in the sitemap.
• Fragments shown inside other pages (testimonials, team members without profiles, FAQ items, sliders): take it out, and noindex the single views or disable them.

Core has no screen for this. Without a plugin, a developer removes a type with the wp_sitemaps_post_types filter:

add_filter( 'wp_sitemaps_post_types', function ( $types ) {
    unset( $types['testimonial'] );
    return $types;
} );

Removing a type from the sitemap does not stop it being indexed. The pages still exist and can be found through links, so pair the removal with a noindex or with making the type non-public.

Doing it without code

In Hydrogen SEO, the Robots screen has one row per public post type and taxonomy. Setting a type to noindex there also keeps it out of the plugin's sitemap, because the sitemap follows your indexing rules; the Sitemap screen has switches for each type as well. See robots meta settings and XML sitemaps.

That link between the two is what core lacks. The core sitemap has no knowledge of noindex tags added by a plugin or filter, so on a site that noindexes a type by code, the core sitemap keeps listing it. Search Console then shows submitted URLs excluded by a noindex tag, which is the two signals contradicting each other.

After any change, reload the index, confirm the file for that type has gone or returned, and check one URL of the type with URL Inspection.