Todo lo que necesita saber sobre la puntuación de preparación del agente de Cloudflare

La preparación de los agentes pasó del concepto a la infraestructura mensurable esta semana. El 17 de abril, cuando la Semana de Agentes de Cloudflare se extendió a su sexto día, la compañía lanzó isitagentready.com, un escáner público que califica cualquier sitio web según su preparación para los agentes de IA. Pegue una URL, obtenga una puntuación, vea qué comprobaciones se aprobaron y cuáles no, lea instrucciones generadas por IA sobre cómo mejorar. Por primera vez, la conversación sobre la legibilidad de los agentes pasó de “¿mi sitio web está listo para los agentes?” como un presentimiento a “mi sitio web obtuvo una puntuación de X sobre 100 en estas cinco categorías; aquí están las señales de error”.

El puntaje de preparación del agente es un cambio real. También es una herramienta estructuralmente engañosa si se deja de leer después del número compuesto.

Ejecuté el escaneo en este sitio web (nohacks.co) y obtuve una puntuación de 33 sobre 100, Nivel 2 “Bot-Aware”. El archivo robots.txt pasó. El mapa del sitio pasó. Se aprobaron las reglas del bot de IA en robots.txt. Contenido Las señales pasaron. Luego, la puntuación se derrumbó en las categorías en las que un blog de solo contenido realmente no necesita lo que busca el escáner. Más sobre eso en un minuto.

Primero, el contexto. Cloudflare ha estado enviando infraestructura orientada a los agentes durante toda la semana. El puntaje de preparación del agente llegó junto con la memoria del agente, los diccionarios compartidos, las redirecciones para el entrenamiento de IA, una técnica de compresión LLM llamada Unweight y una herramienta de señalización de funciones llamada Flagship creada para código generado por IA. Cuatro días antes, enviaron Project Think (un nuevo SDK de agentes) y OpenAI lo combinó en cuestión de horas con su propio SDK de agentes. Escribí sobre eso en The Agent Runtime Wars Comenzó esta semana. El escáner de preparación es la siguiente pieza lógica: si los tiempos de ejecución son la nueva capa del navegador, los propietarios de sitios web necesitan una forma de probar si su sitio web es legible en esa capa. Cloudflare envió el probador.

La pregunta que responde este artículo es más concreta: ¿qué comprueba realmente el escáner, qué debe hacer usted con su puntuación y dónde la puntuación es estructuralmente lo suficientemente engañosa como para que el número por sí solo le lleve por mal camino?

Lo que envió Cloudflare: escáner, API y un punto final de MCP Los agentes pueden llamarlo

El escáner está en isitagentready.com. Pegue cualquier URL, elija un tipo de sitio web (Todas las comprobaciones, Sitio de contenido o API/Aplicación) para determinar qué señales se escanean, presione Escanear. El escáner busca la página de inicio y un puñado de rutas conocidas, ejecuta una serie de comprobaciones en cada una y devuelve un informe puntuado con marcadores de aprobación/rechazo, códigos de estado, cuerpos de respuesta y orientación generada por IA sobre qué corregir.

El escáner también está disponible en otras tres formas:

• Integrado en Cloudflare Radar, por lo que las mismas comprobaciones se ejecutan junto con el análisis de URL existente de Radar.
• Expuesto mediante programación a través de la API de Cloudflare URL Scanner para automatización.
• Disponible como servidor MCP sin estado en /.well-known/mcp.jsonpor lo que cualquier agente compatible con MCP puede llamar al escaneo como una herramienta y razonar el resultado.

Vale la pena sentarse con este último por un momento. Cloudflare envió un escáner de preparación de agentes al que los propios agentes pueden llamar para auditar sitios web antes de decidir cómo interactuar con ellos. El escáner comprueba si su sitio web está listo para los agentes y cualquier agente puede invocarlo para decidir cómo interactuar con usted antes de llegar. La medida y lo medido empiezan a compartir la misma superficie.

Volvamos a la cuestión práctica. ¿Qué comprueba exactamente?

16 comprobaciones, 5 categorías: lo que realmente prueba el escáner

El escáner agrupa sus cheques en cinco categorías. Esto es lo que busca cada uno, agrupado según lo que realmente significa el cheque en la práctica.

Descubribilidad (3 controles)

Si el sitio web publica los metadatos básicos que un agente necesita para encontrar qué es y dónde.

• robots.txt existe. El clásico archivo de política de rastreo. Un agente que sigue robots.txt necesita que exista y se analice.
• sitemap.xml existe. Ya sea declarado a través de una directiva de mapa del sitio en robots.txt o disponible en la ruta estándar. Un agente que quiere enumerar páginas utiliza el mapa del sitio.
• Encabezados de enlaces (RFC 8288). Encabezados de enlaces HTTP que apuntan a recursos canónicos, alternativos o relacionados. Útil para agentes que analizan respuestas en lugar de HTML.

Contenido (1 cheque)

• Rebaja para agentes. Negociación de contenidos. El escáner envía Accept: text/markdown y comprueba si el sitio web devuelve Markdown en lugar de HTML. Esta es una propuesta propia de Cloudflare en lugar de una especificación de IETF, aunque el mecanismo (negociación de contenido HTTP a través de Accept encabezado) es estándar. Los tiempos de ejecución de agentes reales prefieren Markdown porque es más económico de tokenizar y más fácil de analizar que HTML. Algunos de los primeros (el propio Cloudflare, un puñado de sitios web de documentos) apoyan la negociación de contenido Markdown; la mayoría de los sitios web no lo hacen.

Control de acceso de bots (3 comprobaciones)

• Reglas de bots de IA en robots.txt (RFC 9309). Si robots.txt contiene directivas para agentes de usuario específicos de IA (GPTBot, ClaudeBot, PerplexityBot, etc.).
• Señales de contenido en robots.txt. Una especificación emergente para expresar reglas de acceso por URL dentro de robots.txt. Analizado como User-agent: * seguido por Content-signal: directivas. La adopción es mínima en este momento.
• Firma de solicitud de autenticación de Web Bot. Firmas de mensajes HTTP en /.well-known/http-message-signatures-directory que permiten a los agentes probar su identidad criptográficamente. Este es el lado del Servicio de nombres de agentes, Cloudflare se envió con GoDaddy a principios de la Semana de los Agentes. La adopción es casi nula fuera de las propiedades de Cloudflare.

API, autenticación, MCP y descubrimiento de habilidades (6 comprobaciones)

• Catálogo API (RFC 9727). Un índice legible por máquina de los puntos finales API de un sitio web en /.well-known/api-catalog.
• Descubrimiento OAuth/OIDC (RFC 8414). Metadatos del servidor de autorización estándar OAuth 2.0 en /.well-known/oauth-authorization-server y /.well-known/openid-configuration.
• Recurso protegido de OAuth (RFC 9728). Un sitio web que declara qué puntos finales están protegidos por OAuth y cómo autenticarse.
• Tarjeta de servidor MCP (SEP-1649). Un servidor Model Context Protocol que anuncia sus capacidades en /.well-known/mcp/server-card.json. SEP-1649 es un borrador de propuesta dentro del proceso de especificaciones de MCP.
• Índice de habilidades del agente. Una lista de habilidades a las que puede recurrir el agente en /.well-known/agent-skills/index.json. También emergente.
• WebMCP (experimental). Una API de JavaScript en la página que registra herramientas invocables por agentes a través de navigator.modelContext. El escáner utiliza la representación del navegador sin cabeza para detectar si el sitio web registra alguna herramienta WebMCP al cargar la página.

Comercio (3 controles opcionales, no puntuados en sitios web no comerciales)

• Protocolo de pago x402. Pago HTTP 402 Infraestructura requerida para pagos nativos del agente.
• Perfil UCP (Protocolo de Comercio Universal). Estándar de metadatos comerciales de Google en /.well-known/ucp.
• Documento de descubrimiento ACP (Protocolo de Comercio Agentic). En /.well-known/acp.json.

La categoría Comercio está marcada como “opcional” en sitios web no comerciales. El escáner detecta si hay señales de comercio electrónico presentes y, en caso contrario, muestra los cheques comerciales con fines informativos sin contarlos en la puntuación.

Ese último detalle del diseño importa. Es una prueba de que Cloudflare anticipó exactamente el problema del que trata el resto de este artículo.

Nohacks.co obtuvo una puntuación de 33/100, nivel 2 con reconocimiento de bots

Ejecuté el escaneo en nohacks.co. El resultado fue 33 de 100, Nivel 2 “Consciente de robots”.

Una nota sobre ese número: después del primer escaneo, agregué directivas de Señales de contenido a robots.txt, lo que movió el Control de acceso de bots de 50 a 100 y elevó el compuesto ocho puntos desde los 25 iniciales. Todas las demás categorías siguientes no han cambiado desde el primer escaneo. Volveré a la solución de Content Signals y por qué la hice al final de esta sección.

Esto es lo que impulsó la puntuación de cada categoría:

• Descubribilidad: 67. Se aprobaron robots.txt y sitemap.xml. Los encabezados de los enlaces fallaron porque este sitio web no emite Link: encabezados en sus respuestas.
• Contenido: 0. La negociación de contenido de Markdown no está configurada. El sitio web devuelve HTML independientemente del Accept encabezamiento.
• Control de acceso de robots: 100. Ambos controles puntuados pasaron. Reglas de bot de IA en robots.txt (tengo reglas explícitas para agentes de usuario de IA) y señales de contenido en robots.txt (las agregué después del primer escaneo). La firma de solicitud de Web Bot Auth figura en esta categoría como una verificación informativa, pero no cuenta para el 2/2.
• API, autenticación, MCP y descubrimiento de habilidades: 0. Los seis controles fallaron. Sin catálogo API. Sin descubrimiento de OAuth. No hay metadatos de recursos protegidos de OAuth. Sin tarjeta de servidor MCP. Sin índice de habilidades del agente. No hay herramientas WebMCP en la página.
• Comercio: no puntuado. nohacks.co no tiene comercio electrónico. Todas las comprobaciones de Comercio fallaron, pero la categoría se excluye correctamente de la puntuación compuesta.

Se trata de un 33 en un escáner construido por la empresa en la que más confío para entender hacia dónde se dirige la web lista para agentes. Considero que este sitio web está razonablemente bien diseñado para agentes. El archivo robots.txt es limpio y explícito. El contenido es HTML legible por máquina y renderizado por el servidor con una estructura semántica limpia. El mapa del sitio está actualizado. Las URL son estables. Si me preguntaran hace una semana si este sitio web estaba listo para agentes, mi respuesta estaría entre “principalmente sí” y “para lo que necesita hacer, sí”.

Y aún así: 33, nivel 2.

El escáner está midiendo lo que dice que está midiendo. La puntuación compuesta, por sí sola, sigue siendo un número incorrecto para optimizar.

Una nota sobre la corrección de las señales de contenido, porque es relevante para el argumento de Goodhart más adelante en este artículo. Content Signals es una propuesta de Cloudflare que casi no tiene implementación más allá de los rastreadores alineados con Cloudflare. Debatí agregarlo exactamente por la razón de búsqueda de puntaje sobre la que advierte este artículo. Decidí que era defendible por dos razones. Primero, la solución es declarativa, no decorativa. Las directivas establecen una política real sobre lo que debería suceder con mi contenido, y la declaración tiene significado incluso si la especificación falla. Eso es diferente a agregar una tarjeta de servidor MCP vacía para satisfacer a un anotador. En segundo lugar, para un sitio web que escribe específicamente sobre la preparación de los agentes, declarar públicamente la política de contenido es una práctica editorial, independientemente de qué rastreador la respete. La solución fue un compromiso public/robots.txt y las directivas son legibles por cualquier humano que tenga la curiosidad de comprobarlas.

El mismo sitio web obtiene una puntuación de 33 o 67 según el ajuste preestablecido que seleccione

En el ajuste preestablecido Todas las comprobaciones, nohacks.co obtiene una puntuación de 33 sobre 100, nivel 2 “Bot-Aware”. En el ajuste preestablecido del sitio de contenido, el mismo sitio web, el mismo día, configuración de escaneo diferente, obtiene una puntuación de 67, todavía nivel 2 “compatible con bots”. Casi el doble que el número compuesto. La diferencia de 34 puntos es la diferencia entre dos configuraciones de escaneo del mismo escáner, no una diferencia entre dos sitios web.

Esto es lo que cambia el ajuste preestablecido del sitio de contenido en la configuración de escaneo:

La ejecución de ese ajuste preestablecido en nohacks.co produjo este resultado:

Pasan cuatro de seis cheques puntuados. Las dos fallas son objetivos de solución inequívocos: encabezados de enlace a través de la configuración de respuesta HTTP, negociación de contenido Markdown a través del origen o lógica de respuesta CDN. Ambos se presentan en contra del comportamiento real en tiempo de ejecución del agente actual. Tampoco lo es un formato en etapa de propuesta que quizás sólo se convierta en un estándar. Esta es la lectura honesta del estado de preparación de los agentes de nohacks.co: dos brechas específicas y procesables.

La palanca correcta está oculta y la puntuación predeterminada es incorrecta

El escáner está haciendo su trabajo. Sabe que un blog no necesita una tarjeta de servidor MCP. Sabe que un archivo de podcast no publica un catálogo de API. El ajuste preestablecido del sitio de contenido no es cosmético. Elimina comprobaciones irrelevantes y proporciona al contenido del sitio web una lectura precisa de los estándares que realmente se aplican.

El problema es que el preset está oculto. Cuando un usuario llega a isitagentready.com y pega una URL, el análisis predeterminado es Todas las comprobaciones. La opción Tipo de sitio que cambiaría a Sitio de contenido o API/Aplicación se encuentra dentro de un menú desplegable Personalizar que la mayoría de los usuarios nunca abrirán. El usuario hace clic en Escanear, lee el número compuesto, toma una captura de pantalla y la comparte. El número que se puede compartir, el que viaja en las redes sociales, el que comparan los competidores, es el compuesto All Checks.

Para un sitio web de contenido que ejecuta el análisis predeterminado sin leer comprobaciones individuales, el compuesto es estructuralmente demasiado bajo. El 33 en nohacks.co es incorrecto para el tipo de sitio web que es nohacks.co. El 67 del valor preestablecido del sitio de contenido es la lectura precisa. Dos números del mismo escáner en la misma web. El número exacto está detrás de un menú desplegable. El número equivocado está en la portada.

Cualquier profesional web que ejecute el escáner y planee compartir la partitura en cualquier lugar público debe abrir Personalizar, seleccionar el ajuste preestablecido que coincida con su tipo de sitio web y volver a ejecutarlo antes de compartirlo. Sin ese paso, la puntuación pública subestimará la preparación real del agente del sitio web, y la brecha entre el número compartido y el número exacto será mayor para los sitios web de contenido que para los sitios web API (que están más cerca de la línea de base de All Checks). Lea los cheques individuales. No comparta una composición hasta que sepa qué ajuste preestablecido la produjo.

Para que conste: el 67 me está molestando. Voy a conseguir el 100. Sé exactamente contra qué está a punto de advertir la sección de Goodhart a continuación, y lo haré de todos modos. Dos arreglos se interponen entre los 100 y yo. Ambos son trabajos de cinco minutos. Ambos se corresponden con el comportamiento real en tiempo de ejecución del agente (encabezados de enlaces para descubrimiento, negociación de contenido Markdown para un análisis eficiente del agente), por lo que al menos la motivación es legítima y no pura búsqueda de puntajes. Esa advertencia es también exactamente lo que dicen los buscadores de puntajes. Las partituras públicas son un campo gravitacional. Incluso la persona que escribe un artículo extenso sobre su falta de fiabilidad acaba en órbita.

La preparación del agente mide la entrega, no el mensaje

Cada categoría que prueba el escáner de preparación del agente tiene que ver con la entrega: capacidad de descubrimiento, negociación de contenido, acceso de bot, descubrimiento de API, protocolos comerciales. Ninguno prueba la calidad del mensaje en sí.

El escáner nunca pregunta si sus titulares son claros, si las descripciones de sus productos convencen, si su contenido responde bien a la consulta, si su escritura es buena. Esas son preguntas de SEO y CRO. Ocupan la disciplina de mejorar el mensaje. El puntaje de preparación del agente ocupa una disciplina completamente diferente. Pregunta si un agente puede recuperar su contenido, analizar el formato en el que llega, autenticarse en sus puntos finales, llamar a sus funciones y pagar por sus resultados.

Ésa es la distinción que importa. La optimización web clásica (SEO, CRO) se trata de lo que dices y de cuán persuasivamente lo dices. La preparación del agente se trata de cómo entrega lo que dice a un lector no humano. Dos sitios web pueden publicar contenido idéntico palabra por palabra. Uno lo sirve como HTML renderizado por el servidor con marcado semántico, responde a Accept: text/markdownexpone datos estructurados y devuelve códigos de respuesta predecibles. El otro sirve como una aplicación de una sola página renderizada en JavaScript sin negociación de contenido y con una superficie de error inconsistente. El mensaje es idéntico. La entrega es diferente. La puntuación de preparación del agente será diferente. Y será correcto ser diferente, porque la entrega es con lo que interactúa el agente.

Esta es también la razón por la que las correcciones de preparación de los agentes tienden a ser ortogonales al trabajo de SEO y CRO. Puede mejorar la puntuación de preparación del agente sin tener que volver a escribir una sola palabra de su contenido. También puede tener contenido SEO de clase mundial con una puntuación de 10 en el escáner de preparación del agente porque ninguno de sus canales de entrega fue diseñado para consumidores de máquinas. SEO y CRO trabajan en la capa de contenido. La preparación del agente funciona en la capa de transporte y protocolo. Son adyacentes pero no son el mismo oficio, y tratarlos como si fueran iguales es el error que convierte un proyecto de preparación de agentes en un proyecto de reescritura de contenido y pierde la solución real.

Las personas a las que les irá bien en los próximos años son las que dejan de discutir sobre qué disciplina importa más y empiezan a reconocer que ocupan diferentes niveles de la pila.

Tres riesgos de Goodhart integrados en la puntuación de preparación del agente

La ley de Goodhart dice que cuando una medida se convierte en un objetivo, deja de ser una buena medida. El puntaje de preparación del agente está bien diseñado, pero ahora también es un número público, compartible y comparado, que produce tres fallas de comportamiento predecibles en la naturaleza.

El primer riesgo es que los propietarios de sitios web optimicen en función del número y no del comportamiento real de los agentes. Agregue una tarjeta de servidor MCP que no apunte a ninguna parte porque el escáner quiere una. Publicar un índice de habilidades de agentes sin habilidades reales. Envíe una herramienta WebMCP que no haga nada solo para pasar la verificación de detección. La puntuación aumenta y nada cambia en los tiempos de ejecución de los agentes reales que visitan el sitio web.

El segundo riesgo es que las consultoras comiencen a vender la “optimización de la puntuación de preparación del agente” como un servicio, vendiendo la puntuación en lugar de la arquitectura subyacente. La historia del SEO nos brinda un siglo de datos sobre cómo se desarrolla esto. PageRank se convirtió en un objetivo y a su alrededor creció una década de economía de spam de enlaces. Core Web Vitals se convirtió en un objetivo, y siguió una generación de optimizaciones de teatro de espectáculos. El puntaje de preparación del agente es una métrica mejor diseñada que cualquiera de las dos en el lanzamiento, pero se aplica la misma gravedad.

El tercer riesgo es que la inclusión por parte del escáner de estándares emergentes como señales puntuadas acelerará la adopción de esos estándares más allá del punto en que estén listos para transportar tráfico real. El escáner busca llms.txt, un formato propuesto para exponer el contenido del sitio web a modelos de lenguaje. Llms.txt no es un estándar ratificado, no tiene un órgano rector y tiene propuestas competitivas sobre cómo debería estructurarse. Incluirlo como señal puntuada le da un peso que no ha ganado en el ecosistema. El propietario de un sitio web que busca corregir una verificación fallida es el adoptante marginal que convierte una propuesta en un estándar de facto antes de que se realice el trabajo de especificaciones.

Ninguno de estos modos de falla es hipotético. Así es como se ha desarrollado cada puntuación de medición pública en la historia de la web. El puntaje de preparación del agente es mejor que el de la mayoría porque Cloudflare es honesto acerca de lo que es, porque el detalle por cheque está disponible junto al número compuesto y porque la categoría Comercio se excluye correctamente en sitios web no comerciales. Esa honestidad es una característica que vale la pena proteger. Los propietarios de sitios web y la industria de la consultoría se verán tentados a tratar el número compuesto como el objetivo de todos modos.

No hagas esto.

6 correcciones de fin de semana que se asignan a tiempos de ejecución de agentes reales

Seis acciones para un profesional web que ejecuta el escáner el fin de semana de su lanzamiento, ordenadas de mayor a menor apalancamiento:

1. Ejecute el escaneo en su sitio web. Tarda unos 30 segundos. Anote la puntuación y abra el informe detallado. El detalle es dónde está la señal.
2. Corrija las comprobaciones fallidas que se envían con tiempos de ejecución de agentes reales hoy. Estos son aquellos cuya ausencia perjudica considerablemente su sitio web para los agentes que lo visitan en este momento:
   • robots.txt. Si falta, agregue uno. Si está presente, asegúrese de que contenga reglas específicas para agentes de usuario de IA (GPTBot, ClaudeBot, PerplexityBot, Google-Extended, etc.).
   • mapa del sitio.xml. Si falta, genere uno y vincúlelo desde robots.txt. Manténgalo actualizado.
   • Negociación de contenido Markdown. Configura tu origen o CDN para regresar text/markdown cuando el Accept el encabezado lo solicita. El propio AI Crawl Control de Cloudflare tiene soporte de primera clase para esto. Otros proveedores requieren una lógica de servidor personalizada.
   • Datos estructurados. Envíe esquema.org JSON-LD para los tipos de contenido que publica su sitio web (artículo, producto, organización, lista de rutas de navegación). Esta no es una verificación puntuada, pero es la solución de mayor influencia para el comportamiento de las citas en todos los tiempos de ejecución de agentes implementados actualmente.
3. Trate los formatos de la etapa de propuesta como una lista de vigilancia, no una lista de verificación. llms.txt, señales de contenido en robots.txt, Web Bot Auth, API Catalog, MCP Server Card, Agent Skills, WebMCP, ACP, UCP son todos estándares de trabajo reales en cierto sentido. Todavía no se están comercializando a escala con un comportamiento real en tiempo de ejecución del agente. Míralos. Impleméntelos cuando su pila tenga un motivo para hacerlo, no porque el escáner los marque.
4. Ignore el número compuesto en su propio seguimiento. Realice un seguimiento de los resultados de los controles individuales a lo largo del tiempo. Un sitio web que pasa de 3 de 5 verificaciones en tiempo real a 5 de 5 ha mejorado considerablemente, incluso si la puntuación compuesta apenas se movió porque las 10 verificaciones de la etapa de propuesta aún fallan.
5. Vuelva a escanear después de los cambios. El escáner es rápido, gratuito y está disponible a través de la API del escáner de URL si desea programar comprobaciones de regresión en su proceso de implementación.
6. Evite las consultorías que venden optimización del puntaje de preparación del agente. El trabajo es lo suficientemente sencillo como para que una auditoría de medio día y un sprint de remediación enfocado superen a cualquier servicio empaquetado.

El escáner es la herramienta. El trabajo sigue siendo el trabajo.

Llegan escáneres específicos de cada proveedor: realice un seguimiento de lo que prueba cada escáner

El escáner de preparación del agente tiene forma de lista de estándares: un conjunto de verificaciones contra una lista fija de protocolos y formatos, algunos ratificados (encabezados de enlace RFC 8288, reglas robots.txt RFC 9309, descubrimiento OAuth RFC 8414, catálogo API RFC 9727, recurso protegido OAuth RFC 9728), algunas propuestas emergentes (MCP SEP-1649, WebMCP, señales de contenido, Autenticación de bot web, x402, UCP, ACP, llms.txt). Lo siguiente que sucederá en el ecosistema es predecible: otros proveedores enviarán sus propios escáneres según sus propias listas preferidas. La superposición será significativa porque la mayoría de las normas ratificadas no son controvertidas. La divergencia estará en las propuestas para las que puntúa cada proveedor.

Esa divergencia es donde la historia de la medición de la preparación de los agentes se vuelve interesante. Un escáner de Cloudflare que busca Web Bot Auth y UCP está haciendo una apuesta. Un escáner de Google, si se envía, comprobaría algunas de las mismas cosas y otras diferentes (Google tiene UCP, no tiene Web Bot Auth). Un escáner de Perplejidad buscaría otro conjunto más. Los propietarios de sitios web verían diferentes puntuaciones de diferentes escáneres en el mismo sitio web. El número compuesto, que ya no es confiable, se vuelve específico del proveedor.

La señal que vale la pena seguir es qué cheques aparecen en cada escáner que se envía. Ésas son las normas de facto. Los cheques que solo aparecen en el escáner de Cloudflare son las apuestas de Cloudflare. Algunos ganarán. La mayoría no lo hará.

Este es el patrón que me hizo sentir cómodo al publicar un artículo sobre una herramienta de Cloudflare el día de su lanzamiento. El puntaje de preparación del agente es real. La tesis detrás de esto (la preparación de los agentes es una propiedad mensurable) es la tesis correcta. El cuadro de mando específico es la versión uno de algo que tendrá docenas de versiones, cada una de las cuales reflejará las apuestas de su proveedor. Los profesionales de la web deben interactuar con el cuadro de mando de la versión uno, corregir lo que marca correctamente como real, observar lo que marca como emergente y mantener su propia lista actualizada de qué comprobaciones sobreviven en cada escáner que se envíe en los próximos seis meses.

Esa lista en ejecución es el verdadero estándar de preparación de los agentes. La puntuación compuesta es la capa de marketing.

Ejecute el escaneo. Lea el informe. Arreglar lo que importa. Mira lo que podría.

Más recursos:

Esta publicación se publicó originalmente en No Hacks.

Imagen de portada: RobinRmD/Shutterstock