Check your analytics before you answer. On most business websites the answer is almost nobody, and that single number should decide this whole question for you. Adding AI search to a site with twelve pages solves a problem you do not have, at a cost you will keep paying every month.
We get asked about this a lot, usually after someone has seen a demo where a website answers a question in a sentence instead of returning ten blue links. It is a genuinely impressive demo. It is also the wrong first question for most of the sites we are asked to build.
So here is our honest position. AI search is real, it works, and it is worth it for a specific kind of site. That kind of site is rarer than the sales pages suggest. This article explains how to tell whether you are one of them.
It is site search that matches on meaning rather than on exact words, usually by converting your content into embeddings and comparing them to the visitor's question. Instead of finding pages that contain the words someone typed, it finds pages that are about what they asked.
The underlying technique is well documented. OpenAI's own guidance lists search as the first use case for embeddings, describing it as results ranked by relevance to a query string, alongside clustering, recommendations, anomaly detection, diversity measurement, and classification. Search is not an exotic application of this technology, it is the main one.
Some implementations go further and generate an answer rather than a list of results. That is a different product with different risks, and it is worth keeping the two ideas separate in your head. Better retrieval is a fairly safe upgrade. Generated answers are a decision about whether your website is allowed to speak on your behalf.
Conventional search matches keywords. If someone types how much does it cost and your page says pricing, keyword search finds nothing. Semantic search understands the two are related, so it returns the pricing page. That gap is the entire value proposition, and on a large site it is a real gap.
The difference shows up most with the way people actually type. Real visitors do not use your internal vocabulary. They ask for what they want in their own words, using the term their previous supplier used, or a phrase from their industry rather than yours. Keyword search punishes them for that. Semantic search does not.
The trade is predictability. Keyword search is wrong in ways you can debug, because you can see exactly why a page did or did not match. Semantic search is wrong in ways that are harder to explain, and tuning it is less like fixing a bug and more like adjusting a recipe. That matters when a client asks why their most important page is not showing up.
More than a search box and less than a rebuild. There are three ongoing costs: generating embeddings when content changes, storing and querying them, and the service you use to tie it together. None is enormous, but all three recur, and they scale with how much content you have and how often it changes.
The tooling is mature and there are real options at different levels. Algolia describes itself as a hosted AI retrieval platform that makes your data searchable and helps you build search, recommendations, generative AI, and AI agent experiences. Typesense is open source if you would rather run it yourself, and Elasticsearch remains the heavyweight option for teams with the engineering to support it.
Embedding models are cheap and getting cheaper. OpenAI lists text-embedding-3-small with a default length of 1536 and text-embedding-3-large at 3072, and for a normal marketing site the volume involved is trivial. The real cost is almost never the model. It is the integration, the content pipeline, and the person who owns it when it misbehaves.
This is the question that settles it for most businesses. Our rough threshold is a few hundred meaningful pages that people genuinely need to search across. Below that, good navigation and a clear structure beat any search technology, because a visitor can simply see where things are.
The sites that clear the bar have a recognisable shape. Documentation with hundreds of articles, a knowledge base built over years, a large product catalogue, a research archive, a job board. What they share is that no menu could reasonably expose everything, so search is the primary way in rather than an escape hatch.
A twenty page marketing site is the opposite case. If someone cannot find your pricing, the fix is your navigation, not a better search engine. We would rather spend that budget on making the site clearer, and honestly, so would most clients once the choice is put that way. Our guide to site search in Webflow covers the simpler options that solve most real cases.
It can, and this is where these projects quietly go wrong. Search adds JavaScript, and JavaScript competes with everything else on the main thread. A search widget that loads on every page, whether or not anyone opens it, is paying a performance cost on every visit for a feature almost nobody uses.
The metric to watch is responsiveness rather than load time. Google's web.dev states that pages should have an Interaction to Next Paint of 200 milliseconds or less. A heavy search bundle parsing on page load is exactly the kind of thing that pushes a site past that threshold, and it does so on the cheap phones where you can least afford it.
The fix is straightforward if you plan for it. Load the search code only when someone actually interacts with the search box, keep the results panel light, and never let a third party script block your first render. Across the 150 or more projects we have delivered, the studio average PageSpeed score of 98 survives because features earn their weight rather than arriving by default. Our piece on Interaction to Next Paint explains what actually moves that number.
You own it. That is the part teams underestimate. If your site generates an answer about your refund policy and gets it wrong, the customer will reasonably hold you to what your website said. A results list that shows the wrong page is an inconvenience. A confident wrong sentence is a commitment.
This is the strongest argument for retrieval without generation. Returning the right page and letting the visitor read your actual words carries almost none of that risk, and it still delivers most of the benefit. Better matching is where the value is. Speaking on your behalf is where the exposure is.
If you do generate answers, treat it as a published surface rather than a feature. That means a review process, a way to see what people asked and what they were told, and a fast route to correct a bad answer. Anyone who tells you this part is set and forget has not run one in production.
No, though they increasingly share plumbing. Search answers a question and gets out of the way. A chatbot invites a conversation and implies someone is available to have it. Those are different promises to a visitor, and mixing them up produces an experience that satisfies nobody.
The failure mode is familiar. A visitor with a simple question opens what they think is search, gets a chat greeting, types their question, receives a vague answer, and then asks for a human who is not there. The interaction has now cost them more time than the navigation menu would have.
Pick one job and do it well. If people mostly need to find things, build search. If people mostly need to ask things and you can actually stand behind the answers, build a chat experience deliberately, which we covered in our article on website chatbots.
We start with the analytics rather than the demo. How many people used site search last month, what did they type, and how many of those searches returned nothing useful? Those three numbers answer the question faster than any discussion about technology.
If search usage is low and the failed queries are things your navigation should have covered, we fix the navigation. If search usage is high and people are failing because they use different words than your content does, that is the specific problem semantic search solves, and we would recommend it without hesitation.
The queries themselves are valuable either way. A list of what people typed and could not find is the most honest content brief you will ever get. It tells you which pages to write, which terms to use, and where your site is confusing, and it costs nothing to collect.
Probably not yet, unless you have a large content library and evidence that people are searching it and failing. If you do have that evidence, start with better retrieval rather than generated answers, load it lazily so it costs nothing on pages where it goes unused, and keep the query log.
If you do not have that evidence, spend the money on the pages themselves. Clearer navigation, better structure, and content that answers the questions people are actually asking will do more for you than any search layer, and it also happens to be what makes your site findable in Google and citable by AI answer engines.
If you want help working out which situation you are in, we are happy to look at your search data with you and give you a straight answer, including when that answer is that you do not need this. You can find us at phoenix.studio, and we usually reply within 48 hours.
Tell us where you want to go. We'll tell you how we'd get you there.