The search worked great when you launched. Two hundred listings, type a word, get the right results, everybody's happy.
Now you're at twenty thousand listings, and search either takes eight seconds to load, returns nothing when you know the match is in there, or — the special one — ignores the filters entirely and hands back the whole database like it didn't hear you.
This is one of those problems that feels like the plugin broke. It didn't. You just crossed the line where the easy version of search stops being good enough, and nobody told you the line existed.
Here's what's going on. Most directory search starts life simple: when someone searches, the site asks the database to look at every listing and find the matches. At small scale that's instant — checking 200 things is nothing. At 20,000 listings, with categories and locations and custom fields all being filtered at once, that same “just check everything” approach turns into the database doing an enormous amount of work on every single search. It's the difference between finding a name in a 10-page pamphlet and finding it in a phone book with no alphabetical order. Same method. Wildly different afternoon.
The specific things that bite, roughly in order of how often I see them:
- Missing database indexes. This is the big one. An index is what lets the database jump straight to the matching rows instead of reading all of them. Directory plugins index the obvious fields, but the moment you're filtering and sorting on custom fields — the ones you added — those usually aren't indexed, and search slows to a crawl. The fix is real but it's under-the-hood: the right indexes on the fields you actually filter by.
- Filters that don't actually filter. When search “ignores” your category or location and returns everything, it's usually a mismatch between how the filter is being passed and how the query is built — a parameter that's getting dropped, a taxonomy that isn't wired into the search query, a conflict between the plugin's search and the theme's. The result is a query that quietly throws your filter away and falls back to “show all.”
- Geolocation doing too much. Location search (“within 25 miles of”) is heavier than it looks — it's running distance math across your whole dataset. Without the right indexing and some sane limits, it's often the single slowest thing on the site.
- No caching on the heavy stuff. The same popular searches run from scratch every time instead of being remembered for a few minutes. At scale, that's a lot of identical work.
- A plugin or theme conflict. Sometimes search “breaks” the day after an update because two pieces of code are now fighting over the same query. This one hides well and wastes the most time, because the thing that broke isn't the thing you changed.
What actually fixes it depends on which of those it is, and the honest answer is you have to find out which before you start changing things — otherwise you're swapping plugins and clearing caches at random and hoping. Indexing problems get solved at the database level. Filter-logic problems get solved in how the search query is built. Conflicts get solved by isolating what changed. Throwing a faster server at it sometimes buys you breathing room, but if the underlying search is doing too much work, a bigger server just lets it do too much work slightly faster.
The thing I'd want you to walk away with: slow or broken search on a big directory isn't a sign you picked the wrong platform. It's a sign you outgrew the default, which is a good problem — it means you have enough listings to matter. The fix is usually targeted, not a rebuild.
If your search is timing out or ignoring filters and you can't tell which of the above it is, that diagnosis is exactly the first thing I do on a site — find the real cause before touching anything. But if you're handy, start by asking the boring question that solves the most cases: are the fields you're filtering on actually indexed?