Skip to main content
Esta guía agrega un Worker de Cloudflare a tu zona. El Worker inspecciona el User-Agent, reenvía a Profound las solicitudes de asistentes de IA que coinciden y transmite todo lo demás directamente a tu origen. El Worker llama al endpoint general de Profound, GET https://concierge.tryprofound.com/v1/concierge, y proporciona el host y la ruta originales como encabezados.
Un Worker en una ruta /* se ejecuta en cada solicitud a ese nombre de host, por lo que forma parte de la ruta de solicitudes de producción. El código reintenta en tu origen ante fallos de obtención, un plazo límite para los encabezados de respuesta y los estados 400, 401, 403, 500, 502, 503 y 504. Transmite los demás estados, incluidas las redirecciones, 404 y 429. Adapta la lista de páginas públicas permitidas y el presupuesto de latencia, y luego prueba primero en un nombre de host de staging. Un fallo después de que comienza la transmisión de la respuesta no puede reemplazar de forma transparente un cuerpo enviado parcialmente.

Requisitos previos

  • Una cuenta de Cloudflare con Workers habilitado en la zona
  • Un registro DNS con proxy existente para el nombre de host y un origen accesible a través de él. Usa una Worker Route, no un Worker Custom Domain.
  • Un inventario de las rutas de Worker existentes y superpuestas. Conserva su lógica en lugar de reemplazarla. Si combinarlas requiere un cambio de diseño, detente y revísalo por separado.
  • Un modo de fallo de ruta registrado y una verificación de capacidad frente a los límites de Workers. Usa fail-open para el agotamiento de cuota solo cuando omitir el Worker preserve la seguridad existente. Fail-closed también puede afectar al tráfico humano, antes de que se ejecute el catch de JavaScript.
  • Permiso para agregar rutas de Worker para el nombre de host
  • Tu clave de API de Dynamic Bot Rendering, un dominio registrado, una política de servicio y una página de prueba publicada conocida. Consulta Antes de empezar.

Configuración

1

Crea el Worker

En el panel de Cloudflare, abre Workers & Pages → Create → Create Worker. Asígnale el nombre profound-bot-rendering y despliega el marcador de posición para que el Worker exista.
2

Agrega el código del Worker

En el nuevo Worker, abre Edit code y agrega lo siguiente. Reemplaza las cuatro rutas de ejemplo con páginas públicas revisadas. No sobrescribas la lógica de Worker existente.
El ejemplo concede 2 segundos para los encabezados de respuesta de Profound. Elige un valor acotado que deje tiempo suficiente para la respuesta de tu origen dentro del presupuesto de latencia del asistente. El plazo termina cuando llegan los encabezados; no limita la transmisión del cuerpo de la respuesta. Workers admite AbortController.
3

Guarda la clave de API como secreto

Abre Settings → Variables and Secrets, agrega un secreto llamado PROFOUND_CONCIERGE_KEY y pega tu clave de API. Guarda y despliega.Usa un secreto en lugar de una variable de entorno en texto plano. Los secretos son de solo escritura una vez guardados, por lo que la clave permanece oculta en el panel.Para hacer lo mismo con Wrangler:
4

Asocia el Worker a tu nombre de host

Abre Settings → Domains & Routes → Add route, introduce el patrón para el tráfico de tus páginas y selecciona la zona.
Si tu sitio sirve recursos desde el mismo nombre de host, el Worker igualmente se ejecuta en ellos y los devuelve con una obtención simple del origen. Para mantener el Worker completamente fuera de esa ruta, acota el patrón de ruta en lugar de depender de la verificación de rutas del código.
5

Verifica

Comprueba el enrutamiento y luego verifica por separado la página publicada conocida y el tráfico excluido:
Comprueba el estado HTTP, un x-concierge-request-id válido y x-concierge-bot-kind: chatgpt-user. En tu página de prueba publicada, exige también x-concierge-cache: HIT y el cuerpo HTML esperado. Una solicitud normal de navegador debería permanecer en la ruta de tu origen. Prueba también solicitudes que no sean GET, de API, de recursos y con credenciales.Las comprobaciones completas y el significado de los encabezados están en Verificar y solucionar problemas.

Caché

La llamada ascendente del Worker nunca debe almacenarse en caché. Todas las páginas usan la misma URL ascendente, https://concierge.tryprofound.com/v1/concierge, y el host, la ruta y la consulta que identifican la página viajan solo en encabezados de confianza. Si esa URL se almacenara en caché sin esos encabezados en la clave de caché, distintas páginas o hosts colisionarían, y agregar User-Agent a la clave no lo solucionaría. El ejemplo usa la configuración de fetch cache: 'no-store' y marca las respuestas devueltas por Profound con Cache-Control: no-store. Cloudflare evalúa el almacenamiento en caché según la URL de la subsolicitud fetch, no según la URL del visitante, por lo que las reglas de caché de tu propia zona no se aplican a la llamada ascendente. Antes del despliegue, envía solicitudes repetidas de asistente a dos rutas publicadas y a una variante con consulta de cada una, y confirma que cada respuesta incluye un x-concierge-request-id nuevo. Revisa también cualquier otra capa de caché delante de tu sitio para comprobar la separación entre asistentes y humanos, y qué sucede con las entradas en caché después de publicar un reemplazo, despublicar o pausar. No agregues una clave de caché basada solo en User-Agent como solución alternativa. Si necesitas almacenar en caché las respuestas de Profound en tu edge, comunícate primero con el soporte de Profound: la clave de caché debe incluir la identidad del host, la ruta y la consulta, y debe invalidarse cuando cambien las publicaciones.

Cómo protege el Worker tu sitio

  • Los encabezados ascendentes están en una lista de permitidos. Para las solicitudes enrutadas, el Worker copia solo User-Agent, Accept, Accept-Encoding y Accept-Language, y luego establece la clave, el host y la ruta de confianza. No copia la identidad x-concierge-* ni las credenciales proporcionadas por el cliente. Las solicitudes que llevan cookies o autorización omiten Profound por completo. Las solicitudes ordinarias que se omiten conservan sus encabezados para tu origen.
  • La protección contra bucles no es autenticación. El marcador se puede falsificar; nunca lo uses para omitir reglas de WAF o controles de acceso. Consulta los requisitos previos de contenido público.
  • La protección contra bucles funciona en ambos sentidos. Profound marca con x-concierge-request sus propias obtenciones de origen, y el Worker las transmite directamente. Profound también rechaza cualquier solicitud entrante que lleve ese encabezado, por lo que incluso una regla mal configurada interrumpe una sola solicitud en lugar de entrar en bucle.
  • La clave nunca llega al navegador. Se guarda en un secreto del Worker y solo se adjunta en la llamada ascendente.
  • Las redirecciones se transmiten. redirect: 'manual' devuelve una redirección al asistente en lugar de seguirla, por lo que el manejo de redirecciones sigue siendo decisión de tu origen.