Add AJAX Search to PrestaShop Without Page Reloads

Test your own store before you install anything. PrestaShop 9's default theme ships live search already. Most guides written for PrestaShop 1.7 — and most module sales pages — assume it does not, and that assumption is now wrong.

On a stock PrestaShop 9.1.1 store, typing mug into the header box produced five results under the box with no page reload, from a fetch call to the store's own /search endpoint. Here is the whole feature, seen from the DOM:

<div class="ps-searchbar js-search-widget">
  <input class="js-search-input form-control ps-searchbar__input" name="s">
  <span class="js-search-clear ps-searchbar__clear d-none">
  <div class="js-search-dropdown ps-searchbar__dropdown d-none">
    <div class="js-search-results ps-searchbar__results"></div>
  </div>
  <template class="js-search-template">...</template>
</div>

Every part is a separate hook the theme expects an implementation to fill in: an input, a clear button, a dropdown, a results container, and a markup template. None of it is module-supplied.

Test whether you already have it — 30 seconds

1. Open your store's front page.
2. Open the browser developer tools, go to the Network tab, filter to Fetch/XHR.
3. Type a product word slowly into the header search box — at least four characters.
4. Watch the URL bar. If it does not change, and a request appears in the Network tab, you already have live search.

If the URL changes to /search?..., you have the classic form and the rest of this guide applies. If it does not, go fix your search settings instead — matching is what your customers are actually struggling with.

To check it from the console instead of by eye:

document.querySelector('.js-search-dropdown')?.classList.contains('d-none')
// before typing: true   →  after typing: false

What changes, and what does not

Changes	Does not change
Results appear without a page reload	Which products match. That is the search index, not the interface.
The customer refines the query while looking at results	Ranking. Live search shows the same order.
The number of searches per session usually rises	Whether the products exist

This is important: live search is an interface change. If your search returns the wrong products, live search makes it faster to see wrong products. Fix the search settings first, then add the interface.

The two failures to avoid

Failure 1 — A request per keystroke

Typing "wireless earbuds" is 16 keystrokes. Firing a request on each one is 16 requests for one search, and on mobile it makes the site feel slower, not faster.

Two guards, both necessary:

• Debounce — wait about 250–300 ms after the last keystroke before sending.
• Minimum characters — do not search under 3 characters.

Without both, live search measurably slows the store down under any real traffic.

Failure 2 — Duplicate results while the customer types

The customer types "sh", sees results, types more, sees new results. If the old requests are still in flight when a newer one returns, the older response can arrive last and overwrite the correct results.

Guard: cancel the pending request when a new one starts. This is a two-line fix and it is the difference between a working feature and an intermittent bug you will never reproduce.

What live search costs

• Server load per search session. Debouncing and a 3-character minimum cut this by roughly 80%.
• A JavaScript file on every page. Small, but it is one more script in the critical path on mobile.
• A dependency on the theme. The dropdown renders inside your theme's header. A theme update can break the positioning.

Budget a re-test after every theme update. This is the same maintenance cost as any front-end module, and it should be part of the decision.

If you already have it, three things still decide whether it helps

The feature existing is not the same as the feature being configured. Once the dropdown appears, check these three:

1. How many requests per search. Type ten characters and count them in the Network tab. One or two means a debounce is working. Ten means a request per keystroke.
2. How many characters before it fires. Type one character and watch. On a large catalogue a single-character query is a full-table scan any visitor can trigger, repeatedly.
3. Whether stale results can win. Type shoes, then immediately backspace to sh. The results shown must match sh, not shoes. If the longer query's response lands last, you have the race below.

All three are fixable without replacing the theme, and all three are invisible until you look for them.

When it is worth adding

Add it when:

• You sell products with names customers do not remember
• You have more than roughly 100 products, so browsing to a product is slow
• Your search log shows a high number of searches per session — that means customers search repeatedly, and each search costs them a page load today

Do not add it when:

• Search returns zero results often. Fix the index first.
• The store already loads slowly. Add load, get a slower store.
• You have 20 products. A category menu does the job.

How to check it works

Three checks, all in the browser:

1. Network panel: type 10 characters, count the requests. With a 300 ms debounce there should be 2–3, not 10.
2. Type fast, then stop: the results shown must match the full query, not a prefix of it. This is the race condition test.
3. Mobile, throttled connection: results should appear within about a second. If they take longer, the server-side search is the bottleneck, not the interface.

Measure it

Two numbers over two weeks:

Metric	Direction
Searches per session	Up — customers try more queries
Search-to-add-to-cart rate	Up — the point of the feature
Server requests per session	Should stay close to flat

If searches per session goes up and add-to-cart does not, the problem is product matching, not the interface. Go back to the search settings.

Related guides

• Set up advanced search in PrestaShop — make search match the right products first
• Add AI-powered search to a PrestaShop store — match by meaning, not by typed words
• Fix slow product pages in PrestaShop — the pages live search sends customers to
• Agile AJAX Search module — debounce, minimum length and request cancellation preconfigured

Checklist

• ☐ Checked first whether the theme already has live search (30-second test)
• ☐ URL bar confirmed not to change while typing
• ☐ Search settings fixed before touching the interface
• ☐ Debounce set to 250–300 ms
• ☐ Minimum characters set to 3
• ☐ Pending request cancelled when a new one starts
• ☐ Request count checked in the network panel while typing
• ☐ Race condition tested by typing fast then stopping
• ☐ Mobile test on a throttled connection
• ☐ Re-tested after the last theme update

FAQ

Is live search the same as advanced search? No. Advanced search changes which products match, through the search index and settings. Live search changes only how results are presented. You can have either without the other, and the matching fix is worth more.

Will it hurt my page speed score? It adds one script and no requests until a customer types. The score impact is small. The real cost is server load per search session, which is why debouncing matters.

Can I add it without a module? On PrestaShop 9 with the default theme you do not have to add anything — it is already there. On an older theme, yes: edit the theme and add JavaScript. The maintenance cost is that a theme update overwrites your edit unless you use a child theme.

I checked and I already have it. Did I waste money on a search module? Possibly, on the interface half. A module can still be worth it for what the default theme does not do: debounce tuning, minimum character length, request cancellation, and search analytics. Check those four before deciding the module does nothing — and check them even if you keep it.

Why do results sometimes show a shorter query than I typed? An older request finished after a newer one and overwrote the results. That is the missing request-cancellation guard. It is a known failure mode of this feature and it is fixable in a few lines.