Why keyword search is not enough anymore
Traditional site search matches the words a visitor types against the words on your pages. If someone searches for "payment not working" but your support article is titled "declined transaction troubleshooting", the search returns nothing. Users bounce, open a support ticket, or assume you do not have the answer.
AI site search closes that gap. It reads intent, handles synonyms, tolerates typos, and can reply in full sentences rather than just listing links. For content-heavy business sites, knowledge bases, and product catalogues, the uplift in useful results is real.
The question is not whether to add AI search. It is which approach fits your site, your budget, and the level of maintenance you can sustain.
The four approaches that matter
There are dozens of vendors and libraries, but almost all implementations fall into one of four buckets.
1. Hosted search with AI features bolted on
Algolia, Elastic, Meilisearch Cloud, and Coveo all offer semantic and AI-assisted ranking on top of their existing keyword engines. You index content through their API or crawler, and they handle embeddings, reranking, and query understanding.
This is the fastest path to production. For a brochure site or small ecommerce catalogue, you can be live in a week, front-end widget included. Algolia's NeuralSearch and Elastic's ELSER models give solid out-of-the-box results with minimal tuning.
Cost in 2026 starts around AUD 40-80 per month for small sites and scales with query volume and record count.
2. Open-source search with embeddings
Typesense, Meilisearch, and Qdrant can all be self-hosted and combined with an embedding model (OpenAI text-embedding-3-small, Cohere, or a local model like bge-small) to produce hybrid search. You get keyword plus semantic matching, and you keep the stack.
This makes sense when you already run infrastructure, have data residency requirements, or expect enough query volume that hosted pricing becomes painful. The trade-off is operational effort. Someone has to run the cluster, monitor it, and keep the embedding pipeline healthy.
3. Vector search only (OpenAI, Pinecone, Supabase pgvector)
If the goal is pure semantic search over a medium-sized corpus, say under 100,000 documents, a vector database plus an embedding model can be cheap and simple. Supabase pgvector is close to free for small sites because you already have a Postgres database. Pinecone and Weaviate offer managed services for a few dollars a month at small scale.
The catch is that pure vector search is not always better than keyword search. It misses exact matches, product SKUs, and model numbers. Most serious deployments combine both.
4. Custom RAG with generative answers
This is the "ChatGPT on your site" pattern. Instead of returning a list of links, the system retrieves relevant content and asks an LLM to summarise an answer with citations.
RAG search works for documentation, policy libraries, and internal knowledge bases. For marketing sites it is usually overkill. The cost and risk profile is also different, which we cover in a later section.
A decision framework
Rather than picking a vendor first, start with three questions.
How many documents do you have, and how often do they change? Under a few thousand pages that change monthly, hosted search is almost always the right call. Over 100,000 records that update constantly, you want control of the pipeline.
Do users know what they are looking for? Product search on an ecommerce site is mostly known-item lookup with filters. Informational search on a services site is more exploratory, where semantic matching pays off. Support search tends to be question-based and benefits from RAG.
Can the answer be wrong? A wrong product in search results is annoying. A wrong answer in a generative summary about refunds, medical information, or legal advice is a liability. Keep generative answers out of regulated content until you have proper evaluation in place. Under the Australian Consumer Law, misleading on-site claims sit with you, not the vendor.
What implementation actually involves
For an Aussie SMB site on a headless CMS or WordPress, an AI search rollout looks something like this.
Indexing takes one to three days. Content has to be pulled from the CMS, cleaned, chunked if long, and pushed to the search provider. Image alt text, PDF content, and product metadata are easy to forget and commonly asked about. Getting the chunking right matters more than the embedding model.
Front-end integration is another two to five days depending on the design. Instant search UIs, autocomplete, filters, and mobile behaviour all need consideration. Algolia and Typesense ship decent React and vanilla JS components. Headless setups with full custom UI take longer.
Ongoing sync is where projects quietly fail. When a page is published or updated in the CMS, the search index has to be refreshed. Webhooks into a serverless function usually do the job, but you need monitoring. Stale search results after a rebrand or price change are worse than no AI at all.
The pitfalls nobody tells you about
Hallucinated or fabricated results happen when generative answers are built on weak retrieval. If the retrieved chunks do not actually contain the answer, the model fills in the gap. Guardrails and a confidence threshold are non-negotiable.
Staleness is the most common real-world failure. The search index lags the site by hours or days, users get outdated prices, booking links, or office hours, and trust erodes.
Relevance regression is subtler. An AI model upgrade from the vendor can quietly change ranking in ways that hurt your top queries. Save a suite of 50-100 golden queries and regression-test them whenever the stack changes.
Cost surprises come from query volume rather than storage. Embedding 10,000 pages is cheap. Running a RAG query through a frontier model for every search can hit several thousand dollars a month if uncapped.
What we recommend
For most business sites we build, hybrid search via Algolia or Typesense with semantic reranking covers 90 per cent of what clients need. It is fast, predictable, and the UX is well understood by users.
Custom RAG we reserve for specific problem shapes. Large support knowledge bases, internal staff portals, and documentation sites where natural-language answers with citations are valuable. Even then, we pair it with strong evaluation and a fallback to link-based results when confidence is low.
If you are weighing up AI search for your site and want a pragmatic view on which approach fits your traffic, content volume, and risk tolerance, we are happy to walk through it with you.
