La IA no te menciona porque no te puede leer

Abres tu sitio y todo está en su lugar. El menú responde, las imágenes cargan, el texto se lee. Le preguntas a ChatGPT por lo que tú vendes y la respuesta menciona a otros tres. No hay error en pantalla, no hay página caída, no hay nada que arreglar a simple vista.

El sitio que estás mirando no es el que se leyó la IA. Antes de citar a alguien, los asistentes que contestan con información del momento mandan un rastreador a la dirección. Ese rastreador no abre una ventana de Chrome: pide el HTML, lee lo que llega y sigue con el siguiente.

Ahí vive el problema. Un agente no ejecuta JavaScript, no completa un login y no adivina rutas. Todo lo que necesite una de esas tres cosas para aparecer, para él no aparece.

La misma página, dos lecturas

No son dos versiones del sitio ni una copia para robots. Es la misma URL, servida el mismo día. Lo único que cambia es quién la pide.

En los tres casos el resultado es el mismo: no eres candidato. No te ganó nadie con mejor contenido. Nunca estuviste en la lista de la que sale la respuesta.

Y es una lista que se arma sin avisarte. No hay un correo que diga que te bloquearon, ni un tablero donde se vea. Por eso lo primero no es escribir más: es comprobar qué te está dejando fuera.

Cuál de las tres puertas tienes cerrada no se adivina mirando tu sitio, porque tu navegador te la esconde. Se mide. La 01 es el escaneo: pegas tu dominio, esperas menos de un minuto y te vuelve un reporte con la evidencia de cada revisión, en la palabra del escáner y no en la tuya.

El resto de la página es el bucle completo, en el orden en que conviene hacerlo: escanear, leer el reporte sin engañarte, elegir qué arreglar y qué ignorar, dárselo a Claude Code y volver a medir para comprobar que sirvió.

Antes de arreglar nada necesitas la foto de cómo te ve hoy un agente. Esa foto sale de una sola pantalla: un campo, un botón y un reporte con la evidencia de cada revisión. No hay nada que instalar, ninguna extensión que autorizar y ningún paso previo que preparar.

Lo único que conviene saber antes de escribir el primer dominio es dónde termina ese reporte, porque no se queda en tu pantalla. El resto es escribir y hacer clic.

El escáner es de Vercel Labs y vive en is-agentic.com. Acepta cualquier URL pública: la tuya, la de un competidor, la de un cliente. Lo único que exige del sitio medido es que se pueda abrir sin iniciar sesión.

Son tres movimientos y ninguno tiene truco. Si tienes el dominio a la mano, hazlo mientras lees.

123

• 1El campo. Con https o sin él, da igual: acepta el dominio pelado.
• 2Un clic. No pide cuenta, ni correo, ni tarjeta.
• 3El mismo escaneo desde la terminal, si prefieres no abrir el navegador.

El navegador no es la única puerta: el mismo escaneo corre desde la terminal. Los comandos y las tres superficies automatizables están en la 08; para el primer escaneo no hacen falta.

Cuando el reporte aparece, la parte fácil ya se acabó. Lo que sigue es leerlo sin engañarte: qué significa cada bolsa de puntos, qué quiere decir un resultado parcial y por qué la tarea en vivo que corre ahí abajo no mueve el número. Eso es la 02.

Corre el escaneo ahora y deja el reporte abierto en otra pestaña. De aquí en adelante la guía habla de tus hallazgos, no de un ejemplo.

El reporte abre con un número grande y una etiqueta que lo resume en palabras. Ese número es lo último que conviene leer. Primero va de dónde sale, porque de ahí sale la única decisión que importa: qué arreglas y en qué orden.

La nota se arma con tres bolsas separadas. Las revisiones esenciales se reparten 80 puntos. Las recomendadas se reparten 20. Las señales emergentes suman aparte, con un tope de 5, y nunca son requisito de nada. No hay una cuarta bolsa ni un multiplicador escondido.

Dos reglas más cambian cómo se lee la lista de hallazgos. Las revisiones que no aplican a tu sitio se excluyen del cálculo: no cuentan en contra, sencillamente no están ahí. Y un resultado parcial recibe crédito proporcional, así que un hallazgo a medias sí te da puntos, y el reporte lo marca como parcial en vez de fallido.

Las tres bolsas

La suma, con el redondeo a la vista

Así se ven las tres bolsas en el reporte de tododeia.com. Cada una trae su puntaje y cuántas revisiones pasaron de las que aplicaban.

Essential        76.2 / 80     6 / 7 passed
Recommended        20 / 20     9 / 9 passed
Bonus                 +3.3     14 positive signals

76.2  +  20  +  3.3  =  99.5

Y arriba, en el número grande, dice 100. El redondeo existe y conviene tenerlo presente. Un 100 no significa que no quede nada: en este reporte queda una revisión esencial en parcial. Significa que lo que falta ya no alcanza a mover el entero.

Por eso una mejora chica puede no mover la portada y sí mover una bolsa. Cuando vuelvas a medir, compara las tres bolsas y el estado de cada revisión, no solo el número de arriba: es la diferencia entre saber si algo sirvió y creerlo. Cómo volver a medir sin engañarte está en la 07.

La página de metodología es corta y vale la pena leerla una vez: is-agentic.com/methodology trae las reglas de reparto tal como su autor las escribió.

Cómo se escribe ese archivo, y por qué ese encabezado va en inglés aunque el resto del sitio esté en español, no es de esta sección: el catálogo de arreglos de la 05 lo trae con el prompt que lo redacta por ti.

La página, de arriba abajo

El reporte trae siempre las mismas secciones y en el mismo orden. Reconocerlas de memoria te ahorra leerlo entero cada vez.

1234

• 1La nota. Aquí suma 99.5 y se muestra redondeada a 100.
• 2Las esenciales valen 80 de los 100. Es donde se gana o se pierde.
• 3El botón que arma el informe de arreglos para tu agente.
• 4Fuerza una medición nueva, sin esperar a que caduque la guardada.

Con esto ya puedes leer cualquier reporte sin que el número te maneje. Falta la parte incómoda, y es el error caro que se comete con esta herramienta: la 03 explica por qué esa nota no sirve para compararte con otro sitio, porque dos sitios distintos casi nunca reciben el mismo conjunto de revisiones.

Regla corta para leer cualquier reporte: primero el estado de cada revisión esencial, después las tres bolsas, y al final el número grande. En ese orden el reporte te dice qué hacer. Al revés, solo te dice cómo sentirte.

La nota se lee como una calificación de escuela, y ahí empieza el problema. Un 100 no te pone arriba de nadie y un 71 no te pone abajo. Entre un sitio y otro no cambia solo qué tan bien resolviste: cambia cuántas revisiones te tocaron.

El ejemplo está medido. tododeia.com saca 100 sobre 16 revisiones elegibles. vercel.com saca 87 sobre 33. Leído de corrido parece que un sitio de guías está mejor resuelto que la empresa que construyó el escáner. No es lo que dice el número: a vercel.com le aplican 17 revisiones más.

Esas revisiones de más son las que solo existen donde hay una API pública que consumir. Piden un OpenAPI publicado, un modelo de errores, encabezados de límite de tasa, una política de versionado, OAuth, permisos por alcance y compatibilidad con function calling. Un sitio de guías no tiene dónde fallar eso, así que ni se le pregunta.

La nota mide qué tan bien resuelves las revisiones que te tocan, no cuántas te tocan. Por eso no se resta contra la de otro dominio.

Ocho dominios, el mismo día

Los ocho se midieron el 27 de agosto de 2026 con la API pública del escáner, en la misma tanda. Lee primero la columna de revisiones elegibles y después la nota. En ese orden la tabla se explica sola.

El último renglón es el control. example.com no vende nada, no documenta nada y no expone nada: recibe 14 revisiones y sale con 52. Ese 52 no es el castigo por estar mal hecho, es lo que queda cuando casi no hay nada que revisar. Y el 87 de arriba tampoco es un reproche: es una nota sobre el doble de preguntas.

Cómo se reparten los puntos dentro de cada bolsa, qué pasa con un resultado parcial y por qué lo que no aplica no cuenta en contra está en la sección 02, la que lee el reporte. Aquí solo importa una consecuencia de todo eso: el denominador cambia con cada sitio, y nadie te lo enseña completo.

Contra qué sí te puedes comparar

La nota es útil como termómetro de una sola cosa: tu propio sitio a lo largo del tiempo. Ahí el conjunto de revisiones se queda quieto, y cualquier movimiento del número es tuyo. En cuanto cambias de dominio, cambian las preguntas, y el número deja de medir lo mismo.

Compararte contigo mismo tiene su propia letra chica —cuándo el escáner vuelve a medir de verdad y qué cuenta como el mismo objetivo—, y eso se resuelve en la sección 07. Sin esa parte es fácil celebrar un arreglo mirando una medición vieja.

Compárate contigo mismo entre mediciones y deja de restar dominios: es la única lectura que aguanta. Y un 100 no quiere decir que terminaste. Quiere decir que resolviste las revisiones que hoy te aplican. El día que publiques una API, un CLI o un servidor MCP, el escáner te va a hacer preguntas que hoy no te hace, y la nota se recalcula con ellas adentro.

El reporte no termina en la nota. Termina en una lista de hallazgos, cada uno con la evidencia exacta que el escáner midió y el cambio que recomienda. Ahí es donde se atora casi todo el mundo: ya sabe qué está mal y no sabe cómo pedirlo.

Is Agentic cubre ese salto con un botón. Se llama «Prompt to improve», está junto a la nota y redacta el pedido por ti: eliges qué hallazgos entran, copias, y te llevas un informe de tarea listo para pegar en Claude Code.

Importa más de lo que parece. Cuando cuentas un hallazgo con tus palabras, lo primero que se pierde es la evidencia —la frase medida, el número, la ruta— y sin ella el agente arregla lo que cree que dijiste. El informe la lleva pegada.

123

• 1Recomendados, todos o ninguno. Empieza por los recomendados.
• 2Cada hallazgo se marca por separado, para pedir un arreglo a la vez.
• 3Copia el informe ya redactado. De aquí se va directo a Claude Code.

El cuadro no mide nada nuevo: empaqueta los hallazgos que el reporte ya trae, con la evidencia con la que salieron. Cómo se lee ese reporte y qué pesa cada bolsa está en la 02.

Cuál de los tres eliges

Los tres hacen lo mismo —marcar casillas— y lo que cambia es cuánto trabajo le entregas al agente de una sentada. El criterio no es cuántos hallazgos tienes: es cuánto vas a poder revisar tú después.

Marcar una sola casilla es la opción menos vistosa y la que más conviene. Pides un arreglo, lo revisas, lo despliegas y vuelves por el siguiente. Un informe con doce hallazgos produce un cambio grande que nadie lee entero, y el día que algo se rompe no sabes cuál de los doce lo rompió.

El atajo que se salta el cuadro

Después del prompt del escáner va el tuyo

El informe que copiaste está escrito contra la evidencia, no contra tu stack. El escáner mide desde fuera: ve el HTML que le llega, los encabezados y las respuestas. No sabe con qué framework se construyó tu sitio, ni quién sirve esa ruta, ni si el hallazgo aplica a tu caso.

Ahí está el error caro: pegar el informe y dejar que el agente empiece a editar archivos. Un agente con un informe y sin contexto encuentra dónde tocar en segundos y te devuelve un cambio grande sobre un hallazgo que quizá ni era tuyo.

El prompt de abajo se pega justo debajo del informe, en el mismo turno. Lo primero que hace es prohibir la escritura: ese turno es de diagnóstico y nada más. Devuelve los hallazgos separados en tres grupos —aplica y es barato, aplica y es caro, no aplica— con el motivo de cada uno y el orden en que los haría.

Arriba está el informe de Is Agentic para mi sitio.

NO EDITES NINGÚN ARCHIVO TODAVÍA. Este turno es solo de diagnóstico.

MI SITIO
- Dominio: _______
- Framework y hosting: _______
- Quién puede desplegar: _______

QUÉ QUIERO QUE HAGAS
1. Recorre el informe hallazgo por hallazgo. Para cada uno dime en una línea qué
   observó el escáner y qué habría que cambiar en MI stack, no en abstracto.
2. Sepáralos en tres grupos:
   APLICA Y ES BARATO — se arregla con configuración o con un archivo nuevo.
   APLICA Y ES CARO — pide rediseño, migración o tocar el render.
   NO APLICA — explícame por qué mi sitio no lo necesita.
3. Si un hallazgo depende de algo que no puedes ver desde el repo, dilo y dime
   qué comando corro yo para averiguarlo.
4. Cierra con el orden en que los harías y qué ganaría de puntos cada uno, y
   marca cuáles son esenciales y cuáles recomendados.

REGLA
Si no estás seguro de que un arreglo aplica a mi stack, dilo en vez de
suponerlo. Prefiero una lista corta y correcta que una larga y a medias.

El triaje ordena, todavía no arregla. El catálogo de arreglos está en la 05: los que se resuelven con configuración o con un archivo nuevo, y el único que toca cómo se sirve el sitio.

Entre el botón del escáner y el triaje ya tienes el pedido completo: la evidencia sin parafrasear y la decisión de qué aplica a tu sitio. Lo que sigue es hacer uno, comprobarlo y volver por el siguiente.

Este es el catálogo. Siete arreglos que no piden que sepas programar: se resuelven con un archivo nuevo, con un bloque de datos en la portada, con texto escrito a mano o con una regla en el panel de tu hosting. Cada uno apaga una revisión concreta del escáner, y de cada uno se sale con una comprobación, no con una sensación.

El orden de abajo va por esfuerzo: primero los que son un archivo suelto, después los que piden sentarte a escribir, y al final los que dependen de cómo responde tu servidor. Si no vas a hacerlos todos, empieza por los dos últimos: el 404 y los bots son esenciales, y son los que dejan a un agente sin poder leerte.

Hay un octavo. Va aparte y marcado, porque es el único que toca configuración de verdad y porque trae una trampa que casi nadie documenta.

La columna de la derecha dice en qué bolsa cae cada revisión. Cuánto pesa cada bolsa y por qué un hallazgo a medias no vale cero está en la 02; aquí la bolsa sirve nada más para saber cuál harías primero si tuvieras que elegir.

Uno por uno, con su comprobación

Escribe el llms.txt de mi sitio y déjalo en la raíz, servido como texto
plano en /llms.txt.

MI SITIO
- Qué es y para quién: _______
- Las cinco páginas que más importan: _______
- A qué NO sirve mi sitio (para que un agente no me recomiende mal): _______

CÓMO LO QUIERO
1. Empieza con un encabezado de primer nivel con el nombre del sitio y una línea
   que diga qué es.
2. Después, una sección titulada EN INGLÉS: "## When to use <nombre del sitio>".
   El detector de Is Agentic busca esa frase en inglés, así que ese encabezado va
   en inglés aunque el resto del archivo esté en español. Dentro: en qué casos un
   agente debería recurrir a mi sitio y en cuáles no. Sé concreto — el texto de
   marketing genérico no cuenta como guía.
3. Después, un índice de enlaces en markdown a las páginas reales, cada una con
   una línea de qué contiene.
4. Mantenlo por debajo de 30,000 caracteres. Si me sobra contenido, muévelo a
   /llms-full.txt y enlázalo desde el índice.

ANTES DE DARLO POR HECHO
Comprueba con curl que cada enlace que declaraste devuelve el documento y no la
portada. Un 200 no basta: mira el cuerpo. Si alguno no resuelve, quítalo o
arréglalo; un agente que sigue el índice trata un enlace roto como callejón sin
salida.

Vas a arreglar los hallazgos del grupo APLICA Y ES BARATO del triaje.

CÓMO QUIERO QUE TRABAJES
Uno a la vez. Por cada arreglo: me dices qué vas a cambiar y en qué archivo,
lo haces, y me das el comando con el que YO lo compruebo. No pases al siguiente
hasta que yo confirme.

LA LISTA, EN ESTE ORDEN
1. JSON-LD de Organization en la portada, con name, description, url, logo,
   contactPoint (con correo o teléfono y contactType) y address como
   PostalAddress. Añade sameAs con todos los perfiles de autoridad que tenga:
   _______
2. /about, /contact y /privacy de verdad, con al menos 500 caracteres de texto
   real cada una. No plantillas vacías: son las páginas que un agente lee para
   decidir si mi negocio existe.
3. Los cuatro metadatos de la portada: link canonical, atributo lang en html,
   og:image y og:type.
4. sitemap.xml con todas las URLs indexables y con lastmod real, actualizado
   cuando el contenido cambia de verdad.
5. Un 404 que devuelva HTTP 404 —nunca un 200 con el cascarón de la app— y que
   traiga un cuerpo corto en markdown apuntando al sitemap y al llms.txt.

REGLAS
- No toques archivos de configuración de despliegue, secretos ni lockfiles.
- Si un cambio necesita un dato que no tengo escrito arriba, pregúntamelo en vez
  de inventarlo. Un contactPoint falso es peor que ninguno.

El octavo: el único que toca configuración

Los siete de arriba se hacen con archivos, con texto y con una regla en un panel. Este no. Pide entender cómo tu hosting arma la respuesta, y si despliegas en Vercel con Next trae una trampa que casi nadie documenta. Si no eres tú quien despliega, este es el que se le pasa a quien sí.

La revisión se llama «Markdown content negotiation (acceptmarkdown.com)» y pide dos cosas: que tu URL canónica sirva text/markdown cuando el cliente lo prefiere en su encabezado Accept, y que agregues Accept al encabezado Vary. La razón del Vary la dice el propio arreglo: sin él, un CDN puede entregarle la variante HTML guardada a un agente que pidió markdown.

La revisión toma su nombre del validador que la mide: acceptmarkdown.com te dice qué partes del contrato cumple una URL, y es la forma más rápida de ver si el arreglo quedó antes de volver a escanear.

Falta una revisión esencial que no está en esta lista, y no es olvido: «Content without JavaScript» no se arregla con nada de lo de arriba y casi nadie la pasa. Se ve aparte, en la 06, con su fórmula real y con el criterio para decidir si vale la pena perseguirla.

Cuando despliegues, no vuelvas a escanear dando por hecho que verás el cambio: el reporte se guarda un rato y te puede devolver la foto vieja. Cómo comprobar que el arreglo sirvió está en la 07.

Ninguno de estos arreglos te promete una cita en una respuesta de IA. Lo que hacen es quitar las razones por las que hoy no eres candidato: un rastreador que rebota, una ruta que miente, una página que nadie puede leer sin cuenta. Hazlos de uno en uno y comprueba cada uno antes de pasar al siguiente. Así, cuando la nota se mueva, vas a saber cuál la movió.

Hay una revisión esencial que no pasa casi nadie. Se llama «Content without JavaScript», y en los seis sitios grandes que esta guía midió el mismo día —vercel.com, stripe.com, nextjs.org, anthropic.com, figma.com y notion.com— sale parcial. En los seis. Ninguno la pasa entera.

Eso cambia cómo se lee. Una revisión que sale parcial en todos lados no es una tarea que se te quedó pendiente: es el estado normal de la web moderna. Conviene entenderla bien, porque casi siempre la decisión correcta es no perseguirla, y esa decisión hay que poder sostenerla con algo más que un encogimiento de hombros.

Los números de cada uno de esos sitios —cuántas revisiones les tocaron y qué nota sacaron— están en la tabla de la sección 03. Aquí importa una sola coincidencia: la misma revisión, parcial, en los seis.

PARTIAL · ESSENTIAL   Content without JavaScript
  Evidence   811 chars with H1 but flat heading structure

Esa línea es una plantilla fija. Cambia el número de caracteres y nada más: el resto del texto sale idéntico en todos los reportes, tenga tu página los encabezados que tenga.

Y como termina en «flat heading structure», se lee como si te faltaran encabezados. Lo primero que hace casi todo el mundo es irse a meter h2 a la portada. Conviene decirlo antes de que pierdas la tarde: agregar encabezados no mueve esta revisión.

Que sea esencial y no un extra importa, y cómo se reparten los puntos entre esenciales, recomendadas y bonus está en la sección 02. Lo que se decide aquí es otra cosa: qué separa un parcial que puedes dejar así de una falla que sí te deja fuera.

La fórmula que de verdad se mide

La revisión no cuenta encabezados. Calcula una proporción: cuánto de lo que mandas por la red es texto que un agente puede leer sin ejecutar JavaScript. Son tres pasos y una comparación, y ninguno de los tres tiene que ver con la jerarquía de tus títulos.

Ahí está lo que hay que ver: el arreglo que el propio escáner recomienda —un h1 y más de 500 caracteres en el HTML crudo— esta portada ya lo cumple, con 811. Y aun así sale parcial. La recomendación describe el síntoma; lo que se mide es la proporción.

Parcial no es fallida, y ahí está la diferencia

Nada de lo anterior significa que el render del servidor dé igual. Significa que hay dos resultados distintos bajo el mismo nombre, y solo uno de los dos es un problema tuyo.

Si tu sitio manda de verdad un cascarón vacío y todo el contenido aparece después, con JavaScript, la revisión no sale parcial: sale fallida, y la evidencia deja de ser la plantilla. Eso sí te deja fuera, y eso sí se arregla.

Cuándo vale el rediseño y cuándo no

Esta es la revisión donde se aprende a decidir, porque es la primera que te pide más de lo que devuelve. El reporte no ordena por costo: te pone un hallazgo que se resuelve con un archivo de texto al lado de uno que pide tocar el render, y los dos se ven igual de rojos.

Antes de rediseñar algo por una revisión, contesta estas cuatro preguntas. Si la mayoría sale en contra, no la persigas y escribe por qué.

• ¿El arreglo cabe en un archivo, o toca cómo se renderiza el sitio entero?
• ¿La pasan los sitios que se parecen al tuyo, o no la pasa casi nadie?
• ¿Lo que mide describe un problema que tus lectores notarían, o es una proporción interna?
• ¿Qué le cambia a tu nota cerrarla? El peso de cada revisión dentro de su bolsa no está documentado, así que esto se estima, no se calcula.

Las que sí valen el rato son las otras: el catálogo de la sección 05 junta las siete que se resuelven con configuración o con un archivo nuevo, y la única que toca código de verdad.

Una revisión que decides no perseguir deja de ser un pendiente el día que escribes por qué. Anótalo junto al reporte, con fecha, y vuelve a abrirla solo cuando cambie el motivo. Lo que sigue es comprobar que los arreglos que sí hiciste movieron algo, y eso tiene su propia trampa: lo que te devuelve el escáner puede ser una foto guardada de antes de tu despliegue. Eso es la sección 07.

Arreglaste, desplegaste y quieres el número nuevo. Aquí es donde se rompe casi toda la remedición, y no por el arreglo: por la fecha. El escáner guarda cada reporte, así que lo que ves al volver a pedirlo puede ser lo que midió antes de tu cambio.

Volver a medir bien son tres cosas: saber cuándo el reporte que estás leyendo es viejo, forzar una medición nueva cuando lo necesitas, y escanear exactamente la misma dirección que arreglaste. Ninguna es difícil. Las tres se saltan seguido.

La fecha es el árbitro

Antes de comparar una sola cifra, busca la fecha de la medición y ponla al lado de la de tu despliegue. Si la medición es anterior, lo que tienes enfrente es el sitio de ayer y cualquier lectura sobra. En la página del reporte aparece como «Scanned»; en la respuesta en JSON, como scanned_at.

REPORT
  URL      https://is-agentic.com/scan/tododeia.com
  Scanned  2026-08-27T17:26:13.843Z
  Checks   16 eligible

Esas tres líneas se leen primero, no al final. Dicen qué dirección se midió, cuándo se midió y cuántas revisiones entraron. Si la segunda no es posterior a tu despliegue, las demás no significan nada todavía.

Quién lanza la medición y quién solo la lee

Hay dos formas de volver a pedir el número sin abrir el navegador, y se comportan distinto. Confundirlas es un error de lectura frecuente, porque una de las dos puede responder que no hay nada y hacerte creer que tu sitio se rompió.

Aquí solo importa cuál de las dos mide y cuál solo consulta lo ya medido. Los comandos, el formato de salida y el servidor MCP están en la sección 08, con lo que devuelve cada uno.

Ya desplegué los arreglos. Quiero saber si movieron la nota de verdad.

QUÉ HACER
1. Corre: npx is-agentic _______ --json
2. Mira scanned_at en la respuesta. Los reportes solo se refrescan cuando una
   visita los encuentra con más de seis horas, así que si esa fecha es anterior a
   mi despliegue estás leyendo la foto vieja. Dímelo y no sigas: en ese caso yo
   abro el reporte en el navegador y le doy a Rescan.
3. Cuando la fecha ya sea posterior al despliegue, compárala contra estos números
   de antes:
   - nota: _______
   - esenciales: _______ / 80
   - recomendadas: _______ / 20
   - bonus: _______
4. Dime qué hallazgo cambió de estado, cuál sigue igual, y si alguno empeoró.

LO QUE NO QUIERO
No me digas que "mejoró la visibilidad". Dime qué revisión pasó de fallida a
parcial o de parcial a pasada, con la evidencia que trae el reporte. Si la nota
no se movió pero un hallazgo sí, eso también es progreso y quiero verlo.

El progreso se mide por revisión, no por la nota. Si un hallazgo pasó de fallido a parcial y el número redondeado no se movió, avanzaste igual: lo que cambió está en la lista de hallazgos y en su evidencia, no en el encabezado. Guarda el estado de cada revisión, no solo la cifra grande, y la comparación siguiente te va a decir algo en vez de dejarte adivinando.

El navegador está bien para el primer escaneo y para leer el reporte con calma. Deja de estarlo el día que desplegaste tres veces y quieres saber si el arreglo entró. Is Agentic sirve el mismo reporte por tres puertas: una terminal, una API y un servidor MCP.

Ninguna de las tres pide cuenta, correo ni API key. Lo que cambia entre ellas no es el dato: es quién lo lee. Tú, un script, o el agente que va a hacer el arreglo.

El CLI

El paquete se llama is-agentic y vive en npm, en la versión 1.0.1 con licencia ISC. Con npx no instalas nada de forma permanente: se descarga, corre y se va.

Se corre de dos maneras y la diferencia es para quién es la salida. La primera dibuja la barra, la nota y los hallazgos, y está pensada para que la leas tú. La segunda devuelve el reporte crudo, y es la que le pasas a un agente o a un script.

Así se ve la primera corrida contra este sitio. Este bloque no se copia a propósito: es lo que aparece en tu terminal.

▲ / Is Agentic  tododeia.com

  ████████████████████████████████████    100 / 100
                                          Strong technical baseline
                                          0 failed · 1 partial

SCORE BREAKDOWN
  Essential       76.2 / 80    6 / 7 passed
  Recommended       20 / 20    9 / 9 passed
  Bonus                +3.3    14 positive signals

PARTIAL (1)

1. PARTIAL · ESSENTIAL  Content without JavaScript
   Evidence  811 chars with H1 but flat heading structure

REPORT
  URL      https://is-agentic.com/scan/tododeia.com
  Scanned  2026-08-27T17:26:13.843Z
  Checks   16 eligible

Fíjate en la última línea, la que dice «Checks 16 eligible». Es cuántas revisiones consideró aplicables el escáner a este sitio, y es el número que cambia de un dominio a otro. Qué implica eso al comparar dos notas está en la 03; aquí basta con saber que el CLI te lo imprime siempre, al pie del reporte.

La API pública de solo lectura

Un GET y ya. Sin autenticación, sin llave y sin registrar nada. Le pasas la URL codificada y te devuelve el reporte completo en JSON, listo para un panel o para un tablero interno.

Cambia el dominio del final por el tuyo, codificado: los dos puntos van como %3A y las diagonales como %2F. Si mandas la URL sin codificar, el parámetro se corta en el primer signo raro y te contesta con un error.

El último punto es el que sorprende. Un report_not_found no significa que tu sitio esté mal: significa que todavía no hay reporte, y la API no lo va a crear por ti. El CLI sí lanza la medición y espera a que termine; la API solo lee. Esa es la diferencia práctica entre las dos. Cuándo estás leyendo una foto vieja y cómo forzar una nueva está en la 07.

El servidor MCP

La tercera puerta no es para ti, es para tu agente. Se conecta pegando la URL, sin OAuth y sin API key, y expone tres herramientas de solo lectura.

La ventaja es de contexto, no de velocidad. Con el MCP conectado, el agente pide el reporte en el mismo hilo en el que va a arreglar: en vez de pegarle un texto que copiaste hace media hora, lo consulta en el momento y lo vuelve a consultar cuando termina.

La skill oficial

Las tres puertas de arriba le dan datos a tu agente. La skill le da criterio: es el archivo que le explica cómo se lee un reporte y qué hacer con cada hallazgo. Existe, y se sirve como archivo público.

Ábrela en la URL well-known donde vive el SKILL.md y guarda ese archivo como una skill de tu agente. Es texto plano: lo que ves en el navegador es lo que se instala.

Con cualquiera de las tres puertas el escaneo deja de ser una visita al navegador y pasa a ser un paso más de tu flujo: despliegas, corres el comando, comparas. La que más rinde a diario es el CLI con --json. La que más cambia el trabajo es el MCP, porque el agente que arregla es el mismo que mide.

Sales del escaneo con una lista de hallazgos y un prompt pegado en Claude Code. La pregunta que aparece sola es de herramientas: si Is Agentic ya te dijo qué falta, para qué quieres además un plugin que audita tu sitio. La respuesta corta es que no auditan lo mismo, y ni siquiera lo miran desde el mismo lado.

Is Agentic es un escáner externo: mide el dominio ya publicado, sin instalar nada y sin entrar a tu repositorio. Claude SEO AI es un plugin de Claude Code que corre en tu máquina, sobre los archivos del proyecto, y además de auditar aplica el cambio. Una te dice qué te está dejando fuera; la otra lo escribe donde vive.

Ninguna reemplaza a la otra y ninguna te pide una llave de API. Lo único que hay que tener claro es a cuál le preguntas qué.

Qué es el plugin, cómo se instala, sus cuatro comandos, cómo se lee su doble nota y qué hace antes de tocar un archivo: nada de eso se repite aquí. Todo está en la guía de Claude SEO AI, que es su casa.

El orden que sí sirve

El tercer paso trae una trampa de tiempo que conviene conocer antes de sacar conclusiones: un reporte recién pedido puede ser una foto vieja. Cómo se fuerza una medición nueva está en la 07.

Esa parte —que el archivo le diga al agente cuándo usarte— sí la revisa el escáner. Cómo aparece en el reporte está en la 02.

El plugin es de código abierto con licencia MIT, así que puedes leer qué revisa y qué cambia antes de dejarlo entrar a tu proyecto. El repositorio está en GitHub.

La regla corta: lo que se mide desde fuera se arregla desde dentro, y luego se vuelve a medir desde fuera. Usar una sola te deja con media vuelta: o sabes qué falta y no lo arreglas, o arreglas a ciegas sin saber qué ve un agente que llega de la calle.

Este sitio corrió la guía entera contra sí mismo antes de escribirla. tododeia.com empezó en 73 y hoy marca 100. Abajo está el recorrido con lo que cambió en cada paso y, sobre todo, lo que ese 100 no dice.

Los siete problemas abiertos del primer escaneo eran de plomería, no de contenido. Ninguno pedía escribir un artículo más ni cambiar una palabra de la portada: pedían un sitemap, unos datos estructurados, un llms.txt, tres páginas de confianza y un 404 que devolviera 404 de verdad. Esa suele ser la buena noticia de un reporte flojo. Lo que te deja fuera casi nunca es lo que dices, sino cómo lo sirves.

La letra chica es que el 100 no significa que no quede nada. Quedan tres cosas abiertas, y las tres están abiertas a propósito.

El recorrido, movimiento por movimiento

Las tres que quedan abiertas

Un reporte en 100 sigue trayendo hallazgos. Estos son los de este sitio, con el estado que marca el reporte y la razón por la que se quedan así. Ninguno es un olvido.

La primera es la que más se pregunta, y la respuesta no cabe aquí. La 06 explica cómo se mide esa revisión y cuándo conviene no perseguirla; la decisión de este sitio salió de ese cálculo, no de darla por imposible.

Y falta el dato que ordena todo lo anterior: son 16 revisiones elegibles, no 33. La 03 explica por qué esa cifra cambia de sitio en sitio y por qué dos notas no se comparan sin mirarla primero.

Compruébalo tú

Los números de arriba son los del 27 de agosto de 2026. Los reportes se vuelven a medir, así que el de hoy puede decir otra cosa. Corre esto y mira la nota que sale ahora mismo.

Si lo prefieres con formato y con la evidencia de cada revisión desplegada, el reporte completo se abre en el navegador. Cambia el dominio por el tuyo y tienes el mismo par para tu sitio.

Si el reporte dice algo distinto a lo que acabas de leer, gana el reporte. Esta sección es una foto fechada del 27 de agosto de 2026 y la herramienta mide en vivo. Lo que no caduca es el método: arreglas lo que aplica, escribes por qué descartaste el resto, y vuelves a medir con la fecha enfrente.