RAG Knowledge Assistants
Assistants that answer from your documents, cite their sources, and say "I don't know" instead of inventing an answer.
Three disciplines that share a habit: they are all done badly when done from a checklist and well when done from measurement. Every engagement here starts by establishing what the numbers actually are, because the bottleneck is very often not where the team assumes it is.
Search that returns the right thing
Database search stops being adequate quickly. Elasticsearch, OpenSearch or Solr give you full-text ranking, faceted filtering, typo tolerance, synonyms, autocomplete and multilingual analysis — and the ability to filter a large catalogue without generating queries that cripple the database.
The engine is the straightforward part. Relevance tuning is the work: field boosting so a title match outranks a body match, synonym and stopword lists reflecting how your users actually phrase things, handling of exact identifiers and part numbers, and analysing what people search for and fail to find. That last one consistently produces the biggest gains and is the most frequently skipped.
Semantic and hybrid search
Vector search finds conceptually related content where the wording differs, which is where keyword search fails. It also misses exact identifiers, which is where keyword search excels. Hybrid retrieval runs both and fuses the rankings, and it outperforms either alone for most real catalogues and knowledge bases.
This overlaps directly with RAG assistants — the retrieval layer is largely the same engineering, whether the output is a ranked list of results or a generated answer with citations.
Core Web Vitals and front-end performance
Google measures LCP, INP and CLS from real users, so lab scores are a diagnostic tool rather than the target. Field data first, then find the cause.
- LCP is usually the hero image or a slow server response. Preloading the right resource, modern image formats, correct sizing, and getting time-to-first-byte down.
- INP is long JavaScript tasks blocking the main thread. Breaking up work, deferring non-critical scripts, and questioning third-party tags.
- CLS is almost always images without dimensions, injected content, or fonts swapping. Cheap to fix and frequently ignored.
Third-party scripts deserve particular scrutiny. Analytics, tag managers, chat widgets and advertising tags routinely account for the majority of a page's JavaScript, and each one usually has an 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 the expensive queries, and correct cache tag invalidation so publishing one page does not flush everything.
The hard part is never the caching. It is invalidation being precise enough to be useful and reliable enough to be trusted — a cache people clear manually "just in case" is not providing what it should.
Technical SEO
The part of SEO that is engineering: crawl budget spent on pages that matter rather than on faceted filter combinations, canonical URLs on paginated and parameterised pages, correct status codes, redirect chains collapsed, XML sitemaps that reflect reality, structured data that validates, and hreflang on multilingual sites.
For JavaScript-rendered sites there is an additional question of whether crawlers see the content at all — see Headless & Composable. And during any migration, a complete redirect map is what separates a replatform that keeps its rankings from one that does not.
What this does not cover
Content strategy, keyword research, link building and copywriting are a different discipline and I do not do them. This is the technical foundation those efforts depend on. If your content is strong and the site is technically obstructing it, this work helps considerably; if the underlying content is the problem, it will not.
See this in practice: Search, Performance & Technical SEO
Common questions
Our Lighthouse score is poor but the site feels fast. Does it matter?
Lab scores and real-user data often disagree, and the field data is what Google uses. Check Search Console Core Web Vitals or the CrUX report for what actual visitors experience. If the field data is fine, a low lab score on a throttled simulated device is not worth chasing. If it is not fine, the lab tools are useful for finding out why.
Do we need Elasticsearch, or is database search enough?
Database search is fine for a few thousand items with simple matching. You need a search engine when you want faceted filtering that does not hammer the database, relevance ranking beyond keyword matching, typo tolerance, or search across content types. Large e-commerce catalogues with layered navigation are the clearest case — see the WooCommerce page for why.
Will you improve our Google rankings?
I can remove technical obstacles: crawlability problems, slow pages, duplicate content from parameter handling, missing structured data, broken redirects. Where those are holding a site back the improvement can be significant. But rankings depend heavily on content quality and authority, which is a different discipline, and anyone guaranteeing rankings from technical work is overselling.
How do you approach a site that got slower over time?
Measure before changing anything, because gradual degradation usually has a specific cause rather than general bloat — a plugin added last year, a query that scaled badly as content grew, a third-party script someone dropped in. Profiling finds it. Applying general optimisation advice without that step adds complexity and rarely moves the number much.
Can you help us not lose traffic during a replatform?
Yes, and this is worth planning before the build rather than before launch. It means a complete map from every existing URL to its new location, preserved titles, meta descriptions and structured data, sitemap submission, and monitoring through the transition so problems surface in days rather than after a quarter of lost traffic.
Want to talk this through?
Describe the problem in your own words — I will tell you what I would actually build, and what I would not.
Start a conversation