Dynamic Bot Rendering

Muchos asistentes de IA obtienen tus páginas con una simple solicitud HTTP y sin motor de JavaScript. En un sitio renderizado del lado del cliente, es posible que vean una estructura vacía en lugar de tu contenido. Dynamic Bot Rendering soluciona esto en tu red de distribución de contenido (CDN). Agregas una pequeña regla de enrutamiento a la CDN que ya utilizas. Esa regla reconoce el tráfico de asistentes de IA por su User-Agent y lo reenvía a Profound. Para las páginas públicas que hayas habilitado, Profound devuelve una copia publicada y prerrenderizada de la página cuando existe. Para todo lo demás, transmite directamente la respuesta en vivo de tu origen. Los visitantes humanos, los rastreadores de búsqueda, las llamadas a la API y los recursos nunca salen de tu ruta actual.

​

Cómo fluye una solicitud

​

Asistentes de IA compatibles

Profound identifica al asistente a partir del User-Agent original en cada solicitud, usando los mismos tokens con los que coincide tu regla de CDN. La coincidencia es una prueba de subcadena que no distingue entre mayúsculas y minúsculas.

​

Enrutamiento de rastreadores de búsqueda

Las solicitudes habituales de Googlebot y Bingbot quedan fuera de la lista anterior y permanecen en tu ruta actual. Prueba las reglas de caché y de edge de tu sitio para confirmarlo antes del despliegue. Dynamic Bot Rendering no hace cloaking: la página renderizada es la misma página que produce un navegador después de ejecutar JavaScript.

​

Cómo se controlan el renderizado y el servicio

Dos configuraciones independientes deciden qué recibe un asistente para una URL determinada:

• Política responde a “¿puede Profound servir contenido almacenado para esta ruta y a qué asistentes?”
• Publicación responde a “¿qué renderizado exacto está activo para esta ruta?”

Ambas deben coincidir antes de que se sirva un renderizado almacenado. Una página publicada con una política off no sirve nada. Una política serve en una ruta sin publicación recurre a tu origen. Tú mismo administras ambas en el panel de Profound.

​

Modos de política

off es el valor predeterminado para cualquier ruta que no esté cubierta por una regla. Un dominio recién registrado no hace nada hasta que una regla habilita una ruta, por lo que la incorporación no tiene efecto hasta que decidas qué renderizar. Usa warm para acumular candidatos para revisión antes de empezar a servir. serve nunca publica nada por sí solo; solo permite que se entregue una publicación existente.

​

Reglas y precedencia

Cada regla pertenece a un dominio registrado. Una regla predeterminada del dominio establece la base para todo el host, y las reglas de página la sobrescriben para rutas específicas. Una regla de página coincide con una ruta exacta (opcionalmente fijada a una cadena de consulta), un prefijo de ruta o un patrón glob como /blog/*. Las reglas de prefijo y glob coinciden con la ruta sin su cadena de consulta. Para cada solicitud, Profound elige una regla ganadora:

1. Una regla exacta para la ruta y la cadena de consulta.
2. Si no existe, una regla exacta para la ruta.
3. Si no existe, la regla de prefijo o glob que mejor coincida. Gana la de mayor prioridad y, después, el patrón más específico.
4. Si no existe, la regla predeterminada del dominio.
5. Sin ninguna regla, el modo efectivo es off.

Solo se aplica la regla ganadora. Cualquier configuración que deje sin definir se hereda de la regla predeterminada del dominio, nunca de una regla de página más amplia que también haya coincidido. Por ejemplo, con una regla predeterminada del dominio serve, una regla /docs/* configurada en warm y una regla exacta /docs/start que solo cambia sus asistentes permitidos, /docs/start se resuelve como serve. La regla /docs/* no contribuye. Una regla también puede desactivarse. Una regla inactiva se omite por completo, de modo que la regla predeterminada del dominio u otra regla coincidente toma el control de esa ruta. Por lo tanto, desactivar una regla off que excluía una ruta puede volver a activar el servicio. Para mantener una ruta en tu origen, usa una regla activa con el modo off.

​

Configuración por regla

Cada regla puede definir cualquiera de estas opciones y heredar el resto:

• Modo. off, warm o serve, como se describió arriba.
• Asistentes permitidos. Restringe qué asistentes compatibles reciben tratamiento en las rutas coincidentes. Si no se define, hereda la lista del dominio y, cuando nada define una lista, todos los asistentes compatibles son aptos. Una lista reemplaza la lista heredada en lugar de intersecarse con ella, y una lista vacía excluye a todos los asistentes. Un asistente excluido recibe la respuesta de tu origen con una política efectiva off. El renderizado publicado en sí es compartido: no puedes publicar versiones diferentes para distintos asistentes.
• Renderizado automático. Permite o bloquea los renderizados de candidatos en segundo plano independientemente del modo. serve con el renderizado automático desactivado sirve solo lo que publicas manualmente. off nunca renderiza automáticamente, sin importar lo que indique esta configuración.

​

Pausar un dominio

Pausar un dominio envía todas las solicitudes de asistentes para ese host a tu origen, manteniendo intactos el registro, las reglas, los renderizados y las publicaciones. Al reanudarlo, se restaura el comportamiento guardado. Usa la pausa cuando quieras dejar de servir rápidamente sin tocar tu CDN ni tus reglas. Mientras está en pausa, puedes seguir renderizando, revisando y publicando páginas.

​

Del renderizado a la página activa

Cada renderizado comienza como un candidato: una instantánea almacenada de una URL, creada en segundo plano por una solicitud apta o bajo demanda. Una URL puede acumular varios candidatos. Ninguno se sirve hasta que publiques uno. Un renderizado publicado permanece activo hasta que publiques un reemplazo o lo despubliques. Profound nunca reemplaza una publicación automáticamente, y un renderizado no deja de servirse por su antigüedad. Si un renderizado almacenado ya no se puede leer, Profound recurre a tu origen para esa solicitud en lugar de servir un renderizado diferente. La identidad de una página es el host público más la ruta y la cadena de consulta exactas. Publicar /pricing no publica /pricing?plan=pro, y cada variante se renderiza, revisa y publica por separado.

​

Recurso seguro al origen por diseño

El recurso seguro al origen (fail-open) ocurre en dos capas, y ninguna cubre todos los fallos por sí sola. Una clave de API incorrecta, un host no registrado o una ruta mal formada son rechazados por Profound en lugar de redirigirse por proxy, por lo que una regla mal configurada no puede filtrar solicitudes a tu origen en nombre de Profound. Cloudflare y CloudFront pueden ocultar algunos de estos rechazos mediante la conmutación por error de su CDN, lo que significa que una página que funciona en un navegador no prueba que la integración sea correcta. Inspecciona los encabezados de respuesta x-concierge-*, como se describe en Verificar y solucionar problemas.

​

Alcance y límites

• Solo GET. Otros métodos, incluido HEAD, no forman parte del contrato. Usa curl -sD - -o /dev/null, no curl -I, al hacer pruebas.
• Solo páginas públicas y no personalizadas. Habilita solo páginas públicas revisadas, ya sea mediante tus reglas de política en Profound o mediante una lista de rutas permitidas en tu regla de CDN. Una ruta sin extensión no prueba que sea una página: deja fuera las API, GraphQL, la autenticación, la administración, los recursos del framework y las rutas sensibles a la sesión. Los ejemplos de Cloudflare y CloudFront permiten solo /, /pricing, /docs y /docs/getting-started; reemplázalas con tus propias rutas.
• Las cadenas de consulta forman parte de la identidad de la página. /products?id=a y /products?id=b son páginas distintas, que se almacenan y renderizan por separado.
• Un host por regla. El host público que envía tu regla debe coincidir con un dominio registrado en Profound. Sirve varios hosts con una regla por host.
• No llegan credenciales a tu origen a través de Profound. Profound no reenvía las cookies del visitante ni los encabezados de autorización cuando obtiene tu origen, y las reglas de ejemplo mantienen las solicitudes con credenciales en tu ruta actual. Las páginas protegidas pueden renderizarse como una página de inicio de sesión o como contenido público, lo cual es un límite de compatibilidad y no una filtración.
• Un renderizado por URL, no por visitante. Un renderizado almacenado no varía según la sesión, el idioma, la geografía u otros encabezados de solicitud. Si la misma URL sirve contenido diferente según esas señales, previsualiza el renderizado y confirma que una sola versión es aceptable para todos los asistentes antes de agregarla a tu lista de permitidos.

​

Antes de empezar

Completa estos pasos en el panel de Profound antes de configurar tu CDN. El endpoint de Dynamic Bot Rendering al que llamará tu CDN es https://concierge.tryprofound.com. Además, registra tus rutas, funciones, políticas de caché y configuraciones de reversión actuales de la CDN antes de cambiar nada, y verifica que las reglas del firewall de aplicaciones web (WAF), los desafíos para bots, la protección de despliegues y las listas de orígenes permitidos dejen pasar tanto las solicitudes de asistentes como las obtenciones de origen de Profound. Si tu origen necesita una forma de identificar las obtenciones de Profound, comunícate con el soporte de Profound.

​

Elige tu CDN

¿Usas otra cosa, como Akamai, Fastly o un proxy personalizado? El contrato subyacente consiste en tres encabezados de solicitud en un GET. Comunícate con el soporte de Profound y te ayudaremos a adaptarlo.