Title: Rate limiting in Enterprise Search
Author: WordPress VIP Documentation
Published: March 10, 2021
Last modified: May 26, 2025

---

 1. [Enterprise Search](https://docs.wpvip.com/enterprise-search/)
 2. Rate limiting in Enterprise Search

#  Rate limiting in Enterprise Search

Rate limiting is a measure put in place to protect a site’s search services from
spikes in requests that can cause instability. Rate limiting is likely to occur 
if many pages are making the same queries directly to Elasticsearch (ES) rather 
than making use of caching.

When Elasticsearch queries are rate limited, a portion of the requests will go to
the database instead. Depending on the type of queries and the volume of queries
made, they could overload the primary database and lead to an increase in responses
with a `503` HTTP status code.

In addition to Elasticsearch queries, rate limiting can also be applied to the indexing
process.

## Determine if rate limiting is in effect

Two methods are available to determine if rate limiting is in effect for a site.
These methods will also indicate if rate limiting is in effect for `search` or `
indexing`:

 * **WordPress Admin toolbar:** Refer to the [Enterprise Search Dev Tools](https://docs.wpvip.com/enterprise-search/dev-tools/#h-search-status-area)
   panel.
 * **VIP-CLI:** Run the command: `wp vip-search health rate-limits`.

## Prevent rate limiting

A site’s normal peak traffic load should be less than the per-application default
rate limit for Enterprise Search. If a site is being rate limited, it indicates 
that the queries being made to Elasticsearch need to be reduced in number and optimized.

 1. Review opportunities to reduce the **frequency** of the queries. Ensure that each
    page is being [cached in page cache at the edge](https://docs.wpvip.com/caching/page-cache/),
    or normalization and object caching of the search results themselves.
 2. Implement caching layers. Use the WordPress [object cache](https://docs.wpvip.com/caching/object-cache/)
    to store successful results for a period of time, and use those instead of making
    repeated requests to Enterprise Search.

## WP_Query cache

Because [WP_Query works with object cache](https://docs.wpvip.com/caching/query-cache/)
to cache the results of each query, and Enterprise Search is intercepting just the
MySQL portion, repeated queries within a short period of time should be hitting 
Memcached rather than Elasticsearch. This is normal, supports scaling, and avoids
repeated Elasticsearch calls that trigger rate limiting.

Query parameters that are constantly changing—especially date or time parameters—
result in excess resource use, contribute to poor site performance, and can trigger
rate limits. Because query parameters are combined together in a hash to access 
the cache, changing times will miss the cache and result in a new query every time.
Use [Enterprise Search Dev Tools](https://docs.wpvip.com/enterprise-search/dev-tools/)
to determine which parameters are being sent to Elasticsearch, and if they are constantly
changing.

Last updated: May 26, 2025