Búsqueda inteligente para PrestaShop: cuando la búsqueda por defecto no basta

Última revisión: junio de 2026 — comportamiento nativo verificado con la clase Search del núcleo de PrestaShop y los ajustes de Parámetros de la tienda → Buscar en 1.7.6+, 8.x y 9.x.

Un cliente escribe "bycicle helmet" en la barra de búsqueda. Quería decir "bicycle helmet": una sola letra cambiada de sitio. En una instalación limpia de PrestaShop, a menudo sí obtiene resultados, porque PrestaShop lleva años incorporando coincidencia difusa. Pero activa el interruptor equivocado, publica un vocabulario de sinónimos pesado que tu catálogo nunca contempló, o deja que el índice de búsqueda se quede desactualizado, y ese mismo cliente verá una página vacía, asumirá que no vendes cascos y se irá. Tenías 47 en el almacén. Este artículo trata de la brecha concreta entre lo que la búsqueda nativa de PrestaShop hace realmente —que es más de lo que la mayoría de comerciantes cree— y el punto en el que de verdad se queda corta.

Esa distinción importa porque el consejo habitual ("la búsqueda por defecto es tonta, compra un módulo de búsqueda") es medio falso y te cuesta dinero en ambos sentidos. Algunas tiendas pierden ventas por ajustes que podrían corregir gratis esta misma tarde desde el panel de administración. Otras ya han afinado todas las palancas nativas y aun así siguen perdiendo usuarios con alta intención de compra; para ellas, un motor distinto es la respuesta honesta. Solo puedes saber en qué grupo estás cuando entiendes qué hace realmente la búsqueda nativa.

Qué hace realmente la búsqueda nativa de PrestaShop (más de lo que crees)

El cuadro de búsqueda del front office lo gestionan el SearchController y la clase principal Search (classes/Search.php). No hace un escaneo ingenuo con LIKE '%term%' sobre tus productos. En su lugar, cada vez que se guarda un producto, PrestaShop tokeniza los campos indexables en las tablas ps_search_word y ps_search_index; cuando llega una consulta, compara contra ese índice ya construido y puntúa los resultados. Hay tres comportamientos nativos que sorprenden a la mayoría de comerciantes:

• La coincidencia difusa (tolerante a errores tipográficos) viene incorporada. El ajuste PS_SEARCH_FUZZY permite que PrestaShop compare una palabra consultada con una palabra indexada dentro de una pequeña distancia de edición, de modo que "bycicle" todavía puede llegar a "bicycle". Comprueba si la búsqueda aproximada/difusa está activada en Parámetros de la tienda → Buscar. El valor PS_SEARCH_FUZZY_MAX_LOOP limita cuánto lo intenta por palabra para que la búsqueda siga siendo rápida. El mito de que PrestaShop devuelve cero resultados ante cualquier errata sencillamente está desactualizado.
• Los sinónimos ya existen, con otro nombre. PrestaShop los llama aliases y los guarda en la tabla ps_alias. Se gestionan en el panel de administración, en Parámetros de la tienda → Buscar → Aliases. Asocia "couch" con "sofa", "trainers" con "sneakers", "telly" con "television", y la palabra del usuario se reescribe a la tuya antes de consultar el índice.
• La relevancia se pondera, y tú decides los pesos. La misma página de preferencias de búsqueda permite definir un peso para cada campo indexado: nombre del producto, referencia/EAN/MPN, descripción corta, descripción larga, nombre de categoría, fabricante, etiquetas, atributos y características. Una coincidencia en el nombre del producto puede contar mucho más que una mención suelta enterrada en una descripción, que es exactamente como evitas que "vestido rojo" muestre una caja de herramientas roja por encima de los vestidos reales.

Entonces, ¿qué significa esto para ti? Antes de gastar en nada, el primer paso es abrir las preferencias nativas de búsqueda y confirmar que la búsqueda difusa está activada, que los pesos de los campos tienen sentido para tu catálogo y que has empezado una lista de aliases. Una parte significativa de las quejas por "búsqueda rota" son en realidad un valor por defecto que nunca se configuró, una lista de aliases vacía o, muy a menudo, un índice desactualizado.

La causa más común de "la búsqueda está rota": un índice desactualizado

Como PrestaShop busca en un índice previamente construido y no en la tabla viva de productos, cualquier cambio realizado fuera del guardado normal de un producto puede dejar el índice describiendo un catálogo que ya no existe. Importaciones masivas, actualizaciones SQL, copias de seguridad restauradas, cambios multitienda o una migración a medias provocan esto. El síntoma es desesperante: un producto está claramente publicado en su página, pero al buscar su nombre exacto no aparece nada.

La solución es reconstruir el índice. En la página Parámetros de la tienda → Buscar hay una acción "Reconstruir el índice completo" (y una opción "Añadir productos faltantes al índice" para retoques más ligeros). En catálogos grandes, ejecútala desde la tarea cron en lugar de hacerlo desde el navegador para evitar tiempos de espera agotados.

PrestaShop incluye un endpoint cron para indexar la búsqueda exactamente para esto. El botón de la página de Búsqueda lo llama con una marca de reconstrucción completa; puedes ejecutar el mismo trabajo de forma programada. Los campos del formulario te indican la URL: la reconstrucción completa añade &full=1, mientras que el pase más ligero de "añadir productos faltantes" la omite:

# Full rebuild (use after a bulk import / restore / SQL change)
curl -s "https://yourstore.com/searchcron.php?id_shop=1&token=YOUR_SEARCH_TOKEN&full=1"

# Lighter pass: only index products missing from ps_search_index
curl -s "https://yourstore.com/searchcron.php?id_shop=1&token=YOUR_SEARCH_TOKEN"

El token es el valor que PrestaShop muestra junto a las acciones del índice en la página de preferencias de búsqueda (no inventes uno: copia la URL exacta que te da). Integra la llamada de reconstrucción completa en tu rutina de importación y la categoría de incidencias "la búsqueda está rota" causada por índices desactualizados casi desaparece.

Convierte la reconstrucción del índice en un paso estándar después de cada importación masiva: es la corrección de búsqueda más barata que existe y resuelve de golpe una gran parte de las incidencias de "mi búsqueda está rota".

Dónde la búsqueda nativa llega realmente a su techo

Nada de lo anterior convierte el motor nativo en ilimitado. Después de configurar pesos, completar aliases y mantener el índice fresco, quedan cuatro límites reales; esos son los que merece la pena pagar por eliminar.

Esa última columna es la prueba honesta. Si tu dolor está en la primera columna, probablemente ya has agotado lo que la configuración puede hacer, y una capa de búsqueda dedicada es un gasto racional, no un lujo.

Una nota sobre las dos funciones de "búsqueda" de PrestaShop que la gente confunde

Conviene separar dos cosas que ambas suelen llamarse "búsqueda". El cuadro de búsqueda (este artículo) responde a una consulta escrita —"casco de bicicleta"— y está impulsado por la clase Search del núcleo. La búsqueda por facetas (el módulo ps_facetedsearch) es la barra lateral de filtros de la columna izquierda en las páginas de categoría: precio, marca, color, talla; para un cliente que ya está navegando por una categoría y quiere acotar. Resuelven trabajos distintos y normalmente necesitas ambas. Si tu verdadero problema es ayudar a la gente a cribar una categoría grande una vez que ha llegado, ese es el artículo sobre filtrado, no este: consulta ayudar a los clientes a encontrar productos en catálogos grandes y páginas de categoría que convierten.

Qué aporta una capa de búsqueda dedicada, y por qué recupera la inversión

Cuando la búsqueda nativa se te queda pequeña, un módulo de búsqueda específico no solo "busca mejor" en abstracto: elimina los cuatro límites concretos anteriores. Estas son las funciones que importan, formuladas desde el problema de negocio que resuelve cada una:

• Resultados AJAX instantáneos mientras escribe. Un desplegable con productos coincidentes —con imagen, precio y enlace de acceso— aparece antes de que el cliente termine la palabra. Es la mejora de calidad percibida más importante y acorta el camino desde la intención hasta la página del producto.
• Sinónimos gestionados en lugar de aliases uno a uno. Agrupa "couch = sofa = settee" una sola vez y todas las variantes se resuelven, así que un plural olvidado o una palabra regional ya no deja caer una venta.
• Analítica de búsquedas sin resultados. Un registro exacto de qué búsquedas no devolvieron nada convierte búsquedas perdidas en una lista de tareas: cada consulta vacía es un producto que incorporar, un sinónimo que añadir o una descripción que corregir. Son datos de demanda que no puedes obtener de ninguna otra forma.
• Redirecciones y enrutamiento por patrones. Envía una errata conocida, un nombre de marca o una palabra clave de campaña directamente a la página correcta. El enrutamiento por patrones gestiona familias enteras de consultas con una sola regla; por ejemplo, cualquier tamaño "NxN" como "800x800" o "90x90" puede aterrizar en tu página de medidas en lugar de en un conjunto pobre de resultados.
• Merchandising y potenciación. Sube en los resultados los productos con mayor margen, disponibles en stock o de temporada para los términos elegidos, de modo que la búsqueda venda activamente en lugar de limitarse a listar.

Esa es la brecha que nuestro módulo MPR Search Revolution está diseñado para cerrar en PrestaShop: búsqueda AJAX en tiempo real, grupos de sinónimos gestionados, un panel de analítica de búsqueda que saca a la luz consultas sin resultados y tendencias, redirecciones de términos con enrutamiento basado en patrones y potenciación de productos; todo configurado desde el panel de administración, sin cirugía en el tema ni ediciones del núcleo, para que sobreviva a las actualizaciones. Entonces, ¿qué significa esto para ti? Las palancas nativas que de otro modo ajustarías a mano (sinónimos, relevancia, redirecciones) se convierten en un flujo de trabajo gestionado, y las búsquedas que antes perdías en silencio pasan a ser una lista medible y corregible. También mantenemos un simulador de búsqueda en el panel de administración para que puedas probar qué devuelve una consulta concreta antes de que lo hagan tus clientes.

Cómo decidir: un marco breve

Recórrelo en orden y detente en el primer paso que solucione tu problema.

• ¿La búsqueda no devuelve productos que claramente existen? Reconstruye el índice (Parámetros de la tienda → Buscar). Conviértelo en rutina después de cada importación.
• ¿Productos irrelevantes se posicionan por encima de los correctos? Sube el peso del nombre del producto y baja el peso de la descripción larga en esa misma página.
• ¿Fallan unos pocos sinónimos o errores ortográficos conocidos? Añádelos como aliases. Si la lista es corta y estable, los aliases nativos son realmente suficientes; no compres de más.
• ¿Necesitas resultados instantáneos, sinónimos escalables, datos de búsquedas sin resultados o control de merchandising? Esos son los cuatro límites nativos. Aquí una capa de búsqueda dedicada es la decisión correcta, no un retoque de configuración.

La búsqueda forma parte de una imagen más amplia de encontrabilidad

El cuadro de búsqueda es una de las tres formas en que un cliente encuentra un producto, y las otras deben hacer su parte para que la búsqueda no cargue con todo el trabajo. Una estructura de categorías sólida y un menú mega claro permiten navegar hasta lo que se quiere sin escribir nada, mientras que los filtros en página acotan una categoría una vez que el usuario llega. Y como una parte grande y creciente de esas búsquedas ya ocurre en el móvil, el desplegable mientras se escribe debe ser cómodo para el pulgar y rápido; consulta comercio móvil.

Tu barra de búsqueda es uno de los espacios más valiosos del sitio: todo el que la usa ya te ha dicho, con sus propias palabras, exactamente qué vino a comprar. Los clientes que buscan tienden a convertir a una tasa notablemente mayor que quienes solo navegan: tienen intención. Por eso, una búsqueda fallida es un visitante con alta intención de compra saliendo por la puerta. La buena noticia es que las correcciones más baratas (un índice fresco, pesos sensatos, una lista inicial de aliases) son gratis y ya están en tu panel de administración. Invierte en una capa de búsqueda dedicada solo cuando hayas chocado con los límites nativos; y cuando lo hagas, haz que se gane su sitio mostrándote cada día exactamente qué búsquedas estabas perdiendo antes.

Preguntas frecuentes

¿La búsqueda por defecto de PrestaShop gestiona errores tipográficos?

Sí: la coincidencia difusa (aproximada) lleva años incorporada y se controla con el ajuste PS_SEARCH_FUZZY en Parámetros de la tienda → Buscar. Compara una palabra de la consulta con una palabra indexada dentro de una pequeña distancia de edición, de modo que "bycicle" todavía puede llegar a "bicycle". La vieja afirmación de que cualquier errata devuelve cero resultados está desactualizada; la causa habitual de un cero real en una errata evidente es que la búsqueda difusa estaba desactivada o que el índice está desactualizado.

Mi producto está activo, pero buscar su nombre exacto no encuentra nada: ¿por qué?

Casi siempre por un índice desactualizado. PrestaShop busca en las tablas ya construidas ps_search_word / ps_search_index, no en tu tabla viva de productos, así que cualquier cambio de productos realizado fuera de un guardado normal —importaciones masivas, actualizaciones SQL, copias de seguridad restauradas, migraciones— puede dejar el índice describiendo un catálogo que ya no coincide. Reconstruye el índice desde la página de Búsqueda (o desde el endpoint cron anterior) y volverá a aparecer.

¿PrestaShop admite sinónimos?

Sí, con otro nombre: aliases, guardados en ps_alias y gestionados en Parámetros de la tienda → Buscar → Aliases. Asocia "couch" con "sofa", "trainers" con "sneakers", y la palabra del usuario se reescribe a la tuya antes de consultar el índice. Son realmente suficientes cuando la lista es corta y estable; el límite es que cada sinónimo es una fila manual, algo que no escala hasta los cientos que un catálogo real termina necesitando.

¿Por qué productos irrelevantes aparecen por encima de los correctos?

La relevancia se pondera, y los pesos son tuyos. La página de preferencias de búsqueda expone un peso por cada campo indexado: nombre, referencia, descripciones, categoría, etiquetas, atributos, características. Si una búsqueda de "vestido rojo" muestra una caja de herramientas roja, sube el peso del nombre del producto y baja el de la descripción larga para que una coincidencia en el nombre cuente mucho más que una mención suelta en una descripción.

¿Cómo averiguo qué búsquedas no devuelven nada?

La búsqueda nativa no registra las consultas sin resultados de una forma útil, y precisamente por eso la demanda no satisfecha se escapa en silencio. Capturar esa señal —un registro de búsquedas que no devolvieron nada, para que cada una se convierta en un producto que incorporar, un sinónimo que añadir o una descripción que corregir— es uno de los cuatro límites que elimina una capa de búsqueda dedicada (como MPR Search Revolution). Son datos de demanda que no puedes obtener solo con la búsqueda nativa.

¿Cuál es la diferencia entre el cuadro de búsqueda y la búsqueda por facetas?

Son trabajos distintos. El cuadro de búsqueda responde a una consulta escrita y está impulsado por la clase Search del núcleo (este artículo). La búsqueda por facetas (ps_facetedsearch) es la barra lateral de filtros de la columna izquierda en las páginas de categoría —precio, marca, color, talla— para alguien que ya está navegando por una categoría. Normalmente necesitas ambas; si tu verdadero problema es cribar una categoría grande después de llegar a ella, eso pertenece al tema del filtrado, no a este.

Lecturas relacionadas

• Ayudar a los clientes a encontrar productos en catálogos grandes — filtrado por facetas, la otra mitad de la encontrabilidad dentro del sitio.
• Estructura de categorías de PrestaShop para una navegación optimizada para SEO — permitir que la gente llegue a los productos navegando, sin escribir nada.
• Menú mega de PrestaShop: navegación que convierte — un menú claro quita carga al cuadro de búsqueda.