Hiding post types from search: the exclude_from_search policy

From 5.52, Super Speedy Search honours the standard WordPress exclude_from_search flag plugin-wide. Post types registered with exclude_from_search => true no longer appear as options anywhere in the SSS admin UI or in search results. This article explains what changed, where you’ll notice it, and how to re-expose a specific CPT if you intentionally want it surfaced.

What exclude_from_search means

When a post type is registered with WordPress via register_post_type, one of the arguments is exclude_from_search. Setting it to true tells WP “this post type shouldn’t appear in front-end search results”. The flag is part of the post type’s contract – the author of the post type (a plugin or theme) is explicitly opting it out of search.

Examples of post types that commonly set this flag:

• attachment (media items)
• revision
• WooCommerce internal types (shop_order, product_variation in some contexts)
• Many page-builder “template part” types
• Many plugin-internal CPTs that store config or relationships rather than user-facing content

Before 5.52, SSS offered all public post types in its admin UI regardless of this flag, so an admin could (often accidentally) wire one of these internal types into the search results.

What changed in 5.52

Post types with exclude_from_search => true are no longer offered as options in:

• Weights tab – no per-post-type weights block for excluded types
• Suggestions tab – post-types picker for token-based suggestions
• Suggestions tab – Taxonomy Suggestions Post Type dropdown
• Ajax Search tab – ajax post types list
• Front-end tab – Default Post Type dropdown
• Front-end tab – Multi-search Overrule post types tick list
• Front-end tab – Mixed Sections “Add section” dropdown
• Widgets – Super Speedy Search widget admin form
• Gutenberg block – the Search Block’s post-types picker

Excluded post types are also dropped from the searchable set at query time, so even if a stale setting from a pre-5.52 install referenced one, it would not contribute results.

Side effect on upgrade

If your site previously had an exclude_from_search CPT configured anywhere (e.g. in the Ajax tab), it will:

• Disappear from the admin UI on upgrade – you can’t see it or untick it.
• Remain present in the stored sss_options value – SSS does not delete saved settings.

This is intentional. If you later expose the CPT via the filter below, the saved settings reactivate without you needing to retick everything.

Re-exposing a specific CPT to SSS

If a CPT is flagged exclude_from_search => true but you intentionally want users to search it via SSS, you can re-expose it via the existing sss_post_types_args filter. This is the same filter SSS has always used to fetch the post type list – it just now defaults to exclude_from_search => false in the arguments.

Drop this into your theme’s functions.php or a small must-use plugin:

add_filter('sss_post_types_args', function($args) {
    // Allow CPTs marked exclude_from_search through.
    unset($args['exclude_from_search']);
    return $args;
});

That returns the pre-5.52 behaviour for all post types. To re-expose only a specific CPT, use the more targeted sss_post_types filter, which gets the resolved list:

add_filter('sss_post_types', function($list) {
    $extra = get_post_type_object('my-internal-cpt');
    if ($extra) {
        // $list is an array of objects keyed by slug when returned as 'objects',
        // or an array of slugs when returned as 'names'. Both call paths exist.
        if (is_object(reset($list)) || empty($list)) {
            $list['my-internal-cpt'] = $extra;
        } else {
            $list[] = 'my-internal-cpt';
        }
    }
    return $list;
});

After adding the filter:

1. Reload the SSS admin – the CPT appears in the pickers again.
2. Re-tick it in whichever tabs apply (it may already be ticked from the preserved pre-upgrade settings).
3. Run a rebuild – wp sss rebuild or the Rebuild button on the Advanced tab – to index the CPT’s posts into the SSS search table.

When you should re-expose a CPT

Most of the time you shouldn’t – the CPT author had a reason for setting the flag. Re-expose only when:

• The CPT was flagged exclude_from_search by a third-party plugin/theme but contains content your users legitimately want to find.
• You’re migrating from an older plugin that didn’t respect the flag and your users have grown to expect this CPT in their search results.
• You’re using SSS to search internal content (e.g. a member-only document archive in a CPT that’s hidden from public search but should be findable by logged-in users – pair this with a pre_get_posts filter that restricts the visibility appropriately).

When you should not re-expose

Don’t re-expose if:

• The CPT stores configuration, relationships, or template fragments rather than user-facing content (e.g. shop_order, product_variation, a custom “Slider” CPT, a “Form Submission” CPT).
• The CPT is media – attachment results are searchable by GUID (filename) by default in SSS via the GUID FULLTEXT index, and exposing the full attachment post type clutters the search with thumbnails and PDF descriptions you probably don’t want.

Tips

• The filter runs every time SSS resolves the post type list, including in the admin. There’s no rebuild needed to make a freshly re-exposed CPT visible in the UI – but you’ll need a rebuild before its posts appear in search results.
• The sss_post_types_args filter accepts the standard get_post_types arguments – see the WordPress reference for the full list. Most sites only need to unset exclude_from_search.
• If you ever need to hide a normally-public CPT from SSS (the opposite use case), filter on sss_post_types to remove it from the resolved list.

Further reading

Related products

Super Speedy SearchSpeeds up front-end and wp-admin search