Faster editorial search with the WordPress REST API

A client of mine had around 15,000 articles built up over a decade. Their editorial team knew that archive well, and they were still losing hours every week to it. Every internal link meant opening the live site, waiting for the ads and Jetpack’s search to load, finding the post, then copying the URL by hand. One lookup is a small thing. Repeated all day, it had become the slowest part of their process.

My first idea was a custom dashboard widget with a quick PHP search behind it. Wrong call. All it did was put more load on an already stressed database every time an editor refreshed the dashboard. I had optimized the wrong layer. The fix was not on the site at all. It was in how we got at the data, through the WordPress REST API search.

Search that never loads the site

What changed my mind was noticing that the editors never needed to be on the site to find a post. A recent write-up over at css tricks makes the same point. They cover a Raycast extension that queries a site’s content straight from your own machine. The query never touches the browser, so nothing has to render before you get an answer.

The REST API hands you raw data instead of a rendered page, so you can format it wherever you like: Alfred, Raycast, a shell script. It is much quicker than the front end because none of the DOM, the scripts or the styles get loaded. All you wanted was a title and a URL.

Building a clean REST query

To build a tool that hits your site without the overhead, you mainly need to know the endpoint structure, and WordPress ships that out of the box. There is nothing to reinvent. Keep the lookup logic separate from whatever search engine powers the front end and it keeps working as the archive grows.

function bbioon_fetch_remote_content( $query ) {
    $api_url = 'https://your-site.com/wp-json/wp/v2/posts?search=' . urlencode( $query ) . '&_fields=title,link,excerpt';

    $response = wp_remote_get( $api_url );

    if ( is_wp_error( $response ) ) {
        return [];
    }

    $posts = json_decode( wp_remote_retrieve_body( $response ) );

    return $posts;
}

The part to notice is the _fields parameter. Without it, the API returns every piece of metadata attached to a post, which is a lot of JSON. With it, you name the three fields you actually want and the payload shrinks to match. That is the difference between a two second lag and an instant result.

What this does for performance

Most search setups are “Pretty OK,” and OK stops being enough once you are running a high-traffic site with a decade of archive behind it. Moving the lookup out of the browser and into a local utility or a single API call helps the editors, and it saves server resources too. You are no longer spinning up a full WordPress instance to match one string.

This kind of thing gets complicated fast. If you are tired of debugging someone else’s code and you just want your site to work, drop my team a line. We have probably seen it before.

The short version

• Do not send editors through the front end for an internal lookup.
• Use the _fields parameter so your REST API responses stay small.
• A local extension like Raycast takes the lookup out of the browser entirely.

Ahmad Wael

I'm a WordPress and WooCommerce developer with 15+ years of experience building custom e-commerce solutions and plugins. I specialize in PHP development, following WordPress coding standards to deliver clean, maintainable code. Currently, I'm exploring AI and e-commerce by building multi-agent systems and SaaS products that integrate technologies like Google Gemini API with WordPress platforms, approaching every project with a commitment to performance, security, and exceptional user experience.

See Full Bio

WordPress WooCommerce PHP AI integrations Javascript Linux Docker