Site search monitoring runs stable golden queries through the API and user interface, then verifies response shape, expected results, ranking bounds, freshness, permissions, locale, and latency. Pair synthetic checks with real zero-result, reformulation, click-through, and conversion metrics: a search endpoint can be technically healthy while usefulness declines.
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 owned, versioned, and representative. Include exact-match, category, typo/synonym, locale, permission, fresh-content, and legitimate no-result cohorts so a global results.length >= 1 rule does not create false alerts.
What to Assert
Monitoring search means asserting more than HTTP 200:
| Layer | Assertion |
|---|---|
| Endpoint health | Status 200, JSON parse succeeds |
| Result count | Expected range for each query cohort |
| 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 and User Outcomes
Synthetic checks catch obvious regressions:
- 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 leaves its approved bound, then correlate with real-user metrics: zero-result rate, query reformulation, result click-through, abandonment, and conversion after search. A single golden query cannot measure overall relevance.
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 or reformulation rate moves materially above its seasonal baseline
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.