Skip to main content

​
Prueba tu configuración

Cada una de las comprobaciones siguientes envía una solicitud GET. El contrato de Profound solo cubre GET, así que usa curl -sD - -o /dev/null en lugar de curl -I, que envía HEAD. Una respuesta HEAD puede provenir de tu origen o de un controlador que omite el cuerpo, y no te dice nada sobre el enrutamiento.
1

El tráfico de asistentes debe llegar a Profound

Busca un UUID en x-concierge-request-id y x-concierge-bot-kind: chatgpt-user. Juntos demuestran que tu CDN enrutó la solicitud a Profound y que Profound reconoció al asistente. No demuestran que se haya servido una página renderizada: un MISS con x-concierge-failopen: 1 significa que Profound devolvió el contenido en vivo de tu origen.
2

Tu página de prueba publicada debe servirse desde Profound

En la página que publicaste durante la configuración, exige también x-concierge-cache: HIT y el HTML renderizado. Guarda el cuerpo para compararlo y deja que curl lo descomprima por si Profound lo sirvió con codificación gzip:
Si esta solicitud es un MISS, revisa los encabezados x-concierge-policy como se describe en Interpretar el resultado. Repetir la solicitud no convierte un MISS en un HIT; solo publicar un renderizado lo hace.
3

El tráfico humano no debe verse afectado

No esperes encabezados x-concierge-* y sí el mismo contenido de página que antes. Compara también la latencia y las tasas de aciertos de caché con tu línea base: un Worker o un cambio en una política de caché compartida puede afectarlas incluso cuando el enrutamiento no cambia.
4

Los rastreadores de búsqueda no deben verse afectados

Tampoco esperes encabezados x-concierge-*. Si esta solicitud se enruta, consulta Problemas comunes.
5

El tráfico excluido debe mantener su comportamiento actual

En staging, envía métodos distintos de GET, solicitudes a /api/users, /graphql, autenticación, administración, recursos del framework y activos, incluidos endpoints sin extensión. Usa endpoints de prueba inofensivos para los métodos que podrían modificar datos, y valores de prueba no secretos para cookies y encabezados de autorización. Todos ellos deben permanecer en tu ruta actual. En Vercel, prueba también los hosts de vista previa y alternativos.
6

Prueba el comportamiento ante fallos de forma segura

Usa staging o una configuración aislada, registra la configuración original y restáurala después de cada prueba.
  • Cloudflare: prueba un upstream inaccesible, un tiempo de espera de encabezados de respuesta y uno de los estados de respaldo configurados. Espera contenido del origen con x-concierge-cdn-failover: 1. Las redirecciones, 404 y 429 se transmiten tal cual, y una respuesta que ya ha comenzado a transmitirse no se puede reemplazar.
  • CloudFront: prueba los tiempos de espera de conexión y de respuesta del origen principal dentro del presupuesto configurado y los criterios de estado seleccionados. Espera el origen de respaldo para los fallos configurados, pero no para 401. Envía solicitudes no almacenadas en caché y ten en cuenta que las respuestas de respaldo en caché persisten hasta que expire su TTL, incluso después de restaurar el origen principal.
  • Vercel: no hay conmutación por error a nivel de CDN. Durante una interrupción de Profound o tras un rechazo definitivo, un asistente puede recibir un error. No esperes un respaldo transparente al origen.
Después de restaurar la configuración, espera a que se propague y repite las comprobaciones de enrutamiento y de la página publicada.

​
Ejecuta la verificación de la configuración desde el dashboard

El dashboard de Profound puede probar el enrutamiento por ti. Envía una solicitud con cada uno de los nueve valores de User-Agent de asistentes compatibles a una URL de tu host registrado, desde fuera de tu red, e informa cuáles enrutó tu CDN a Profound. Estas sondas no llevan credenciales ni marcador de bucle, por lo que tu CDN las ve como tráfico real de asistentes. Un asistente cuenta como enrutado solo cuando su respuesta incluye un ID de solicitud válido y el tipo de bot correspondiente. Un MISS, un dominio en pausa, una redirección o un estado distinto de 200 pueden igualmente confirmar el enrutamiento; el estado de la página se informa por separado. Asegúrate de que la URL que pruebas esté en tu lista de páginas públicas permitidas; de lo contrario, todos los asistentes aparecerán, correctamente, como no enrutados.
La verificación de la configuración es una observación en vivo de una URL en un momento concreto. Confirma que la regla de tu CDN se activa para cada asistente. No verifica la propiedad del dominio y no sustituye la comprobación manual de tu página de prueba publicada.

​
Referencia de encabezados de respuesta

​
Interpretar el resultado

​
Respuestas de error

Profound solo recurre a tu origen después de que una solicitud está autenticada y es válida. Los errores de configuración se rechazan en lugar de redirigirse por proxy. El Worker de Cloudflare enmascara sus estados de rechazo configurados sirviendo tu origen, y CloudFront enmascara 400 y 403, pero no 401. Vercel no tiene reintentos. Cuando aparezca una página del origen donde esperabas un rechazo, inspecciona los diagnósticos de tu CDN.

​
Problemas comunes

Tu patrón de User-Agent coincide con algo fuera de la lista de tokens compatibles. Compáralo con el patrón de tu guía de configuración y con los asistentes compatibles. Los rastreadores de búsqueda como Googlebot deben seguir llegando a tu origen.
CloudFront reemplaza el User-Agent del visitante por Amazon CloudFront en las solicitudes al origen, a menos que una política de solicitudes al origen lo reenvíe. Entonces Profound no tiene nada que clasificar. Usa la política de solicitudes al origen personalizada y restringida de la guía de CloudFront. Evita AllViewer, que también reenvía el Host del visitante y puede romper la conexión con Profound. Añade User-Agent a la política de solicitudes al origen, no a la clave de caché.
La lista de asistentes permitidos de la regla ganadora lo excluye. La respuesta muestra x-concierge-policy: off junto con el ID de la regla. Añade el asistente a la lista, o vacía la lista para que la regla herede el valor predeterminado del dominio.
Alguna capa de caché almacena HTML sin separar las respuestas de asistentes y humanos, o sin separar hosts, rutas y cadenas de consulta.En CloudFront, incluye x-concierge-route en la clave de caché, mantén el TTL mínimo en 0 y revisa las variantes de host y de consulta. En Cloudflare, verifica que la llamada al upstream del Worker omita la caché; usar solo el User-Agent como clave no puede separar las identidades de página, porque todas las páginas usan la misma URL de upstream. En Vercel, inspecciona la configuración de caché de reescrituras externas del proyecto. En todos los proveedores, revisa también qué ocurre con las entradas en caché después de publicar un reemplazo, despublicar o pausar: una entrada de la CDN puede sobrevivir al cambio en Profound.
La protección contra bucles está fallando. Tu regla debe dejar que las solicitudes que llevan x-concierge-request pasen directamente a tu origen. Profound añade ese encabezado a sus propias solicitudes al origen y rechaza con 400 cualquier solicitud entrante que lo lleve, de modo que una exclusión defectuosa se traduce en una solicitud fallida en lugar de un bucle.En Vercel, se trata de una condición missing sobre x-concierge-request con el valor ^1$, el marcador que añade Profound. Cualquier otra expresión regular desactiva la exclusión sin avisar, porque una condición missing con un valor solo excluye las solicitudes cuyo encabezado coincide con él.
Las cadenas de consulta forman parte de la identidad de la página. Si tu CDN las elimina antes de la solicitud al origen, /product?id=a y /product?id=b se reducen a /product, y se renderiza y sirve la variante incorrecta.En CloudFront, incluye en la política de caché las cadenas de consulta de las que dependen tus páginas, o “All”. Una política de solicitudes al origen puede reenviar cadenas de consulta adicionales sin incluirlas en la clave, así que verifica el reenvío y la identidad de caché por separado.
Lee x-concierge-policy y x-concierge-policy-source en la respuesta. Si no hay ninguna regla coincidente, el modo es off, y warm sirve contenido en vivo del origen incluso cuando existe una publicación. Establece la regla ganadora en serve.Luego confirma que se revisó y publicó un candidato para esta ruta y consulta exactas. La aprobación por sí sola no lo publica, y las solicitudes repetidas tampoco. Un candidato retenido como pendiente sigue pendiente hasta que alguien lo apruebe, lo rechace o lo publique. Si la página está publicada y la política es serve, pero sigues viendo un MISS, revisa las cachés de tu CDN y la accesibilidad de tu origen.
Revisa las reglas de WAF, los desafíos de bots, la protección de despliegues y las listas de permitidos del origen, tanto para el tráfico entrante de asistentes como para las solicitudes de Profound al origen. Profound no reenvía las cookies ni los encabezados de autorización del visitante, por lo que las páginas protegidas o dependientes de la sesión deben quedar fuera de esta configuración. El marcador de bucle se puede falsificar y no debe usarse como forma de eludir el firewall o la autenticación. Si tu origen necesita una forma de identificar las solicitudes de Profound, contacta con el soporte de Profound.

​
Desactivarlo

Para dejar de servir renderizados sin tocar tu CDN, pausa el dominio en el dashboard de Profound. Todas las solicitudes de asistentes van a tu origen mientras se conservan tus reglas, renderizados y publicaciones, y al reanudarlo se restauran. Una pausa surte efecto en Profound de inmediato, pero las respuestas que tu CDN ya almacenó en caché persisten hasta que expiran. Una pausa no sustituye la conmutación por error a nivel de CDN durante una interrupción, porque la solicitud aún tiene que llegar a Profound. Para eliminar la integración, restaura la configuración de la CDN que registraste antes de la configuración:
  • Cloudflare: elimina la ruta del Worker añadida o restaura su vinculación anterior sin eliminar otra lógica del Worker.
  • CloudFront: restaura la asociación de solicitudes del visitante y las políticas anteriores. Usa No association solo cuando antes no había ninguna.
  • Vercel: elimina solo la ruta añadida de vercel.json, conserva el resto del enrutamiento y vuelve a desplegar.
Los cambios de enrutamiento surten efecto tras la propagación de la configuración o del despliegue. Las respuestas de respaldo almacenadas previamente en caché pueden persistir hasta su expiración o hasta tu proceso habitual de invalidación. Verifica el enrutamiento y el contenido originales después de revertir. Los dominios registrados, las claves y las publicaciones permanecen en Profound hasta que los elimines.