Cuando me encuentro ante una tarea repetitiva mi primer reflejo es preguntarme si esa tarea debería ocupar mis pensamientos y mi tiempo, e instintivamente calculo el upside de dedicar esos preciosos recursos en labores alternativas no automatizables. Y este, me parece que es el quid de la cuestión, tener criterio para saber qué automatizar y qué no.
Automatizar tareas, y procesos complejos, nunca había sido tan fácil gracias a la IA. Es tan grande este superpoder que uno se desliza rápidamente por la tentación de querer automatizarlo todo. ¿Quién, en esta era del vibe coding no se ha construido un ‘ferrari’ para resolver tareas que se podrían hacer perfectamente en «bicicleta»?
En la misión de automatizar, lo que cuenta es: qué automatizar, hasta dónde y con qué red de seguridad. Ahí se decide si una automatización te libera, te hace perder tiempo, o incluso te endosa un problema nuevo que mantener.
En las siguientes líneas os comparto mi criterio y el step by step que sigo para construir automatizaciones: de los scripts a los agentes, y de los agentes a los bucles que se mejoran solos.
Automatizar para dejar de hacer, no para presumir
Hay un nombre para el trabajo que merece la pena automatizar. En ingeniería de fiabilidad, Google lo llama toil: el trabajo manual, repetitivo, automatizable, táctico, sin valor duradero y que crece de forma lineal con el tamaño de lo que gestionas. No es «trabajo malo»; es trabajo necesario que no te hace mejor por repetirlo. Los equipos de SRE de Google se ponen un tope explícito: que el toil no pase del 50 % del tiempo, para reservar la otra mitad a lo que reduce toil futuro.
Traducido al SEO: subir doscientos ALT a mano es toil. Exportar Search Console y pegarlo en una hoja cada lunes es toil. Revisar cinco mil URLs buscando canonicals rotas es toil. Decidir sobre qué clúster apuestas el trimestre, no: eso es criterio, y el criterio no se delega a un script determinista.
Por eso no automatizo a lo loco. Automatizo por una razón concreta y medible: ganar tiempo y velocidad, mover más negocio o, la que más me importa, quitarme carga mental para pensar a un nivel más alto. Si una automatización no me da nada de eso, sobra.
Y de mis primeros años de carrera, llevo grabado un aviso de Bill Gates en Camino al futuro (1995): la automatización aplicada a una operación eficiente magnifica la eficiencia; aplicada a una operación ineficiente, magnifica la ineficiencia. Automatizar un proceso roto solo te trae el desastre más rápido. Primero el criterio; después la máquina.
Qué automatizar (y qué no)
Mi heurística sale directa de la definición de toil. Automatizo cuando se cumplen tres cosas a la vez:
- Se repite. Si lo hago una vez al año no compensa; si lo hago cada día, sí.
- Tiene reglas claras. Puedo describir el «cómo» sin que dependa de mi intuición caso a caso.
- El resultado es verificable. Puedo comprobar de forma objetiva si salió bien.
Con esos tres filtros, lo que mejor responde en SEO es predecible: auditorías técnicas, investigación y clustering de keywords, control de calidad de contenido y de schema, enlazado interno y extracción de datos por API. Lo aplico de forma sistemática con agentes.
Lo que no automatizo importa igual: la decisión estratégica (sobre contra qué competir o qué priorizar), la narrativa y el ángulo de una pieza, las relaciones y cualquier juicio que necesite contexto de negocio. Una IA puede opinar, claro, pero ahí el valor está en mi criterio, y delegarlo es perder justo lo que me diferencia. Esa frontera, además, es la que conecta este trabajo con que los buscadores con IA te citen: de poco sirve automatizar la producción si pierdes el criterio que te hace una fuente fiable.
Ahrefs lo resumía hace nada: el cuello de botella ya no es «¿puede el software hacer esto?» (hoy la respuesta casi siempre es sí), sino «¿qué trabajo repetitivo sigues haciendo a mano y puedes convertir en un flujo automatizado?». Esa es justo la pregunta. La mía va un escalón más allá: una vez decides automatizar algo, cómo lo construyes importa tanto como el qué.
La escalera de la automatización
No toda automatización es igual. Hay una escalera, y cada escalón pide más ingeniería que el anterior.
Escalón 1. Scripts: lo determinista
Cuando una tarea tiene reglas fijas y cero ambigüedad, un script basta y sobra. Es la automatización más fiable que existe porque hace exactamente lo mismo cada vez. Un script en Python que tira de la API de Search Console te saca todas las filas, no las mil que te deja exportar la interfaz. No necesita «inteligencia»: necesita estar bien escrito. La mayor parte de lo que automatizo vive aquí: subir metadatos en lote, purgar parámetros de tracking, comprobar enlaces rotos, descargar data de GA4/GSC/BigQuery, analizar perdedores y ganadores de un Core Update… Determinista y aburrido, que es justo lo que quieres.
El error de principiante es querer un agente de IA para algo que resuelve un bucle for. Si las reglas son claras, el modelo solo añade coste, latencia y una forma nueva de equivocarse. Además, estos scripts bien hechos se convertirán en tools poderosas para los agentes en el siguiente escalón.
Escalón 2. Agentes: lo que se puede enseñar (con red de seguridad)
El salto a agentes ocurre cuando la tarea ya no tiene reglas cerradas pero sí se puede enseñar: redactar un primer borrador, clasificar intenciones de búsqueda, auditar una página contra unos criterios, o compararnos con la competencia en las SERP. Un agente maneja la ambigüedad que un script no tolera. El problema es que también se equivoca de formas que un script no puede, y a veces lo hace con mucha seguridad.
Por eso un agente suelto no es automatización: es una apuesta. La automatización empieza cuando lo rodeas de tres cosas:
- Jueces. Otro modelo evalúa la salida del primero contra una rúbrica. La técnica tiene nombre, LLM-as-a-judge, y un matiz que conviene conocer: los jueces arrastran sus propios sesgos (de posición, de verbosidad, de auto-preferencia), así que se diseñan con cuidado y no se improvisan.
- Gates. Comprobaciones deterministas que bloquean lo que no pasa el listón antes de que llegue a producción. Son, sobre la salida de un modelo, el equivalente de los quality gates de un CI/CD sobre el código.
- Feedback loops. El agente genera, el juez evalúa y critica, y esa crítica vuelve a entrar para un segundo intento. Anthropic llama a este patrón evaluator-optimizer: una llamada genera la respuesta mientras otra aporta evaluación y feedback, en bucle.
Aquí hay una idea de Anthropic que debería estar enmarcada en todo equipo de SEO que use agentes: el resultado de un agente es el estado final, no lo que el agente dice. Ejemplo: un agente de reservas puede terminar diciendo «tu vuelo está reservado», pero el resultado real es si existe la reserva en la base de datos. En SEO es idéntico: que un agente afirme «meta actualizada» no vale nada; lo que vale es que la meta haya cambiado de verdad en la base de datos. Por eso mis gates comprueban el estado, no el relato.
Escalón 3. Loops automejorables: el sistema que escribe a los agentes
El escalón más alto no es «más agentes». Es un agente que aprende de sus propios errores sin que yo reescriba el prompt cada vez. La investigación lleva años en ello: Reflexion hace que el agente reflexione sobre el feedback y guarde esas lecciones en una memoria para la siguiente vez; Self-Refine usa un mismo modelo como generador, crítico y refinador, iterando sobre su propia salida. Nada mágico: es el feedback loop del escalón anterior, cerrado sobre sí mismo.
La cumbre, tal como la veo, es un bucle que itera hasta resolver la tarea completa, supera las specs y el QA que tú le pusiste y, sobre todo, escribe los runbooks para los siguientes agentes. Es la dirección del desarrollo guiado por especificación, donde la intención pasa a ser la fuente de la verdad en lugar del código. Y es, casi al pie de la letra, lo que persigue Anthropic con sus Agent Skills: instrucciones reutilizables organizadas como la guía de onboarding que le darías a un compañero nuevo, con el objetivo declarado de que los propios agentes creen, editen y evalúen esas skills por su cuenta.
Ese es el techo: no escribir el script, ni siquiera el agente, sino el sistema que escribe y mejora a los agentes.
Y una regla que me ahorra disgustos: la solución más simple que funcione gana. No se sube la escalera por deporte; subes un escalón cuando el de abajo se queda corto, y ni uno más. (Anthropic da el mismo consejo con sus agentes: añade complejidad solo cuando demuestre que mejora los resultados.)
Con qué lo construyo
No trabajo con un único stack: uso el que encaja con cada problema. En el día a día me apoyo en asistentes de IA para programar. Uso más Codex para armar scripts y depurar código, y Claude más para construir los procesos agénticos y feedback loops, aunque reconozco que cuando se me acaban los caros tokens de Anthropic sigo en Codex.
Cuando acumulo muchos scripts para administrar una misma entidad, un blog de WordPress o un headless CMS como Strapi, los empaqueto en un MCP. Eso convierte ese montón de tools sueltas en algo que un agente usa con fiabilidad, sin que yo le explique cada vez cómo se llama cada función ni qué espera recibir.
En el escalón de los agentes, el juez y el gate los monto yo. El juez es otra llamada al modelo con una rúbrica propia; el gate, un script en Python sin una gota de IA que comprueba el estado real antes de dar nada por bueno. Los tengo funcionando en mi propio flujo: uno puntúa lo que sale, el otro bloquea si el cambio no está de verdad en la base de datos.
Para arrancar algo nuevo empiezo con Claude y la skill superpowers:brainstorming. Me obliga a describir bien el problema y a dejar las specs sin ambigüedad antes de tocar código. Y en lo más alto vive un loop que itera hasta cumplir esas specs y el QA que le marqué, y que va dejando escritos los runbooks para los siguientes agentes. Esos runbooks, en mi caso, son skills: las escribo una vez, las reutilizo y, cada vez más, son los propios agentes quienes las afinan.
Preguntas frecuentes
¿Qué se puede automatizar en SEO con IA?
Todo lo que se repite con reglas claras y puedes comprobar después: revisar el estado técnico de un sitio, agrupar keywords, generar borradores y briefs, vigilar la calidad, enlazar internamente o sacar datos por API. Lo que decide la estrategia se queda contigo.
¿Qué NO deberías automatizar?
Las decisiones de criterio: dónde competir, qué priorizar, el ángulo de cada pieza, el trato con personas. Si una tarea depende de tu juicio, automatizarla te quita justo aquello por lo que te eligen a ti.
¿Necesito saber programar para automatizar mi SEO?
Ayuda, pero no es imprescindible. Con asistentes como Claude Code, Codex o Cursor puedes escribir scripts en Python apoyándote en la IA aunque partas de poca base. Lo que no puedes externalizar es el criterio de qué automatizar.
¿No-code o código?
No-code vale para empezar y para flujos sencillos o de una sola vez. El problema llega cuando algo se rompe y no puedes abrirlo: te quedas esperando al proveedor. En cuanto un flujo es crítico o se repite mucho, prefiero código propio.
¿Qué son los «jueces», «gates» y «feedback loops» al automatizar con agentes?
Un juez es un modelo que evalúa la salida de otro contra una rúbrica; un gate es una comprobación que bloquea lo que no pasa el listón; un feedback loop reinyecta la crítica para un nuevo intento. Son la red de seguridad. Sin ellas, soltar un agente en producción no es automatizar: es cruzar los dedos.
¿Qué es MCP y por qué importa para el SEO?
MCP es un protocolo que permite a un asistente de IA usar tus herramientas y datos. Para un SEO significa conectar la IA directamente con sus auditorías, APIs y pipelines.
Sigue leyendo sobre SEO e IA
¿El GEO es SEO?
Agentes de IA para SEO: casos de uso reales y cómo implementarlos
N8N para SEO: 6 flujos que automatizo desde mi NAS (y dónde falla)
SEO con IA: workflows prácticos para research, contenidos y auditorías sin degradar la calidad | Guía
SEO para productos IA: cómo posicionar un producto de Inteligencia Artificial | Guía
Cómo instalar N8N en Synology NAS con Docker | Guía actualizada
