Añádelo como fuente preferida en Google
Imagina que tu agencia gestiona el centro de ayuda de WordPress para una empresa de software de reserva de citas. Los clientes no paran de preguntar al servicio de soporte cómo cambiar la fecha de las citas recurrentes. Las instrucciones ya están ahí, pero al buscar «cambiar mis citas del viernes» no aparece la guía.
El cliente quiere probar la búsqueda con IA. En lugar de que los clientes tengan que escribir las palabras exactas de un artículo, el sistema podría relacionar su pregunta con una guía de significado similar. La primera versión mostraría enlaces a la documentación ya existente.
Elegir un proveedor plantea una cuestión más complicada. ¿El servicio que recomiendas hoy seguirá siendo adecuado para tu sitio el año que viene? No puedes prometerlo, y el cliente no debería necesitar esa promesa antes de que empieces.
Puedes dejar las guías originales en WordPress y desarrollar la integración de tal forma que cambiar el servicio de búsqueda no implique tener que volver a crear el centro de ayuda.
Este artículo hace un seguimiento de ese proyecto, desde una prueba limitada hasta su uso más generalizado. Explica qué partes de la configuración deben seguir bajo tu control y cómo el alojamiento puede dar a tu equipo margen para adaptarse, independientemente de la herramienta de IA, las tendencias o la integración que elijas.
No puedes esperar a tener certezas
Te planteo un posible escenario. Tu desarrollador empieza a comparar servicios justo cuando otro proveedor anuncia un nuevo producto de búsqueda. El cliente te reenvía el anuncio: «¿Deberíamos esperar a que salga esto?»
Mientras tanto, el soporte sigue enviando el enlace al mismo artículo.
Antes de comprar nada, tu agencia puede averiguar por qué el buscador actual no encuentra la guía. Es posible que el centro de ayuda guarde los artículos en un tipo de entrada personalizado que la configuración actual del buscador no tiene en cuenta. O quizá el artículo se refiera a las citas recurrentes como «gestión de series», una expresión que los clientes casi nunca usan.
Esos problemas requieren soluciones diferentes, por supuesto. Los desarrolladores pueden comprobar si el buscador de WordPress incluye los artículos del centro de ayuda, y un editor puede añadir la terminología que usan los clientes y aclarar qué instrucciones se aplican a la versión actual del software.
Los tickets de soporte recientes te proporcionan preguntas reales con las que hacer pruebas. El equipo de soporte ya sabe qué guía responde a cada pregunta, lo cual es muy útil. Probar esas preguntas en la web muestra dónde falla la búsqueda, sin tener que adivinar qué podrían escribir los clientes.
Otra forma de mejorar esto es con la búsqueda semántica. Utiliza el aprendizaje automático para encontrar contenido con un significado similar al de la consulta, incluso cuando la formulación sea diferente. Esto ayuda a relacionar frases como «cambiar mis citas del viernes» con otras como «reprogramar citas recurrentes».
La documentación de referencia sigue siendo importante. Si dos guías describen versiones diferentes del software de reservas, el servicio de búsqueda necesita información suficiente para distinguirlas.
Tu agencia puede resolver esos problemas de contenido mientras la decisión de compra sigue en el aire. Cuando pruebas la búsqueda con IA, tienes una biblioteca más ordenada y un conjunto de preguntas con las que comparar.
WordPress sigue siendo la fuente del contenido
Cancelar la suscripción al servicio de búsqueda no debería eliminar ni una sola guía del sitio de WordPress del cliente. Los editores siguen trabajando en WordPress. El proveedor de búsqueda conserva una copia indexada del contenido que le envía la integración.
Esa distinción es importante a la hora de planificar un cambio. Tu agencia tiene que volver a crear el índice de búsqueda a partir de los artículos originales, sin depender de que el proveedor anterior te facilite la única copia que tiene.
En este centro de ayuda, los tipos de entrada personalizados permiten separar las guías de las entradas del blog. Un campo personalizado o una taxonomía pueden indicar la versión del software de reservas que trata cada guía. Esa información forma parte del artículo en WordPress, donde los editores pueden actualizarla.
El código de indexación envía el texto y los metadatos relevantes al servicio de búsqueda. También conserva una referencia al ID de la entrada de WordPress para que el resultado de la búsqueda apunte a la guía correcta.
Las exportaciones del proveedor siguen mereciendo atención. Es posible que tu equipo configure sinónimos o reglas de clasificación en el panel de control del servicio. Puede que sea necesario exportar o documentar esas configuraciones por separado antes de cerrar la cuenta. No deberían ser el único lugar donde registres qué guías cubren el software actual.
Las modificaciones también deben llegar al índice. Cuando un editor sustituye instrucciones obsoletas, la integración debe actualizar o eliminar el contenido indexado correspondiente. Si no se lleva a cabo este paso, la búsqueda seguirá mostrando una respuesta que ya no está incluida en la biblioteca de recursos.
Las guías públicas facilitan la primera prueba. Si más adelante el cliente añade documentación exclusiva para miembros, la integración tendrá que aplicar las normas de acceso del sitio antes de mostrar resultados restringidos o enviar extractos a un modelo de generación de respuestas. El hecho de saber que alguien ha iniciado sesión no significa que podamos saber qué artículos puede leer gracias a su membresía.
Cómo gestionar los cambios de proveedor
El cuadro de búsqueda puede seguir en el tema de WordPress, mientras que un plugin se encarga de gestionar la API del proveedor. El tema envía la consulta al plugin, que a su vez envía la solicitud y convierte la respuesta al formato que espera tu sitio.
Por ejemplo, el plugin puede asociar los identificadores de documentos del proveedor con los IDs de las entradas de WordPress. El tema muestra entonces las guías correspondientes utilizando sus títulos y enlaces permanentes de WordPress. Añadir un nuevo proveedor requiere trabajar en la integración, mientras que el diseño del centro de ayuda puede seguir siendo prácticamente el mismo.
La «búsqueda con IA» también necesita una definición más precisa antes de que puedas calcular ese trabajo.
En un sistema basado en representaciones, un modelo convierte el texto de un artículo en representaciones numéricas llamadas embeddings. Un índice de búsqueda almacena esas representaciones. El sistema convierte la consulta de un visitante en una representación compatible y busca contenido relevante.
Entonces, un modelo de lenguaje grande puede usar los fragmentos recuperados para generar una respuesta, si la funcionalidad incluye ese paso. Para mostrar enlaces a artículos relevantes no hace falta una respuesta generada.
Es posible que tu agencia adquiera todas estas funciones juntas a través de un proveedor de búsqueda administrada. Otra forma de implementarlo podría ser utilizando servicios independientes. Sea como sea, el desarrollador tiene que saber a qué parte afecta el cambio que se propone.
A menudo puedes sustituir el modelo que genera las respuestas y conservar el índice de búsqueda actual. Cambiar de modelo de incrustación suele implicar volver a generar las incrustaciones de los documentos y reconstruir el índice. Además, las puntuaciones de relevancia pueden variar según el proveedor, así que tu desarrollador tiene que comprobar si el umbral actual sigue seleccionando resultados útiles.
Hay que tener en cuenta unos datos recientes recopilados en la encuesta de Andreessen Horowitz de 2025, realizada a 100 directores de sistemas de información (CIO) de empresas. La encuesta revela que el 37 % de los CIOs utilizan al menos cinco modelos, frente al 29 % de la encuesta anterior. Para este cliente hipotético, quizá un solo servicio sea suficiente, pero lo que realmente importa es entender qué implicaría cambiarlo más adelante.
Un pequeño plugin puede proporcionar esa separación sin convertir el proyecto en un framework para todos los proveedores imaginables. La forma en que está programado y configurado debería hacer que el trabajo de reemplazo sea lo suficientemente claro como para poder estimarlo.
Dale a los experimentos un alcance manejable
Veinte guías públicas sobre la gestión de citas proporcionan al equipo material suficiente para una primera prueba útil. El personal de apoyo recopila las preguntas que hacen los clientes e identifica el artículo que debería responder a cada una de ellas.
El desarrollador introduce esas consultas tanto en el buscador actual como en el servicio de prueba. ¿Aparece la guía correcta entre los primeros resultados? ¿Distingue el buscador entre cambiar una cita concreta y cambiar todas las citas futuras de una serie?
La prueba también tiene que incluir preguntas que la documentación no pueda responder. Una consulta sobre una funcionalidad que no está disponible no debería llevar a los clientes a instrucciones que no tengan nada que ver solo porque la redacción se parezca.
Si la prueba incluye respuestas generadas, estas deben revisarse por separado. Una respuesta puede citar la guía correcta pero explicar mal un paso. El equipo de soporte debería comprobar si un cliente que siga la respuesta puede completar la tarea.
Un periodo de prueba de cuatro semanas te da tiempo suficiente para decidir si quieres seguir con esa herramienta en concreto. El presupuesto también tiene que tener un límite. Si el proveedor no establece un límite máximo de gasto, la herramienta debe tener límites de uso que impidan nuevas solicitudes de pago antes de que se agote el presupuesto acordado. Una simple alerta por correo electrónico no detiene los cobros, así que es mejor planificarlo con antelación.
El estudio de Deloitte de 2026 sobre «El estado de la IA en la empresa» señala que solo el 25 % de los encuestados lleva a producción alrededor del 40 % de sus experimentos con IA, así que conviene tener en cuenta que quizá no sea la mejor opción.
Prepárate para los cambios en la carga de trabajo
La prueba funciona tan bien que el cliente quiere promocionarla en el newsletter para clientes. Que unos cuantos compañeros del servicio de soporte prueben las búsquedas durante una reunión no te va a dar una idea de cómo se adapta la integración a ese público.
Imagina que el plugin de WordPress hace una solicitud API sincrónica por cada búsqueda. Su hilo de PHP se queda ocupado mientras espera la respuesta externa. Si se hacen varias búsquedas lentas a la vez, puede quedar menos capacidad para otras solicitudes que no estén en caché.
Por eso conviene probar las búsquedas simultáneas antes de enviar el newsletter. Tu desarrollador puede medir cuánto tardan los resultados y comprobar si el resto del sitio sigue respondiendo bien. Los límites de rate del proveedor externo también deben incluirse en esa prueba.
Los costes de uso también hay que tenerlos en cuenta. Un visitante puede hacer varias consultas. Si la funcionalidad genera respuestas, la cantidad de texto que se envía al modelo y que este devuelve puede afectar a los cobros por token. Los registros de solicitudes de la prueba te dan una estimación más precisa que simplemente multiplicar el número de visitantes por el coste de una búsqueda.
La indexación genera trabajo fuera de las sesiones de los visitantes. Al actualizar una guía, normalmente debería actualizarse su contenido indexado, en lugar de volver a generar las representaciones para todo el centro de ayuda. El desarrollador tiene que comprobar qué hace realmente el plugin o servicio elegido cuando un editor hace clic en Actualizar.
La expansión puede seguir siendo selectiva. Si a los clientes les resultan útiles los enlaces pero casi nunca leen los resúmenes generados, el cliente puede mantener la búsqueda semántica y desactivar la generación de respuestas. Separar esos ajustes les ofrece una forma concreta de reducir costes sin renunciar a la mejora que valoran.
Razones para replanteárselo
Si un proveedor retira la API que usa tu plugin, hay que programar un cambio. El anuncio de un nuevo modelo puede esperar hasta que haya un motivo para investigarlo.
Aquí es donde resulta útil la distinción entre componentes. Si tu agencia elige y contacta directamente con una modelo, tiene que llevar un control de su disponibilidad. Un servicio de búsqueda administrado puede gestionar los cambios de modelo internamente, mientras que tu equipo supervisa los avisos de su API y la calidad de sus resultados.
Las preguntas de la prueba se convierten en un pequeño conjunto de pruebas de regresión. Un desarrollador puede ejecutarlas tras una actualización importante del proveedor o con una alternativa propuesta. Los resultados esperados hacen que el debate sobre «una búsqueda mejor» sea mucho más concreto.
En la consulta sobre citas recurrentes, ¿sigue apareciendo la guía actual en la parte superior? Si la funcionalidad genera una respuesta, ¿mantiene la diferencia entre modificar una cita concreta y modificar la serie de citas?
Las comparaciones necesitan un contenido de origen coherente. Comparar a un proveedor con los artículos del mes pasado y a otro con guías reescritas no te dice gran cosa sobre los propios proveedores. El informe de la prueba debería indicar la revisión del contenido y la configuración relevante del modelo o del servicio.
Los tickets de soporte pueden incluir nuevas consultas a medida que los clientes detectan deficiencias. Así, quien se encargue de sustituir el servicio tendrá que lidiar con las cuestiones que realmente causan problemas en esta web.
El coste también puede justificar otra revisión. Un modelo más barato para las respuestas generadas puede ser adecuado para el cliente, siempre y cuando las respuestas sigan siendo precisas. Una puntuación de referencia general te da menos información útil que su rendimiento en la propia documentación del cliente.
Elige un alojamiento que te dé margen para hacer ajustes
Un sitio staging de WordPress es una forma estupenda de que los desarrolladores puedan instalar una herramienta alternativa mientras los clientes siguen usando el buscador en producción. Kinsta ofrece entornos staging para este tipo de trabajo, con la opción Staging Premium disponible para pruebas que necesiten más recursos.
La configuración de la búsqueda externa también hay que separarla. Al clonar WordPress, se pueden copiar los ajustes de los plugins que apuntan al índice de producción. Antes de ejecutar una tarea de indexación en el entorno staging, el desarrollador tiene que configurar un índice de prueba y unas credenciales con los permisos adecuados. Si no, una prueba en el entorno staging podría alterar los resultados de búsqueda del sitio en producción.
La monitorización del rendimiento de aplicaciones de Kinsta ayuda a investigar la parte de WordPress de la integración. Con el APM activado, tu desarrollador puede examinar las solicitudes externas lentas del lado del servidor y las consultas a la base de datos. Las llamadas del lado del navegador requieren diagnósticos del navegador. El APM no muestra todas las solicitudes que realiza el navegador de un visitante.
Esos registros pueden revelar si WordPress dedica la mayor parte del tiempo de una búsqueda lenta a esperar al proveedor. Aumentar la capacidad de alojamiento no acortará el tiempo de respuesta de ese proveedor.
Cuando las pruebas detectan una limitación de capacidad de PHP, MyKinsta te ofrece ajustes de los recursos de PHP dentro de las opciones de plan disponibles. Un mayor número de hilos de PHP permite gestionar más solicitudes simultáneas, pero repartir el mismo pool de memoria entre más hilos reduce la memoria disponible para cada uno. Las comparaciones de rendimiento también necesitan recursos staging y configuraciones de caché que reflejen de forma razonable el entorno de producción.
A medida que tu agencia vaya realizando pruebas en más sitios, los endpoints de la API de Kinsta permiten que las herramientas internas recuperen detalles del entorno o creen entornos staging. El equipo puede automatizar esa preparación sin que el proveedor de búsqueda tenga control sobre la cuenta de alojamiento.
Tu agencia sigue decidiendo si la sustitución funciona lo suficientemente bien como para lanzarla. El entorno de alojamiento ofrece un lugar para probar esa decisión e investigar los resultados.
Los compromisos de la propuesta
«Añadir búsqueda con IA» deja demasiado margen para malentendidos. Tu presupuesto puede incluir enlaces a artículos relevantes, mientras que el cliente espera un chatbot que escriba respuestas completas.
La propuesta debería describir lo que ven realmente los clientes. Para este proyecto, el compromiso inicial podría abarcar la búsqueda semántica en veinte guías públicas, quedando las respuestas generadas sujetas a una decisión aparte.
Unas cuantas preguntas ayudan a aclarar las dudas que aún quedan:
- ¿Qué problema aborda la prueba? Los clientes no encuentran las instrucciones actuales para gestionar citas. Las consultas de prueba acordadas reflejan esas solicitudes de soporte.
- ¿Qué queda bajo el control del cliente? WordPress conserva las guías originales y sus metadatos. La agencia documenta los ajustes de búsqueda que solo existen en el panel de control del proveedor.
- ¿Qué depende de este servicio? La propuesta identifica la integración de la búsqueda en el centro de ayuda y cualquier API de modelo a la que recurra. El resto del sitio web sigue usando su búsqueda habitual.
- ¿Cómo detiene el cliente el experimento? Una opción restaura la búsqueda actual. El procedimiento de desactivación también detiene las tareas de indexación programadas y cancela los servicios de pago innecesarios.
- ¿Qué justifica un despliegue más amplio? El cliente acuerda qué se considera un resultado relevante y cuánto tiempo pueden esperar los visitantes. El uso durante el periodo de prueba sirve para calcular los costes de funcionamiento.
El lanzamiento a mayor escala requiere su propio presupuesto para indexar el resto de la biblioteca y realizar pruebas en condiciones de uso más intensivo. Hacer una estimación independiente para ese trabajo permite que el cliente evalúe la fase de prueba antes de comprometerse con ella.
La propuesta también puede indicar quién revisa los resultados al cabo de cuatro semanas. Si no, la próxima renovación de la suscripción tomará la decisión por defecto.
Margen para la próxima decisión
El cliente del software de reservas puede averiguar si la búsqueda semántica ayuda a los clientes a encontrar la guía de citas sin tener que comprometerse con un proveedor durante los próximos cinco años.
Los artículos originales se mantienen en WordPress. Si la prueba no da los resultados esperados, el cliente conserva las mejoras editoriales y vuelve al sistema de búsqueda actual. Si tiene éxito, tu agencia tendrá pruebas que justifiquen un despliegue más amplio.
Un cambio de proveedor en el futuro sigue requiriendo trabajo. Alguien tiene que adaptar la integración de la API y probar los resultados. Dependiendo del cambio, reconstruir el índice puede llevar tiempo y acarrear costes de uso. Mantener esas tareas separadas del resto de la web hace que sean más fáciles de planificar.
Es un tipo de control muy útil que puedes ofrecer al cliente. Puedes explicarle a qué se está comprometiendo hoy y qué implicaría tomar otra decisión más adelante.
El alojamiento administrado para WordPress de Kinsta ofrece a tu equipo entornos staging y herramientas de rendimiento para respaldar esas decisiones. Tu agencia puede probar ahora una función útil de IA, con una vía clara para cambiarla a medida que evolucionen las necesidades del cliente.
