Qué buscar en un proveedor de diseño y desarrollo web: guía para quienes toman la decisión

El diseño sigue importando, pero no alcanza con que el sitio se vea bien. Conviene pedir pruebas que la empresa pueda comprobar: que buscadores y asistentes de IA puedan leer el contenido, que personas con discapacidad puedan usar el sitio, que cargue bien para visitantes reales y que las cuentas y los datos queden a su nombre. Una promesa de «optimizar para IA» sin prueba es una señal de alerta.

Esta guía está pensada para quien decide o aprueba un presupuesto, no para quien programa. Cada criterio explica por qué importa para la empresa, qué pedir, cómo comprobarlo y qué señal debe generar dudas. Los términos técnicos se explican en palabras simples y, cuando hace falta el detalle, aparece bajo la etiqueta «Para el equipo técnico», que se puede pasar directamente al área de sistemas o al proveedor.

Conviene aclarar desde dónde se escribe. CookingMetrics no diseña ni desarrolla sitios para terceros. Ofrece consultoría y acompañamiento a equipos de desarrollo, sobre todo auditorías para ecommerce y empresas B2B y B2B2C que implementan estándares en sitios, tiendas y aplicaciones web, y además desarrolla sus propias aplicaciones y plataformas. Este artículo está escrito desde quien revisa lo que un proveedor entrega, no desde quien lo vende.

En síntesis

• Un proveedor se evalúa por entregables con prueba y fecha, no por promesas. Esta guía propone diez criterios, cada uno con qué pedir, cómo comprobarlo y qué señal de alerta buscar.
• Google documenta, en una página actualizada el 10 de diciembre de 2025, que no hay requisitos adicionales para aparecer en sus respuestas con IA y que no hacen falta archivos ni etiquetas nuevas. Eso describe a Google; no cubre otros sistemas.
• Esta guía no presenta evidencia de que cumplir los diez criterios aumente posiciones, visitas, menciones en respuestas de IA o ventas. Se justifican porque benefician a las personas, a los buscadores y al mantenimiento del sitio.
• La prueba de aceptación se acuerda por escrito antes de la entrega: una medición inicial con fecha y las mismas herramientas para medir de nuevo después.
• En la medición propia del 4 de septiembre de 2026, CookingMetrics encontró que su sitio anunciaba un mapa que no existía, tenía un archivo escrito pero sin publicar y cargaba su contenido principal en 6,15 segundos. Lo que parecía resuelto en el código no lo estaba en el sitio en funcionamiento.

Qué cambió: no solo visitan personas con navegador

Un sitio recibe hoy visitas de personas con navegador, de robots de buscadores y de asistentes o agentes de inteligencia artificial: programas que leen páginas para responder una pregunta o para hacer una tarea en nombre de alguien. Esa lista ya existía en parte. Lo que cambia es cuánto de lo que se publica depende de que una máquina pueda leerlo sin ayuda.

En este tema se mezclan tres tipos de afirmación, y conviene separarlos para no pagar por promesas:

• Documentado por quien opera el sistema. Por ejemplo, Google explica cómo procesa las páginas y qué recomienda. Es lo más sólido, siempre que se cite con su fecha.
• Práctica habitual del sector. Revisar el código de una página o recorrer una compra con teclado son comprobaciones extendidas, aunque la documentación citada en esta guía no las presente como requisito.
• Hipótesis. Es plausible que los agentes que operan una página tropiecen donde tropiezan las personas que usan tecnologías de apoyo, como formularios sin etiquetas o botones sin nombre. Es una hipótesis razonable; esta guía no la demuestra y no la usa como argumento de venta.

Diez criterios, con su prueba

Los criterios se agrupan en tres bloques: que el sitio se pueda leer y usar, que sea rápido y esté bien comunicado a los buscadores y a los robots, y que la empresa conserve el control. Cada uno tiene cuatro partes: por qué le importa a la empresa, qué pedir al proveedor, cómo comprobarlo sin depender de su palabra y qué señal de alerta debe generar dudas.

Bloque A: que el sitio se pueda leer y usar

1. El contenido importante está en la página tal como la entrega el servidor

• Por qué le importa a la empresa: muchos sitios modernos arman la página en el navegador del visitante con un programa llamado JavaScript. Un robot o un asistente que no ejecuta ese programa puede recibir una página casi vacía. Google indica que las páginas pasan por una cola antes de ejecutar su JavaScript y recomienda que el servidor entregue la página ya armada (lo que se llama renderizado en servidor o prerrenderizado), entre otras razones porque no todos los robots ejecutan JavaScript (JavaScript SEO basics, página actualizada el 4 de marzo de 2026, consultada el 27 de octubre de 2026).
• Qué pedir: que los textos, los títulos, los enlaces y los precios importantes estén en la página tal como la entrega el servidor, sin depender de un programa que se ejecuta después.
• Cómo comprobarlo: pedir a alguien del equipo que abra una página clave, haga clic derecho y elija «ver código fuente», y busque un párrafo del texto principal. Si no aparece ahí, depende de un programa que se ejecuta después.
• Para el equipo técnico: el mismo control con curl sobre la URL. No sirve el inspector del navegador, porque muestra el contenido ya procesado.
• Señal de alerta: que la demostración se limite a capturas de pantalla del navegador, o que el código fuente sea un contenedor vacío.

2. La accesibilidad se acuerda por escrito y se prueba

• Por qué le importa a la empresa: accesibilidad significa que personas con discapacidad visual, motriz, auditiva o cognitiva puedan usar el sitio. Hay una norma de referencia, las Pautas de Accesibilidad para el Contenido Web 2.2 (WCAG 2.2), una Recomendación del W3C publicada el 12 de diciembre de 2024 y compatible con la versión 2.1. Permite acordar un nivel de cumplimiento concreto en lugar de una intención (WCAG 2.2).
• Qué pedir: un nivel de conformidad escrito en el contrato (por ejemplo, el nivel AA) sobre WCAG 2.2, con las páginas que se evaluarán.
• Cómo comprobarlo: pedir el informe de pruebas hechas por personas: recorrer el flujo principal solo con teclado, hacerlo con un lector de pantalla y revisar el contraste de los colores, con las páginas probadas y la fecha. El resultado de una herramienta automática es un punto de partida, no la prueba completa.
• Para el equipo técnico: la versión 2.2 agrega criterios como el tamaño mínimo de los objetivos táctiles (2.5.8, nivel AA) y la autenticación accesible (3.3.8, nivel AA).
• Señal de alerta: un «overlay», es decir, un complemento que se instala sobre el sitio y promete corregir la accesibilidad sin modificarlo, presentado como garantía de cumplimiento. El 22 de abril de 2025, la Comisión Federal de Comercio de Estados Unidos aprobó una orden final contra accessiBe que le prohíbe afirmar, sin evidencia, que sus productos automatizados vuelven cualquier sitio conforme con WCAG o lo mantienen conforme, y le exige pagar un millón de dólares (comunicado de la FTC). La orden alcanza a esa empresa; no resuelve qué ocurre con otros proveedores ni con esa tecnología en general.

3. Los formularios, el carrito y el pago se pueden completar

• Por qué le importa a la empresa: es el tramo donde se concreta la venta o el contacto. Si una persona que usa tecnologías de apoyo no puede completarlo, la empresa pierde esa operación. Los agentes que operan una página tendrían que superar los mismos obstáculos; es la hipótesis planteada arriba y un tema aparte. Para este criterio alcanza con que el recorrido funcione para las personas.
• Qué pedir: que cada campo tenga su etiqueta, que todo el recorrido se pueda completar con el teclado, que los errores se expliquen con texto y que el ingreso a una cuenta no dependa solo de una prueba cognitiva, en línea con el criterio 3.3.8 de WCAG 2.2.
• Cómo comprobarlo: hacer una compra de prueba usando solo el teclado y, después, con un lector de pantalla.
• Señal de alerta: elementos que parecen botones pero no lo son, ventanas emergentes que atrapan al usuario sin salida y opciones que solo aparecen al pasar el cursor.

Bloque B: que sea rápido y esté bien comunicado a buscadores y robots

4. El rendimiento se mide con visitantes reales

• Por qué le importa a la empresa: Google publica tres métricas, llamadas Core Web Vitals, para medir la experiencia: cuánto tarda en aparecer el contenido principal (LCP), cuánto tarda la página en responder a un clic o un toque (INP) y cuánto se mueve el contenido mientras carga (CLS).
• Qué pedir: una meta escrita: LCP de 2,5 segundos o menos, INP de 200 milisegundos o menos y CLS de 0,1 o menos, medidos de modo que al menos tres de cada cuatro visitas cumplan el umbral (el percentil 75), por separado en móvil y en escritorio (Web Vitals, página actualizada el 31 de octubre de 2024, consultada el 27 de octubre de 2026).
• Cómo comprobarlo: exigir datos de campo, es decir, mediciones de visitantes reales, y no una sola prueba de laboratorio. Una prueba puntual sirve para depurar; no dice cómo carga el sitio para quienes lo usan.
• Señal de alerta: un puntaje de laboratorio presentado como prueba de entrega, sin datos de campo y sin fecha.

5. El mapa del sitio, las direcciones y las redirecciones funcionan

• Por qué le importa a la empresa: el mapa del sitio (sitemap) es un archivo que lista las páginas que se quiere que los buscadores descubran. Si anuncia direcciones que no existen, es un error simple de detectar que deja dudas sobre el resto del trabajo. En una migración, las redirecciones evitan que las direcciones antiguas dejen de funcionar.
• Qué pedir: un mapa existente y declarado en el archivo de reglas para robots (robots.txt), una dirección preferida para cada página (el canonical) y, si hay migración, una tabla que indique a qué dirección nueva va cada dirección antigua.
• Cómo comprobarlo: abrir cada dirección anunciada y confirmar que carga con el código de respuesta 200 («correcto»). Qué debe contener un mapa del sitio se explica en Sitemaps XML: mejores prácticas para Bing y Google.
• Señal de alerta: un robots.txt que anuncia un mapa que responde 404 («no encontrado»). Es exactamente lo que encontramos en nuestro propio sitio, como se explica más abajo.

6. Los datos estructurados describen lo que la página muestra

• Por qué le importa a la empresa: los datos estructurados son etiquetas, invisibles para el visitante, que describen el contenido (un producto, un precio, una valoración) en un formato que las máquinas leen. Si dicen algo distinto de lo que se ve, incumplen las reglas de Google.
• Qué pedir: etiquetas solo del contenido que una persona puede ver en la página.
• Cómo comprobarlo: comparar las etiquetas con el texto visible. Las políticas de Google exigen que los datos estructurados describan contenido visible para las personas y reflejen lo que la página contiene (políticas de datos estructurados, página actualizada el 10 de julio de 2026, consultada el 27 de octubre de 2026).
• Señal de alerta: etiquetas generadas por una plantilla con datos que la página no muestra, como valoraciones o precios ausentes del texto visible. Nada de esto garantiza resultados destacados en los buscadores ni menciones en respuestas de IA.

7. Las reglas de acceso para robots están definidas con criterio

• Por qué le importa a la empresa: el archivo robots.txt es una página pública que indica a los robots qué zonas del sitio pueden visitar. Content Signals es una declaración adicional que indica qué se puede hacer con el contenido una vez descargado (buscar, responder o entrenar modelos); no bloquea el acceso. Decidir cuánto de su contenido pueden usar los asistentes es una decisión de negocio, no solo técnica. El tema se explica en Content Signals en robots.txt.
• Qué pedir: un archivo documentado, con reglas explícitas para los robots de IA y una decisión sobre Content Signals aprobada por la empresa.
• Cómo comprobarlo: leer el archivo en la dirección pública del sitio (su-dominio/robots.txt), no el que está en el repositorio del proveedor, y probar qué ocurre con cada robot. El método está en el test de accesibilidad para bots.
• Señal de alerta: un archivo copiado de otra plantilla, con bloques que se contradicen, o un filtro de seguridad que bloquea robots que el archivo permite.

8. La red de distribución y la caché están configuradas y documentadas

• Por qué le importa a la empresa: una CDN (red de distribución de contenido) guarda copias del sitio en servidores cercanos al visitante. Con la caché activa, no hace falta construir la página de nuevo en cada visita, de una persona o de un robot. Sin ella, cada visita llega al servidor principal.
• Qué pedir: caché activa para las páginas públicas y las reglas del filtro de seguridad (el cortafuegos) documentadas, con excepciones para los robots legítimos.
• Cómo comprobarlo: pedir al equipo técnico que muestre el estado de la caché de una página clave.
• Para el equipo técnico: en Cloudflare, la cabecera cf-cache-status en DYNAMIC indica que la respuesta no se está sirviendo desde la caché. La guía técnica de Cloudflare para SEO y GEO explica la configuración.
• Señal de alerta: que cada visita llegue al servidor principal.

Bloque C: que la empresa conserve el control

9. Las cuentas quedan a nombre de la empresa

• Por qué le importa a la empresa: las herramientas donde se ve cómo se comporta el sitio y quién lo visita (Google Search Console, Bing Webmaster Tools, Microsoft Clarity, la analítica, el gestor de etiquetas) y los servicios que sostienen el sitio (el dominio, el DNS, la CDN) son activos de la empresa. Si la cuenta está a nombre del proveedor y la relación termina, los datos y la configuración quedan de su lado.
• Qué pedir: que todas esas cuentas estén a nombre de la empresa, con el proveedor como usuario con permisos mientras trabaja.
• Cómo comprobarlo: que alguien de la empresa pueda iniciar sesión en cada herramienta, ver quiénes son los propietarios y reciba por escrito una lista de accesos.
• Señal de alerta: cuentas creadas con el correo del proveedor, o un DNS al que la empresa no puede entrar.

Contenido exclusivo

Para lectores con cuenta

Entregar cuentas y continuidad

Prepare un inventario de titularidad, roles y recuperación con comprobaciones, sin compartir secretos.

Ingrese para acceder a esta sección →

Trabajamos para ofrecer contenidos de la mejor calidad; por eso algunas de estas explicaciones no son públicas.

10. La medición está documentada y existe una medición inicial

• Por qué le importa a la empresa: sin una medición previa, nadie puede demostrar si la entrega mejoró algo. Y si la medición no está documentada, depende de quien la instaló.
• Qué pedir: un plan de medición con los eventos clave (por ejemplo, una compra o un formulario enviado) y el tratamiento del consentimiento de los visitantes, y una medición inicial con fecha, tomada antes de la entrega.
• Cómo comprobarlo: disparar los eventos en un entorno de prueba y compararlos con el plan. Después de la entrega, repetir las mediciones iniciales con las mismas herramientas.
• Señal de alerta: «medición instalada» sin documento, sin lista de eventos y sin prueba.

Contenido exclusivo

Para lectores con cuenta

Comparar propuestas con la misma evidencia

Distinga requisitos indispensables, respuestas pendientes y demostraciones en una matriz editable.

Ingrese para acceder a esta sección →

Trabajamos para ofrecer contenidos de la mejor calidad; por eso algunas de estas explicaciones no son públicas.

Por dónde empezar si hay poco tiempo

Si no es posible verificar los diez criterios, cinco son baratos de comprobar y no requieren saber programar: el código fuente de una página clave (criterio 1), el informe de accesibilidad con pruebas de personas (criterio 2), el mapa del sitio y las direcciones anunciadas (criterio 5), la titularidad de las cuentas (criterio 9) y la medición inicial (criterio 10). Es un criterio de CookingMetrics basado en el costo de comprobarlos; no hay evidencia de que sean los de mayor impacto.

Qué no debería prometer ningún proveedor

• Posiciones ni menciones en respuestas de IA. Nadie controla qué ordena un buscador ni qué cita un asistente. La página de Google sobre sus funciones de IA indica que no hay requisitos adicionales para aparecer en AI Overviews ni en AI Mode y que no hace falta crear archivos legibles por máquina, archivos de texto para IA ni etiquetas nuevas (AI features and your website, página actualizada el 10 de diciembre de 2025, consultada el 27 de octubre de 2026).
• Un efecto de llms.txt. Es un archivo propuesto para orientar a los modelos de lenguaje. Esa página de Google no lo menciona y no habla por otros sistemas. Publicarlo cuesta poco; lo que no se sostiene con la evidencia de esta guía es prometer un efecto. En nuestro caso, el archivo estaba escrito y no se había publicado.
• «Optimización para IA» como paquete aparte. Si un proveedor lo vende, corresponde pedirle qué entregable concreto incluye y con qué prueba se verifica. Si la respuesta es una lista de buenas intenciones, es una señal de alerta.

Protocolos para agentes: cuándo hacen falta y cuándo no

Es posible que una propuesta incluya siglas como MCP, WebMCP, catálogo de API, descubrimiento de OAuth o protocolos de comercio. Son estándares nuevos para que los agentes de IA no solo lean un sitio, sino que ejecuten acciones en él. El anuncio de Cloudflare sobre su puntuación de preparación para agentes indica que varios de ellos están en desarrollo, que la tarjeta de servidor MCP es un borrador, que pocos sitios adoptan los estándares más recientes y que las comprobaciones de comercio se ejecutan pero no suman a la puntuación (Introducing the Agent Readiness score, publicado el 17 de abril de 2026, consultado el 27 de octubre de 2026).

Un criterio razonable es que solo hay caso de uso si el sitio ofrece algo que un agente pueda ejecutar, como una API, una acción o un catálogo consultable. Ante una propuesta que incluya estos protocolos, conviene preguntar quién los va a usar, cómo se probarán y quién los mantendrá. Una lista de protocolos como entregable, sin caso de uso, es una señal de alerta.

Cómo convertir la lista en un acuerdo

La prueba de aceptación convierte los diez criterios en un acuerdo verificable. Conviene fijarla antes de la entrega y por escrito:

• Antes: una medición inicial con fecha que incluya el código fuente de las páginas clave, el estado del mapa del sitio y de robots.txt, los datos de campo de rendimiento, el informe de accesibilidad y la lista de cuentas con sus propietarios.
• Después: las mismas mediciones, con las mismas herramientas y las mismas direcciones, para que la comparación tenga sentido.
• Quién verifica: idealmente, una persona ajena al equipo que construyó el sitio.
• Qué consta en el contrato: cada criterio con su umbral y su método de verificación, la fecha de entrega y qué ocurre si no se cumple.

Una herramienta como isitagentready.com sirve como diagnóstico de partida, con límites que se explican en qué mide isitagentready.com y qué deja afuera.

Contenido exclusivo

Para lectores con cuenta

Una ficha operativa de alcance y aceptación

Defina entregable, condiciones de prueba, responsables y recuperación en un ejemplo de formulario.

Ingrese para acceder a esta sección →

Trabajamos para ofrecer contenidos de la mejor calidad; por eso algunas de estas explicaciones no son públicas.

Preguntas para llevar a la reunión con el proveedor

• ¿Qué parte del contenido se arma en el navegador del visitante y qué parte entrega ya armada el servidor?
• ¿Qué nivel de WCAG 2.2 se compromete y quién hará las pruebas con personas?
• ¿Con qué datos de campo se medirá el rendimiento y cuál es la meta por escrito?
• ¿Quién es el propietario de cada cuenta, del dominio y del DNS?
• ¿Qué medición inicial se entrega antes de empezar y cómo se repetirá después?
• ¿Qué incluye exactamente la «optimización para IA» y con qué prueba se verifica?
• ¿Qué protocolos para agentes se proponen, para qué caso de uso y quién los mantiene?
• ¿Qué ocurre si un criterio acordado no se cumple al entregar?

Contenido exclusivo

Para lectores con cuenta

Una reunión que termina con evidencia

Profundice respuestas comerciales y registre promesas, demostraciones y pendientes por requisito.

Ingrese para acceder a esta sección →

Trabajamos para ofrecer contenidos de la mejor calidad; por eso algunas de estas explicaciones no son públicas.

Un caso propio: lo que no estaba en funcionamiento

El 4 de septiembre de 2026 medimos cookingmetrics.com con los criterios públicos de Agent Readiness de Cloudflare y publicamos el resultado completo en Qué aprendimos al revisar nuestro sitio para agentes de IA. Cada punto se comprobó con una petición HTTP en esa fecha:

• /sitemap.xml, /sitemap_index.xml y /wp-sitemap.xml devolvían 404, aunque robots.txt anunciaba uno de ellos.
• llms.txt devolvía 404: el archivo estaba escrito y revisado en el repositorio, y nunca se publicó.
• La portada respondía con cf-cache-status: DYNAMIC, es decir, sin caché.
• El LCP de campo era de 6,15 s en escritorio y de 6,20 s en móvil, frente a una meta de 2,5 s.

La lección no es sobre ningún proveedor: es sobre la distancia entre lo que está resuelto en el código y lo que está resuelto en el sitio en funcionamiento. Es la distancia que una prueba de aceptación independiente busca cerrar, y es también la razón por la que cada criterio de esta lista se comprueba sobre el sitio real y no sobre el código.

Límites de esta lista

• No es un conjunto de garantías. No hay evidencia, en esta guía, de que cumplir los diez criterios aumente posiciones, visitas, menciones en respuestas de IA o ventas. Se justifican por su valor para las personas, los buscadores y el mantenimiento.
• Alcance de las fuentes. Lo que se cita de Google describe a Google. Lo que se cita de Cloudflare describe una herramienta y un conjunto de estándares en evolución.
• No todos los criterios aplican igual. Un sitio con poco contenido dinámico necesita menos del criterio 1; un sitio sin catálogo ni formularios, menos del criterio 3.
• Vigencia. La documentación oficial cambia. Cada dato lleva la fecha de actualización de su página y la de consulta, y conviene comprobarlo de nuevo antes de incorporarlo a un contrato.

Qué hacer después

El siguiente paso es tomar la medición inicial antes de aceptar la entrega: pedir las direcciones, abrir el código fuente de las páginas clave, recorrer el flujo principal con teclado y revisar quién es propietario de cada cuenta. Para saber si lo acordado se cumplió, se repiten las mismas mediciones después y las diferencias se registran con fecha.

Si desea que revisemos lo que su proveedor entregó, puede conocer nuestro servicio de SEO técnico y el de SEO para búsquedas con IA. Revisamos y acompañamos a su equipo de desarrollo; no desarrollamos el sitio.

Preguntas frecuentes

¿Necesito rehacer el diseño para que me encuentren los asistentes de IA?

No hay en esta guía evidencia de que un rediseño sea necesario para eso. Google indica que no hay requisitos adicionales para sus funciones de IA. Lo que conviene revisar es el estado actual: si el contenido depende de JavaScript, si el sitio responde con los códigos correctos y si la accesibilidad se puede verificar. Esa revisión puede indicar ajustes puntuales o una reconstrucción, según el caso.

¿Un overlay de accesibilidad alcanza para cumplir con WCAG?

La conformidad con WCAG se comprueba sobre el sitio, con pruebas, y no se garantiza por instalar un complemento. La orden de la FTC mencionada arriba prohíbe a una empresa afirmar lo contrario sin evidencia; no alcanza a otros proveedores. Antes de confiar en un overlay, corresponde pedir el informe de pruebas sobre las páginas reales.

¿Hace falta publicar llms.txt?

Google no lo menciona entre los requisitos de sus funciones de IA, y esa página no cubre a otros sistemas. Publicarlo cuesta poco, y prometer un efecto no tiene respaldo en lo que cita esta guía.

¿Quién debe ser el propietario de las cuentas de Google Search Console y de analítica?

La empresa. El proveedor puede tener permisos de usuario mientras trabaja, pero la propiedad de las cuentas, del dominio y del DNS debería estar a nombre de quien es dueño del sitio.

¿Quién debería hacer estas comprobaciones?

Idealmente, alguien ajeno al equipo que construyó el sitio. Puede ser un auditor externo o una persona de la propia empresa que siga los pasos de cada criterio; los más sencillos, como abrir el código fuente o revisar la titularidad de las cuentas, no requieren saber programar.