Búsqueda WordPress Enterprise que ordena por relevancia, no por fecha

No, pero VIP es el camino más corto. Ahí Enterprise Search corre sobre Elasticsearch, gestionado por Automattic, así que nadie de tu lado ni del nuestro opera un clúster de búsqueda.

Fuera de VIP cambia el motor. SearchWP da un control más fino sobre qué se indexa y funciona bien en hosting autogestionado, aunque no es compatible con VIP. Algolia es una opción gestionada para sitios que no están en VIP, y todavía no la usamos en un proyecto con cliente. La capa de interfaz es la misma en cualquiera de los casos.

La búsqueda de sitio responde a una consulta escrita. La búsqueda por facetas atiende a quien todavía no sabe cuál es la palabra correcta, y le permite acotar una lista por atributos que ya tenés guardados: tipo de contenido, industria, año de publicación, autor, región.

La mayoría de las bibliotecas enterprise necesitan las dos, y la primera decisión es para cuál de ellas es cada página. Quien quiere buscar, quien quiere explorar y quien quiere filtrar necesitan interfaces distintas. Intentar servir a los tres con un solo campo es la forma en que las páginas de búsqueda terminan sin conformar a nadie.

Más de lo que la mayoría de los equipos espera. Las facetas se hacen con estructura, así que si todo es una entrada genérica no hay nada por lo que filtrar. Antes de empezar el desarrollo de la búsqueda necesitamos:

• Custom post types y taxonomías definidos, no improvisados durante el desarrollo.
• Campos ACF especificados, con una decisión sobre cuáles se indexan.
• Un diseño para los resultados y los filtros, ya que Enterprise Search viene sin front end.
• Un hosting que soporte el motor que hayas elegido.

Por eso la búsqueda avanzada normalmente va después de la arquitectura de contenido y no en paralelo.

El motor indexa lo que tu modelo de contenido expone, así que la búsqueda multilingüe y multisitio es en gran medida una cuestión de especificación: qué sitios comparten un índice, qué filtros aparecen en cada lugar y cómo se representa un idioma en los datos.

Esas decisiones pertenecen a la fase de requerimientos, no a un retrofit. Cómo se estructura el contenido en sí entre idiomas lo cubrimos en nuestra página de sitios multilingües, y la capa de búsqueda hereda lo que esa estructura decida.

Indexando menos de lo que creés que necesitás. Cada campo indexado de más cuesta rendimiento, así que el índice es una lista deliberada y no una copia de todo el modelo de contenido.

El resto es práctico. Usar la consulta propia del plugin de búsqueda en lugar de un WP_Query estándar para que las dos no peleen entre sí, y mantener el filtrado pesado fuera del front end.

Nuestro objetivo interno de QA para el tiempo de respuesta es de menos de 500 milisegundos, verificado junto con el comportamiento de los filtros combinados, los resultados en móvil y entre navegadores. Ese es el umbral contra el que aceptamos el trabajo, no un benchmark medido en la plataforma de un cliente.