Skip to main content

WordPress Hosting & Operations

High-speed on-site search with OpenSearch

Last updated Thu, Jul 9, 2026

Watch someone use your site search. They type "parking permit", wait three seconds, and get a news story from 2019, a board agenda PDF, and nothing about buying a permit. So they go back to Google and search your site from there. Built-in search in WordPress and Drupal is fine for a small site. Once you have tens of thousands of pages, documents, and events, it becomes slow and blunt at the same time. A dedicated search engine fixes both problems.

Why built-in search struggles

  • WordPress search runs a database query that looks for the words anywhere in titles and content. It cannot use an index for that kind of match, so it scans more rows as the site grows, and it ranks results mostly by date rather than relevance.
  • Drupal core search builds its own index in database tables. It is better than a raw scan, but relevance tuning is limited and the database carries the load.
  • Both struggle with typos, plurals, synonyms, and filters such as "only show forms from Public Works", which are exactly the things visitors expect from search today.

What OpenSearch changes

OpenSearch is an open-source search engine built for this job. Content is copied into an index designed for searching, so queries are answered from that index rather than the website's database. The practical differences:

CapabilityBuilt-in searchOpenSearch
Speed on large sitesSecondsTypically under 100 milliseconds
Relevance rankingBasicTunable, with boosts for titles, content types, recency
Typos and word formsExact words onlyFuzzy matching, stemming ("permits" finds "permit")
SynonymsNoYes ("DMV" finds "motor vehicles")
Filters and facetsLimitedBy department, type, date, tags, and more
DocumentsUsually not searchedPDF and Office file contents can be indexed
Database loadEvery search hits itNone

How the integration works

  1. Design the index around your content model: which post types or content types are searchable, which fields matter most, and which taxonomies become filters.
  2. Index in real time. When an editor publishes, updates, or unpublishes content, the change is sent to the index within moments. On WordPress this is done by an indexing plugin; on Drupal by the Search API module with an OpenSearch or Solr backend.
  3. Replace the search page so queries go to OpenSearch and results render in your theme, with facets and suggestions.
  4. Keep a full reindex procedure for schema changes, run in the background so search keeps working during it.

Tuning results people want

Speed is the easy part. Relevance takes attention:

  • Read the search logs. The most common queries and the queries with zero results tell you what people want and cannot find.
  • Add synonyms for the words residents and students actually use versus the words your departments use.
  • Boost what matters. Service pages above news, current content above archived, titles above body text.
  • Pin best bets for high-volume queries, such as sending "jobs" straight to the careers page.
  • Review quarterly. Language, services, and seasons change.

Keeping search healthy

A search index can silently fall behind if indexing fails. Monitor index freshness (how recently the newest content was indexed), indexing errors, query response time, and cluster health. Stale search results are one of the first things visitors notice and one of the last things teams check.

Before you start

  • Pull your current search logs, if you have them, to see what people search for most.
  • Decide which content should be searchable, and what should never appear, such as drafts, private files, or archived pages.
  • List the filters people would find useful, such as department, content type, or date.
  • Agree who owns relevance tuning after launch. Search improves most when someone looks at it regularly.

Remember access, too. If some content is restricted to signed-in users, the search index must respect the same rules, so a public search never reveals the title or summary of a private page.

How eWay runs search

eWay provisions and operates a managed OpenSearch cluster on AWS or Azure, designs the index schema around your content model, builds the real-time indexing pipeline, and integrates results into your front end. For Drupal, eWay also operates Solr and Elasticsearch where they are the better fit. eWay monitors index freshness, indexing failures, and query latency, and handles upgrades and reindexing. Most sites move from multi-second searches to under 100 milliseconds.

What to include in a support ticket

  • The severity you would assign, P1 to P4 (see severity levels and response times)
  • Example searches that return poor or missing results, and what you expected
  • Whether recently published content is missing from search

eWay customers can open a ticket in the support portal or email support@ewaycorp.com at any time. See how to request support for all the options. Related reading: enterprise search and content scale on Drupal and database performance and read replicas. More on our WordPress and Drupal pages.

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article

Platform Notes

Get practical WebOps and cloud insights in your inbox

We publish articles on managed operations, cloud infrastructure, CMS platforms, government technology, and security, written by engineers who operate these environments every day. No marketing fluff. Unsubscribe any time.

We respect your privacy. No spam, no third-party sharing. Unsubscribe any time.