Un cliente busca un producto que vendes, recibe una lista vacía y
prueba en otra tienda. El equipo de atención encuentra el artículo en el
panel y concluye que está correctamente registrado. Ambas observaciones
pueden ser ciertas: existir en el catálogo no demuestra que el producto
esté disponible para la búsqueda de la tienda.
Conviene separar tres preguntas: ¿el producto puede aparecer en ese
contexto, sus términos están representados en el índice y la consulta
coincide con ellos? Solo después corresponde investigar la posición del
resultado. Esta guía propone un diagnóstico reproducible con ejemplos
ficticios, basado en la documentación de PrestaShop 9 consultada el
14/09/2026. En otras versiones o con módulos de búsqueda, confirma las
funciones disponibles antes de ejecutar comandos.
1. Reproduce
la consulta del cliente, no una parecida
Elige un producto y registra su ID, nombre, referencia principal,
referencias de combinaciones, idioma y tienda. Copia el término exacto,
incluidos guiones, espacios, acentos y códigos. Anota si el cliente
utilizó las sugerencias mientras escribía o abrió la página completa de
resultados.
Haz la prueba como visitante y, cuando corresponda, con el mismo
grupo de clientes. No compares una búsqueda en español con un registro
revisado únicamente en inglés. En multitienda, utiliza el dominio y el
contexto correctos.
Conserva una evidencia sencilla: consulta, resultado esperado,
resultado observado, URL y hora. «La búsqueda no funciona» es difícil de
investigar. «LX-204 no encuentra el producto 42 en la tienda 2 en
español, pero lámpara sí» delimita considerablemente el problema.
2. Identifica
qué componente responde a la búsqueda
El cuadro de búsqueda puede parecer parte del tema, mientras que los
resultados proceden del motor nativo, un módulo o un servicio externo.
El autocompletado y la página completa también pueden seguir caminos
distintos.
Abre el panel de red del navegador y ejecuta la consulta. Identifica
la petición que devuelve los resultados, sus parámetros y el componente
responsable. Una respuesta HTTP 200 con una lista vacía es diferente de
un error de JavaScript que impide mostrarla.
Si interviene un motor externo, revisa su catálogo sincronizado y sus
registros de procesamiento. Reconstruir el índice nativo no demuestra
que el otro motor se haya actualizado. Documenta la arquitectura antes
de cambiar ajustes; así evitas corregir un componente que el cliente ni
siquiera está utilizando.
3.
Comprueba si el producto puede aparecer antes de reconstruir el
índice
Confirma que el producto está activo, asociado a la tienda correcta y
configurado con una visibilidad que permita mostrarlo en la búsqueda.
PrestaShop distingue opciones de visibilidad; acceder mediante una URL
directa no demuestra que deba aparecer en todos los espacios de la
tienda. Consulta las opciones de la versión instalada en la documentación
de productos.
Investiga también restricciones introducidas por módulos, reglas de
acceso y filtros de disponibilidad. No consideres las existencias a cero
una explicación universal: la operación puede permitir productos
agotados y una personalización puede filtrarlos de otra manera.
Si el problema afecta a un solo idioma, compara los campos
localizados realmente guardados. Si afecta a una sola tienda, revisa sus
asociaciones y ajustes. Reconstruir todo antes de esas comprobaciones
puede consumir tiempo y reproducir exactamente el mismo resultado.
4.
Entiende el índice como una estructura separada del registro
La búsqueda nativa relaciona palabras y productos mediante tablas de
índice. La documentación identifica ps_search_word, con
contexto de tienda e idioma, y ps_search_index, con
relaciones entre palabra, producto y peso. El prefijo real de la base de
datos puede ser distinto de ps_. Estructura
oficial del índice.
Esto permite investigar por etapas: ¿existe el término normalizado en
el contexto correcto? ¿Está relacionado con el producto esperado? ¿El
producto supera los filtros de la consulta? ¿El resultado llega al
navegador? No hace falta empezar modificando registros directamente en
la base de datos.
Una importación puede escribir campos sin seguir el mismo proceso de
actualización que utiliza el panel. Si el defecto reaparece después de
cada importación, la solución duradera está en ese proceso y en su
observabilidad. Una reconstrucción manual que funciona durante unas
horas es una evidencia, no el final del diagnóstico.
5. Ejemplo
completo: el nombre funciona, la referencia no
Considera el producto ficticio Lámpara de escritorio
articulada, ID 42, referencia LX-204. El
equipo quiere que los clientes lo encuentren tanto por su descripción
como por el código del embalaje.
| Consulta | Qué comprobar |
|---|---|
| lámpara | Coincidencia por nombre en el idioma correcto. |
| LX-204 | Referencia guardada, campo considerado y tratamiento del guion. |
| LX204 | Variante sin separador; no asumir equivalencia automática. |
| LX | Término corto; comparar con la longitud mínima configurada. |
| lámpraa | Error de escritura; probar los alias o la búsqueda aproximada disponibles. |
Ejecuta la primera consulta. Si encuentra el artículo, sabes que el
producto no está ausente de todas las búsquedas. Revisa después el
código guardado: ¿es la referencia del producto, de una combinación o
solamente texto en una imagen? No debes presumir que el buscador lee una
fotografía del embalaje.
Compara las variantes del código y registra sus resultados. No
elimines todos los guiones del catálogo por una sola prueba. Podrías
modificar identificadores utilizados por otros procesos. Averigua
primero si la diferencia procede del registro, la normalización o los
ajustes del motor.
Tras la corrección elegida, repite todas las consultas de la tabla.
Resolver LX-204 y perjudicar la búsqueda por nombre no es aceptable.
Añade productos similares para comprobar si el motor empezó a devolver
coincidencias irrelevantes.
6. Términos cortos,
palabras ignoradas y alias
Los ajustes incluyen longitud mínima de palabra, palabras ignoradas,
alias y funciones de coincidencia aproximada. Los pesos de los campos
influyen en la relevancia. Estos controles tienen finalidades diferentes
y deben evaluarse por separado. Parámetros
oficiales de búsqueda.
En un catálogo técnico, dos letras pueden identificar una línea
comercial importante. En otro pueden generar resultados poco útiles.
Prepara una lista de consultas cortas relevantes antes de reducir
límites globalmente. Compara calidad de resultados y coste de
procesamiento en una copia de la tienda.
Un alias puede ser apropiado para un error recurrente y bien
identificado, como intercambiar letras en «lámpara». No utilices un
diccionario enorme para compensar fichas incompletas. Cada relación
necesita una intención clara y una prueba que demuestre que ayuda al
comprador.
La búsqueda aproximada tampoco equivale a comprensión semántica. En
referencias técnicas, una diferencia visual pequeña puede conducir a un
producto incompatible. Mantén pruebas por referencia exacta junto a las
de tolerancia a errores.
7.
Producto ausente y producto mal posicionado son fallos distintos
Si el artículo aparece en la quinta página, hay coincidencia, pero
quizá la ordenación no atiende a la intención de la consulta. Si no
aparece en ninguna, aumentar el peso del nombre puede no resolver la
causa.
Prepara un conjunto de consultas con resultados esperados: código
exacto, nombre específico, categoría amplia y término presente solo en
la descripción. Define para cada una si esperas un producto concreto o
un grupo coherente. No existe una única ordenación perfecta para todas
las intenciones.
Cambia un peso cada vez y repite las pruebas. Comprueba si la
implementación instalada necesita reconstruir el índice para reflejar el
cambio en los pesos utilizados. No supongas que guardar un ajuste ha
reprocesado todos los datos existentes.
Evita repetir palabras en las descripciones para forzar una posición.
Además de empeorar la lectura, eso hace que el catálogo dependa de un
comportamiento específico del motor. Ajusta la relevancia en el lugar
adecuado y conserva textos útiles para el comprador.
8.
Reindexa con un alcance definido y verifica la finalización
En el panel, distingue añadir artículos ausentes de reconstruir todo
el índice. Un producto ya indexado, pero con términos antiguos, puede
necesitar una operación diferente de la incorporación de productos
nuevos. Programa las operaciones amplias fuera de las horas punta y
evita reconstrucciones simultáneas.
En instalaciones que dispongan del comando documentado para
PrestaShop 9, consulta primero la ayuda local:
php bin/console prestashop:search:index --helpPara investigar el ejemplo en una copia controlada, sustituye los ID
por los reales:
php bin/console prestashop:search:index --shop-id=2 --product-id=42No añadas --full sin definir el alcance: elimina y
reconstruye datos del índice. Confirma la disponibilidad del comando y
sus opciones en la versión instalada. Comando
oficial de indexación.
Registra duración, salida y código de finalización. Después comprueba
el resultado en la tienda. Si utilizas tareas programadas, supervisa las
ejecuciones reales, no solo la existencia de la tarea. Protege las URL
de mantenimiento con token y no las expongas en capturas públicas.
9.
Cuándo investigar base de datos, módulos y presentación
Si el índice contiene los términos esperados, examina el recorrido de
la consulta. En un entorno de diagnóstico, relaciona la hora de búsqueda
con registros y peticiones. Observa contexto, parámetros, filtros,
ordenación y paginación.
Si el servidor devuelve el producto pero la interfaz no lo muestra,
investiga el tema, JavaScript y la presentación. Si el autocompletado y
la página completa discrepan, compara ambos endpoints. Trata la caché
como una hipótesis concreta: identifica qué capa almacenó qué respuesta
antes de vaciar todo indiscriminadamente.
Cuando hay lentitud, el profiling puede ayudar a localizar el coste,
pero no explica por sí solo por qué se excluyó un producto. Diferencia
tiempo de ejecución y corrección funcional. Conserva un caso
reproducible antes de cambiar módulos o modificar código.
10. Criterios
para dar por resuelta la incidencia
Considera resuelto el problema cuando las consultas aprobadas
devuelvan los resultados esperados en el contexto correcto, el proceso
de actualización mantenga ese comportamiento y el equipo pueda repetir
la verificación.
Registra causa, cambio, pruebas y procedimiento para revertir los
ajustes. Repite una importación o edición representativa y confirma que
el fallo no vuelve. Para supervisar la calidad, la operación puede medir
búsquedas sin resultados, reformulaciones y clics posteriores si esa
recopilación está implementada; no presupongas que todas esas métricas
ya existen en la instalación.
Una búsqueda fiable depende de que catálogo, índice, consulta y
presentación funcionen de forma coherente. AGTI puede ayudar a localizar
la etapa que falla y corregir el proceso que la alimenta. Contacta con el equipo con una
consulta real y el producto que debería aparecer.
