13 de agosto de 2026
Si comparo cómo hacíamos SEO hace relativamente poco con cómo lo hacemos hoy, lo que más ha cambiado no es ninguna técnica concreta.
Seguimos preocupándonos por la indexación. Seguimos revisando arquitectura, enlaces internos, contenido, rendimiento, metadata, datos estructurados, Search Console y resultados de búsqueda.
Nada de eso desapareció.
Lo que cambió mucho fue la forma en la que conectamos todas esas tareas.
Antes era normal trabajar saltando constantemente entre herramientas.
Abríamos Search Console para detectar una caída. Pasábamos determinadas URLs por un crawler. Exportábamos información. Revisábamos keywords. Abríamos el proyecto en VS Code. Buscábamos qué plantilla o componente estaba relacionado con el problema. Hacíamos el cambio. Desplegábamos. Volvíamos a rastrear la web. Y después comprobábamos si el resultado había sido el esperado.
Cada herramienta resolvía correctamente su parte del trabajo, pero había algo que prácticamente siempre ocurría igual: éramos nosotros quienes teníamos que transportar el contexto de una herramienta a otra.
Ese es probablemente el cambio más importante que estamos experimentando con los agentes de IA.
No porque hayan aparecido técnicas SEO completamente nuevas. Sino porque ahora podemos tener un agente trabajando dentro del mismo entorno donde está el código, ejecutar herramientas desde allí, darle acceso controlado a fuentes externas, cruzar información y continuar trabajando sobre el problema sin reconstruir manualmente el contexto en cada paso.
La diferencia puede parecer sutil. No lo es. Porque una cosa es utilizar inteligencia artificial para hacer una tarea SEO. Y otra muy distinta es utilizarla como parte del sistema con el que haces SEO.
Usar ChatGPT para SEO no es lo mismo que trabajar con agentes
La IA lleva tiempo presente en SEO. Generar alternativas para un title. Agrupar miles de keywords. Crear expresiones regulares. Clasificar intenciones de búsqueda. Preparar una estructura de contenido. Analizar una exportación de Search Console. Resumir los problemas encontrados en un crawl.
Todo eso puede ahorrar muchísimo tiempo. Pero sigue siendo, en esencia, la misma metodología anterior con una herramienta más rápida dentro de ella. Nosotros le damos una tarea. La IA devuelve un resultado. Después nosotros llevamos ese resultado hasta la siguiente herramienta.
El cambio que estamos viendo ahora empieza cuando el modelo deja de limitarse a responder preguntas y puede actuar sobre el entorno donde estamos trabajando. Puede leer el repositorio, buscar archivos, seguir dependencias, ejecutar comandos, lanzar un crawler, consultar una API, modificar varios componentes, ejecutar tests, revisar el resultado y continuar investigando dependiendo de lo que encuentre.
Eso empieza a parecerse menos a un chatbot y más a un workflow.
Claude Code es un ejemplo especialmente claro. Anthropic lo define actualmente como una herramienta de programación agéntica que puede leer un codebase, editar archivos, ejecutar comandos y trabajar integrada con herramientas de desarrollo.
Para SEO, esa diferencia importa mucho.
El SEO empieza a acercarse al código
Durante mucho tiempo hemos auditado una parte importante del SEO técnico observando el sitio desde fuera. Y sigue siendo necesario. Pero muchas veces estamos analizando las consecuencias de decisiones que nacieron dentro del código.
Imagina que encontramos 150 páginas con un canonical incorrecto. Desde un crawler tenemos 150 errores. Desde el repositorio quizá tengamos uno. Puede ser una función que construye mal la URL, un layout que recibe una variable equivocada, una condición que no contempla determinada colección, o una configuración incorrecta del dominio principal.
El crawler ve 150 síntomas. El código puede contener una sola causa.
Y ahí es donde trabajar con un agente dentro del repositorio resulta especialmente interesante. En lugar de pedir “dime qué páginas tienen un canonical incorrecto”, podemos llegar a trabajar con instrucciones mucho más cercanas al problema real: “estas URLs están generando un canonical incorrecto, investiga qué tienen en común, identifica dónde se genera dentro del proyecto y determina cuál sería la corrección”.
El agente puede recorrer el proyecto hasta encontrar esa relación. No siempre tendrá razón. No deberíamos aplicar automáticamente todo lo que propone. Pero reduce enormemente la distancia entre detectar un problema y encontrar dónde nace.
De detectar errores a intentar impedir que vuelvan a ocurrir
Esta evolución tiene otra consecuencia que nos parece todavía más importante. Una auditoría tradicional suele preguntar: ¿qué está mal ahora? Cuando el SEO empieza a integrarse con desarrollo podemos añadir otra pregunta: ¿cómo evitamos que esto vuelva a llegar a producción?
Si existe una regla objetiva, existe la posibilidad de comprobarla. Por ejemplo: una página de determinado tipo debe tener canonical; una entrada indexable debe tener title; las rutas generadas no deberían contener enlaces hacia páginas inexistentes; el sitemap debe incluir determinadas colecciones; una página que queremos indexar no debería recibir accidentalmente noindex; un schema generado por una plantilla debe contener determinados campos; una variable de entorno no debería provocar que las URLs canónicas apunten al dominio de staging.
Ese tipo de comprobaciones pueden acercarse al mismo modelo que ya utilizamos con tests, linters y otras validaciones del software.
El SEO deja entonces de ser únicamente publicamos → auditamos → encontramos → corregimos, y parte del flujo puede transformarse en desarrollamos → comprobamos → corregimos → publicamos → verificamos.
No todo problema SEO encaja en ese esquema. Pero muchos más de los que tratábamos así hace unos años sí pueden hacerlo.
El SEO dentro de CI/CD
Aquí es donde CI/CD empieza a resultar especialmente interesante para SEO técnico. Si una comprobación puede ejecutarse desde línea de comandos, también puede ejecutarse automáticamente como parte de un pipeline.
Ya existen proyectos construidos explícitamente alrededor de esta idea. SEOmator, por ejemplo, mantiene actualmente un CLI open source que puede ejecutarse desde terminal o dentro de CI/CD. Su documentación incluye códigos de salida diferenciados para una auditoría aprobada, una auditoría fallida y un error de ejecución, además de ejemplos para GitHub Actions y GitLab CI. También dispone de integración como skill para Claude Code.
Hay crawlers open source como Open SEO Crawler que se ejecutan de forma autoalojada, analizan problemas técnicos, soportan renderizado JavaScript y detectan distintos CMS. Su propio proyecto se presenta como una alternativa abierta a herramientas de crawling tradicionales.
Lo relevante no es decidir cuál sustituye a cuál. Lo interesante es que la auditoría empieza a ser programable. Podemos ejecutar determinada validación cuando hacemos un pull request, ejecutar otra después de un deployment, impedir que un error crítico avance, registrar cuándo apareció, y asociarlo directamente con el cambio de código que lo produjo. Es la misma lógica que aplicamos al decidir cuándo migrar por deuda técnica: mejor detectar el patrón temprano que arrastrarlo hasta que se vuelve costoso.
Eso es conceptualmente muy diferente de descubrirlo semanas después dentro de una hoja de cálculo.
No todo debería bloquear un deployment
Aquí hay que ser prudentes. Automatizar una comprobación no significa que todo deba convertirse en un error crítico. No queremos que un deployment completo falle porque un sistema considera cuestionable la longitud de una meta description. Ese sería un mal uso de la automatización.
Las reglas deben tener severidad y contexto. Un canonical apuntando accidentalmente a otro dominio puede ser crítico. Generar cientos de URLs indexables por error puede ser crítico. Romper el sitemap puede ser crítico. Una recomendación sobre longitud de title probablemente no debería tener el mismo peso. Y una valoración sobre si un H1 comunica correctamente la intención de una página difícilmente debería decidirla de forma automática un pipeline.
La automatización funciona especialmente bien cuando podemos definir con claridad qué significa correcto e incorrecto. Cuanto más subjetiva sea la decisión, más importante sigue siendo la revisión humana.
Los crawlers no desaparecen
Integrar SEO con el repositorio no elimina la necesidad de rastrear el sitio. Son perspectivas diferentes sobre el mismo sistema. El repositorio puede decirnos cómo creemos que debería comportarse la web. Un crawler nos dice qué ocurre cuando alguien realmente intenta recorrerla.
Entre ambos existen muchas capas: CDN, servidor, redirects, headers HTTP, caché, JavaScript, APIs, bases de datos, configuración de producción, WAF, DNS, contenido generado dinámicamente. Un proyecto puede ser impecable localmente y servir algo distinto en producción. Por eso seguimos necesitando crawling.
La diferencia es que ahora podemos conectar mejor ambas partes. El crawler puede encontrar el síntoma. El agente puede utilizar esa información para buscar la causa. Y después podemos volver a rastrear el resultado. El flujo completo se acorta.
Claude Code: de analizar el reporte a investigar el proyecto
Aquí es donde herramientas como Claude Code cambian bastante nuestra forma de trabajar. No porque sean una “herramienta SEO”. No lo son. Precisamente por eso resultan interesantes.
Claude Code trabaja sobre el proyecto. Puede leer archivos, editar múltiples partes del codebase y ejecutar comandos. Eso permite que una auditoría SEO pueda convertirse en una entrada para un proceso más amplio.
Un crawler detecta enlaces rotos. El agente recibe el resultado. Busca dónde se generan. Encuentra que proceden de una colección determinada. Comprueba si existe un patrón. Corrige el componente. Ejecuta nuevamente la herramienta. Revisa el diff. Y deja el cambio preparado para revisión.
La auditoría sigue existiendo. Lo que cambia es lo que ocurre inmediatamente después. Antes el informe terminaba muchas veces convertido en una tarea para desarrollo. Ahora puede convertirse directamente en contexto de desarrollo.
MCP lleva ese contexto más allá del repositorio
El siguiente paso ocurre cuando el agente necesita información que no existe dentro de los archivos del proyecto. Ahí entra Model Context Protocol, o MCP. MCP es un protocolo abierto para conectar aplicaciones de IA con herramientas y fuentes de datos. En Claude Code, Anthropic permite utilizar servidores MCP para dar acceso a herramientas externas, bases de datos y APIs.
Eso abre posibilidades especialmente interesantes para SEO. El repositorio puede contener componentes, rutas, templates, contenido, configuración y tests. Pero no contiene necesariamente consultas reales de Google, clics, impresiones, posiciones, logs de producción, métricas analíticas, información de un CMS externo, datos de una plataforma SEO o incidencias de monitorización.
Esos datos viven en otros sistemas. El objetivo de MCP no es copiarlos todos dentro del modelo. Es permitir que el agente pueda consultar herramientas externas cuando las necesita. Así, un workflow puede empezar con un problema observado en datos externos y terminar dentro del código: Search Console → URLs afectadas → patrón común → repositorio → componente responsable → cambio → validación. O al revés: cambio de código → páginas afectadas → crawl → comparación → resultado.
Esta capacidad de trabajar entre distintos sistemas es una de las razones por las que MCP se ha convertido en una pieza importante del ecosistema de agentes. En diciembre de 2025, Anthropic aportó MCP a la Agentic AI Foundation, creada bajo la Linux Foundation junto con proyectos como goose y AGENTS.md.
Tener acceso no significa dar permiso para todo
Esta nueva capacidad también introduce un problema evidente. Si técnicamente podemos conectar un agente al repositorio, Search Console, un CMS, la infraestructura y producción, es fácil caer en la idea de que también deberíamos permitirle modificar todo automáticamente.
No creemos que ese sea el mejor enfoque. Nuestra preferencia es mantener trazabilidad. Cuando el problema pertenece al código, queremos que la solución termine idealmente dentro del flujo normal del código: detectar → investigar → modificar → validar → revisar → desplegar. No: detectar → modificar producción sin revisión.
Git sigue teniendo valor. Los pull requests siguen teniendo valor. Los permisos siguen teniendo valor. Los entornos siguen teniendo valor. Y cuanto más potente es el agente, más importantes resultan estos límites.
Anthropic incluso advierte en su documentación de MCP que conectar servidores capaces de obtener contenido externo introduce riesgos como prompt injection y recomienda verificar que se confía en los servidores conectados.
Automatizar no significa eliminar controles.
El cambio va más allá del SEO técnico
Hasta aquí podríamos pensar que todo esto afecta principalmente a auditorías. Pero la misma transformación empieza a aparecer en otras partes del SEO: investigación, contenido, arquitectura, análisis competitivo, enlazado interno, monitorización, reporting.
Hasta ahora era frecuente tratar estas actividades como procesos separados. Keyword research producía un documento. La estrategia de contenido producía otro. El crawler producía otro. Search Console producía otro. Desarrollo tenía su propio repositorio. Cada sistema tenía una representación diferente del mismo sitio.
Un agente puede empezar a operar entre todas ellas. Eso no significa que automáticamente tome mejores decisiones. Significa que puede conservar contexto entre pasos que antes estaban separados. Y eso cambia bastante el tipo de automatización que podemos construir.
El verdadero salto es pasar de tareas a workflows
Durante años automatizamos tareas: “extrae estos datos”, “clasifica estas keywords”, “genera estas descriptions”, “encuentra URLs que cumplan esta condición”.
Los agentes permiten pensar en secuencias: “encuentra qué páginas están perdiendo impresiones, determina si comparten plantilla o temática, revisa qué cambió, consulta el repositorio y prepara las hipótesis más probables”.
El resultado puede seguir necesitando un humano. De hecho, muchas veces debería necesitarlo. Pero la máquina ya no resuelve únicamente el tercer paso de diez. Puede recorrer varios pasos, utilizar herramientas diferentes y entregar un problema mucho más avanzado.
Ese es, para nosotros, el cambio metodológico importante.
Mientras cambia cómo hacemos SEO, también cambia dónde aparece el contenido
Todo esto está ocurriendo al mismo tiempo que cambia la propia experiencia de búsqueda. Google ha integrado AI Overviews y AI Mode. ChatGPT tiene funciones de búsqueda. Claude puede consultar la web. Perplexity está construido alrededor de búsqueda y respuestas con fuentes.
Esto introduce otra pregunta que hace unos años tenía mucha menos importancia: ¿nuestro contenido solo necesita rankear o también necesita ser recuperable y útil como fuente?
La respuesta no es abandonar Google tradicional. La respuesta es ampliar lo que entendemos por visibilidad.
Los clics siguen importando, pero ya no cuentan toda la historia
Hay señales claras de que algunas experiencias generativas reducen el porcentaje de sesiones que terminan en una visita externa. Semrush estudió casi 69 millones de sesiones de Google Search en escritorio en Estados Unidos entre mayo y julio de 2025. Dentro de su muestra, únicamente entre el 6% y el 8% de las sesiones de Google AI Mode terminaron visitando un dominio externo, es decir, aproximadamente un 92-94% fueron sesiones sin clic externo. El propio estudio advierte que las comparaciones con búsqueda tradicional deben hacerse con cautela porque proceden de metodologías y periodos diferentes.
Eso no significa que “Google ya no envía tráfico”. Sería una conclusión mucho más amplia de lo que permiten esos datos. Significa que hay experiencias de búsqueda donde la respuesta puede resolverse sin necesidad de visitar otro sitio. Por lo tanto, la visibilidad de una marca ya no se refleja únicamente en clics. También puede existir dentro de la propia respuesta — la misma idea que desarrollamos en nuestra nota sobre búsquedas zero-click, donde el objetivo deja de ser solo el tráfico.
Rankear y ser citado están relacionados, pero no son idénticos
Uno de los estudios que mejor ilustra este cambio fue publicado por Ahrefs en marzo de 2026. Analizaron 863.000 SERPs y unos cuatro millones de URLs citadas en AI Overviews. Solo el 37,9% de las URLs citadas también aparecía dentro de los primeros diez bloques de la SERP correspondiente — un patrón parecido al que documentamos en el impacto de Google AI Overviews sobre el tráfico orgánico. Cuando analizaron únicamente enlaces orgánicos tradicionales, la cifra fue del 37,1%.
Eso no demuestra que rankear haya dejado de importar. Sí demuestra algo relevante: Google puede utilizar como fuentes URLs que no ocupan las primeras posiciones de la consulta original.
Una explicación está en el funcionamiento de las propias experiencias generativas. Google documenta que AI Overviews y AI Mode pueden utilizar una técnica denominada query fan-out, generando varias búsquedas relacionadas sobre subtemas y fuentes de datos para construir una respuesta y encontrar más páginas de apoyo.
Eso cambia parcialmente cómo pensamos el contenido. La pregunta tradicional era: ¿para qué keyword queremos que rankee esta página? Ahora también tiene sentido preguntar: ¿para qué preguntas, subpreguntas o comparaciones podría esta página ser una fuente especialmente buena?
GEO existe, pero no reemplaza el SEO
A este nuevo trabajo se le suele llamar GEO: Generative Engine Optimization. El término es útil para hablar específicamente de visibilidad dentro de respuestas generativas. Pero conviene no convertirlo en una colección de trucos separados de los fundamentos del SEO.
Google publicó en mayo de 2026 una guía específica para optimizar sitios de cara a sus funciones generativas. Su posición es bastante clara: las mejores prácticas de SEO siguen siendo relevantes porque AI Overviews y AI Mode se apoyan en los sistemas centrales de Search. Google incluye entre los fundamentos la estructura técnica, crawlability, contenido valioso, enlaces internos y accesibilidad del contenido — los mismos fundamentos técnicos que revisamos en Core Web Vitals e INP, otra señal que Google confirma que sigue pesando en 2026.
Google también dice expresamente que, desde su perspectiva, optimizar para GEO o AEO dentro de Search sigue siendo SEO.
Esto coincide bastante con lo que vemos en la práctica. No estamos sustituyendo SEO por GEO. Estamos añadiendo nuevas superficies en las que un buen trabajo SEO puede generar visibilidad.
Para ser citado por una IA primero tiene que poder acceder a tu contenido
Aquí aparece otro aspecto técnico que se suele simplificar demasiado. No existe simplemente “el bot de ChatGPT” o “el bot de Claude”. Los proveedores utilizan distintos agentes para funciones diferentes.
OpenAI distingue actualmente entre OAI-SearchBot y GPTBot. OAI-SearchBot está destinado a las funciones de búsqueda de ChatGPT. GPTBot está asociado al crawling que puede utilizarse para mejorar los modelos fundacionales. Los controles son independientes: OpenAI documenta que un sitio puede permitir OAI-SearchBot para aparecer en resultados de búsqueda y bloquear GPTBot para indicar que no quiere que ese contenido se utilice para entrenamiento. Esta distinción es importante: bloquear entrenamiento no equivale necesariamente a bloquear búsqueda.
Anthropic diferencia también distintos agentes. Claude-SearchBot navega la web para mejorar la calidad y relevancia de los resultados de búsqueda. Claude-User puede acceder a una web cuando un usuario realiza una consulta que requiere recuperar ese contenido. Anthropic advierte que bloquear estos agentes puede reducir la capacidad de sus sistemas para recuperar o mostrar contenido de ese sitio en búsquedas iniciadas por usuarios.
Perplexity mantiene una separación parecida. PerplexityBot está diseñado para descubrir y enlazar páginas en los resultados de búsqueda de Perplexity. Perplexity-User puede acceder a una página durante una acción iniciada por un usuario para ayudar a responder su consulta e incluir un enlace en la respuesta.
Por eso no recomendamos manejar robots.txt simplemente bloqueando cualquier user-agent relacionado con IA. Primero hay que entender qué función cumple.
llms.txt: interesante, pero no una estrategia
Otra recomendación que aparece constantemente alrededor de GEO es crear un archivo llms.txt. La idea es sencilla: ofrecer una representación especialmente fácil de consumir para modelos de lenguaje.
Nos parece una iniciativa interesante. Y en determinados proyectos su coste de implementación puede ser tan bajo que no existe demasiado inconveniente en experimentar con ella. Pero no basaríamos una estrategia de visibilidad en ese archivo.
Google lo ha aclarado de manera especialmente contundente en su documentación de 2026: Search no utiliza llms.txt como requisito ni como señal especial para sus funciones generativas, y mantenerlo no beneficia ni perjudica rankings o visibilidad dentro de Google.
La misma documentación también desmonta otra recomendación habitual: no es necesario dividir artificialmente los contenidos en pequeños “chunks” para que la IA pueda entenderlos, ni reescribir un artículo siguiendo un formato especial únicamente para buscadores generativos.
Esto es importante porque ayuda a separar dos cosas. Facilitar el acceso técnico sí importa. Inventar rituales de optimización sin evidencia no.
Lo más importante para ser citado probablemente no sea un archivo técnico
Hay una consecuencia interesante de todo esto. Cuanto más fácil sea técnicamente generar contenido con IA, menos diferenciador será simplemente publicar contenido correcto. Un modelo puede explicar qué es un canonical, qué es un sitemap, crear una lista de errores habituales de SEO técnico, resumir diez artículos existentes y producir el undécimo.
Eso hace que la información propia cobre todavía más valor. Google utiliza en su guía de 2026 una expresión especialmente útil: recomienda producir contenido valioso y no commodity, con información única, experta y útil — el mismo criterio de confianza que ya afecta cómo se perciben las reseñas generadas por IA: lo genérico deja de convencer cuando es fácil de producir en masa.
Para nosotros, ese es probablemente uno de los principios más importantes para pensar también en citabilidad. Una página tiene más razones para convertirse en fuente cuando contiene algo que merece ser recuperado: datos propios, experiencia, metodologías, comparaciones originales, pruebas, resultados, errores encontrados, explicaciones especialmente claras, fuentes primarias bien atribuidas.
No existe una etiqueta HTML que pueda convertir contenido genérico en una fuente imprescindible.
Cómo ha cambiado nuestra metodología
Si tuviera que resumir lo que hacemos diferente hoy, no sería en términos de herramientas. Sería en términos del ciclo de trabajo.
Intentamos acercar SEO al momento en que se construye la web. No esperamos necesariamente a terminar el proyecto para empezar a comprobar SEO técnico. Cuando algo puede definirse en la arquitectura, intentamos resolverlo allí: rutas, metadata, canonicals, sitemaps, schema, enlazado, renderizado, indexabilidad.
Automatizamos aquello que puede expresarse como una regla objetiva. No todo merece automatización. Pero si sabemos de forma inequívoca que una condición es incorrecta, tiene sentido intentar detectarla automáticamente.
Seguimos observando la web desde fuera. El repositorio no sustituye a producción. Seguimos necesitando crawling, Search Console, analítica, rendimiento real y observación del comportamiento que reciben buscadores y usuarios.
Utilizamos agentes para investigar, no únicamente para generar. Esta ha sido una de las diferencias más importantes. El valor no está en pedir cien titles. Está en entregar un problema, proporcionar herramientas y dejar que el agente recorra distintas fuentes de información hasta reducir el espacio de posibles causas.
Intentamos convertir errores repetibles en comprobaciones. Después de resolver un problema técnico nos interesa una segunda pregunta: ¿podemos detectar automáticamente que esto vuelva a ocurrir? Cuando la respuesta es sí, la corrección deja de ser únicamente una corrección. También mejora el sistema.
Qué automatizamos y qué no
Hay una frontera importante que conviene mantener.
Son buenos candidatos para automatización: determinados errores de rutas, URLs rotas, campos obligatorios, generación incorrecta de canonicals, sitemaps, ciertas reglas de indexación, validación de determinados datos estructurados, problemas técnicos reproducibles, inconsistencias de configuración, comprobaciones posteriores a deployments.
Son buenos candidatos para asistencia de IA, pero con revisión: análisis de patrones, diagnóstico de caídas, oportunidades de enlazado interno, agrupación semántica, investigación competitiva, hipótesis sobre contenido, detección de posibles canibalizaciones, cambios grandes sobre templates.
Y hay decisiones que seguimos considerando humanas: qué producto merece posicionarse, qué tema merece publicarse, qué intención comercial perseguimos, qué página debe existir, qué contenido es realmente útil, qué recomendación representa mejor al negocio, qué riesgo estamos dispuestos a asumir, qué significa “mejor” cuando no existe una métrica objetiva que pueda decidirlo.
La IA puede aportar contexto. Pero contexto no equivale a responsabilidad.
El futuro no parece completamente autónomo
Es fácil imaginar una versión extrema de este futuro: un agente detecta una caída, consulta Search Console, rastrea el sitio, modifica el código, publica, analiza el resultado, y continúa indefinidamente sin intervención humana.
Técnicamente, cada vez estamos más cerca de poder construir sistemas así. Eso no significa que sean la mejor arquitectura. En SEO intervienen demasiadas decisiones ambiguas, comerciales y editoriales como para reducir todo el proceso a un bucle automático.
Nos resulta más interesante otro modelo: automatización amplia, acceso a mucho contexto y puntos claros de control humano. El agente hace más. El humano no necesariamente hace cada paso. Pero sigue decidiendo qué objetivo perseguimos, qué riesgo aceptamos y cuándo una solución es suficientemente buena.
SEO y desarrollo están convergiendo
Una de las conclusiones más claras que estamos sacando de esta evolución es que la separación tradicional entre “hacer una web” y “hacer SEO técnico” resulta cada vez menos natural.
Si un componente genera 500 títulos duplicados, eso es SEO. Pero también es código. Si una función crea canonicals incorrectos, es SEO. Y código. Si una arquitectura JavaScript impide acceder correctamente al contenido, es SEO. Y arquitectura de software. Si un deployment genera redirects incorrectos, es SEO. Y operaciones.
El SEO técnico siempre estuvo unido al desarrollo. Lo que está cambiando es que las herramientas empiezan a permitirnos trabajar de una manera que refleja mejor esa realidad.
Y SEO también está convergiendo con la búsqueda generativa
Algo parecido ocurre con GEO. No parece que estemos entrando en un mundo donde SEO desaparece y nace una disciplina completamente distinta. Lo que estamos viendo es una ampliación.
Antes queríamos que una página pudiera ser rastreada → ser indexada → rankear → recibir clics. Ahora también debemos contemplar: ser encontrada → ser recuperada → ser utilizada como fuente → ser citada o mencionada.
Gran parte de los fundamentos son los mismos: accesibilidad, arquitectura, autoridad temática, información clara, contenido original, fuentes, actualización, calidad. La superficie donde aparece el resultado es lo que está cambiando.
Nuestra principal conclusión después de cambiar la forma de trabajar
Lo que más ha cambiado nuestra metodología no ha sido una herramienta concreta. Claude Code puede evolucionar. MCP seguirá cambiando. Aparecerán nuevos crawlers. Los modelos serán distintos dentro de un año. Y seguramente algunas de las herramientas que hoy utilizamos serán reemplazadas.
La transformación más importante está un nivel por encima. Estamos pasando de hacer SEO como una colección de tareas realizadas en herramientas separadas a tratarlo cada vez más como un sistema conectado alrededor de la web.
Un problema puede empezar en Search Console. Pasar por un crawler. Llegar al repositorio. Convertirse en un cambio. Ejecutar una validación. Desplegarse. Volver a rastrearse. Y terminar de nuevo en los datos.
Los agentes reducen la fricción entre todos esos pasos. No sustituyen la estrategia. No sustituyen el criterio. No sustituyen el crawling. No sustituyen al desarrollador. Pero sí pueden eliminar una enorme cantidad del trabajo mecánico que existía entre una herramienta y la siguiente.
Y creemos que ahí está el cambio más profundo. Durante mucho tiempo, gran parte del trabajo SEO consistió en encontrar problemas y trasladarlos hasta la persona o herramienta capaz de solucionarlos. Cada vez más, detectar, investigar, corregir y comprobar pueden formar parte del mismo flujo.
Eso cambia la velocidad. Cambia la forma de auditar. Cambia la relación entre SEO y desarrollo. Y probablemente cambie también qué esperamos de un profesional SEO durante los próximos años.
El trabajo deja de consistir tanto en operar cada herramienta manualmente. Y empieza a consistir más en diseñar el sistema, definir las reglas, conectar las fuentes correctas y saber cuándo confiar —y cuándo no confiar— en lo que hace el agente.
Preguntas frecuentes
¿Qué es un agente de IA aplicado al SEO?
Es un sistema capaz de utilizar un modelo de IA junto con herramientas externas para realizar varias acciones dentro de un flujo de trabajo. En SEO puede analizar información, ejecutar crawlers, consultar APIs, inspeccionar un repositorio, ejecutar comandos o preparar modificaciones, dependiendo de las herramientas y permisos que tenga disponibles.
¿Claude Code puede hacer SEO?
Claude Code no es una herramienta SEO especializada. Sin embargo, puede leer y modificar un repositorio, ejecutar comandos y utilizar herramientas externas, por lo que puede participar en auditorías, diagnóstico de problemas técnicos y automatizaciones relacionadas con SEO.
¿Los agentes de IA reemplazan herramientas como Screaming Frog?
No necesariamente. Un crawler y un agente resuelven problemas diferentes. El crawler observa el sitio desde fuera; un agente de código puede investigar por qué el proyecto genera determinado comportamiento. Utilizarlos juntos puede reducir la distancia entre detectar un problema y corregir su causa.
¿Qué es MCP en SEO?
Model Context Protocol es un protocolo abierto para conectar aplicaciones de IA con herramientas, APIs y fuentes de datos externas. En SEO puede utilizarse, mediante integraciones adecuadas, para acercar al agente información que no vive dentro del repositorio.
¿GEO reemplazará al SEO?
No hay evidencia de que deba plantearse de esa manera. Google considera que optimizar para sus experiencias generativas continúa formando parte del SEO y recomienda mantener los fundamentos tradicionales de rastreo, indexación, estructura y contenido de calidad.
¿Cómo puede una página aparecer como fuente en ChatGPT?
OpenAI utiliza OAI-SearchBot para sus funciones de búsqueda y permite gestionarlo independientemente de GPTBot, asociado al uso de contenido para mejorar sus modelos. Para aparecer en resultados de búsqueda de ChatGPT, OpenAI recomienda permitir OAI-SearchBot.
¿Cómo puede una web ser encontrada por Claude?
Anthropic documenta Claude-SearchBot para la búsqueda y Claude-User para accesos realizados durante solicitudes concretas de usuarios. Bloquear estos agentes puede limitar la capacidad de Claude de recuperar contenido del sitio para determinadas experiencias de búsqueda.
¿Cómo puede una web aparecer en Perplexity?
Perplexity recomienda permitir PerplexityBot para que un sitio pueda aparecer y ser enlazado en sus resultados de búsqueda. También utiliza Perplexity-User para accesos iniciados por consultas concretas de usuarios.
¿Necesito llms.txt para aparecer en respuestas de IA?
No existe una garantía general. Google dice expresamente que no utiliza llms.txt para determinar la aparición en Google Search o sus funciones generativas y que el archivo no mejora ni perjudica la visibilidad dentro de Google.
¿Qué importa más para que una IA cite un contenido?
No existe una fórmula universal publicada por todos los proveedores. Técnicamente, el contenido debe poder ser descubierto o recuperado por el sistema correspondiente. A partir de ahí, resulta más defendible priorizar información original, útil, bien estructurada y correctamente respaldada que intentar optimizar siguiendo supuestos formatos especiales para LLMs. Google recomienda explícitamente contenido único, experto y no commodity para sus experiencias generativas.
Fuentes y metodología
Este artículo combina experiencia de trabajo con documentación técnica y estudios públicos. Para las afirmaciones sobre funcionamiento de plataformas se han priorizado fuentes oficiales.
Google Search Central: documentación oficial sobre AI Overviews, AI Mode, query fan-out, SEO para búsqueda generativa y llms.txt.
Anthropic: documentación oficial de Claude Code, MCP y los agentes utilizados por Claude para acceso y búsqueda web.
OpenAI: documentación oficial de OAI-SearchBot y GPTBot.
Perplexity: documentación oficial de PerplexityBot y Perplexity-User.
Linux Foundation: documentación sobre la creación de Agentic AI Foundation y la incorporación de MCP como proyecto fundacional.
Ahrefs: análisis publicado en marzo de 2026 sobre 863.000 SERPs y aproximadamente cuatro millones de URLs citadas en AI Overviews.
Semrush: estudio de comportamiento de Google AI Mode basado en cerca de 69 millones de sesiones de escritorio en Estados Unidos durante 2025.
SEOmator y Open SEO Crawler: documentación de sus respectivos proyectos open source utilizada como ejemplo de herramientas de auditoría que pueden integrarse en flujos técnicos modernos.
Última revisión de fuentes: agosto de 2026.
