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.
An allow list must be identified and created separately for the below items that should be indexed and made available for search:
It’s important to be consistent for each allow list, but also to be aware of the format differences between the allow lists.
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_Queryand indexed by default.
- Terms: Supports
WP_Term_Queryand must be enabled.
- Users: Supports
WP_User_Queryand 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:
- 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.
- 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_taxonomyis already declared for these.
Last updated: April 03, 2023