Saltar al contenido
Doctor SEO

SEO con IA: la IA como herramienta de trabajo

Claude Code para SEO técnico

El agente de terminal aplicado a logs, schema, enlazado interno y mapas de redirecciones, con un protocolo de ensayo en seco y la aritmética real del ahorro.

Actualizado el 3 octubre 2026 27 min de lectura

Al terminar esta lección tendrás dos cosas que casi nadie publica juntas: un protocolo de ejecución en seco que impide que un agente de terminal escriba en tu sitio antes de que una persona haya visto qué iba a escribir, y la aritmética para saber si ese montaje ahorra tiempo o solo lo mueve de sitio.

El límite que conviene tener claro antes de instalar nada lo dejó escrito Lawrence Hitches en «Claude for Technical SEO» (2 de abril de 2026): Claude analiza datos de rastreo (crawling); no rastrea sitios. Interpreta lo que tu rastreador, tus logs y Search Console ya produjeron.

Esta lección es del nivel 8, SEO con IA, sobre usar los modelos como herramienta. Cómo te citan los buscadores con IA es el nivel 4, GEO y AIO. El curso los separa porque la evidencia de cada uno es distinta; si eso son dos disciplinas o una con dos nombres es una discusión abierta que esta lección no resuelve.

Lo que vas a aprender

  • Qué tareas de SEO técnico puede hacer Claude Code y cuáles no llegan nunca a la máquina.
  • Un protocolo de ejecución en seco con cinco garantías: ensayo por defecto, registro JSONL, una petición por segundo, copia previa y aprobación humana.
  • Cómo se resuelven con ese protocolo los cuatro trabajos clásicos: logs, schema, enlazado interno y mapas de redirecciones.
  • Qué umbrales de similitud están publicados, por quién y con qué fecha, y qué hacer con lo que cae por debajo.
  • Cómo calcular el ahorro neto, descontando montaje, tokens, suscripción y revisión humana.

Qué hace Claude Code en SEO técnico y qué no hace nunca

Claude Code es el agente de terminal de Anthropic, y en SEO técnico su trabajo es leer ficheros grandes, cruzarlos y escribir otros: exportaciones de rastreo, logs, respuestas de la API de Search Console, plantillas de un CMS. Lawrence Hitches, en «Claude for Technical SEO» (2 de abril de 2026), documenta una lista concreta: análisis de logs, generación de JSON-LD, revisión de hreflang y mapas de redirecciones con las reglas ya escritas para nginx, Apache o Cloudflare.

Lo que no hace: no visita tus URL, no renderiza tu JavaScript y no descubre páginas huérfanas. Alguien rastrea primero, y la calidad del análisis queda acotada por esa exportación.

La demanda está medida, aunque sin volumen. En el sondeo de autocompletado de Google hecho para este curso el 20 de septiembre de 2026, la semilla claude code seo devolvió ocho variantes (skill, plugin, agent, skill github, github, optimization, prompt y la semilla): el segundo grupo más denso del estudio. El autocompletado prueba presencia, no volumen, y ninguna fuente con nombre publica volumen para estos términos.

Tarea Qué necesita conectado Qué sigue haciendo una persona
Análisis de logs El fichero de log Decidir qué URL merecen presupuesto
Generación de JSON-LD El HTML o la plantilla Validar en la prueba de resultados enriquecidos
Enlazado interno a escala Rastreo con contenido de página Fijar el umbral y revisar el plan
Mapa de redirecciones URL antiguas, nuevas y enlaces entrantes Revisar lo que baje del umbral
Meta descriptions en lote API del CMS y Search Console Aprobar la escritura antes de producción
Rastrear el sitio — Todo: el agente no rastrea

El bloque de SEO técnico cubre rastreo, indexación y arquitectura sin IA de por medio, y qué es el SEO y qué no es en 2026 sitúa el oficio entero: un agente conectado a un sitio que no se rastrea bien acelera el diagnóstico equivocado.

Lo que dice la única encuesta del tema con muestra publicada

La automatización total del SEO técnico es hoy una rareza estadística: el 1% de los encuestados describe su trabajo como completamente automatizado, 1 de 97 personas. La cifra está en State of AI in SEO 2026, de Keyword.com, del 1 de enero de 2026, con n = 97 respuestas útiles. Es la única fuente citada aquí que publica tamaño de muestra, y es pequeña y autoseleccionada: ordena magnitudes, no estima población.

Tres cifras más encuadran la lección. El 38% usa IA para auditorías de SEO técnico. Entre el 79% que dijo tener tareas automatizables que había decidido no automatizar, el 40% nombró SEO técnico. Y el freno más citado, con un 57%, es «Quality not good enough»: la calidad del resultado.

Ese 57% hay que citarlo con cuidado, porque la misma página publica otros dos porcentajes que se confunden con él: un 70% que agrupa a quienes señalaron la mala calidad de salida, las alucinaciones o el tiempo de control de calidad como su mayor limitación, y otro 57% sin relación, el de adopción de ChatGPT. Aquí importa el freno por calidad.

El protocolo de ejecución en seco: cinco garantías antes de escribir nada

Claude Code con permiso de escritura sobre tu sitio necesita cinco garantías, y las cinco van en tu código, no en la buena voluntad del modelo. Son las que Lawrence Hitches describe en «How to Use Claude Code for SEO Automation» (StudioHawk, 12 de mayo de 2026): modo DRY_RUN, auditoría en JSONL, una petición por segundo, copias previas y puerta de aprobación humana.

Garantía Qué impide Cómo compruebas que está
Ensayo por defecto Que una ejecución accidental escriba Sin banderas no se modifica ningún fichero
Registro JSONL No saber qué pasó ni cuándo Una línea por evento, incluido el rechazo de una escritura
Una petición por segundo Tumbar tu API o que te corten 10 escrituras no bajan de 10 segundos
Copia previa Perder el estado anterior Hay un .bak por cada fichero tocado
Aprobación humana Que el plan cambie tras la revisión La firma coincide con la aprobada

La quinta es la que casi todo el mundo implementa mal. No basta con preguntar «¿aplico?» por pantalla: entre la revisión y la ejecución el plan puede cambiar. Por eso la puerta no aprueba una ejecución, sino una firma criptográfica del plan concreto: si cambia un carácter, cambia la firma y la escritura se bloquea.

Las tres salidas de la puerta de seguridad: ensayo, escritura rechazada y escritura aplicadaTabla de las tres salidas del mismo comando de la puerta de seguridad de esta lección, que aprueba la firma criptográfica del plan y no la ejecución. Uno, sin banderas: hace un ensayo, imprime qué cambios son aplicables y no toca ningún fichero, y deja una línea de ensayo por cambio y un código de salida 0. Dos, con la firma vieja después de que el plan haya cambiado un solo carácter: bloquea la escritura porque la firma ya no coincide, y anota una escritura rechazada con la firma esperada y la recibida y un código de salida 1, para que el paso de integración continua falle en vez de dar por buena una ejecución que no escribió nada. Tres, con la firma correcta y un nombre en aprobado-por: escribe, con la copia de seguridad hecha antes de tocar el fichero y una pausa de un segundo entre escrituras, y anota la ruta de esa copia. Protocolo de cinco garantías descrito por Lawrence Hitches en StudioHawk el 12 de mayo de 2026; el script es original de la lección.La puerta aprueba la firma del plan, no la ejecuciónLas tres salidas del mismo comando, tomadas de la sesión verbatim de la lección.QUÉ EJECUTASQUÉ HACE LA PUERTAQUÉ ANOTA EL REGISTRO1Sin banderasEnsayo: imprime qué cambios son aplicables yno toca ningún fichero.Una línea de ensayo por cambio, y el comando salecon código 0.2Con la firmaviejaBloquea la escritura: el plan cambió un caráctery la firma ya no coincide.Escritura rechazada, con la firma esperada y larecibida, y código 1.3Firma yaprobadorEscribe, con la copia .bak hecha antes de tocarel fichero y una pausa de un segundo.Una línea escrito con la ruta de la copia, y elcomando sale con 0.El patrón ambiguo es el fallo que más daño hace: dos coincidencias dejan el fichero sin revisar.Nivel 8 del curso de SEO gratuito. Protocolo de Lawrence Hitches, StudioHawk, 12 de mayo de 2026.doctor-seo.net
Las tres salidas del mismo comando de la puerta de seguridad de esta lección, que aprueba la firma criptográfica del plan y no la ejecución. El protocolo de cinco garantías es el que describe Lawrence Hitches en StudioHawk, «How to Use Claude Code for SEO Automation», 12 de mayo de 2026; el script y la sesión verbatim son originales de esta página.

El script siguiente es original de esta lección: cien líneas de Python sin dependencias, sobre ficheros locales. Para escribir contra la API de un CMS solo cambia aplicar().

#!/usr/bin/env python3
"""Puerta de seguridad para cambios SEO en lote. Por defecto no escribe:
hace un ensayo. Escribir exige --aplicar, la firma exacta del plan y
un nombre en --aprobado-por. Una escritura rechazada sale con código 1."""
import argparse, hashlib, json, os, shutil, sys, time
from datetime import datetime, timezone

PAUSA = 1.0  # segundos entre escrituras: 1 petición por segundo


def ts():
    return datetime.now(timezone.utc).isoformat(timespec="seconds")


def anotar(registro, **campos):
    campos["ts"] = ts()
    with open(registro, "a", encoding="utf-8") as f:
        f.write(json.dumps(campos, ensure_ascii=False) + "\n")


def firma(plan):
    bruto = json.dumps(plan, sort_keys=True, ensure_ascii=False).encode("utf-8")
    return hashlib.sha256(bruto).hexdigest()[:16]


def comprobar(cambio):          # devuelve (aplicable, motivo); no escribe
    ruta = cambio["archivo"]
    if not os.path.isfile(ruta):
        return False, "archivo inexistente"
    texto = open(ruta, encoding="utf-8").read()
    n = texto.count(cambio["buscar"])
    if n == 0:
        return False, "patrón no encontrado"
    if n > 1:
        return False, f"patrón ambiguo ({n} coincidencias)"
    if cambio["buscar"] == cambio["reemplazar"]:
        return False, "cambio nulo"
    return True, "ok"


def aplicar(cambio, copias):
    ruta = cambio["archivo"]
    os.makedirs(copias, exist_ok=True)
    sello = ts().replace(":", "").replace("+0000", "Z")
    respaldo = os.path.join(copias, os.path.basename(ruta) + "." + sello + ".bak")
    shutil.copy2(ruta, respaldo)      # la copia va ANTES de tocar el archivo
    texto = open(ruta, encoding="utf-8").read()
    open(ruta, "w", encoding="utf-8").write(
        texto.replace(cambio["buscar"], cambio["reemplazar"], 1))
    return respaldo


def main():
    p = argparse.ArgumentParser()
    p.add_argument("plan")
    p.add_argument("--aplicar", action="store_true")
    p.add_argument("--aprobado-por", default="")
    p.add_argument("--firma", default="")
    p.add_argument("--registro", default="auditoria.jsonl")
    p.add_argument("--copias", default="copias")
    a = p.parse_args()

    plan = json.load(open(a.plan, encoding="utf-8"))
    f = firma(plan)
    print(f"plan: {len(plan)} cambios · firma {f}", flush=True)

    escribir = a.aplicar and a.firma == f and bool(a.aprobado_por)
    rechazada = a.aplicar and not escribir
    modo = "aplicar" if escribir else ("rechazada" if rechazada else "ensayo")

    anotar(a.registro, evento="inicio", firma=f, total=len(plan), modo=modo,
           aprobado_por=a.aprobado_por or None)

    if rechazada:
        motivo = ("firma no coincide" if a.firma != f else "falta --aprobado-por")
        print("ESCRITURA BLOQUEADA: " + motivo, file=sys.stderr)
        anotar(a.registro, evento="escritura_rechazada", motivo=motivo,
               firma_esperada=f, firma_recibida=a.firma or None,
               aprobado_por=a.aprobado_por or None)

    ok = bloqueados = 0
    for c in plan:
        aplicable, motivo = comprobar(c)
        if not aplicable:
            bloqueados += 1
            anotar(a.registro, evento="omitido", id=c["id"],
                   archivo=c["archivo"], motivo=motivo)
            print(f"  [omitido] {c['id']}: {motivo}")
            continue
        if not escribir:
            ok += 1
            anotar(a.registro, evento="ensayo", id=c["id"],
                   archivo=c["archivo"], motivo=motivo)
            print(f"  [ensayo ] {c['id']}: aplicable")
            continue
        respaldo = aplicar(c, a.copias)
        ok += 1
        anotar(a.registro, evento="escrito", id=c["id"],
               archivo=c["archivo"], respaldo=respaldo)
        print(f"  [escrito] {c['id']} · copia en {respaldo}")
        time.sleep(PAUSA)

    anotar(a.registro, evento="fin", aplicables=ok, bloqueados=bloqueados)
    print(f"aplicables: {ok} · bloqueados: {bloqueados} · registro: {a.registro}")
    return 1 if (bloqueados or rechazada) else 0


if __name__ == "__main__":
    sys.exit(main())

El plan es un JSON con una entrada por cambio: identificador, ruta, texto buscado y sustituto.

[
  {"id": "meta-001",
   "archivo": "public/zapatillas-trail/index.html",
   "buscar": "content=\"Compra zapatillas de trail online\"",
   "reemplazar": "content=\"Zapatillas de trail: tallaje, drop y 14 modelos\""}
]

La sesión completa, verbatim, con los cuatro casos que importan. El sed del medio hace de quien altera el plan ya revisado.

$ python3 guardia_seo.py plan.json
plan: 1 cambios · firma cd465a47b8c25b63
  [ensayo ] meta-001: aplicable
aplicables: 1 · bloqueados: 0 · registro: auditoria.jsonl
$ echo $?
0
$ python3 guardia_seo.py plan.json --aplicar --firma cd465a47b8c25b63
plan: 1 cambios · firma cd465a47b8c25b63
ESCRITURA BLOQUEADA: falta --aprobado-por
  [ensayo ] meta-001: aplicable
aplicables: 1 · bloqueados: 0 · registro: auditoria.jsonl
$ echo $?
1
$ sed -i 's/14 modelos/15 modelos/' plan.json
$ python3 guardia_seo.py plan.json --aplicar --firma cd465a47b8c25b63 --aprobado-por txema
plan: 1 cambios · firma 1890b0b852a42594
ESCRITURA BLOQUEADA: firma no coincide
  [ensayo ] meta-001: aplicable
aplicables: 1 · bloqueados: 0 · registro: auditoria.jsonl
$ echo $?
1
$ sed -i 's/15 modelos/14 modelos/' plan.json
$ python3 guardia_seo.py plan.json --aplicar --firma cd465a47b8c25b63 --aprobado-por txema
plan: 1 cambios · firma cd465a47b8c25b63
  [escrito] meta-001 · copia en copias/index.html.2026-09-25T115447Z.bak
aplicables: 1 · bloqueados: 0 · registro: auditoria.jsonl
$ echo $?
0

Dos detalles deciden si la puerta sirve dentro de un proceso automatizado. Una escritura rechazada sale con código 1, nunca con 0, para que el paso de integración continua falle en vez de dar por buena una ejecución que no escribió nada. Y el rechazo deja su propia línea en el registro:

{"evento": "escritura_rechazada", "motivo": "falta --aprobado-por", "firma_esperada": "cd465a47b8c25b63", "firma_recibida": "cd465a47b8c25b63", "aprobado_por": null, "ts": "2026-09-25T11:54:47+00:00"}
{"evento": "escritura_rechazada", "motivo": "firma no coincide", "firma_esperada": "1890b0b852a42594", "firma_recibida": "cd465a47b8c25b63", "aprobado_por": "txema", "ts": "2026-09-25T11:54:47+00:00"}

El script solo da por aplicable un cambio si el fichero existe, el patrón aparece exactamente una vez y el reemplazo no es idéntico al original. El patrón ambiguo es el fallo que más daño hace en lotes grandes: un reemplazo sobre dos coincidencias deja el fichero en un estado que nadie revisó.

Hay evidencia de por qué el límite de una petición por segundo vive en tu script y no en la interfaz de la herramienta. Rich Voller, en «Screaming Frog v24 MCP» (26 de mayo de 2026, act. 12 de junio de 2026), registró que los rastreos lanzados por MCP ignoran la configuración de velocidad de Screaming Frog: con 1 URL/segundo fijado en la herramienta, un rastreo de 500 URL se completó en 20 segundos. Lo que falta ahí es la muestra: una observación única, sin número de sitios ni de versiones probadas. Vale como aviso, no como medida.

Análisis de logs: dónde se va el presupuesto de rastreo

El análisis de logs es donde Claude Code rinde más, porque consiste en leer mucho y decidir poco. Lawrence Hitches, en «Claude for Technical SEO» (2 de abril de 2026), enumera cinco preguntas que un log responde y una exportación de rastreo no: qué URL se rastrean más, con qué frecuencia, cuáles devuelven error, qué páginas importantes no se han rastreado nunca y dónde se gasta presupuesto en lo que no lo merece.

El agente no necesita conexión para esto, porque el log es un fichero. Sí necesita preprocesado cuando el volumen crece: para sitios de millones de URL, Hitches recomienda agregar en Claude Code antes de pedir el análisis, en vez de pegar el conjunto entero en una conversación.

Hay una trampa propia de los agentes de Anthropic. Anthropic documenta tres agentes distintos —ClaudeBot, Claude-User y Claude-SearchBot—, cada uno con su entrada de User-agent en robots.txt: bloquear uno no bloquea los otros. Esa página de soporte solo muestra una marca de tiempo relativa, así que esta lección no le asigna fecha. El fichero claude.com/crawling/bots.json, consultado el 20 de septiembre de 2026, contenía 26 prefijos IPv4 y ningún nombre de bot, con creationTime del 18 de agosto de 2026: puedes verificar por IP que una petición es de Anthropic, pero no cuál de los tres la hizo.

Qué cuenta como desperdicio depende de tu sitio y se mide: ese trabajo vive en analítica y medición, y el mecanismo de rastreo, en cómo funciona Google.

Generar schema JSON-LD con Claude Code

El JSON-LD generado por un modelo se valida en un minuto, y por eso es la tarea de SEO técnico más segura para delegar en Claude Code. SE Ranking, en «Claude AI vs. ChatGPT: Which AI Tool is Better for SEO?» (Yulia Deda, 7 de julio de 2025, act. 24 de junio de 2026), comparó el JSON-LD de cuatro tareas de SEO: el de Claude arrojó 1 incidencia no crítica en la prueba de resultados enriquecidos frente a 5 del de ChatGPT. Lo que falta ahí es la escala: cuatro tareas ejecutadas una vez, sin muestra ni repeticiones. La regla no cambia con el marcador: todo JSON-LD generado se valida antes de subirlo.

Enlazado interno a escala: cómo elegir el umbral

El umbral de similitud coseno decide qué pares de páginas se enlazan, y es el parámetro que no puedes copiar de otro sitio. Niko Alho, en «How to Automate Internal Linking with AI Embeddings» (20 de mayo de 2026, act. 18 de julio de 2026), sitúa la banda útil en 0,78–0,85 y señala que el enlazado manual deja de ser viable entre las 200 y las 500 páginas; el artículo no publica sobre cuántos dominios se obtuvo esa banda. StudioHawk (12 de mayo de 2026) describe un grafo de puntuación en tres niveles que produce un plan en seco con origen, destino, ancla y punto de inserción.

Esa banda es un punto de partida, no una respuesta: depende del dominio. La calibración se ejecuta una vez por sitio:

  1. Toma 50 pares de páginas repartidos por todo el rango de puntuación, no solo los altos.
  2. Que una persona etiquete cada par como pertinente o no, sin ver la puntuación.
  3. Dibuja la precisión frente al umbral y quédate con el codo de la curva.
  4. Fija tres guardas que el modelo no impone solo: tope de enlaces salientes por página, diversidad de anclas y orden que atienda primero a las huérfanas.

Sin esas guardas, un plan técnicamente correcto concentra decenas de enlaces en las mismas cuatro páginas con el mismo ancla. El plan entero pasa por el protocolo en seco.

Mapas de redirecciones: la migración se decide en lo que no encaja

Un mapa de redirecciones con embeddings acierta la inmensa mayoría de las URL y se equivoca donde más duele. El umbral por defecto más citado es 0,95, que figura en la documentación de Screaming Frog sobre embeddings para mapeo de redirecciones, modificada el 20 de octubre de 2025. Mark Williams-Cook, en Search Engine Land, describe un montaje con all-MiniLM-L6-v2 y FAISS que procesa 10.000 URL en minutos y reporta que en un solo caso alrededor del 95% de las URL puntuaron por encima de 0,98; es una migración, no una muestra, y esa página no muestra fecha.

Las herramientas que exponen un umbral de similitud por defecto no publican qué hacer con lo que queda por debajo, y lo que queda por debajo es la migración. La revisión estratificada reparte el esfuerzo según la puntuación:

Similitud Revisión humana Motivo
Por debajo de 0,80 100% a mano No hay equivalente claro; puede que no lo haya
0,80 – 0,95 Muestra del 20% Aciertos y errores igual de plausibles
Por encima de 0,95 Sondeo del 5% Comprobar que el proceso no se desvía

A eso se suman cuatro comprobaciones que ninguna similitud semántica puede hacer: las series paginadas, que deben apuntar a su equivalente y no todas a la página 1; las URL con parámetros, que suelen colapsar contra la versión limpia; las fusiones de muchos a uno, donde hay que decidir si esa concentración es deseada; y las URL antiguas con enlaces entrantes, que el modelo no puede conocer porque ese dato está en tu herramienta de backlinks.

Lo que Claude Code sí resuelve entero es traducir el mapa aprobado a reglas para nginx, Apache, .htaccess y Cloudflare (Lawrence Hitches, 2 de abril de 2026): trabajo mecánico, determinista y verificable, la definición de lo que conviene delegar.

La aritmética que nadie publica

Las cifras de ahorro que circulan sobre Claude Code y SEO son brutas, no netas, y esa diferencia es el contenido de esta sección. StudioHawk, en «How to Use Claude Code for SEO Automation» (Lawrence Hitches, 12 de mayo de 2026), publica dos: la reescritura de meta descriptions vía API del CMS con datos de Search Console pasa de 6–8 horas a minutos, y un proyecto de enlazado interno, de 3–5 días a menos de una hora.

La resta que falta en las cifras de ahorro: montaje, tokens, suscripción y verificaciónDiagrama de tres pasos sobre la aritmética del ahorro de automatizar SEO técnico con Claude Code. Uno, la cifra bruta: StudioHawk publica el 12 de mayo de 2026 que reescribir meta descriptions pasa de seis u ocho horas a minutos y que un proyecto de enlazado interno pasa de tres a cinco días a menos de una hora, pero eso es el tiempo de la máquina y no se declara sobre cuántos sitios o tareas se midió. Dos, los descuentos: el montaje de los servidores MCP, el coste en tokens de cargar las definiciones de herramientas en cada contexto, la suscripción y el paso de verificación humana que los propios autores declaran obligatorio; ninguna publicación del género resta ninguno de los cuatro. Tres, el ahorro neto: lo que queda al restarlos, multiplicado por las veces que ejecutarás la tarea en el periodo evaluado, de modo que si el tiempo de verificación se acerca al del agente el ahorro se lo come la revisión, y si la tarea se ejecuta una sola vez se lo come el montaje.Las cifras de ahorro que circulan son brutas, no netasLas cuatro líneas de coste que ninguna publicación del género descuenta.1La cifra brutaDe 6–8 horas a minutos; de 3–5días a menos de una hora enenlazado interno.POR QUÉ IMPORTAEs el tiempo de la máquina, y nadiedice sobre cuántos sitios se midió.2Los descuentosMontaje de los MCP, tokens de lasdefiniciones, suscripción yrevisión humana.POR QUÉ IMPORTANinguna publicación del géneroresta ninguno de los cuatro.3El ahorro netoLo que queda al restarlos, por lasveces que ejecutarás la tarea enel periodo.POR QUÉ IMPORTASi revisar cuesta lo que tarda elagente, se lo come la revisión.Una tarea anual casi nunca justifica un servidor MCP; una semanal casi siempre.Nivel 8 del curso de SEO gratuito. StudioHawk, 12 de mayo de 2026: cifras sin muestra ni descuento.doctor-seo.net
Las cuatro líneas de coste que las cifras de ahorro publicadas no descuentan. Las cifras brutas son de StudioHawk (Lawrence Hitches, 12 de mayo de 2026), que no declara sobre cuántos sitios o tareas se midió el antes y el después. Del coste en tokens de las definiciones de herramientas no consta ninguna medición publicada hasta el 20 de septiembre de 2026.

Lo que falta en esa página, y en las demás publicaciones del mismo género fechadas hasta el 20 de septiembre de 2026, es el descuento. Ninguna resta el montaje de los servidores MCP, el coste en tokens de cargar las definiciones de herramientas en cada contexto, la suscripción, ni el paso de verificación humana que los propios autores declaran obligatorio. Tampoco dicen sobre cuántos sitios o tareas se midió el antes y el después. Describen lo que tarda la máquina, no lo que tarda el trabajo.

Hacer esa resta es aritmética, no opinión:

ahorro_neto = (T_manual - T_agente) * N
              - T_montaje
              - T_verificacion * N
              - coste_suscripcion_del_periodo
              - coste_tokens_del_periodo

T_montaje es el tiempo de instalar y autorizar los servidores MCP, que se paga una vez; T_verificacion, lo que tarda una persona en revisar el resultado de una ejecución; N, las veces que ejecutarás la tarea en el periodo evaluado. El equilibrio se despeja solo: si T_verificacion se acerca a T_agente, el ahorro se lo come la revisión; si N vale 1, se lo come el montaje. Una tarea anual casi nunca justifica un servidor MCP; una semanal casi siempre.

Línea de coste ¿La publican las cifras de ahorro? Qué se sabe con fuente
Tiempo de tarea, antes y después Sí 6–8 h → minutos; 3–5 días → <1 h (StudioHawk, 12 may 2026)
Montaje de los servidores MCP No Sin medida publicada localizable
Tokens de las definiciones de herramientas No Solo el tamaño del problema: 61 herramientas en un único conector
Suscripciones No Semrush incluye 50.000 unidades de API y no cobra extra por MCP, con plan elegible (docs, 5 ago 2026)
Verificación humana No Obligatoria según los propios autores; 57% cita la calidad como freno (Keyword.com, n=97, 1 ene 2026)

El tamaño del problema de tokens sí tiene cifra: el conector de Ahrefs para Claude, consultado el 20 de septiembre de 2026, expone 61 herramientas, y la documentación del MCP de Semrush (act. 5 de agosto de 2026) más un servidor de Search Console añaden unas veinte cada uno. De lo que cuesta esa carga dentro de un flujo de SEO no consta ninguna medición publicada hasta el 20 de septiembre de 2026. Mide la tuya.

La verificación humana tampoco es un trámite. ContextBolt, en «Claude SEO Experiment» (23 de junio de 2026, firmado solo como «David»), documenta que Claude trató estimaciones de terceros como si fueran datos y siguió empujando una keyword inviable tras ver su dificultad. Lo que falta ahí es la muestra: una semana, un solo sitio, sin control.

Generar páginas a escala: la frontera que esta lección no fija

En cuanto Claude Code puede escribir en tu CMS aparece la pregunta de cuántas páginas son demasiadas. Esta lección no la responde, porque la evidencia tampoco.

El texto de la política antispam de Google, con última actualización del 28 de agosto de 2026, define el scaled content abuse como la generación de muchas páginas cuyo propósito principal es manipular el posicionamiento y no ayudar a los usuarios. La definición es de propósito: no menciona volumen ni método de producción, y no publica ningún umbral de páginas. Quien te diga que el límite está en 100, en 500 o en 5.000 no lo ha sacado de ahí.

A partir de ahí el sector se parte en dos. Un lado sostiene que el método de producción es irrelevante y que decide si cada página está verificada, es distinta y sirve para algo. El otro, que producir a escala con un agente es de por sí un riesgo, porque volumen e intención son difíciles de separar. Los dos citan el mismo párrafo, y esta lección se detiene ahí.

Hay un caso documentado que ninguno de los dos discute. Will Scott lo publicó en Search Engine Land el 28 de agosto de 2026: Claude clonó la página de inicio de un sitio en dos rutas nuevas, /seo-grader y /content-grader, cambiando solo las etiquetas de título; las dos registraron cero impresiones y cero clics, y la página de inicio se quedó en la posición 9 o peor. La duplicación se repitió en un segundo sitio. El artículo no publica tamaño de muestra: son dos casos de un autor. No se verificó en vivo el 25 de septiembre de 2026, así que se cita por publicación, autor y fecha, sin enlace.

Las consecuencias a nivel de sitio se tratan en estrategia SEO avanzada. Aquí toca el mecanismo: crear cien páginas debe exigir que una persona firme un plan de cien páginas, en vez de descubrirlas en el rastreo del mes siguiente.

Errores comunes

  1. Dar permisos de escritura antes de tener registro de auditoría. Si no sabes qué cambió, no puedes revertirlo con precisión. El arreglo: el registro JSONL se escribe siempre, también en ensayo, y la primera escritura real va sobre un único fichero.
  2. Confiar el límite de velocidad a la interfaz de la herramienta. Rich Voller lo documentó el 26 de mayo de 2026: un rastreo por MCP ignoró el límite de 1 URL/segundo de Screaming Frog y completó 500 URL en 20 segundos. El arreglo: impón la pausa en tu propio código.
  3. Tratar como datos las cifras de dificultad o volumen que devuelve el modelo. ContextBolt documentó el 23 de junio de 2026 que Claude trató estimaciones de terceros como hechos. El arreglo: todo número que decida algo sale de la fuente que lo mide.

Resumen

  • Claude Code analiza datos de rastreo; no rastrea sitios (Lawrence Hitches, 2 de abril de 2026).
  • El 1% de los encuestados describe su SEO como completamente automatizado, 1 de 97 (Keyword.com, State of AI in SEO 2026, 1 de enero de 2026, n=97).
  • El freno más citado en esa encuesta es la calidad del resultado, 57%, que no es el 70% de limitaciones ni el 57% de adopción de ChatGPT de la misma página.
  • Cinco garantías antes de dar escritura: ensayo por defecto, registro JSONL, una petición por segundo, copia previa y aprobación de la firma del plan, no de la ejecución.
  • Las cifras publicadas —6–8 horas a minutos, 3–5 días a menos de una hora (StudioHawk, 12 de mayo de 2026)— son brutas: no descuentan montaje, tokens, suscripción ni verificación humana.
  • Umbrales publicados: 0,95 por defecto en mapas de redirecciones (Screaming Frog, doc. modificada el 20 de octubre de 2025) y banda 0,78–0,85 en enlazado interno (Niko Alho, 20 de mayo de 2026).
  • La política de Google sobre scaled content abuse (texto actualizado el 28 de agosto de 2026) define por propósito y no publica umbral. El sector discrepa y esta lección no dicta sentencia.

Preguntas frecuentes

¿Puede Claude Code rastrear mi sitio?

No. Lawrence Hitches lo formula sin ambigüedad el 2 de abril de 2026: Claude analiza datos de rastreo, no rastrea sitios. Claude Code lee ficheros —exportaciones de tu rastreador, logs, respuestas de la API de Search Console— y el rastreo lo hace antes otra herramienta.

¿Qué umbral de similitud uso para enlazado interno?

Empieza en la banda 0,78–0,85 que publica Niko Alho el 20 de mayo de 2026 y calíbrala para tu dominio, porque el número correcto cambia de un sitio a otro: 50 pares repartidos por todo el rango, etiquetado humano a ciegas, curva de precisión frente a umbral y el codo de esa curva. Añade después el tope de enlaces salientes por página, la diversidad de anclas y el orden que atiende primero a las huérfanas.

¿Cuántas páginas puedo generar con un agente sin problemas con Google?

El texto de la política antispam de Google, actualizado el 28 de agosto de 2026, no publica ningún umbral: define el scaled content abuse por el propósito de las páginas, no por su número ni por cómo se produjeron. El sector se divide entre quienes concluyen que el método es irrelevante si cada página está verificada y es distinta, y quienes consideran que producir a escala con un agente es de por sí un riesgo. Esta lección presenta las dos posturas y no elige.

Fuentes

Las marcadas (sin enlace) no se verificaron en vivo el 25 de septiembre de 2026 y se citan por publicación, autor y fecha.

  • Lawrence Hitches, «Claude for Technical SEO: Audits, Crawl Fixes & Schema» — 2 de abril de 2026.
  • Lawrence Hitches, «How to Use Claude Code for SEO Automation», StudioHawk — 12 de mayo de 2026. Sin muestra ni descuento de costes.
  • Keyword.com, State of AI in SEO 2026 — 1 de enero de 2026, n = 97.
  • Rich Voller, «Screaming Frog v24 MCP» — 26 de mayo de 2026, act. 12 de junio de 2026. Observación única, sin muestra.
  • Yulia Deda, «Claude AI vs. ChatGPT», SE Ranking — 7 de julio de 2025, act. 24 de junio de 2026. Cuatro tareas, sin muestra.
  • «David», «Claude SEO Experiment», ContextBolt — 23 de junio de 2026. Una semana, un solo sitio, sin control.
  • Anthropic, «Does Anthropic crawl data from the web…» — solo marca de tiempo relativa, sin fecha absoluta.
  • Anthropic, claude.com/crawling/bots.json — consultado el 20 de septiembre de 2026; creationTime 18 de agosto de 2026, 26 prefijos IPv4, sin nombres.
  • Anthropic, conector de Ahrefs para Claude — consultado el 20 de septiembre de 2026; 61 herramientas.
  • Semrush, documentación del MCP de Semrush — act. 5 de agosto de 2026.
  • Will Scott, «Use Claude for SEO. Don’t let Claude do SEO.», Search Engine Land — 28 de agosto de 2026. Dos casos, sin muestra. (sin enlace)
  • Google Search Central, políticas antispam, scaled content abuse — act. 28 de agosto de 2026. (sin enlace)
  • Screaming Frog, documentación sobre embeddings para mapeo de redirecciones — modificada el 20 de octubre de 2025; umbral 0,95. (sin enlace)
  • Mark Williams-Cook, «How to speed up site migrations with AI-powered redirect mapping», Search Engine Land — sin fecha; un solo caso. (sin enlace)
  • Niko Alho, «How to Automate Internal Linking with AI Embeddings» — 20 de mayo de 2026, act. 18 de julio de 2026; banda 0,78–0,85, sin muestra. (sin enlace)
  • Autocompletado de Google — 20 de septiembre de 2026; semilla claude code seo, ocho variantes. Presencia, no volumen.

Continuar el curso