Resources

How to Build an Intelligent Search Widget for a Government WordPress Site (Without Plugins)

When someone visits a government website, they usually have a very specific need. They want to renew a vehicle registration, find a property tax record, or look up a marriage license. They are not browsing. Every extra second they spend searching for the right page is a second of frustration — and a small failure of the site to do its job.

At Exemplifi, we recently tackled this problem for the Fayette County Clerk's office in Kentucky (fayettekyclerk.gov). The brief was straightforward: make it significantly easier for residents to find what they are looking for. What we built — an advanced search widget with intelligent keyword routing — became a case study in how content strategy, front-end engineering, and a clear understanding of user intent come together to create something genuinely useful.

Why Default WordPress Search Fails Government Websites — And What to Do Instead

Most WordPress sites ship with a default search function that queries post titles and body content. For a content-heavy government site, this is nearly useless. A resident searching for "pay my taxes" might get a blog post from three years ago instead of the property tax payment portal. Relevance is not guaranteed, and the path to the right page is often buried.

The solution is not always a more powerful search engine. Sometimes it is a smarter one — a system built around the actual words real users type, mapped directly to the right destinations.

How to Identify High-Intent Search Keywords for a Government Website Using Google Analytics

Before a single line of code was written, the content team at Exemplifi started with Google Analytics. The goal was to understand what residents were actually searching for, not what the county assumed they were searching for.

What emerged from that research was a list of high-intent keywords — terms like "property tax appeal," "land records," "register a vehicle," "renew tags," and "marriage license." These were not guesses. They were drawn directly from real search behavior on the site and in Google, representing the language residents genuinely use.

Identifying the right keywords, however, was more complex than it sounds. The raw data was full of overlapping terms, near-duplicates, and variations that all pointed to the same destination. The content team had to clean, prioritize, and deduplicate that list down to a set of terms that were both distinct and comprehensive. This process required close coordination with the development team to understand how the widget would function — because the way a keyword is written affects how the filter matches and surfaces it.

For each keyword, the content team also wrote the supporting copy: a short CTA (like "Register a Vehicle") and a brief descriptor (like "Renew your tags and vehicle registration"). Every word had to earn its place. CTAs were kept to four words or fewer. Descriptions were tight and precise. This is not cosmetic work — it directly determines whether a user recognizes what they are looking at and clicks.

Popular searches — the terms displayed by default before a user types anything — were selected based on search volume and represent the most common resident needs. These defaults matter enormously because they are the first thing a visitor sees when they engage with the search widget.

How to Build a Custom Vanilla JavaScript Search Widget for WordPress: Architecture and Logic

Once the keyword list and content were in place, the front-end team built the search widget from scratch as a custom vanilla JavaScript class called SearchInterface — a deliberate choice over relying on a plugin or third-party library. Keeping it dependency-free meant faster load times, no risk of plugin conflicts in WordPress, and full control over every behaviour. Depending on the requirements, we can also utilize a third-party plugin like Relevanssi for the search widget, trading better functionality for a simpler setup.

The internal logic follows a clean three-step flow:

User Input → performSearch() → fetchSearchResults() → displayResults()

As a user types, performSearch() hands the query to fetchSearchResults(), which filters the keyword dataset in real time using case-insensitive matching against both the keyword phrase and its subtext. This means a user who types "renew" can surface results tagged to vehicle registration or marriage license — because both have "renew" in their supporting description. The matched results are then passed to displayResults(), which renders them as anchor links inside a dropdown overlay that appears directly beneath the search input.

The data powering this sits in two intentionally separate structures. Search results use:

javascript

{ phrase, subtext, url }

Popular searches — the defaults shown before a user types — use a simpler format:

javascript

{ text, url }

This distinction is not just technical tidiness. It is why the content team had to write two different kinds of copy: rich, searchable keyword entries with CTAs and descriptions for the results layer, and shorter, scannable labels for the popular searches layer. The data model and the content strategy are directly connected.

The widget also handles a set of interaction details that are easy to overlook but make a significant difference in everyday use. Full keyboard navigation for better web accessibility is built in — arrow keys move through results, Enter selects or submits, and Escape closes the dropdown and returns focus. ARIA roles, labels, and aria-selected attributes are applied throughout, making the widget usable with screen readers without any additional effort from the site editor. A clear button appears when the input has content, allowing a one-click reset. Click-outside detection closes the dropdown when a user moves away, and a carefully timed blur delay ensures the dropdown stays open long enough for a mouse click on a result to register — a small but important detail that prevents the dropdown from vanishing before the user's click completes.

State is managed internally across four tracked values: lastQuery and lastResults cache the most recent search so the dropdown can be restored accurately when a user refocuses the input; selectedIndex tracks which result is currently highlighted during keyboard navigation; and the clear button's visibility is toggled based on whether the input is empty. None of this requires a framework or a state management library — it is clean, readable JavaScript that any developer can maintain.

One architectural decision worth noting: early in the project, an AI-powered API was evaluated to handle search dynamically. After assessment, the team chose a curated static keyword list instead. For a government site where accuracy and reliability are non-negotiable, a handcrafted, editable dataset offers more control, faster performance, and no dependency on an external service. The AI layer adds value when the vocabulary is too large to manage manually — at this scale, intentional curation produced better results.

Why Keyword-Routed Search Widgets Perform Better in AI-Powered Search and LLM Responses

Advanced search widgets like this one have renewed relevance in the current landscape, where AI assistants and large language models are increasingly involved in how people find information. There are a few specific reasons this architecture is well-suited to that environment.

Structured, predictable content surfaces better in AI-generated responses. When an LLM or a search engine's AI overview tries to answer a question like "how do I renew my vehicle registration in Fayette County," it looks for clear, well-labeled pages with a specific, actionable answer. A keyword-routed search widget points users to exactly those pages — and the discipline applied to CTAs and descriptions on the site feeds the same clarity that AI systems reward.

Overlay-based search patterns reduce crawl ambiguity. Because the search widget renders results in a dropdown overlay rather than a separate search results page, it does not create a sprawl of low-quality, dynamically generated URLs that search engines may index redundantly. The destination pages — the ones the keywords link to — are clean, purposeful, and individually optimized.

Citation optimization starts with findability. For AI tools to cite a page in a response, that page needs to be discoverable, authoritative, and clearly relevant to a specific query. The keyword-to-URL mapping in this widget is essentially a human-curated version of what AI systems try to infer algorithmically. Building it explicitly gives the site a structural advantage.

The Content and Development Workflow for Building a Government Site Search Widget

For teams considering something similar, the project broke down into roughly this sequence:

The content team began by pulling search data from Google Analytics to identify high-frequency, high-intent search terms. They deduplicated and categorized these, then wrote CTAs and short descriptions for each. They also defined the default "popular searches" — the five or so terms shown before a user types anything.

The development team mapped each keyword to its destination URL and built the JavaScript widget to handle real-time filtering, keyboard navigation, accessibility, and graceful no-results fallback. The widget was implemented in WordPress without a plugin dependency, keeping the codebase clean and maintainable.

The two teams worked in parallel rather than in sequence, with the content team needing to understand widget behavior to write appropriate copy, and the development team needing finalized keyword data to configure the filter logic correctly. The coordination between these workstreams is where projects like this tend to succeed or struggle — and getting it right is as much a project management challenge as a technical one.

What a Well-Built WordPress Search Widget Delivers for Government Website Users

The Fayette County Clerk site now offers residents a search experience that works the way they think, not the way the site is organized. A resident who types "property tax" sees relevant options immediately. One who clicks into the search bar without typing anything sees the five most common tasks front and center. One who searches for something the widget doesn't recognize is still shown useful default options rather than an empty state.

For a government audience that skews toward residents who may not be comfortable navigating complex websites, this kind of search experience is not a nice-to-have. It is a meaningful reduction in friction for people trying to complete real civic tasks.

The same approach applies equally well outside government. Any content-heavy site — legal services, healthcare, real estate, local services — where users arrive with specific intent and specific language benefits from this kind of keyword-routed, overlay-based search design.