Búsqueda en catálogos grandes: cuando el buscador de WooCommerce no da

En una tienda mayorista, el comprador no "navega": busca. Llega sabiendo lo que quiere —un SKU, un código interno, una marca, un calibre— y lo escribe. Si el buscador no lo encuentra, no se pone a explorar categorías: levanta el teléfono y se lo pide al vendedor, que es exactamente el canal manual que la tienda venía a descargar. Con un catálogo de cientos de productos, el buscador nativo de WooCommerce alcanza. Con miles de SKU y variaciones, se cae: es lento y, peor, impreciso. Y en B2B la imprecisión cuesta ventas.

Por qué el buscador nativo se queda corto

La búsqueda por defecto de WooCommerce es una consulta LIKE %término% sobre el título y el contenido del producto en la tabla de posts de WordPress. Eso tiene tres problemas a escala. Primero, no indexa lo que el B2B busca: el SKU, los códigos internos, los atributos y —crítico— los SKU de las variaciones viven en otras tablas (postmeta), que la búsqueda nativa no mira. El cliente busca el código del producto hijo y no aparece nada. Segundo, no tiene relevancia: no hay ranking, un match exacto de SKU vale lo mismo que una mención perdida en una descripción. Tercero, es lento: un LIKE con comodín al inicio no usa índices, y sobre decenas de miles de productos cada búsqueda escanea de más.

El B2B busca distinto al retail. El consumidor escribe "zapatillas rojas para correr"; el comprador mayorista escribe FE-3344 o "perno hexagonal 3/8". Necesita precisión sobre códigos y atributos, no interpretación de lenguaje natural. Un buscador que ignora el SKU está ciego justo para el dato que el mayorista más usa.

Las opciones, de menos a más

1. Mejorar la búsqueda nativa (Relevanssi)

Relevanssi reemplaza la búsqueda de WordPress por un índice propio: indexa más campos, da ranking por relevancia y tolera mejor las palabras parciales. Es el salto más barato y, para catálogos medianos, suele bastar. Su límite es el tamaño: el índice vive en la misma base de datos del sitio, y en catálogos muy grandes empieza a pesar tanto como el problema que vino a resolver.

2. Motor de búsqueda dedicado en el sitio (SearchWP)

SearchWP es el punto medio para B2B. Indexa lo que importa —SKU, SKU de variaciones, atributos, custom fields, categorías— y deja configurar qué pesa más, de modo que un match exacto de código gane a una coincidencia parcial en la descripción. Sigue siendo un índice dentro de WordPress, así que hay que cuidar su peso, pero está pensado para catálogos de verdad y resuelve el caso típico del mayorista: que buscar por código encuentre el producto, variación incluida.

3. Búsqueda externa (Algolia, Elasticsearch)

Cuando el catálogo es enorme o la búsqueda tiene que ser instantánea —resultados mientras escribes, tolerancia a errores de tipeo, filtros facetados—, la búsqueda se saca del sitio y se delega a un motor externo. Algolia o Elasticsearch indexan el catálogo aparte y responden en milisegundos a cualquier escala. El costo es más infraestructura y una dependencia nueva: hay que mantener ese índice sincronizado con el catálogo, y eso es un proyecto, no un plugin.

Dónde se rompe en producción

En la demo, con doscientos productos, cualquier buscador encuentra todo. La diferencia aparece con el catálogo real y el índice encendido.

El SKU de la variación no aparece. El caso más común y más caro: el cliente busca el código exacto de un producto variable —la talla, el color, el formato— y no sale, porque ese SKU vive en la variación y el buscador solo miró el producto padre. Si vendes productos con variaciones, indexar los SKU hijos no es opcional.

El índice se desfasa del catálogo. Tu catálogo cambia —precios, stock, productos nuevos— porque se sincroniza con el ERP. El índice de búsqueda tiene que actualizarse con esos cambios; si no, el cliente encuentra productos que ya no hay o no encuentra los que acabas de cargar. Un índice desactualizado devuelve fantasmas, y eso erosiona la confianza en el buscador más rápido que la lentitud.

La relevancia mal calibrada es tan mala como no buscar. Si el match exacto de SKU no gana al match parcial de una descripción, el cliente escribe el código y el producto correcto aparece en la página tres. Buscar bien no es solo encontrar: es ordenar para que lo más probable salga primero.

La búsqueda tiene que respetar precios y visibilidad por cliente. Si ocultas precios o productos a invitados, o muestras precios por cliente, los resultados de búsqueda tienen que respetar esa lógica: no devolver con precio lo que ese rol no debería ver. La búsqueda es otra superficie donde la regla de visibilidad B2B se tiene que cumplir.

Peso sobre el sitio. Indexar dentro de WordPress carga la base de datos; un índice grande mal gestionado vuelve lento justo lo que querías acelerar. Es el mismo cuidado de rendimiento que cualquier catálogo grande exige: medir antes de asumir.

Qué elegir según el catálogo

Opción	Cuándo sirve	Dónde se queda corto
Nativa de WooCommerce	Catálogo chico, búsqueda ocasional.	No indexa SKU ni variaciones, sin relevancia, lenta a escala.
Relevanssi	Catálogo mediano que necesita ranking y más campos.	El índice vive en la DB del sitio; pesa en catálogos muy grandes.
SearchWP	B2B con SKU, variaciones y atributos que hay que encontrar.	Sigue siendo índice interno; requiere mantener el peso bajo control.
Algolia / Elasticsearch	Catálogos enormes o búsqueda instantánea y facetada.	Más infraestructura y costo; el índice externo hay que mantenerlo sincronizado.

La recomendación

Para un catálogo B2B grande, la búsqueda tiene que indexar lo que el comprador usa —SKU, SKU de variaciones, códigos internos y atributos— con una relevancia que ponga el match exacto primero. El índice se mantiene sincronizado con el catálogo, que ya viene del ERP, para que nunca devuelva fantasmas. Y la elección entre un motor interno (SearchWP) y uno externo (Algolia) se decide por el tamaño real del catálogo y la velocidad que necesitas, no por moda: medir el catálogo y el comportamiento de búsqueda antes de sumar infraestructura.

El buscador parece un detalle hasta que mides cuántas búsquedas terminan en cero resultados y cuántas de esas eran un SKU que sí tenías. Cada una de esas es una venta que volvió al vendedor. Una agencia activa la búsqueda por defecto y sigue; el buscador que de verdad encuentra —con las variaciones indexadas y el índice al día con el ERP— es lo que hace que el catálogo grande sea un activo y no un laberinto. Si tu tienda tiene miles de SKU y el buscador no da, un diagnóstico te dice si el arreglo es calibrar lo que tienes o cambiar de motor.