WordPress Custom Post Types and SEO: What Needs Manual Configuration

A recurring support ticket I see at Rank Math goes like this: “I created a custom post type, published a bunch of entries, and none of them show up in my sitemap or get indexed.” Nine times out of ten, nothing is broken. WordPress core did exactly what it was told to do, which is less than most site owners assume.

WordPress Core Doesn’t SEO-Optimize Custom Post Types for You

Registering a custom post type is a handful of arguments passed to register_post_type(): public, publicly_queryable, show_ui, show_in_nav_menus, has_archive, rewrite, and — critically for the block editor and REST API — show_in_rest. None of those arguments touch sitemaps, meta titles, schema markup, or search indexing decisions. They control whether the post type shows up in the WordPress admin, whether it gets a front-end URL at all, and whether it’s queryable — that’s it. Everything an SEO plugin does with a post type is a separate, deliberate layer on top of that registration, not something WordPress core hands you automatically.

What SEO Plugins Actually Need to Be Told

For every custom post type on a site, someone has to explicitly configure, per plugin:

• Whether it’s included in the XML sitemap at all — this is opt-in per post type in both Rank Math and Yoast, not automatic.
• A title and meta description template for that post type, since the generic site-wide default rarely fits a portfolio item, product, or event listing well.
• A schema type assignment — custom post types don’t inherit Article or Product schema automatically; without configuration they typically get no structured data, or a generic type that undersells what the content actually is.
• Robots directives for the archive page the post type generates, if has_archive is enabled — that archive is often thin and may need its own indexing decision.
• Canonical handling, if the same content is also queryable through a custom template, shortcode, or secondary taxonomy structure elsewhere on the site.

The show_in_rest Trap

A specific version of this ticket I see often: a developer registers a custom post type and forgets show_in_rest => true. Without it, the block editor won’t load for that post type at all, and because most modern SEO plugin panels — the content analysis, the snippet preview, the schema settings — hook into the block editor through the REST API, those panels quietly don’t appear either. The post type looks broken in the SEO plugin when the actual gap is one missing boolean in the original registration code.

Archive Pages Are Their Own Problem

Setting has_archive to true gives WordPress a listing page for that post type, generated automatically, with no content of its own beyond the loop of entries. That page needs the same decisions any archive or category page needs: does it deserve a real title and description, should it be indexed at all if it’s thin, and what happens once it paginates into low-value later pages. Left unconfigured, it’s usually indexed by default with no meaningful on-page content — exactly the kind of thin page that quality systems don’t reward.

A custom post type is WordPress core telling you “I’ll structure this data for you” — it says nothing about whether that data should be indexed, how it should be titled, or what schema it should carry. Every one of those decisions is manual, and skipping them is the single most common reason a CPT-heavy site underperforms relative to its regular post content.

Treat every new custom post type as its own small onboarding checklist — sitemap inclusion, meta template, schema type, archive indexing decision, canonical check — rather than assuming your SEO plugin’s defaults will catch it. They won’t, because there isn’t a sensible universal default for content WordPress itself doesn’t know the meaning of.