Search is often the shortest path from intent to revenue. A user types "pricing", "refund policy", "red shoes", "api status", or "enterprise plan" because they know what they want. If the search endpoint returns 500, empty results, stale results, or irrelevant results, they do not file a bug. They leave.
Site search failures are usually invisible to standard uptime monitoring. The homepage loads. The API responds. The database is fine. But /search?q=pricing returns zero results because an indexing job failed, Algolia credentials rotated, Elasticsearch fell behind, or a frontend deploy changed the query parameter name.
This guide shows how to monitor site search as a production user journey: which queries to test, what to assert in the response, how to catch empty-result regressions, and how to separate "search is up" from "search is useful."
Why Search Needs Its Own Monitoring
Search has multiple moving parts:
- Frontend search box
- Search API endpoint
- Indexing pipeline
- Search provider (Algolia, Elasticsearch, Meilisearch, Typesense, Solr, custom SQL)
- Ranking rules
- Synonyms and filters
- Permissions and locale handling
Any one layer can fail while the page still returns HTTP 200.
Common failures:
- Endpoint returns 500
- Endpoint returns 200 with empty
results: [] - Indexing job stops and new content never appears
- Query parameter changes (
q->query) and frontend sends the wrong shape - Search provider API key expires
- Locale filter removes all results
- Permission filter hides public content
- Ranking rule change buries the expected result
- Search becomes slow during peak traffic
The Golden Query Set
Build a small set of queries that should always work.
For a SaaS website:
| Query | Expected result |
|---|---|
pricing |
Pricing page |
status |
Status page or monitoring page |
api |
API/docs page |
login |
Login/help article |
uptime |
Core product page |
For ecommerce:
| Query | Expected result |
|---|---|
| Top product SKU | Exact product |
| Top category | Category page |
| Brand name | Brand results |
| Common typo | Corrected result |
| Out-of-stock item | Clear unavailable state |
For docs:
| Query | Expected result |
|---|---|
webhook |
Webhook docs |
api key |
Auth docs |
rate limit |
Rate limit docs |
status page |
Status page docs |
Keep the set small enough that every failure is actionable.
What to Assert
Monitoring search means asserting more than HTTP 200:
| Layer | Assertion |
|---|---|
| Endpoint health | Status 200, JSON parse succeeds |
| Result count | results.length >= 1 for golden queries |
| Expected result | First page contains expected title/URL |
| Latency | p95 below user-facing threshold |
| Freshness | Recently published item appears |
| Empty state | No-result query shows helpful empty state |
| Locale | EU/US/localized results match expected |
| Permissions | Public query does not require auth |
Example API assertion:
{
"query": "pricing",
"results": [
{ "title": "Pricing", "url": "/pricing" }
]
}
Assert that /pricing appears in the response. Do not only assert the array exists.
Monitoring Search Result Pages
Some sites render search results as HTML rather than JSON:
https://example.com/search?q=pricing
Content assertions:
- Page contains
Search results - Page contains
Pricing - Page does not contain
No results found - Page does not contain
Something went wrong - Page response time below threshold
If JavaScript renders results client-side, use synthetic browser monitoring or a server-rendered health endpoint that exposes the search check result.
See JavaScript SEO Monitoring for crawler/rendering pitfalls.
Freshness Monitoring
Search can be up and stale. Add one freshness query:
- Publish a known test document or product.
- Query its title or SKU.
- Assert it appears within expected indexing SLA.
Examples:
- Blog post appears in search within 10 minutes
- Product inventory update appears within 5 minutes
- Docs page appears within 30 minutes
This catches failed indexing jobs and queue backlogs. If your indexing pipeline is asynchronous, pair this with Cron Job Monitoring or Job Queue Monitoring.
Relevance Drift
Relevance is harder than uptime, but basic monitoring is still useful:
- Expected result appears in top 3 for golden query
- Exact SKU query returns exact SKU first
- Brand query returns brand landing page first
- Typo query returns corrected result
Alert when an expected URL disappears from the first page. Ranking changes may be intentional, but they should not be silent.
Provider-Specific Notes
Algolia
Monitor:
- Search API status
- API key validity
- Indexing task queue
- Record count per index
- Empty result rate for golden queries
Elasticsearch / OpenSearch
Monitor:
- Cluster health
- Index refresh lag
- Query latency
- Shard failures in response
- Circuit breaker errors
Meilisearch / Typesense
Monitor:
- Health endpoint
- Indexing task queue
- Document count
- Query response shape
For the database layer behind custom search, see PostgreSQL Production Monitoring and MySQL Production Monitoring.
Alerting Thresholds
Critical
- Golden query returns 500
- Golden query returns zero results
- Expected critical URL missing from results
- Search latency > 5s for top queries
- Search provider auth failure
High
- Freshness SLA missed
- Expected result drops below top 3
- Locale-specific query returns wrong locale
- Empty-result rate spikes
Informational
- Search response shape changes
- Result count changes materially
- New synonym/ranking config deployed
Site Search Monitoring Checklist
- Golden query set defined
- Search API status monitored
- Result count asserted for each golden query
- Expected URL/title asserted
- Latency threshold set
- Freshness check for newly indexed content
- Locale-specific checks where applicable
- Empty-state page checked
- Provider health monitored
- Search provider API key expiry/validity tracked
- Alerts routed to product/search owner
How Webalert Helps
Webalert can monitor site search from the outside:
- HTTP monitoring - Check
/search?q=pricingor/api/search?q=pricing. - Content validation - Assert expected result titles and URLs appear.
- JSON/API checks - Verify result arrays are non-empty and response shape is stable.
- Synthetic checks - Search through the actual UI when results require browser rendering.
- Freshness checks - Query for a known recently published page or product.
- Multi-region checks - Detect geo/locale-specific search failures.
- Alert routing - Notify product, search, and engineering teams before conversion drops.
Example Webalert check:
- URL:
https://example.com/search?q=pricing - Expected status: 200
- Must contain:
Pricing - Must not contain:
No results found - Response time: under 1500ms
- Region: US + EU
Summary
Site search is a conversion path. It can fail with 200 responses, empty arrays, stale indexes, bad ranking rules, or missing locale data.
Monitor golden queries, expected results, latency, freshness, and empty states. Search that is merely "up" is not enough; it has to return the result users came for.