Zoeken vs filteren in WooCommerce: waarom categorie-archieven geen zoekmachine nodig hebben

Een categoriepagina is geen zoekmachine. De bezoeker staat al in “Heren > Sneakers” en wil die verzameling inperken op maat, kleur en prijs. De zoekbalk in de header doet het omgekeerde: een vrije tekst over de hele catalogus, en vaak ook over pagina’s en berichten. InstantFilter houdt die taken uit elkaar. Het maakt WooCommerce-archieven direct filterbaar, inclusief een zoekveld dat alleen de producten van dát archief doorzoekt, zonder de header-zoekbalk te vervangen en zonder bij elke klik een SQL-query te starten.

Wat is het verschil tussen zoeken en filteren in WooCommerce?

Zoeken begint bij een leeg veld en een onbekende verzameling. De bezoeker typt “blauwe hardloopschoen maat 42” en verwacht dat de shop raadt wat hij bedoelt: synoniemen, typfouten, relevantie over de hele catalogus. Dat is een retrieval-probleem. WordPress lost de standaardvariant op met de queryparameter s en een LIKE over post_title en post_content. Dedicated zoekplugins bouwen daar een eigen index omheen, met gewichten per veld en soms fuzzy matching.

Filteren begint bij een verzameling die al vaststaat. De URL is een categorie, een tag, een merk of een ander productarchief. De bezoeker kiest bekende waarden: maat 42, kleur blauw, prijs tot €120. Dat is een set-operatie, geen vrije-tekstzoektocht. Elke klik hoort de doorsnede van die facetten te tonen, mét een teller bij opties die daarna nog iets opleveren.

Die twee paden lopen in een shop naast elkaar, niet door elkaar:

• Header-zoekbalk (sitewide zoeken). Vrije tekst over de catalogus. De bestemming is meestal een zoekresultatenpagina. Een zoekplugin blijft hiervoor verantwoordelijk.
• Categorie-archief (filteren). De bezoeker bladert binnen één tak van de catalogus. Facetten, prijs en sortering horen hier, niet een tweede zoekmachine die de hele database opnieuw doorloopt.

De verwarring ontstaat omdat beide een invoerveld kunnen hebben. YITH Ajax Product Filter is een archieffilter; YITH WooCommerce Ajax Search is een zoekplugin. Dat zijn twee producten. Wie op “yith woocommerce ajax search” zoekt en daarna een filterplugin installeert op de categoriepagina, lost het verkeerde probleem op. De vergelijking van InstantFilter met het filterproduct staat op InstantFilter vs YITH Ajax Product Filter.

Waarom hoort een zoekmachine niet op je categorie-archief?

Een categorie-archief heeft de verzameling al. WooCommerce heeft via de taxonomy-query bepaald welke producten bij “Sneakers” horen. Op dat moment een sitewide zoekopdracht starten gooit die begrenzing weg of legt er een zware tekstquery bovenop. Het resultaat is traag, en de bezoeker ziet producten die buiten de categorie vallen of juist te weinig, omdat een titel niet het woord bevat waarop hij filterde.

Klassieke AJAX-filters maken het erger. Elke klik op “Maat 42” stuurt een verzoek naar admin-ajax.php. WordPress start op, WooCommerce bouwt een tax_query en vaak een meta_query, en MySQL join’t wp_postmeta. Dat kost 800ms tot 2,5 seconden. Een zoekplugin die op dezelfde archiefpagina óók bij elke toetsaanslag de database bevraagt, bezet dezelfde PHP-workers. Tijdens een piek wacht dan niet alleen de filterende bezoeker, maar ook iemand die afrekent.

Facets horen geen zoekresultaten te zijn. “Blauw (14)” is een telling van de doorsnede met de andere gekozen filters, binnen dit archief. Een full-text engine rankt documenten op relevantie. Die twee antwoorden lijken op elkaar in de interface en zijn technisch iets anders. Relevantie-ranking op een categoriepagina verbergt producten die wél maat 42 zijn, omdat hun titel minder op de zoekterm lijkt. Een facet toont ze wel.

Een concreet voorbeeld. Een bezoeker staat op “Sneakers” en wil blauwe maat 42. In een zoekwidget op diezelfde pagina typt hij “blauw 42”. De zoekplugin rankt de hele catalogus, of in het beste geval de categorie, op tekstovereenkomst. Een sneaker die in de attributen blauw en 42 is, maar in de titel alleen “Roadrunner” heet, zakt weg of verdwijnt. Een andere sneaker met “blauw” in de productomschrijving en maat 44 komt bovendrijven. Daarna klikt hij alsnog op een facet, en die klik start een tweede ronde SQL. Twee systemen beantwoorden één doorsnede, en beide belasten PHP.

Hetzelfde archief met een archieffilter werkt anders. Maat en kleur zijn waarden die al aan het product hangen. De doorsnede is exact: elk product dat beide waarden heeft, telt mee, ongeacht of het woord in de titel staat. Het zoekveld in de filterbalk is er voor het moment dat de bezoeker wél een naam weet binnen deze categorie (“Roadrunner”), niet om de facetlogica te vervangen. Die naam wordt tegen de producten van dit archief gehouden, niet tegen de rest van de site.

SEO lijdt mee als de archief-HTML afhangt van een zoekresponse. Google bot moet op /product-categorie/sneakers/ de producten van die categorie zien, server-side gerenderd, met links en prijzen. Een pagina die pas na een JavaScript-zoekopdracht een grid vult, levert de bot een leeg of incompleet archief. De architectuur daarachter staat in de gids AJAX vs frontend-first filtering.

Hoe werkt de header-zoekbalk anders dan een filter op een categoriepagina?

De header-zoekbalk is sitewide. De bezoeker weet de categorie nog niet, of hij wil één artikelnummer. De query mag producten, en bij een brede zoekplugin ook pagina’s, vinden. De index leeft op de server, omdat de verzameling de hele site is en de ranking per verzoek wordt berekend. Plugins als Relevanssi of ElasticPress horen in die balk. InstantFilter neemt die plek niet in.

Een categoriepagina is al een query. De term, de children van die term en de paginering staan vast voordat iemand een filter aanraakt. Wat daarna verandert, is de doorsnede: welke van díe producten maat 42 én blauw zijn. Dat kan de browser doen zodra hij de gegevens van het archief heeft, zonder de zoekindex van de header te vragen.

Bouw je het archief in Elementor of Bricks Builder, dan blijft die scheiding hetzelfde. De page builder is de schil. De filtering hoort niet in een zware loop van de builder, en de header-zoekbalk hoort niet in die loop te worden nagebootst met een AJAX-zoekwidget op elke categorie.

Wat doet het zoekveld in de InstantFilter-filterbalk wel?

InstantFilter heeft wél een zoekveld, maar het staat in de filterbalk van het archief, niet in de header. Het veld heet in de markup instant-filter-search (id if-filter-bar-input). De standaard placeholder is “Zoek op productnaam of filter…”. Dat veld doorzoekt de producten van het huidige archief.

Na hydratatie gebeurt dat in de browser. De engine houdt contextItems bij: de producten die bij deze categorie, tag of ander productarchief horen. Een listing met “respect context” begrenst die set tot de huidige term én de child-terms, via if_terms_map. Typen filtert die set. De query wordt in tokens geknipt en vergeleken met een zoekindex die per product uit de titel en de facetlabels is opgebouwd. De invoer wacht 140ms na de laatste toets, zodat niet elke letter de hele set opnieuw langsgaat. Daarna geldt dezelfde doorsnede als bij een klik op een facet: alleen producten die én aan de tekst én aan de gekozen filters voldoen. De eerste pagina van die doorsnede wordt getoond. Dat is geen verzoek naar admin-ajax.php en het kost geen SQL.

Op het serverpad, vóór die hydratatie of via de archive-API, geldt dezelfde grens. Een meegestuurde zoekterm vernauwt de al begrensde archiefquery: een LIKE op de titel in if_strings of op de slug van het item. Niet op blogposts, niet op pagina’s, en niet los van de taxonomy van het archief. De eerste HTML van de categorie blijft server-side gerenderd, zodat de categorie-URL voor zoekmachines een archief blijft.

Suggesties onder het veld en chips boven het grid horen bij datzelfde archief. Een suggestie kiest een facetwaarde in deze set. Een chip haalt die keuze weer weg. Geen van beide opent een sitewide zoekresultatenpagina.

Hoe blijven een zoekplugin en een archieffilter naast elkaar werken?

Laat de zoekplugin de header. Laat InstantFilter de archieven. Ze beantwoorden een andere vraag, dus ze hoeven elkaars index niet te delen.

1. Header. De bestaande zoekplugin blijft de sitewide balk. Die indexeert titels, en als je dat wilt ook inhoud en synoniemen, over de catalogus. InstantFilter registreert zich niet als vervanging van die balk.
2. Archief. Op categorie, tag en merk plaatst je het InstantFilter-archief: in Bricks een van de vier native elementen, in Elementor de shortcode van het archief. De opmaak van grid, kaarten en het zoekveld in de balk stel je in via InstantFilter → Layouts, niet in een builder-loop.
3. Niet stapelen. Zet geen tweede AJAX-zoekwidget, zoals een live-search van een filterplugin, óp de categoriepagina. JetSmartFilters en vergelijkbare AJAX-filters sturen dan alsnog elke wijziging naar de server, precies de latency die het archief niet nodig heeft.
4. Cache. Omdat filteren en het zoeken in de balk na hydratatie in de browser gebeuren, blijft de categorie-HTML cachebaar. Hoe dat samenwerkt met WP Rocket, Redis, LiteSpeed en Cloudflare staat in de gids over WooCommerce-filtercaching.

Grote catalogi veranderen deze scheiding niet. Ook bij tienduizenden SKU’s blijft de header-zoekbalk een server-index, en het archief een begrensde set die de browser filtert. Boven ongeveer 100.000 SKU’s kan het JSON-codebook te groot worden voor een trage mobiele verbinding. Dan is een geïndexeerde serveroplossing voor het archief de eerlijke afweging, niet een zoekmachine die je op de categoriepagina zet. De header blijft in dat scenario gewoon de plek voor vrije tekst; alleen de manier waarop het archief zelf wordt ingeperkt verandert.

Welke aanpak hoort bij zoeken, en welke bij een categorie-archief?

Drie patronen die shops door elkaar halen, naast elkaar:

Hoe zet je een categorie-archief filterbaar zonder de zoekbalk te vervangen?

Je vervangt de header niet. Je geeft het archief een eigen engine.

1. Zoekplugin laten staan. De header blijft de sitewide zoekopdracht doen. Test die balk op een artikelnummer en op een typfout, los van de categoriepagina’s.
2. InstantFilter op het archief. Activeer de plugin. De index bouwt de producten, termen en titels op in de eigen tabellen. Het archief krijgt daaruit zijn codebook.
3. Context aan laten staan. Op een categorie moet de listing het huidige archief respecteren, inclusief child-categorieën. Anders toont het zoekveld in de balk producten van buiten die tak, en gedraagt het zich als een stiekeme sitewide zoekopdracht.
4. Plaatsen in de builder. In Bricks sleep je een InstantFilter-element in het categorie-template. In Elementor plaats je het archief-shortcode. Het zoekveld, de facetten en het grid komen uit de Layout Builder.
5. Controleren. Open een categorie. De eerste HTML toont producten van die categorie. Een klik op een facet en een paar letters in de filterbalk vernauwen alleen die set, zonder spinner naar de server. Het aantal zichtbare kaarten hoort altijd precies gelijk te zijn aan de facet-teller van die doorsnede, niet aan een relevantiescore van een zoekmachine. De header-zoekbalk opent nog steeds een eigen resultatenpagina, ook als het archief al gefilterd is.

Veelgestelde vragen over zoeken en filteren in WooCommerce

Verdiep je verder in archieven en filterarchitectuur

Zoeken in de header en filteren op een categorie lossen een andere vraag op. Deze gidsen gaan verder op het archief:

• WooCommerce filteren op merk
• Dynamische facet-tellingen zonder SQL
• AJAX vs frontend-first filtering
• InstantFilter vs YITH Ajax Product Filter
• Trage queries en wp_postmeta
• WooCommerce-filter voor Elementor
• WooCommerce-filter voor Bricks Builder
• Bekijk InstantFilter licenties en prijzen