Hay herramientas que pruebas porque están de moda.
Y hay herramientas que te obligan a replantearte cómo trabajas.
Hace poco descubrí Claude SEO, una skill open source diseñada para analizar sitios web desde distintos ángulos: SEO técnico, contenido, rendimiento, datos estructurados y visibilidad en buscadores impulsados por IA.
Decidí probarla con este blog personal.
No esperaba que encontrara tantos puntos que podía revisar.
Mi experiencia está en construir productos, no en hacer auditorías SEO
Durante todos mis años trabajando en desarrollo de software, mi foco ha estado principalmente en construir aplicaciones web.
He trabajado sobre todo construyendo aplicaciones web completas, tanto en frontend como en backend; también he tocado mobile, aunque en menor medida. Mi experiencia está en crear productos, resolver problemas de arquitectura y llevar aplicaciones a producción.
SEO nunca ha sido mi especialidad.
Conozco lo básico: títulos, metadatos, rendimiento, imágenes y algunas buenas prácticas. Pero no conozco todas las técnicas, recomendaciones y cambios que aparecen constantemente alrededor de buscadores, infraestructura y visibilidad en sistemas de IA.
Por eso esta skill fue tan útil.
No reemplazó conocimientos que ya tenía. Me ayudó a encontrar puntos ciegos en un área donde no trabajo todos los días y a convertirlos en preguntas concretas que podía entender, revisar y priorizar.
Cloudflare no deja de ser útil porque no seas experto en infraestructura
Uso Cloudflare en prácticamente todos mis proyectos desde que lo conocí.
Sé configurar lo necesario para desplegar un sitio, manejar DNS, agregar algunas medidas de seguridad y hacer que todo funcione. Pero nunca me he considerado experto en infraestructura.
Y ahí fue donde la skill me ayudó de verdad.
El análisis no se limitó a decirme si el sitio estaba funcionando. Me mostró configuraciones y decisiones que podía revisar:
- Opciones de seguridad en Cloudflare que no tenía activadas.
- Headers que podían mejorar la protección del sitio.
- Detalles de rendimiento que no estaban en mi lista diaria de trabajo.
- Carga y optimización de imágenes.
- Recomendaciones de contenido e interlinking.
- Nuevas piezas como
llms.txt.
Muchas de esas cosas no eran completamente desconocidas para mí. El problema era otro: no tenía una lista estructurada para revisarlas ni el tiempo para investigar cada área desde cero.
La skill convirtió una tarea enorme y difusa en un plan concreto.
Lo que encontré al revisar el blog
No todo terminó siendo una recomendación teórica. Algunas mejoras fueron muy concretas:
- El blog no tenía
llms.txt; ahora existe y describe correctamente el contenido del sitio. - La carga principal de
/blog/pasó de 4,3 segundos a 1,72 segundos. - El peso de esa página bajó de 862 KB a 298 KB al corregir la entrega de imágenes responsivas.
- Añadí headers de seguridad y revisé cómo convivían con Astro y Cloudflare Analytics.
No son cambios espectaculares por separado. Pero juntos hacen que el sitio sea más rápido, más claro para los rastreadores y más robusto.
También aparecieron mejoras que no tenía en mi radar inicial:
- Los canonical y
hreflangde las páginas del blog dejaron de apuntar a rutas antiguas y ahora coinciden con la URL real de cada artículo. - Cada post cuenta con datos estructurados
BlogPosting,BreadcrumbListy una entidad de autor consistente, en lugar de no tener JSON-LD. - Se añadieron fecha de publicación, biografía del autor, tiempo de lectura, tabla de contenidos y migas de pan visibles en todos los posts.
- El blog pasó de no tener enlaces internos entre artículos a contar con 15 enlaces cruzados mediante posts relacionados.
- El envío a IndexNow quedó integrado al despliegue, por lo que las URLs nuevas o actualizadas se notifican sin un paso manual adicional.
La auditoría técnica pasó de 62 a 90 sobre 100 y la salud SEO general de 54 a 83. No tomo esas puntuaciones como una promesa de tráfico: son una forma de comprobar que corregimos problemas concretos y de decidir qué vale la pena mejorar después.
Parte de esa mejora también consistió en usar las herramientas del framework correctamente. En mi experiencia con Astro explico por qué el rendimiento no depende solo de elegir una tecnología, sino de cómo se utiliza en el proyecto real.
El valor no fue recibir una lista de tareas
Podría haber tomado el reporte, aplicado todo y dado el análisis por terminado.
Pero esa sería probablemente la peor forma de usar un agente.
Después de recibir cada recomendación, leía qué proponía y por qué. En algunos casos pedí explicaciones. En otros, no estuve de acuerdo con la prioridad o decidí no hacer el cambio.
No porque la herramienta estuviera equivocada necesariamente, sino porque una recomendación técnica solo tiene sentido dentro del contexto del proyecto. Es el mismo principio que aplico al tomar decisiones imperfectas pero correctas: la mejor solución depende del problema, el riesgo y el contexto.
Por ejemplo, activar un header, cambiar una política de caché o agregar una regla de seguridad puede sonar como una mejora automática. Pero siempre hay preguntas que responder:
- ¿Qué protege exactamente?
- ¿Qué parte del sitio podría afectar?
- ¿Es necesario para este proyecto?
- ¿Cómo voy a comprobar que no rompió nada?
- ¿Qué problema real estoy resolviendo?
La IA puede investigar más rápido que yo. Puede revisar documentación, encontrar configuraciones y proponer un plan.
Pero no conoce mi proyecto mejor que yo.
La IA no es una herramienta para quien sabe menos
Se suele hablar de inteligencia artificial como si fuera una muleta para personas sin conocimientos técnicos.
No estoy de acuerdo.
Quien más provecho puede sacarle a un agente suele ser quien ya tiene una base sólida. No porque pueda ignorar lo que hace el modelo, sino porque puede cuestionarlo.
Puede detectar una recomendación fuera de contexto. Puede pedir una explicación. Puede cambiar el plan. Puede distinguir entre una mejora real y una configuración agregada solo porque parece profesional.
La diferencia no está en usar IA o no usarla.
Está en usarla como un oráculo o usarla como un colaborador.
Una skill no reemplaza conocimiento: organiza experiencia
Lo interesante de las skills es que no convierten mágicamente a un modelo en experto absoluto.
Le dan un proceso.
En este caso, el análisis combinaba muchas áreas que normalmente revisaría por separado: contenido, rendimiento, infraestructura, headers, imágenes, schema, visibilidad en buscadores y preparación para sistemas de IA.
Yo podría aprender cada una de esas áreas a fondo. De hecho, algunas ya las conocía parcialmente.
Pero una skill me permitió partir de un diagnóstico estructurado y dedicar mi tiempo a lo más importante: entender, validar y decidir.
Eso cambia por completo la conversación sobre productividad.
No se trata de hacer más cosas sin pensar.
Se trata de reducir el tiempo que gastas buscando por dónde empezar para invertirlo en tomar mejores decisiones.
Los límites siguen importando
Esto tampoco significa instalar una skill, darle acceso al proyecto y aceptar todos sus cambios.
Las skills, los agentes y cualquier automatización deben revisarse igual que revisarías el trabajo de otra persona.
Hay que entender qué archivos puede modificar, qué comandos puede ejecutar, qué servicios puede consultar y qué datos puede leer. Y, cuando la skill viene de terceros, también conviene revisar sus instrucciones antes de darle permisos amplios.
También hay que mantener criterio sobre las recomendaciones.
No toda sugerencia de SEO necesita aplicarse. No toda optimización de rendimiento tiene prioridad. No todo header de seguridad tiene sentido sin evaluar compatibilidad y riesgo.
La velocidad sin revisión puede terminar creando más trabajo del que ahorra.
La mejor forma de trabajar con IA
Mi flujo ahora es bastante simple:
- Dejo que el agente analice y proponga.
- Leo el diagnóstico y pido contexto cuando lo necesito.
- Discuto o cambio las decisiones con las que no estoy de acuerdo.
- Aplico cambios pequeños y verificables.
- Compruebo que el resultado realmente mejora el proyecto.
No delego el criterio.
Lo amplifico.
Y para mí, esa es una de las formas más útiles de trabajar con IA actualmente: no pedirle que decida por ti, sino usarla para llegar más lejos en áreas donde todavía estás aprendiendo.
Si usas Claude Code, vale la pena probar Claude SEO. Y si usas Codex, el proyecto también tiene una versión para Codex para convertir un agente generalista en un colaborador con un proceso más específico.
Quizá no te convierta en experto en infraestructura, SEO o rendimiento de un día para otro.
Pero sí puede ayudarte a hacer mejores preguntas, descubrir puntos ciegos y aprender mientras mejoras un proyecto real.
