Search results with faceted filters alongside relevance tuning, Core Web Vitals, crawl health and cache performance panels
Illustrative overview. Search relevance, Core Web Vitals, index coverage and cache behaviour reviewed together rather than as separate exercises.
Elasticsearch Core Web Vitals Caching Technical SEO

Three disciplines that fail the same way — done from a checklist rather than from measurement. Every engagement here opens by establishing what the numbers actually are, because the bottleneck is very often not where the team assumes it is.

Measure before changing anything

Gradual degradation almost always has a specific cause rather than general bloat — a plugin added last year, a query that scaled badly as content grew, a third-party tag someone dropped in without telling anyone. Profiling finds it in hours.

Applying general optimisation advice without that step adds complexity and rarely moves the number much, which is how sites end up with four caching layers and the same response time.

Search relevance is the work, not the engine

Standing up Elasticsearch, OpenSearch or Solr is the straightforward part. What determines whether people find things is the tuning: field boosting so a title match outranks a passing body mention, synonym and stopword lists reflecting how users actually phrase things, correct handling of exact identifiers and part numbers, and analysis of the queries that return nothing.

That last one consistently produces the largest gains and is the most frequently skipped. Where the catalogue or knowledge base warrants it, hybrid retrieval — keyword and vector search fused — outperforms either alone, and shares most of its engineering with RAG assistants.

Core Web Vitals from field data

Google measures LCP, INP and CLS from real users, so lab scores are a diagnostic rather than the target. Field data first, then the cause: LCP is usually the hero image or a slow server response; INP is long JavaScript tasks blocking the main thread; CLS is nearly always images without dimensions, injected content or font swapping.

Third-party scripts get particular scrutiny. Analytics, tag managers, chat widgets and advertising tags routinely account for most of a page's JavaScript, and each usually has an internal owner who assumes it is free.

Caching architecture

The largest single lever on server response time and the one most often configured approximately. Page caching at CDN or reverse proxy for anonymous traffic, object caching in Redis for expensive queries, and cache tag invalidation precise enough that publishing one page does not flush everything.

The difficulty is never the caching — it is invalidation being precise enough to be useful and reliable enough to be trusted. A cache that people clear manually "just in case" is not doing its job.

Crawl health and migration safety

Crawl budget spent on pages that matter rather than on faceted filter permutations, canonical URLs on paginated and parameterised pages, correct status codes, redirect chains collapsed, sitemaps that reflect reality, and structured data that validates.

During any replatform, a complete redirect map from every existing URL is what separates a migration that keeps its rankings from one that does not — worth planning before the build rather than before launch.

Something similar in mind?

Client identities and confidential implementation details are intentionally omitted here. Happy to talk through the specifics of your situation directly.

Start a conversation