Make a custom content type visible in WordPress search

Search for a known title to isolate the problem

A resource entry is published and opens at its URL, but internal search never offers it. First reproduce the discrepancy using a distinctive word in the entry's title. Choose a sufficiently rare word to recognize the result and check that it actually exists in the saved title. If the entry appears for this word but disappears when you search for a reference stored in a custom field, examine that field's indexing. If no title of this content type appears while ordinary posts do, continue here.

Open the entry and search in the same visitor session without an administration login. Record domain, subsite if needed, entry language, status, and page responding to search. A draft, private entry, or entry reserved for certain accounts requires another decision. Confirm with the person responsible that the entry and other content of the same type are intended to be publicly searchable. An entry visible to an administrator may respond differently for a visitor.

Compare two paths. Use the problematic search field, then the site's general search with the same term if available. On an installation using standard search, an address such as https://recette.example/?s=astere lets you compare this second path. Adapt it to your site and language. Some forms send users to a directory page or pass a type filter. If results differ, record both final URLs. You need to know which form produced the list you want to correct.

Record the type's key and effective parameters

Identify the content type's technical key. An interface may display “Resources” while the key is ressource. In the type's administration list, the post_type parameter may provide a clue. Confirm it with the person maintaining registration, whether in a plugin, theme, or configuration interface. A category or page-template name does not necessarily identify a content type.

If WP-CLI is already available on the copy, the maintainer can read the registered object with wp --path=/srv/recette/wordpress --url=https://recette.example post-type get ressource --fields=name,public,publicly_queryable,exclude_from_search,has_archive --format=json. Adapt path, URL, and key. In multisite, select the subsite owning the entries. The command shows registration after loading the site and plugins. Compare it with intended configuration. If the key does not exist or recorded fields differ, first check the selected site and version of the component registering the type.

Record parameters separately. public provides defaults to several options. publicly_queryable affects access through public queries. exclude_from_search determines, among other things, inclusion when a query requests searchable types with post_type set to any. has_archive concerns the type archive. An accessible archive and working direct link do not establish search inclusion. Likewise, making an entry appear in search does not require creating an archive. Keep a record of values before any change.

Approach 1. Correct the type registration

If exclude_from_search is true and the entire type is intended for public search, open its authoritative configuration. In a registration interface, locate the option excluding search results. Some screens instead present an inclusion checkbox. Read the label and help text before changing the value. Save on the copy and confirm, if possible with the previous command, that exclude_from_search is now false for this type alone. If registration is maintained in your project's PHP, adjust this argument in the versioned definition.

Leave access rules, archive settings, and other values at the site's intended level. A type may be deliberately excluded because it contains technical entries, internal records, or data published only in a particular context. If only part of the type should appear, ask the maintainer for a filter matching that scope. Enabling a general setting to find one entry may broaden the list to every entry of that type. On the copy, also choose an entry the public must not find and check that counterexample.

Check results with the reference title and an ordinary-post search. If the registered object shows the new value while the entry remains absent, keep evidence of the setting and move to the query or template. Depending on the site, search may be restricted to certain types after registration. An indexing plugin may also use its own allowed types and require rebuilding according to its options. First identify the mechanism actually used, then follow its existing workflow. Core native search requires no manual reindexing for this change.

Approach 2. Apply a targeted registration filter

This fragment is intended for a maintainer on an authorized copy when a component whose files should not be edited registers the type and diagnosis confirmed exclusion in registration. If your site plugin already has a rule here, edit that rule in the existing PHP file. If integrating this filter there, use the call and function within the PHP portion. The fragment header belongs to the dedicated plugin. Otherwise, place the complete fragment in wp-content/plugins/bpc-ressources-recherche/bpc-ressources-recherche.php. Replace the example key ressource with the confirmed one. Activate the plugin from the relevant staging site's Plugins screen. In a network, use this site's administration to limit testing to that subsite.

The filter must be registered before the type. It particularly suits types registered later during init. If another component registers the type earlier, have its maintainer check loading order and verify the effective value after activation. The fragment requires the type to be registered as public and publicly queryable. It accounts for the value inherited from public when publicly_queryable is absent or null. If a later filter or type-specific filter redefines exclusion, reading the loaded object should reveal the discrepancy. The change affects only exclude_from_search. Nevertheless, test as a visitor and check entries your site reserves for certain accounts. Effective access may depend on other rules.

After activation on the copy, reread the type and repeat the control search. If registration changed but another search based on any also shows entries, assess that consequence before retaining the filter. The change affects the type across the site and may touch other lists relying on the same searchable types. If you want to correct only a specific directory, act on that directory's query. To undo testing, deactivate the dedicated plugin or restore the existing rule's previous version.

<?php
/**
 * Plugin Name: BPC Ressources dans la recherche
 */

defined('ABSPATH') || exit;

add_filter('register_post_type_args', static function (array $args, string $post_type): array {
    $public = $args['public'] ?? false;
    $queryable = $args['publicly_queryable'] ?? $public;

    if ('ressource' === $post_type && $public && $queryable) {
        $args['exclude_from_search'] = false;
    }

    return $args;
}, 10, 2);

Approach 3. Adjust the query or results template

If registration includes the type, compare form parameters with the query producing the page. A query specifying an explicit type list may continue selecting only posts even if Resources are searchable in a general query. Look for a filter in the form, theme search code, or directory plugin. Edit the existing list on the copy if it should now include Resources. Preserve previously intended types and check other filters, particularly language and terms.

With a block theme, open Appearance > Editor > Templates and find the results template if permitted. Select the Query Loop displaying the main list. In versions exposing query type, Default mode inherits the template query. A custom loop may apply its own type, filters, and order unrelated to the search term. On the copy, adjust only the loop intended to represent search results. Keep a separate loop for suggested content if the template has one.

With a classic theme or search plugin, ask the maintainer to identify whether the main query is modified or the template launches a secondary query. If a pre_get_posts rule changes scope, examine its conditions. In a classic flow, the maintainer can target the main public search query by checking administration context and methods on the received instance. A directory form, AJAX query, or indexing engine may follow another route. Correct the layer actually producing the list and leave the rest of the site outside testing.

Follow variants that change the diagnosis

If a post and entry contain the same term but only the entry disappears, first check that the form includes its type and permits its status. Compare a working entry of the same type if available. If only one entry is missing, record language, publication state, directory filters, and possible placement on another results page. If no title appears for the type, recheck registration parameters and the type list before editing entry text.

If entries appear in standard search but are missing from a specialized form, focus on directory options. Record the expected type and reproduce the test without a category or language filter only where the copy allows it. Add filters one by one to see which excludes the control. After finding the correct scope, restore necessary filters. Preserve the WordPress definition if already correct. If the directory is designed for a particular category, also check one control with that category and another without it. The form must continue separating both cases after correction.

If results contain the entry but the card links elsewhere or displays no title, open the card template and check its connection to the current post. If the list itself is empty, also check the template before concluding exclusion. To distinguish query from rendering, keep a search returning at least one ordinary post. A template failing for every type points toward presentation. A template rendering posts but not Resources justifies comparing type filters and card behavior for a Resource.

Verify results with controls that must remain distinct

On your authorized copy, prepare a public Resource titled “Astrolune – ressource témoin” and an ordinary post titled “Astrolune – article témoin”. Add a draft and private Resource entry containing the same word. If your site has another deliberately excluded type, also prepare a public “Astrolune – type exclu” entry of that type. Record IDs, statuses, and links. From a visitor session, search for “Astrolune” before changing anything and open the public Resource directly. A direct link and presence in results are separate observations.

Make a single change and search for “Astrolune” through the initial form. Compare with general search if both paths differ. In a search intended to cover Resources and posts, the public Resource should join the ordinary post. Check that neither the draft, private entry, nor excluded type appears in this list. Open the Resource result and check that it leads to the correct ID. Also check pagination, if present, and the language filter using a control that must remain out of scope.

Record the test visitor's role, form used, and useful result count. Compare a no-results search to ensure the template retains its usual behavior. Also check an ordinary site list using the same entries. A test restoring a type to search but exposing unexpected content elsewhere requires narrowing scope before going live.

Return to the initial setting if scope expands too far

If unintended entries appear or ordinary results disappear, reverse the change actually made. Restore the exclusion option in the definition if you changed registration, disable the dedicated filter if you added the staging plugin, or restore the previous type list if the form was limited by its query. If you edited a template, restore the targeted loop's configuration. Check search and affected lists after rollback. If you restored a plugin filter, use the read command to check that the loaded value matches the initial record. A setting displayed on one screen may still be overridden by a rule maintained elsewhere.

Keep records of the starting and retained states. Identify the type key, layer deciding scope, language, and form tested. Also specify types and statuses that must remain absent from visitor results. After a theme, plugin, or form change, the team can find the correct layer from the reference title and verify direct link, result, and counterexamples in the same session.

Targeted example for a main search limited to posts

This example concerns only a native search confirmed to include posts, pages, and public entries of type ressource. It fixes neither AJAX search nor an external engine's index. Prefer editing the existing rule imposing post_type over stacking two competing rules. In a site plugin already intended for your customizations, use this filter after checking that the type is public and searchable.

Adapt this list to types actually authorized on your site: it replaces this search's scope and must not remove an already necessary type. The code does not change statuses or access rules. Test the reference title as a visitor, an ordinary page, pagination, a draft, and a private entry. To undo it, remove only this rule or restore the previous definition. If another filter later redefines the list, correct its source instead of arbitrarily increasing priorities.

add_action('pre_get_posts', static function ($query) {
    if (is_admin() || !$query->is_main_query() || !$query->is_search()) {
        return;
    }
    $type = get_post_type_object('ressource');
    if (!$type || !$type->publicly_queryable || $type->exclude_from_search) {
        return;
    }
    $query->set('post_type', array('post', 'page', 'ressource'));
});