Herramientas para mejorar tus proyectos que ya están en producción (SEO, rendimiento, testing y code review con agentes)

Cuando tienes aplicaciones que ya están en producción, tarde o temprano vas a necesitar herramientas extras para mejorarlas: rendimiento, calidad de código, SEO o experiencia de usuario. La buena noticia es que hoy puedes conectar varias de estas herramientas directamente a tus agentes de código (Claude Code, Codex, OpenCode y similares) y obtener reportes claros sin mayor esfuerzo. Y lo mejor: la mayoría son gratuitas o funcionan con la suscripción del agente que ya tienes.

En este artículo te muestro las herramientas que uso en mi día a día para auditar SEO, medir rendimiento frontend, testear sitios desplegados, hacer review de código y organizar todas las correcciones como tareas pendientes.

1. Claude SEO: auditoría SEO completa desde tu agente

La primera herramienta se llama Claude SEO, y aunque tenga "Claude" en el nombre, en realidad es un skill, así que puede usarse con prácticamente cualquier agente. Lo que hace es analizar tu sitio web en producción y darte un puntaje con todo lo que le falta a nivel de SEO: contenido, metadatos, estructura semántica, imágenes, etc.

El proyecto es completamente open source (el código está en GitHub) y funciona como plugin para Claude Code, así que no pagas nada adicional: con los tokens de tu suscripción actual es suficiente. Y si no usas Claude, existe su contraparte Codex SEO, desarrollada por la misma persona, que adapta los mismos plugins para otras herramientas como Codex u OpenCode.

Instalación

La forma más fácil es desde el propio Claude Code:

1. Escribe /plugin y presiona Enter.
2. En el buscador de plugins escribe "SEO" y selecciona la extensión.
3. Elige instalarlo para todos los usuarios.

Al reiniciar Claude Code, escribiendo /seo ya vas a ver los comandos disponibles. Ejecutar una auditoría es tan simple como pasarle la URL de tu sitio.

Por qué funciona tan bien con Claude Code

La razón por la que este skill está tan enfocado en Claude es el soporte de subagentes. Cuando lanzas la auditoría completa del sitio, no se ejecuta una sola sesión: se lanzan varios subagentes en paralelo, cada uno enfocado en algo distinto (rendimiento, contenido, sitemap, metadatos...). Cuando terminan, reportan al agente principal, que consolida todo en un solo resultado. Puedes incluso hacer clic en cada subagente y ver qué está ejecutando.

El proceso puede tardar entre 10 y 20 minutos dependiendo del tamaño del sitio, pero al final obtienes un reporte con las correcciones clasificadas por prioridad: bajas, medias, altas y críticas.

Un tip extra: si la tabla en la terminal no te resulta cómoda, pídele que exporte el reporte a HTML ("exporta el reporte en HTML en el escritorio") y lo abres desde el navegador. En mi caso, mi sitio obtuvo 75/100 — no está mal, aunque el punto más crítico resultó ser el rendimiento.

Y aquí viene lo mejor: si tienes el repositorio en la misma máquina, puedes pasarle ese reporte al mismo Claude Code (o a otro agente) y que él mismo corrija los problemas. Es una forma muy sencilla de mejorar un proyecto que ya está en producción.

2. Lighthouse: mide el rendimiento frontend

Además del SEO, importa el rendimiento, sobre todo en el frontend. Para eso está Lighthouse, del ecosistema de Google. Tiene un CLI que se instala con Node, pero en realidad es más fácil pedírselo al agente: es una herramienta de consola que el agente entiende perfectamente.

Basta con decirle algo como "mide el rendimiento de [tu-sitio.com]" y pegarle el repositorio de Lighthouse (o indicarle que use el Lighthouse CLI). Si ya tienes Node instalado, el agente ejecuta la herramienta con npx y empieza la medición.

El reporte incluye:

• Rendimiento: qué tan rápido carga el JavaScript, si hay código sin utilizar o que carga innecesariamente.
• Accesibilidad y mejores prácticas.
• SEO (como segunda opinión de la herramienta anterior).

Puedes pedirle que mueva los reportes al escritorio: obtienes uno en JSON (datos crudos, ideales para pasárselos de vuelta al agente) y otro en HTML con las métricas clásicas que quizás ya conoces del navegador. La ventaja de medirlo así es que la medición es más exacta y ayuda a detectar, por ejemplo, qué demora tanto el renderizado en dispositivos móviles.

En mi caso, el diagnóstico fue claro: los chunks de JavaScript. Cuando construyes un sitio, este se divide en múltiples archivos JS pequeños... y en mi caso no eran tan pequeños (había uno de 35 KB), lo que hacía que las páginas cargaran lento.

3. TestSprite: un QA automático para tu sitio desplegado

TestSprite es la herramienta que uso cuando el proyecto ya está desplegado y quiero verificar funcionalidades: es como tener un QA que entra a tu sitio en producción, navega, prueba cosas y te entrega un reporte final. Combina tres cosas en una: un framework de testing, una herramienta de verificación en el navegador y reportes, todo funcionando en la nube.

Es una plataforma que consume créditos, pero el plan gratuito te regala 150 créditos por mes, así que probarla no cuesta nada.

Setup

1. Instala el CLI con el comando de npm que aparece en su página o GitHub.
2. Ejecuta testsprite setup.
3. Te pedirá una API key: créate una cuenta (Google o GitHub), y en el panel busca la sección API Keys → New API Key. Ponle cualquier nombre, cópiala y pégala en la terminal.

Con eso, ya puedes delegarle el testing a Claude Code con un prompt como:

Ayúdame a testear mi proyecto usando TestSprite CLI en el dominio [tu-sitio.com]

Cómo funciona en la práctica

Aunque no le des información del sitio, TestSprite entra, lo escanea y arma tests de forma automática: verifica que las páginas carguen, que se puedan explorar, que se puedan abrir ítems específicos, etc. Si además le das acceso al código del proyecto, puede armar tests mucho más completos.

Un detalle importante: algunos tests pueden disparar acciones reales (registros, suscripciones a newsletter, transacciones). TestSprite es prudente y pausa los que podrían generar registros, pero tú decides cuáles activar. Mi recomendación: si tienes un entorno de QA o staging, lánzalos todos sin problema; si estás sobre producción, revisa test por test.

En mi caso, uno de los tests falló: el registro de usuarios devolvía un error 400. Y justamente para eso sirve esto — si el registro no funciona, estás impidiendo que usuarios prueben tu aplicación. Lo interesante es que puedes ver el paso a paso de cada test (entra al register, acepta, llena nombre, apellido, correo...) y editar cualquier paso: cambias el correo de prueba, le das save and run y el test se vuelve a ejecutar con tus modificaciones. Con eso descubrí que el problema era el correo (ya estaba registrado), y el mensaje de error correcto apareció.

Al final obtienes un test report con una métrica resumida de todo lo que hay que mejorar, que puedes copiar y dárselo a tu agente para que lo corrija y vuelva a ejecutar los tests.

4. Thermonuclear Code Quality Review: review de código antes de lanzar

Una vez que tienes métricas y vas haciendo cambios, algo muy útil antes de lanzar a producción es un review de código. Claro, podrías escribirle a cualquier IA "limpia el código, evita código repetido, sigue mejores prácticas, evita código espagueti, que sea mantenible, no sobrecompliques"... pero todas esas consideraciones ya están muy bien descritas en un skill llamado Thermonuclear Code Quality Review, que viene por parte de Cursor.

Como es un skill, funciona con cualquier agente: puedes descargarlo y guardarlo en la carpeta de skills de tu herramienta. Pero la forma más fácil de instalarlo es desde el directorio de skills skills.sh, donde hay una lista enorme. Busca "thermonuclear" y vas a encontrar el skill de cursor-plugins (con bastantes estrellas en GitHub).

El instalador crea una carpeta .agents que puede ser leída por Cursor, Codex, Antigravity y varias herramientas más. Ojo: Claude Code va por su lado, así que si lo vas a usar con Claude, asegúrate de marcarlo en la lista durante la instalación. Recomiendo instalarlo a nivel de proyecto (aunque también se puede global).

Una vez instalado, dentro del proyecto simplemente escribes algo como "Thermonuclear code quality review" y listo. Dos recomendaciones:

• Hazlo por secciones si tu proyecto es grande. Si lo lanzas sobre el root completo, puede proponer una reescritura demasiado grande.
• El review no modifica el código: funciona como un plan. Primero te informa, y luego tú decides qué cambios aceptar o cuáles corregir uno por uno.

En mi caso (lo corrí sobre el repositorio del frontend), después de unos 8 minutos obtuve un resumen con cosas como funcionalidades de calendario que no se estaban utilizando y código abandonado por revisar. Todo esto hay que leerlo con calma: el análisis puede malinterpretar algunas cosas y te tocará aclararlas antes de pasar a la corrección. Igual que con las otras herramientas, puedes pedirle el reporte en HTML para leerlo más cómodo, y luego pasarle tareas específicas (o el archivo completo) al agente para que corrija.

5. Bonus: convierte los reportes en tareas (Notion MCP)

Esto último no es una herramienta de análisis, pero cierra el flujo completo. Si llevas tu planificación en Notion, Linear o Jira, puedes conectar tu agente mediante un MCP (o una herramienta de consola). En el caso de Notion, existe CLI, pero al momento de escribir esto el MCP hace muchas más tareas, así que es el más recomendado.

La idea es simple: no todo lo que sale en los reportes se tiene que corregir ahora. Muchas correcciones toman tiempo o interfieren con otra lógica que estás desarrollando. Entonces, en lugar de arreglarlo todo de inmediato, conviertes el reporte en tareas pendientes y las vas priorizando.

Por ejemplo, con el reporte del code review abierto, le paso un prompt como:

Crea tareas independientes a partir de este reporte y guárdalas en mi Notion: [URL de la página]

El agente, usando el MCP de Notion, detecta la página y empieza a crear tareas nuevas en estado "no iniciado". En mi caso creó 14 tareas independientes, enumeradas. Y como al final esto es una nota de toda la vida, puedes editarlas, cambiar prioridades o añadir contexto fácilmente.

Eso sí: esto no es para aprobar a ciegas. No se trata de vibe coding puro — hay que leer cada tarea y entender de qué se trata. Luego, el flujo inverso también funciona: desde el repo, conectas el agente al MCP y le pides que vaya resolviendo tarea por tarea.

Conclusión

Como puedes ver, obtener estos reportes es relativamente sencillo y no requiere mucho trabajo. Además, muchas de estas herramientas funcionan con la suscripción que ya tienes del agente que uses. En resumen:

No son perfectas, pero son una gran ayuda, sobre todo cuando no tienes experiencia en todas las áreas: puedes saber mucho de SEO pero poco de code review, o mucho de código pero poco de rendimiento frontend. Cada una de estas herramientas te da un análisis global desde el cual puedes ir mejorando tu proyecto — ya sea que lo hayas hecho puramente con vibe coding o que sepas programar, aplican para todos.

En esta lista no incluí herramientas de monitoreo, que es otro tema importante. Ese listado viene pronto en un próximo artículo.

¿Usas alguna otra herramienta de este estilo en tus proyectos? Déjala en los comentarios.