Enterprise Search

WordPress VIP’s Enterprise Search can be enabled via code.

By default, Enterprise Search will not index every post type, taxonomy, or meta. You will need to identify and create “allow lists” for the custom post types, taxonomy, and post meta that should be indexed and made available for search.

Additional Enterprise Search features can be enabled, and Enterprise Search indexes can be re-indexed and versioned with VIP-CLI.

Learn more about rate limiting and optimizing Enterprise Search queries and caching, and how to investigate issues with Enterprise Search using Query Monitor or New Relic.

Index only what is necessary for searches

So what is needed to ensure the right things are indexed, but only the right things? Should we gather up all possible meta keys and post types and add them all to an allow list?

Why only index what is necessary?

Generally, indexing content that will not be used in searches, or post types that should not be searched, will be wasteful:

• additional time will be spent during modification events indexing the items
• if there are many of these items, versioning an index will take longer
• the items will occupy space in the index
• Possibly, search results will be polluted by content that wasn’t meant to be included

For example, there’s no need to reindex a post just because a particular post meta changed, if you’re not using that meta for searches. If you have a post meta for a custom post type that is only used to display information to users, that would not be something ever searched on, and your WordPress code can obtain and display it with standard post meta functions.

How the indexing decisions are made during code execution

The only taxonomy or meta that actually needs to be indexed in Elasticsearch, are those that are used as criteria in actual queries or searches, either in a WHERE clause or used for sorting. Those can be identified with allow lists, which in Enterprise Search are lists of which slugs should be indexed.

As posts, post meta, and post taxonomies are updated, the Enterprise Search code checks allow lists to determine which of these should be indexed. The post meta and taxonomies are configurable on a post by post basis. All we need to do is to ensure the appropriate items are in the allow lists.

Your codebase is the foundation from which we can review and discover what needs to be enabled for indexing to support this search use case.

Conduct an audit in code

A good starting approach would be to make an audit of any custom queries, or query modifications, in use. Identify in those queries the post type(s) and then the taxonomies and post meta that may be involved. In each of the more detailed How Tos that follow, we’ll demonstrate, with sample code, an approach that should help you pinpoint the desired indexing and also identify the queries so they can be explicitly tested after adding the necessary configurations.

Let’s say your site has a list of events. To manage this, you’ve created a custom post type of event, given these posts some standard meta such as event_duration, event_start_date, event_end_date, event_location and others, and an event format taxonomy that includes virtual and in_person event formats.

You’ve got a custom user interface to handle updating this content, and a custom, filterable, event search page which allows a user to find the in person events for a week when they’ll be in a particular city.

Depending on how you’ve organized your code, you may approach these allow lists in different ways. There are two basic approaches, either is appropriate:

Search Centralized

You’ve got one file specifically for search, as a must-use plugin, which defines each allow list. Whenever you make adjustments to search configurations, you do it here.

Feature Centralized

You’ve separated each feature, so all the code associated with events is in one directory, set of classes, or perhaps in a plugin. When you need to define indexing for the events, you do that in the code associated with the feature, where you’re already declaring the register_post_type and register_taxonomy for these.

In our examples, we show one or the other method depending on the context. The right method for you will depend on how you’re already organizing your code.