Motores de búsqueda para webs: Elasticsearch, OpenSearch, Algolia y alternativas

En este artículo repasamos las opciones reales que hay hoy para poner un buscador interno en una web: la búsqueda nativa de WordPress, los motores autoalojados (Elasticsearch, OpenSearch, Solr, Meilisearch y Typesense) y los servicios gestionados como Algolia. Verás qué hace bien cada uno, qué cambió en sus licencias y en su disponibilidad, qué plugins existen para WordPress y cómo lo tenemos montado en este mismo blog. También aclaramos qué puedes esperar del buscador en términos de SEO, que es menos de lo que se suele decir.

Qué le pedimos a un buscador interno

Antes de comparar productos conviene fijar los criterios, porque «rápido» por sí solo dice poco. Nosotros miramos estas cosas:

• Relevancia: que el resultado que busca el usuario salga arriba, con control sobre el peso de cada campo (título, extracto, etiquetas).
• Tolerancia a erratas: que «elasticserch» encuentre «Elasticsearch». En sitios pequeños es lo que más se nota.
• Búsqueda mientras se escribe: resultados o sugerencias con cada tecla. Es una función de la interfaz y del tipo de índice, no algo que venga gratis con cualquier motor.
• Facetas y filtros: imprescindibles en catálogos y tiendas.
• Latencia de indexación: cuánto tarda un contenido nuevo en aparecer en los resultados.
• Coste de operación: un servidor de búsqueda autoalojado hay que actualizarlo, monitorizarlo y dimensionarlo; un servicio gestionado se paga por uso.

El punto de partida: la búsqueda nativa de WordPress

Si la web es un WordPress, ya tiene buscador. WP_Query con el parámetro s busca cada término con LIKE '%término%' en las columnas post_title, post_excerpt y post_content, y ordena por relevancia con una regla sencilla: primero la frase completa, luego si todos los términos están en el título, luego si alguno lo está y, por último, si la frase completa aparece en el contenido. No tolera erratas, no pondera campos personalizados ni taxonomías y, con muchas entradas, el LIKE con comodín inicial no puede usar índices de MySQL.

Para sitios pequeños suele bastar con afinarla. Desde WordPress 6.2, WP_Query acepta search_columns, que permite limitar en qué columnas se busca. Por ejemplo, para que la búsqueda del front solo mire título y extracto:

add_action( 'pre_get_posts', function ( $query ) {
	if ( ! is_admin() && $query->is_main_query() && $query->is_search() ) {
		$query->set( 'search_columns', array( 'post_title', 'post_excerpt' ) );
	}
} );

Cuando eso se queda corto (erratas, campos ACF, facetas, miles de entradas), toca un motor de verdad.

Motores de búsqueda para webs

Elasticsearch

Motor distribuido basado en Apache Lucene, con API REST y JSON. Es la opción más completa para volúmenes grandes, búsquedas complejas y analítica, a cambio de ser también la más exigente de operar.

Ojo con la licencia, que ha cambiado dos veces. En 2021 Elastic dejó la licencia Apache 2.0 y pasó a SSPL y Elastic License 2.0 (ELv2). En agosto de 2024 anunció que añadía AGPLv3 como tercera opción. Hoy el código del repositorio se distribuye por defecto bajo AGPLv3, SSPL o ELv2, a elegir, salvo la carpeta x-pack, que sigue solo bajo ELv2 (lo explica el LICENSE.txt del repositorio y la FAQ de licencias de Elastic).

Un matiz técnico que se confunde a menudo: Elasticsearch es near real-time. Un documento no es buscable hasta el siguiente refresh, que por defecto ocurre cada segundo, y solo en los índices que han recibido alguna búsqueda en los últimos 30 segundos (documentación de Elastic). Eso es la latencia de indexación. La búsqueda mientras se escribe es otra cosa y se resuelve con el tipo de campo search_as_you_type o con autocompletado en la interfaz.

OpenSearch y Amazon OpenSearch Service

OpenSearch nació en 2021 como fork de Elasticsearch tras el cambio de licencia y se publica bajo Apache 2.0. Hoy lo gobierna la OpenSearch Software Foundation, un proyecto de la Linux Foundation. Para quien quiera un motor tipo Elasticsearch con licencia permisiva es la alternativa directa. En AWS, la versión gestionada es Amazon OpenSearch Service.

Apache Solr

Solr también se basa en Lucene, es un proyecto de la Apache Software Foundation y tiene licencia Apache 2.0. Lleva muchos años en producción en portales y catálogos grandes, con buena búsqueda facetada. Hoy lo vemos sobre todo en proyectos heredados o en entornos donde ya hay experiencia con él; para una web nueva rara vez es la primera opción.

Meilisearch

Meilisearch está pensado para la búsqueda de cara al usuario: se levanta con un binario, se configura por API y trae activada por defecto la tolerancia a erratas (una errata a partir de cinco caracteres y dos a partir de nueve). La parte comunitaria tiene licencia MIT y algunas funciones de la edición Enterprise van bajo Business Source License 1.1 (LICENSE del repositorio). Se puede autoalojar o usar en su servicio gestionado.

Typesense

Typesense juega en la misma liga que Meilisearch: buscador orientado a la experiencia de usuario, sencillo de desplegar y con tolerancia a erratas configurable (el parámetro num_typos, que por defecto admite hasta dos). Tiene licencia GPL-3.0 y también ofrece servicio gestionado. Ambos son alternativas razonables a Algolia cuando se prefiere autoalojar.

Algolia

Algolia es un servicio gestionado: tú envías los registros a sus índices por API y consultas desde el navegador con una clave de solo búsqueda. No hay servidor que mantener, y las bibliotecas de interfaz (InstantSearch para React, Vue y JavaScript) resuelven el autocompletado, las facetas y la paginación. A cambio, el coste depende del número de búsquedas y de registros.

A fecha de octubre de 2026, su página de precios muestra cuatro planes: Free (incluye 10.000 búsquedas al mes y 50.000 registros), Grow y Grow Plus (de pago por uso por encima de lo incluido) y Elevate (contrato anual a medida). Consulta la página antes de decidir, porque los precios y los límites cambian.

Amazon CloudSearch: cerrado a nuevos clientes

La versión anterior de este artículo recomendaba CloudSearch. Ya no tiene sentido: AWS cerró el acceso a nuevos clientes el 25 de julio de 2024. Quien ya lo usaba puede seguir haciéndolo, pero AWS recomienda migrar a Amazon OpenSearch Service. Para un proyecto nuevo, descártalo.

Plugins para WordPress

En un WordPress tradicional (no headless) no hace falta programar la integración desde cero. Estos son los plugins que hemos revisado:

• Relevanssi: sustituye la búsqueda nativa por la suya, ordena por relevancia y admite coincidencias parciales. Crea su propio índice en la base de datos de WordPress, así que no necesita un servidor aparte, pero ese índice ocupa espacio: el propio plugin estima unas tres veces el tamaño de la tabla wp_posts.
• ElasticPress: conecta WordPress con un servidor Elasticsearch que tienes que instalar y configurar tú, o con ElasticPress.io, su servicio gestionado.
• WP Search with Algolia: indexa entradas, páginas, tipos de contenido personalizados, términos y usuarios en Algolia, y añade autocompletado e InstantSearch. Lo mantiene WebDevStudios, que lo bifurcó cuando Algolia dejó de dar soporte a su plugin original.

Cómo lo hacemos en este blog

Este blog es un WordPress usado como headless CMS con un frontend en Gatsby, así que la búsqueda nativa de WordPress no nos sirve: las páginas son estáticas. Usamos Algolia, en dos partes:

• Indexación en el build: el plugin gatsby-plugin-algolia lanza una consulta GraphQL sobre las entradas y páginas y envía los registros a Algolia al construir el sitio. Indexamos título, extracto, slug, fecha, categorías y etiquetas, no el contenido completo, para mantener los registros pequeños. Esta parte usa la clave de administración, que solo existe en las variables de entorno del build.
• Búsqueda en el navegador: el componente de búsqueda usa algoliasearch/lite e InstantSearch para React con la clave de solo búsqueda, que según la documentación de Algolia es segura en el código del frontend. La de administración nunca llega al navegador.

Una consecuencia de este diseño: un post nuevo no aparece en el buscador hasta el siguiente build. En un blog no es un problema; en una tienda con stock cambiante sí lo sería, y ahí indexaríamos desde WordPress al guardar.

Cómo elegir

• Blog o web corporativa con pocas decenas o cientos de páginas: la búsqueda nativa afinada o Relevanssi. No añadas infraestructura que no necesitas.
• Sitio estático o headless: un servicio gestionado (Algolia) o Meilisearch o Typesense, autoalojados o gestionados. Necesitas un índice fuera de WordPress de todas formas.
• Catálogo grande con facetas, o búsqueda combinada con analítica: Elasticsearch u OpenSearch, con ElasticPress si es WordPress. Antes de elegir Elasticsearch, revisa si su licencia encaja con tu uso.
• En todos los casos: calcula el coste con tu volumen real de búsquedas y registros, y prueba la relevancia con las búsquedas que hacen tus usuarios, no con ejemplos de la documentación.

El buscador interno y el SEO

Un buscador mejor ayuda a que el usuario encuentre lo que busca, y eso puede mejorar la navegación y la conversión. Lo que no hace es subir la web en Google: la documentación de Google no recoge el buscador interno como factor de posicionamiento. Además, las páginas de resultados internas normalmente no se indexan. WordPress, desde la versión 5.7, añade noindex a las páginas de búsqueda por defecto con wp_robots_noindex_search(). Si lo que te preocupa es el rendimiento de la web en Google, mira antes las Core Web Vitals.