Who owns the search box on your own site
Search is the feature where the gap between the platform's version and your own is easy to measure, because both sides publish their numbers. Webflow will crawl your pages and keep an index for you, refreshed twice a day. If twice a day matches how often your content actually changes, you are finished and this post has nothing for you. If your catalogue moves hourly, the next step is usually renting a second search engine on top of the one you already pay for, and that is worth pricing before you sign.
The index refreshes on the platform's clock
Webflow builds your search index after the first publish, and only on a Premium site plan or the legacy CMS plan. Below that, the results page shows sample placeholders rather than your content. Automatic reindexing runs 12 hours after a full site publish. Publishing a single CMS item does not trigger it. Manual reindexing is available once every 12 hours on Premium and once every 24 hours on the legacy CMS plan, and Webflow's own documentation warns that indexing can take up to 24 hours on large sites.
Two other limits matter more than they look. A results page can show up to 60 results and there is no pagination across pages of results, so a query matching 400 items shows you 60 of them and stops. And site search does not work on exported code. The index is a hosted service attached to the hosting plan, so the day you take your HTML elsewhere, the search box goes with the hosting, not with the site.
None of this is a defect. It is a reasonable set of defaults for a brochure site that publishes four pages a month, which is what most Webflow sites are. The trouble starts when the site becomes the product and someone asks why a listing added at 9am is unsearchable until the evening.
What the bolt-on costs once traffic shows up
The standard answer is Algolia, and their published pay-as-you-go pricing is clear enough to do arithmetic on. The Grow plan includes 10,000 search requests a month and 100,000 records, then charges $0.50 per additional 1,000 search requests and $0.40 per additional 1,000 records. Grow Plus, which adds AI ranking and the longer analytics retention, charges $1.75 per additional 1,000 search requests on the same 10,000 included.
Run a modest site through that. Half a million searches a month, which a busy catalogue with an as-you-type box reaches quickly because every keystroke can fire a request, leaves 490,000 billable requests. On Grow that is $245 a month. On Grow Plus the same traffic is $857.50. The free tier caps index size at 1 GB, records at 10 KB each, and gives you 10 indices and 1,000 synonyms, which is a sandbox rather than a plan.
I have no complaint about the product. Algolia is genuinely fast and the relevance tuning is better than anything you will write yourself in an afternoon. The thing to notice is the shape of the bill: it scales with how much your visitors use the feature, which is the same as saying it scales with the site working well.
The database you already run does most of this
PostgreSQL has carried full text search in core for many years. You store a tsvector, you query it with tsquery through the @@ operator, and you put a GIN index behind it. Stemming comes from the dictionaries, so a search for satisfy finds satisfies. Phrase search uses the followed-by operator, and phraseto_tsquery handles the stop words in the middle, turning 'the cats ate the rats' into 'cat' followed by 'ate' with a two-position gap before 'rat'.
Fuzzy matching is the other half and it comes from pg_trgm, which Postgres marks as a trusted extension, meaning anyone with CREATE privilege on the database can install it without a superuser. It scores string similarity on shared three-character sequences with a default threshold of 0.3, which is what you want for typo tolerance. The docs even walk through building a spelling-suggestion table from ts_stat and indexing it with gin_trgm_ops. Reindexing is not a schedule you wait on. It happens in the same transaction as the write.
On the Stay World Class migration we moved a Webflow and Xano stack onto Next.js, NestJS and Supabase, with a four stage ETL that mapped the legacy IDs onto PostgreSQL UUIDs so nothing lost its history. Lighthouse went from 55.91 to 91 out of 100 and LCP came down 77%. Search stopped being a separate vendor and became a column with an index on it.
When renting the index is still right
If your content changes weekly and your visitors search occasionally, Webflow's built-in index costs you nothing beyond the plan you already have, and building the same thing yourself would be a waste of a week. That covers most marketing sites honestly.
If you sell across millions of SKUs with faceted merchandising, A/B tested ranking and per-user personalisation, Algolia at a few hundred a month is cheaper than the engineer who would maintain the equivalent. Paying them is the correct decision, not a compromise.
The case for owning it is narrower than the internet usually admits. It applies when the index has to be current within seconds, when search touches data you cannot hand to a third party, or when the query volume has grown large enough that the meter costs more than the storage. If none of those describe you, keep the search box you have.
