Choose what to index

By default, Enterprise Search will not index every post type, taxonomy, or meta. Indexing unnecessary content can result in:

• Additional time required for modification events or versioning during indexing.
• Unnecessary items occupying space in the index.
• Search results polluted by less relevant content.

The taxonomy, meta, and post types that are indexed should be selected based on the criteria of a site’s actual queries or searches (e.g., those used in a WHERE clause or used for sorting).

Objects indexed by default

All of the public post types, statuses and their public taxonomy terms will be indexed. Post meta is not indexed and will need to be explicitly defined.

To enable indexing of all post types and statuses (including private ones), the “Protected content” feature must be activated.

Allow lists

An allow list must be identified and created separately for the below items that should be indexed and made available for search:

• post types
• post statuses
• taxonomies
• post meta

It’s important to be consistent for each allow list, but also to be aware of the format differences between the allow lists.

Indexables

An indexable is a type of database resource in WordPress, which uses a related class (e.g. WP_Query) and has a separate Enterprise Search index. Indexables enable indexing, search, and queries on any queryable object in WordPress. Not all indexables are supported, or enabled by default.

• Posts: Supports WP_Query and indexed by default.
• Terms: Supports WP_Term_Query and must be enabled.
• Users: Supports WP_User_Query and must be enabled.

Identifying what should be indexed

Begin by auditing any custom queries or query modifications that already exist in a codebase and identify in those queries the post type(s), the taxonomies, and post meta that may be involved.

For example, there is a custom user interface that handles updating content and a custom, filterable, event search page that allows the user to find events for a week when they’ll be in a particular city. Depending on how the code has been organized, the allow lists can be developed in two different ways:

1. Search Centralized: Use one file specifically for search, as a must-use plugin, which defines each allow list. It is used for making adjustments to search configurations.

2. Feature Centralized: Separate each feature, so that all of the code associated with events is in one directory, set of classes, or a plugin. The indexing for the events will be defined in the code associated with the feature, where the register_post_type and register_taxonomy is already declared for these.