Tu web de servicios B2B no está lista para agentes de IA: guía agent-first (esto no va de ecommerce)

Resumen ejecutivo

• Un agente no es un crawler. El crawler indexa por cuenta de OpenAI o Anthropic y respeta robots.txt; el agente actúa por encargo de una persona que quiere algo ahora —«busca tres proveedores y pídeles propuesta»— y se identifica con user-agents distintos (ChatGPT-User, Claude-User, Perplexity-User). Tratarlos igual es un error con coste comercial.
• Todo lo publicado sobre «web lista para agentes» habla de carritos y pagos. Una web de servicios no tiene carrito. Su recorrido agéntico tiene cinco pasos: qué haces, para quién, cuánto cuesta, qué pruebas aportas, cómo contactarte. Cada paso que falla se resuelve en un directorio que no controlas.
• El dato que más pesa es el precio. En 100 productos B2B analizados en julio de 2026, la tarea de precios fue la que más veces no pudo responderse desde la web del proveedor (21 % frente a 7-8 % en otras tareas), y sin precio publicado el 45 % de las ejecuciones acabó citando a terceros.
• Los agentes leen el árbol de accesibilidad antes que los píxeles. Los fallos más comunes de la web —etiquetas de formulario ausentes en el 51 % de las portadas, botones vacíos en el 30,6 %— son exactamente los puntos donde un agente se pierde.
• Hemos pasado nuestra propia web por los cinco pasos. Aprueba en acceso, entidad, formulario y confirmación; suspende en un detalle de precios que nos ha costado verlo hasta hoy. Al final del artículo está la lista completa para hacer lo mismo con la tuya.

Imagina esta escena, que ya está ocurriendo. Un director financiero de una empresa mediana abre ChatGPT en modo agente y escribe: «Necesito una agencia de SEO y visibilidad en IA para España y México. Busca tres opciones serias, dime qué cobra cada una, comprueba que trabajen con empresas de mi tamaño y pídeles a las tres una propuesta con mis datos». Se va a una reunión. Cuarenta minutos después tiene una tabla comparativa y tres formularios enviados —o dos, o uno—, y ninguna de las agencias sabe que ha sido evaluada.

Ese comprador no ha visitado tu web. Lo ha hecho un agente en su nombre, con un presupuesto de tiempo y de tokens limitado, leyendo tu página como la lee un lector de pantalla y decidiendo en cada paso si tiene lo que necesita o se va a buscarlo a G2, a un directorio o al blog de un competidor. Si tu página de precios dice «contacta para más información», ya no estás en la tabla.

Este artículo trata de ese recorrido. No del que aparece en todas las guías de agentic commerce —carrito, catálogo, checkout delegado— porque una web de servicios B2B no tiene nada de eso. Trata de lo que sí tiene: una oferta que hay que entender, un precio que hay que encontrar, unas condiciones que hay que cualificar y un formulario que hay que rellenar sin equivocarse. Auditamos la nuestra, con lo que aprueba y lo que no, y dejamos la lista para que hagas lo mismo. Si aún no tienes claro el marco general de visibilidad en motores generativos, la guía de GEO va primero; esto es el escalón siguiente, cuando el modelo ya no solo te cita sino que actúa.

Un agente no es un crawler (y tu robots.txt lo sabe)

La confusión más extendida es tratar a todo lo que llega de OpenAI o de Anthropic como «el bot de la IA». Son al menos tres cosas distintas, y las propias empresas las separan por user-agent.

Tipo de visitante	Ejemplos	Quién manda	Qué hace	Respeta robots.txt
Crawler de entrenamiento	GPTBot, ClaudeBot	La empresa del modelo	Rastreo masivo para entrenar modelos	Sí
Rastreador de búsqueda	OAI-SearchBot, Claude-SearchBot	La empresa del modelo	Indexa para las funciones de búsqueda del asistente	Sí
Agente por encargo	ChatGPT-User, Claude-User, Perplexity-User	Una persona, ahora	Visita tu página para responder o actuar para ese usuario	Puede no aplicar

Esa última celda no es interpretación nuestra. La documentación de OpenAI dice de ChatGPT-User que se usa «para ciertas acciones de usuario» y que, «como estas acciones las inicia un usuario, las reglas de robots.txt pueden no aplicar». Anthropic describe Claude-User de forma equivalente: cuando alguien pregunta a Claude, «puede acceder a sitios web usando un agente Claude-User».

Cloudflare formalizó la distinción en agosto de 2025 al crear la categoría de Signed Agents: agentes «dirigidos generalmente por un usuario final en lugar de por una única empresa», que firman criptográficamente sus peticiones según el borrador IETF draft-meunier-web-bot-auth-architecture (Web Bot Auth). La primera cohorte incluía al agente de ChatGPT, a Goose de Block, a Browserbase y a Anchor Browser. La consecuencia práctica para quien gestiona una web es que ahora puede decidir por separado qué hacer con los crawlers y qué hacer con los agentes —y que la decisión por defecto de muchos WAF, que es bloquear todo lo que no parece humano, deja fuera al comprador que llega delegando.

Para dimensionar cuánto tráfico es esto: según los datos de Cloudflare Radar recogidos por Search Engine Journal, en la semana del 30 de mayo al 5 de junio de 2026 el tráfico automatizado supuso el 57,2 % de las peticiones HTML frente al 42,8 % humano. No todo es agentes de compra, ni mucho menos, pero la tendencia es la que es. Si tienes configurado el acceso de bots de IA con la mentalidad de 2024 —permitir o bloquear en bloque— conviene releer la auditoría técnica de robots.txt con esta tabla al lado.

Cómo lee tu web un agente

Un agente que navega no «ve» tu página como tú. La mayoría de sistemas en producción combinan dos vistas: el árbol de accesibilidad —la estructura de roles, nombres y estados que el navegador construye para los lectores de pantalla— y capturas de pantalla cuando el árbol no basta. El árbol es texto compacto: «botón, "Enviar solicitud"», «campo de texto, "Correo electrónico", obligatorio». La captura es cara en tokens y ambigua: el modelo tiene que adivinar qué píxeles forman un control clicable. Por eso los agentes empiezan por el árbol y recurren a la imagen como último recurso.

Esto convierte la accesibilidad, que durante veinte años ha sido una obligación legal que muchas empresas cumplían a regañadientes, en infraestructura comercial. Y el estado de esa infraestructura es malo. El informe WebAIM Million de 2026, sobre un millón de portadas, encontró fallos detectables de WCAG 2 en el 95,9 % de ellas —un punto más que el año anterior— con una media de 56,1 errores por página. Los seis fallos más frecuentes llevan siete años siendo los mismos:

Fallo	Portadas afectadas	Qué le pasa al agente
Texto con contraste bajo	83,9 %	Poco: el árbol no depende del color
Imágenes sin texto alternativo	53,1 %	Pierde lo que digas en imagen: precios, logos de clientes, esquemas
Campos de formulario sin etiqueta	51 %	No sabe qué escribir en cada campo
Enlaces vacíos	46,3 %	No sabe adónde lleva el enlace
Botones vacíos	30,6 %	No sabe qué hace el botón —o no lo encuentra
Documento sin idioma declarado	13,5 %	Menor, pero suma ambigüedad

Léelo desde el otro lado: uno de cada dos formularios de la web no dice a un agente qué va en cada campo. No es un problema de nicho.

Y la consecuencia se mide. Online-Mind2Web evalúa agentes sobre 300 tareas en 136 webs reales de comercio, viajes, finanzas y administración. En la actualización del 29 de junio de 2026, los sistemas punteros de laboratorio superaban el 90 % de éxito, pero los productos que un comprador usa de verdad estaban bastante más abajo: el modo agente de ChatGPT Atlas en el 71 %, Gemini 2.5 Computer Use en el 69 %. Son webs de consumo con equipos de producto enormes y años de optimización de conversión. Una web de servicios B2B con la plantilla de la agencia de hace tres años, un CAPTCHA en el formulario y los precios en un PDF no está en esas condiciones. Está peor.

Por qué las guías de ecommerce no te sirven

Casi todo lo que encontrarás bajo «preparar tu web para agentes de IA» es sobre comercio. Tiene sentido: ahí estaba el dinero visible y ahí se han construido los protocolos. ACP, el Agentic Commerce Protocol de OpenAI y Stripe, define cómo un agente presenta un catálogo y delega un pago. AP2, el Agent Payments Protocol de Google, introduce mandatos firmados de intención, carrito y pago, y fue donado a la FIDO Alliance el 28 de abril de 2026. El Instant Checkout de ChatGPT, que fue el escaparate de todo esto, se retiró el 5 de marzo de 2026 tras integrar unas decenas de comercios de Shopify, y OpenAI reorientó la apuesta hacia apps de retailers dentro de ChatGPT.

Nada de eso te afecta si vendes consultoría, servicios jurídicos, tratamientos médicos, software con contrato anual o, como nosotros, retainers de marketing. Una web de servicios no tiene carrito. Su conversión no es un pago, es una solicitud cualificada. Y el recorrido que hace un agente para llegar a ella es otro:

1. Qué haces. Entender la oferta en una frase que pueda repetir a su usuario sin inventarse nada.
2. Para quién. Decidir si el usuario encaja o no —y aquí los criterios de descalificación explícitos valen más que la lista de sectores.
3. Cuánto cuesta. Extraer un precio, un rango o al menos la unidad y las condiciones.
4. Qué pruebas aportas. Casos, cifras, quién firma, desde cuándo existe la empresa, dónde está.
5. Cómo contactarte. Rellenar el formulario correctamente y saber que lo ha conseguido.

Cada paso que el agente no resuelve en tu web lo resuelve fuera. Y eso no es una hipótesis: es el hallazgo central del estudio más serio publicado sobre el tema.

Lo que dicen los datos: el precio es el punto de rotura

En julio de 2026, Growth Memo publicó un análisis sobre 100 productos B2B. Para cada uno, un agente ejecutó tres tareas de comprador —precios y funcionalidades, integraciones, seguridad y cumplimiento— cinco veces cada una, sin que se le diera la URL de partida. La pregunta era simple: ¿consigue el agente responder desde la web del proveedor, o se va a otro sitio?

Tarea	Respondida desde la web del proveedor
Integraciones	93 %
Seguridad y cumplimiento	92 %
Precios y funcionalidades	79 %

El precio es el único punto donde uno de cada cinco intentos no se resuelve en casa. Los datos de detalle son los que importan para decidir:

• Cuando el proveedor no publicaba precio, el 45 % de las ejecuciones citó fuentes de terceros.
• Incluso con precio publicado, el agente recurrió a terceros en el 18 % de los casos —normalmente porque el precio estaba, pero no era extraíble: renderizado por JavaScript, dentro de una calculadora, en un PDF.
• Los errores de acceso aparecieron solo en el 7 % de las ejecuciones, pero cuando aparecían disparaban la citación de terceros del 17 % al 77 %. Un bloqueo puntual no te cuesta esa visita: te cuesta la conversación entera.
• Las fuentes de terceros fueron un 52 % contenido editorial y un 46 % directorios tipo G2 o Capterra. Es decir, el precio que el agente le dio al comprador lo puso alguien que no eres tú.

El estudio identifica tres causas raíz, y conviene aprendérselas porque son las tres que hay que auditar: opacidad (no hay precio o está formulado de forma vaga), legibilidad (el precio existe pero la máquina no lo extrae) y fricción de acceso (bloqueos, límites de peticiones, errores de descarga).

Forrester llegó a la misma conclusión desde el lado del negocio. En agosto de 2026, dos de sus analistas principales lo titularon sin rodeos: los agentes no pueden leer tu página de precios y eso se está convirtiendo en un problema de ingresos. Su cifra: alrededor del 30 % de las ejecuciones de agentes encontró al menos un error de búsqueda o recuperación, y cuando el agente no accede al precio busca en terceros «y potencialmente redirige al comprador a competidores». Su recomendación es tratar la página de precios como «un activo de contenido estratégico diseñado tanto para compradores humanos como para agentes»: accesible sin login, sin dependencia de JavaScript, con jerarquía de paquetes clara y métricas de precio explícitas.

Sabemos que el modelo «contacta para precio» tiene defensores en B2B, y que hay razones comerciales para mantenerlo. Solo diremos esto: en un recorrido humano, «contacta para precio» genera una llamada. En un recorrido agéntico, genera una fila vacía en la tabla comparativa, o peor, una fila rellenada con lo que dice un directorio.

Auditoría real: nuestra web, paso a paso

La forma honesta de escribir esto es aplicarlo primero en casa. Recorrimos autoridaddigital.com con las cinco preguntas del agente y con las tres causas raíz del estudio. Esto es lo que encontramos, incluido lo que no nos gusta.

1. Acceso — aprueba, con una nota

Nuestro robots.txt se genera desde código y declara explícitamente 21 user-agents de IA con allow: /, además del grupo comodín, y solo excluye /api/. No hay CAPTCHA en ninguna página, no hay WAF filtrando por «parece un bot» y el contenido se sirve renderizado en servidor, así que un agente que lea el HTML sin ejecutar JavaScript obtiene la página completa.

La nota: la lista de user-agents refleja la nomenclatura de 2025. Incluye Claude-Web y anthropic-ai, pero no Claude-User ni Claude-SearchBot, que son los nombres actuales de Anthropic para el agente y el rastreador de búsqueda. En la práctica no bloquea nada —el grupo * permite todo—, pero una lista que se presenta como declaración explícita de política debería nombrar a los agentes que existen hoy. Lo corregimos esta semana.

2. Qué hacemos y para quién — aprueba

El llms.txt se genera dinámicamente desde las mismas constantes que renderizan la web y abre con un párrafo que un agente puede citar tal cual: qué somos, para qué sectores, dónde tenemos sede, en qué países operamos, bajo qué razón social y con qué CIF. Ya explicamos para qué sirve de verdad ese fichero y por qué no es una palanca de posicionamiento: aquí su función es otra, es el resumen ejecutivo que le ahorra al agente veinte páginas.

Para el «para quién», cada página de servicio lleva un bloque de criterios de descalificación —para quién no es este servicio— además del de encaje. Es el dato que más le ayuda a un agente a decidir sin adivinar, y el que casi ninguna web de servicios publica porque comercialmente parece que cierra puertas. Las cierra: las que no ibas a ganar de todos modos, y a cambio te deja en la lista corta cuando encajas.

3. Cuánto cuesta — suspende en un detalle

Aquí es donde el ejercicio ha servido. Nuestra página de precios cumple casi todo lo que piden los estudios: cuatro planes en HTML servido por el servidor, precio numérico visible en el texto, Offer en JSON-LD con priceCurrency: "EUR" y periodo mensual explícito. Un agente extrae «Starter, 690 € al mes» sin ejecutar nada.

Lo que no cumple: en la página de precios no aparece si el importe es con o sin IVA. La permanencia sí está —«Mínimo 6 meses» bajo cada plan, «Mínimo 12 meses» en Dominación—, pero el tratamiento del impuesto no está en ninguna parte de la web. Para una persona es un detalle que se resuelve en la primera llamada. Para un agente al que le han pedido «cuánto me costaría el primer semestre» es una inferencia de un 21 %, y las inferencias son donde los agentes se equivocan o, peor, donde van a comprobar a un tercero. Lo hemos añadido junto al precio —«/mes + IVA»— y en el Offer con valueAddedTaxIncluded: false, además de declarar la permanencia con billingDuration. No lo habíamos visto hasta hoy porque nadie nos lo había preguntado sin llamar.

4. Cómo contactarnos — aprueba

El formulario de contacto tiene un <label> asociado por htmlFor a cada uno de sus campos, aria-required en los cuatro obligatorios —nombre, correo, empresa y web—, y los dos campos de cualificación son <select> con valores enumerados y legibles («SaaS / Software B2B», «100.000 - 500.000 EUR/año»). Para el árbol de accesibilidad eso es un formulario que se explica solo: el agente sabe qué va en cada sitio y qué opciones existen.

Un detalle que merece explicación es el honeypot. Como muchas webs, tenemos un campo trampa (website_url) que ningún humano ve y cuyo relleno delata a un bot de spam. El riesgo es evidente: un agente que rellene todos los campos del DOM caería en él y recibiría una confirmación falsa. Nuestro campo está dentro de un contenedor con aria-hidden="true" y su etiqueta dice literalmente «No rellenar»: un agente que lea el árbol de accesibilidad —que es lo que hacen— no lo ve, y uno que lea el DOM completo encuentra la instrucción en la etiqueta. Es la diferencia entre un honeypot que filtra spam y uno que filtra clientes.

5. Confirmación — aprueba

Tras el envío, el mensaje «Solicitud recibida. En menos de 48 horas recibirás tu informe personalizado» se renderiza en texto dentro de una región aria-live. El agente puede leerlo, confirmar a su usuario que la solicitud ha entrado y decirle cuándo esperar respuesta. Parece trivial; no lo es. Una confirmación que solo existe como animación, como cambio de color de un botón o como redirección a una página sin texto deja al agente sin saber si ha terminado, y a los agentes que no saben si han terminado les da por reintentar.

Balance: cuatro de cinco, y el que falla es el que más pesa según los datos. Lo contamos porque el ejercicio solo tiene valor si se hace de verdad, y porque la web que fabrica el propio checklist tenía un hueco justo en el punto del que más se ha escrito este año.

El checklist agent-first para servicios B2B

Esta es la lista que usamos, ordenada por el recorrido del agente y no por disciplina técnica. Cada fila dice qué intenta hacer el agente y qué tiene que encontrar.

Paso	Qué intenta el agente	Qué tiene que encontrar
Acceso	Descargar tus páginas como ChatGPT-User, Claude-User, Perplexity-User	robots.txt que no los bloquee; sin CAPTCHA en páginas de lectura; sin WAF que rechace tráfico firmado; HTML útil sin ejecutar JavaScript
Entidad	Saber quién eres sin deducirlo	llms.txt con la descripción canónica; Organization en JSON-LD con dirección, fundador y perfiles; mismos datos en web y fuera de ella (entity SEO)
Oferta	Resumir qué haces en una frase fiel	Una página por servicio, no anclas en una sola; H1 y primer párrafo que definen el servicio; sin claims que un agente no pueda verificar
Encaje	Decidir si su usuario es cliente tuyo	Criterios de encaje y de descalificación explícitos: tamaño, sector, país, requisitos previos
Precio	Extraer importe, unidad y condiciones	Precio o rango en texto servido, con moneda, periodo, impuestos y permanencia en el mismo nodo; Offer en JSON-LD coherente; nunca en imagen, PDF ni calculadora
Prueba	Valorar si eres fiable	Casos con cifras y fechas; autor con nombre y perfil verificable; año de fundación; sede real (E-E-A-T)
Contacto	Rellenar el formulario sin equivocarse	<label> por campo; obligatorios marcados; selects con valores legibles; sin CAPTCHA; honeypot fuera del árbol de accesibilidad con etiqueta explícita
Confirmación	Saber que ha terminado y qué pasa ahora	Mensaje en texto, en región aria-live o en página propia, con plazo de respuesta

Tres comentarios sobre la tabla.

El schema ayuda, pero no sustituye al texto. Ya documentamos la evidencia sobre schema y citación en IA: cuando un modelo abre tu URL, extrae lo visible. Un Offer con price: 690 en el JSON-LD y un «690 €» en una imagen es un precio que el agente no encuentra. La regla es que el marcado coincida con el HTML, no que lo compense.

La descalificación explícita es la herramienta más infravalorada. Un agente al que le han pedido «agencias que trabajen con startups en fase seed» y lee en tu web «no trabajamos con empresas de menos de un año de actividad» te descarta en dos segundos y sin rencor. Uno que no encuentra el criterio te mete en la lista, su usuario te contacta, y pierdes una hora en una llamada que no iba a ninguna parte. La descalificación no cierra puertas: ahorra reuniones.

El CAPTCHA en el formulario es el equivalente al «contacta para precio». Si el único camino a la solicitud pasa por un desafío diseñado para excluir a las máquinas, has decidido que los compradores que delegan no son tus compradores. Puede ser una decisión legítima; que sea consciente. Rate limiting por IP, honeypot fuera del árbol de accesibilidad y validación en servidor filtran el spam sin cerrar esa puerta.

WebMCP: lo que viene, y por qué no es prioridad todavía

Existe una propuesta para que todo esto deje de depender de que el agente interprete bien tu HTML. WebMCP, impulsada por ingenieros de Google y Microsoft en el W3C Web Machine Learning Community Group, permite que una web declare sus acciones como herramientas: nombre, descripción, esquema de parámetros y función que las ejecuta. Un formulario de contacto pasaría a ser una herramienta solicitar-propuesta con sus campos tipados, en lugar de un conjunto de <input> que el agente tiene que descifrar. Chrome la puso en early preview el 10 de febrero de 2026 con dos vías: una imperativa en JavaScript y una declarativa que sintetiza herramientas a partir de los <form> existentes.

La forma imperativa, tal y como aparece en el repositorio de la propuesta, se parece a esto:

await document.modelContext.registerTool({
  name: "solicitar-propuesta",
  description: "Envía una solicitud de propuesta a la agencia",
  inputSchema: {
    type: "object",
    properties: {
      empresa: { type: "string", description: "Nombre de la empresa" },
      email:   { type: "string", description: "Correo de contacto" },
      sector:  { type: "string", enum: ["saas", "legal", "salud", "consultora"] }
    },
    required: ["empresa", "email"]
  },
  async execute({ empresa, email, sector }) {
    /* llama a la misma server action que usa el formulario */
  }
});

Nuestra recomendación: no lo implementes aún, pero diseña como si fueras a hacerlo. No está en Chrome estable, no lo consumen los agentes mayoritarios y la especificación cambia. Lo que no cambia es que un formulario con campos bien nombrados, valores enumerados y una confirmación en texto es exactamente lo que WebMCP formalizará: cuando llegue, la declaración será un envoltorio de diez líneas sobre un formulario que ya funciona. Si hoy el formulario es un caos de div clicables, WebMCP no lo arregla; lo documenta.

Qué no hacer

Cinco errores que vemos repetidos y que salen de aplicar recetas de otro contexto.

Copiar la guía de ecommerce. Feeds de producto, Product con variantes, integrar ACP: nada de eso tiene sentido si no vendes unidades. Tu «catálogo» son tres o cuatro servicios con criterios de encaje, y tu «checkout» es un formulario.

Bloquear agentes por bloquear bots. La regla de WAF que rechaza todo lo que no parece un navegador humano se comió a ChatGPT-User en 2025 y ahora se come al tráfico firmado con Web Bot Auth. Revisa la regla antes de revisar el contenido.

Precios que existen pero no se extraen. Calculadoras interactivas, tablas que se cargan tras un clic, importes en imagen o en PDF descargable, «desde X» sin decir qué incluye X. El estudio de Growth Memo encontró que un 18 % de los fallos ocurría con el precio publicado: publicado no es lo mismo que legible.

El chat como único camino. Si el formulario está escondido tras un widget de chat que se abre con JavaScript y pide un correo antes de mostrar nada, el agente no llega. Un formulario HTML con acción en servidor es la interfaz más robusta que existe; no la sustituyas por algo más ingenioso.

Honeypots visibles al DOM. Un campo trampa sin aria-hidden y sin etiqueta explicativa filtra a los agentes que leen el HTML completo y les devuelve una confirmación falsa. El comprador cree que te ha contactado; tú no te enteras.

Lo que este artículo no puede prometer

Tres límites, porque la alternativa es vender una urgencia que los datos no sostienen del todo.

Los benchmarks son de consumo. Online-Mind2Web mide compras, viajes y trámites; no hay un benchmark público de agentes sobre webs de servicios B2B, y las tasas de éxito que hemos citado hay que leerlas como techo, no como media. Las de tu sector son, con casi total seguridad, más bajas.

No sabemos qué porcentaje de compradores B2B delega ya la investigación. Sabemos que el tráfico automatizado supera al humano en peticiones HTML y que los agentes de compra existen y se usan; no sabemos cuántas decisiones de contratación de servicios pasan hoy por uno. Lo que sí sabemos es que el coste de prepararse es bajo —la mayor parte es accesibilidad y claridad que deberías tener de todos modos— y el de no hacerlo, si la adopción sigue la curva, es quedarse fuera de una tabla que nadie te enseña.

Y no hay datos en español. Los estudios que hemos citado son sobre productos y consultas en inglés. Los mecanismos son idénticos —un agente lee un árbol de accesibilidad igual en Madrid que en Austin—, pero las cifras concretas de fallback a directorios pueden diferir en un mercado con menos directorios de referencia. Es una razón más para medirlo en tu web y no fiarse de los promedios.

Qué hacer el lunes

Si tienes una hora, en este orden:

1. Abre tu web como un agente. Pásala por el escáner GEO para el acceso y los datos estructurados, y después, con el inspector de accesibilidad del navegador, lee tu formulario de contacto y tu página de precios solo a través del árbol. Lo que no aparezca ahí, para el agente no existe.
2. Arregla el precio primero. Importe o rango en texto servido, con moneda, periodo, impuestos y permanencia en la misma frase. Es el cambio con más impacto medido y el que menos cuesta.
3. Escribe la descalificación. Un párrafo por servicio: para quién no es. Te ahorrará reuniones antes de que ningún agente lo lea.
4. Revisa el formulario campo a campo. <label> asociado, obligatorios marcados, selects con valores legibles, sin CAPTCHA, honeypot fuera del árbol, confirmación en texto.
5. Actualiza la lista de user-agents. Con los nombres que existen hoy, y con la decisión consciente —y separada— sobre crawlers y agentes.

El cambio de fondo es el mismo que llevamos un año contando desde ángulos distintos: de la cita al consenso, del ranking a la entidad, de la posición al flujo. Ahora, del lector al delegado. La web de servicios que gana no es la más bonita ni la que más convence a la persona que la lee; es la que un agente con cuarenta minutos y un encargo concreto puede entender, cualificar, tarificar y contactar sin salir a buscar a otro sitio. Todo lo demás —el diseño, la narrativa, la llamada de ventas— sigue importando. Pero ocurre después, y solo si has pasado esta criba primero.