Lo más caro que ha hecho nunca mi automatización de contenido fue funcionar exactamente como estaba diseñada. Entre abril y mayo de 2026, Google Search Console mostró cómo las páginas indexadas de mi sitio caían de unas 7.000 a unas 1.700: un desplome del 75% en un blog que había pasado años construyendo. El pipeline no estaba roto. Publicaba más rápido de lo que yo verificaba, y Google se dio cuenta antes que yo. Así que esta es mi postura real sobre automatizar el SEO y las redes sociales con Claude: automatiza la fontanería de forma agresiva y las afirmaciones nunca. Todo lo que sigue es el pipeline que uso hoy en mi propio sitio de ~580 posts, incluidas las partes que fallaron.
Primero, una corrección. Una versión anterior de este post contaba una historia sobre despedir a una agencia SEO y sustituirla por un stack de publicación en nueve plataformas que funcionaba sin intervención, con cifras de tráfico incluidas. Lo he borrado todo, porque no podía respaldar esas cifras, y el contenido que no podía respaldar es precisamente lo que hizo que desindexaran mi sitio. Lo que sigue es solo aquello de lo que puedo enseñar pruebas.
Qué automatizo y qué me niego a automatizar
Tras la caída, dividí cada tarea de contenido en dos grupos.
Fontanería: automatízala toda. Obtener y respaldar filas de la base de datos, aplicar ediciones, regenerar sitemaps, invalidar cachés, comprobar enlaces, llevar el control de qué está hecho y qué no, redactar textos para redes sociales a partir de un artículo terminado. Este trabajo es repetitivo y verificable, y Claude con unos cuantos scripts lo hace mejor que yo.
Afirmaciones: no las automatices nunca. Cualquier cosa que afirme un hecho, una métrica, una fuente o una experiencia. Cada cifra, cita y referencia pasa por ojos humanos antes de publicarse. Este es el grupo que, sin supervisión, produjo posts que citaban fuentes que no existían, y es la razón por la que mi número de páginas indexadas se desplomó.
La mayoría de los consejos del tipo "automatiza tu SEO con IA" ignoran por completo esta división. Venden volumen. Yo hice el experimento del volumen en un dominio real, y la respuesta de Google no fue una suave caída de posiciones: fue la eliminación masiva del índice en unas seis semanas. La asimetría (semanas para perderlo, meses para recuperarlo) es la restricción en torno a la cual debería diseñarse todo tu pipeline.
El pipeline de reescritura: 84 posts sin perder trabajo
La automatización más útil que he construido no es un generador de contenido. Es un sistema de reparación de contenido. Cuando necesité reescribir quirúrgicamente 84 posts en inglés (quitar las plantillas de CTA idénticas, arreglar enlaces rotos, corregir datos que se habían quedado desfasados), lo ejecuté en siete lotes de doce con Claude Code orquestando. La arquitectura es aburrida a propósito:
1. Un manifiesto de reanudación duradero. Un único archivo JSON, REWRITE-STATUS.json, registra cada post como PENDING o DONE, con un pequeño script para cambiar los estados. Las sesiones se caen, los terminales se cierran, los lotes duran días: el manifiesto hace que cualquier sesión nueva retome exactamente donde se quedó la anterior en lugar de volver a revisar 84 posts a mano. Si tu automatización no sobrevive a que la maten a mitad de ejecución, todavía no es automatización; es una demo.
2. Copias de seguridad antes de cada escritura. La fila completa de cada post en la base de datos se vuelca a un archivo JSON antes de que la reescritura la toque. Nunca me he arrepentido de una copia de seguridad. Coste: milisegundos por post.
3. Un script de aplicación con salvaguardas. El script que escribe en producción se niega a tocar cualquier ID de post fuera del rango del lote que se le ha dado. Cuando apuntas escrituras automatizadas a una base de datos en vivo, el radio de impacto de un bucle defectuoso debería ser de doce filas, no de toda la tabla.
4. Verificación estricta, no sensaciones. Un script de comprobación aparte valida cada reescritura antes de aplicarla: los enlaces internos apuntan a slugs que existen de verdad, no quedan frases de plantilla, el recuento de palabras está dentro del rango. El modelo que redacta y el script que comprueba discrepan con frecuencia, y esa discrepancia es el sistema funcionando. Un fallo recurrente que detecta: el redactor no paraba de generar enlaces con el slug a secas y con sufijo .md que se renderizan rotos en el sitio en vivo. Una persona los pasa por alto al leer en diagonal; el comprobador nunca.
5. La invalidación de caché como paso de primera clase. Dos cosas hacían que las reescrituras parecieran haber fallado en silencio. Mi app cachea el contenido renderizado de los posts por post e idioma, y el observer del modelo no borraba esa clave, así que la base de datos tenía el texto nuevo mientras la página servía el antiguo. Y el edge de Cloudflare cachea las páginas durante una hora, así que incluso después de borrar la caché de la app, la versión antigua seguía ahí. Ahora el pipeline borra las cachés de la aplicación en cada aplicación y trata la hora del CDN como un retraso esperado. Si automatizas actualizaciones de contenido sin automatizar la invalidación de caché, pasarás tardes depurando escrituras "fallidas" que en realidad tuvieron éxito.
Una cicatriz más para quien escriba scripts sobre SSH: ssh dentro de un bucle while read se come en silencio el stdin del bucle y procesa exactamente un elemento. ssh -n lo soluciona.
El patrón de fondo de estas cinco piezas (comprobaciones recurrentes con estado duradero) es el mismo que uso para la monitorización continua, que expliqué en automatizar comprobaciones SEO con rutinas de Claude Code.
Sitemap e indexación: la automatización que funciona sola
Reescribir contenido solo sirve si Google lo vuelve a rastrear. Esa parte de mi stack está totalmente automatizada y ha sido lo bastante fiable como para que olvide que existe:
- Los observers del modelo invalidan las cachés del sitemap cada vez que se crea, actualiza o elimina un post, un proyecto o una página. Nada de regenerarlo a mano, nunca.
- Un scheduler reconstruye el sitemap cada cinco minutos. Ocho sitemaps cubren posts, imágenes, vídeos y los demás tipos de contenido del sitio. Publica o actualiza cualquier cosa y el sitemap lo refleja en cuestión de minutos.
- Higiene de etiquetas, auditada por Claude. Una auditoría de mi taxonomía encontró 62 grupos de etiquetas duplicadas que repartían el mismo tema entre páginas de archivo casi idénticas. Fusionarlas consolidó páginas pobres en páginas sólidas: la página de mi etiqueta de Claude Code pasó de 6 posts a 198 tras la fusión. Los archivos fragmentados son contenido pobre autoinfligido, y son exactamente el tipo de problema estructural que una auditoría con un LLM encuentra en minutos y que una persona deja para dentro de un año.
El conjunto más amplio de tareas de análisis que le encargo a Claude (rastrear mi propio sitemap, comparar la cobertura, señalar huecos) está en mi guía del toolkit SEO de Claude.
La parte de redes sociales, con sinceridad
Aquí es donde voy a decepcionar a quien busque una configuración de "publica en todas partes mientras duermes", porque pasé esa idea por el mismo filtro que todo lo demás y la mayor parte no sobrevivió.
En lo que Claude es realmente bueno: tomar un artículo terminado y verificado y redactar derivados adaptados a cada plataforma, como un hilo que empieza por el hallazgo más afilado, un post de LinkedIn que empieza por la lección o una descripción breve para un vídeo. Las diferencias de registro entre plataformas son reales, y son exactamente el tipo de trabajo de transformación en el que destacan los LLM. Los escribo con un prompt que incluye el artículo, la plataforma y restricciones estrictas de longitud y tono, la misma estructura de cinco huecos que uso en mi guía de ingeniería de prompts.
Lo que mantengo manual: el botón de enviar. Automatizar la distribución es trivial (todas las herramientas de programación tienen una API), pero la restricción es la confianza, no las herramientas. Un error en un post del blog se puede editar; un error difundido en nueve plataformas es una captura de pantalla. Redacta automáticamente, revisa de una sentada, programa con intención. De todos modos, el paso de redacción es el 80% del coste de tiempo, así que automatizarlo captura la mayor parte de la ganancia sin nada del radio de impacto.
Si quieres ir más lejos y que Claude produzca contenido para redes sociales a escala dentro de una voz definida, el enfoque basado en skills que documenté en crear una skill de Claude para redactar contenido SEO es la base adecuada: un archivo de skill codifica tus restricciones una sola vez en lugar de tener que repetirlas en cada prompt para siempre.
Lo que la caída me enseñó sobre la escala
De ver caer mi propia gráfica de indexación salieron tres reglas. Son la especificación de diseño de todo lo anterior.
La verificación tiene que escalar con la generación. Si Claude puede redactar diez posts por hora pero tú solo puedes verificar dos, la capacidad real de tu pipeline es dos. La reescritura de 84 posts salió bien porque la capa de comprobación (validación de enlaces, verificaciones puntuales de datos, copias de seguridad, manifiestos) creció a la par que la capa de redacción. La caída ocurrió porque no lo había hecho.
La confianza de Google es una función escalón. Mi número de páginas indexadas no bajó en proporción a mi peor contenido; se desplomó en todo el sitio, incluidas las páginas buenas. Las señales de calidad a nivel de sitio significan que tu página automatizada más débil le pasa factura a tu mejor página escrita a mano.
La recuperación se mide en meses, así que diseña para no necesitarla nunca. He hecho más de 1.500 proyectos en más de 8 años, y no se me ocurre otro sistema en el que la relación entre el tiempo de fallo y el de reparación sea tan brutal.
Si estás construyendo tu propia versión, empieza por aquí: un archivo de manifiesto, copias de seguridad antes de escribir, un comprobador de enlaces y sitemaps impulsados por observers. Es trabajo de un fin de semana, no depende del modelo y seguirá siendo la columna vertebral cuando cambies al modelo que salga el año que viene.
Donde estos pipelines fallan en producción nunca es en la redacción: es en la capa de verificación que falta, el lastmod que nunca se movió y la caché que a nadie se le ocurrió borrar, y las tres cosas siguen siendo invisibles hasta que se desploma una gráfica de indexación. Yo ya pagué por esas lecciones en mis propios sitios, así que cuando ese sea el problema que tienes delante, ponte en contacto conmigo.
