Parsed: Una herramienta de SEO que escribe en tu codebase

La mayoría de las herramientas de SEO terminan con un reporte. Parsed empieza ahí.

Obtienes una lista de schema faltante, brechas de keywords, URLs sin indexar. Luego cierras la pestaña y lo olvidas. El trabajo no ha pasado — solo te dijeron qué es el trabajo.

Construí Parsed para saltarme ese paso.

El problema con las herramientas de SEO

Cada herramienta de auditoría que he usado tiene la misma forma: escanea tu sitio, te muestra qué está mal, y te deja arreglarlo solo. Eso tenía sentido cuando el trabajo era manual. Tiene menos sentido cuando existen los agentes.

La brecha no es información. Sé que necesito schema JSON-LD en mis páginas de producto. Sé que tengo brechas de keywords en mi blog. Sé que la mitad de mi sitemap no está indexada todavía. He sabido estas cosas por meses. La restricción es la ejecución — sentarme y hacer cada cosa.

Parsed trata eso como el problema real a resolver.

Qué hace Parsed

Parsed es un super-agente local que corre junto a tu monorepo. Se conecta directamente a tu codebase, no a través de una UI web que te pasa un snippet para copiar.

Tres agentes principales:

Agente de optimización autónoma — escanea tus páginas, identifica datos estructurados faltantes o débiles, genera componentes de schema JSON-LD, y los escribe directamente en tu proyecto. En el próximo deploy, el schema está live. Sin copy-paste.

Agente de publicación — encuentra brechas de keywords en tu contenido, genera artículos de SEO, los pasa por una verificación de puntuación humana, y escribe archivos .md en tu carpeta de contenido. El artículo existe en disco. Lo revisas, lo haces commit, listo.

Agente de indexación rápida — obtiene tu sitemap, envía cada URL a IndexNow. Google, Bing y Yandex reciben la notificación inmediatamente. Sin esperar a que un rastreador descubra una página que publicaste hace tres semanas.

También hay seguimiento de citas — monitoreo de qué tan frecuentemente tu sitio es citado por motores de búsqueda de AI. Llamadas reales a la API, no datos simulados.

El stack es Next.js 14, Zustand, OpenRouter enrutando entre GPT-4o y Claude 3.5 Sonnet según la tarea, e IndexNow para la capa de envío.

AEO: lo que la mayoría de las herramientas de SEO ignoran

Google ya no es el único motor de búsqueda que importa.

ChatGPT, Perplexity y Claude están generando tráfico significativo — y citan fuentes. Cuando alguien le pregunta a Perplexity “¿cuál es la mejor herramienta para X?”, muestra algunos sitios con citas inline. Esas citas generan clics reales.

La lógica de optimización es diferente al SEO tradicional. Google rankea páginas basándose en enlaces, autoridad, señales técnicas. Los motores de AI citan basándose en la claridad del contenido, la riqueza del schema, la autoridad temática, y qué tan bien tu contenido responde una pregunta específica directamente.

Parsed hace seguimiento de ambas. El trabajo de schema alimenta a Google. El trabajo de contenido alimenta las citas de AI. Se superponen pero no son idénticos, y tratarlos igual es dejar cobertura sobre la mesa.

He empezado a pensar en esto como AEO — optimización para motores de respuesta. No es un rebranding del SEO, es una capa adicional. Tu contenido necesita rankear en la búsqueda tradicional y ser citable por AI. Esos son objetivos relacionados pero distintos.

El ciclo del humanizador

Aquí está la parte incómoda.

Estoy generando artículos con una AI, luego pasándolos por un detector de AI, luego reescribiendo las secciones marcadas hasta que la puntuación humana llegue al 87% o más, luego escribiendo el archivo a disco.

La paradoja: usar AI para escribir contenido, luego usar AI para verificar si el contenido parece que no fue escrito por AI, luego usar AI para arreglar las partes que sí parecen.

Funciona. Los artículos pasan. Google no tiene un detector confiable a nivel de contenido — mira señales como enlaces, autoridad, comportamiento del usuario. Pero prefiero publicar contenido que se lea como si lo hubiera escrito un humano independientemente de si el detector importa. Es simplemente mejor escritura.

El ciclo del humanizador es parte del pipeline del agente de publicación. No es opcional. Cada artículo que sale de Parsed ha pasado por él.

Limitación actual

Parsed corre localmente.

Tiene acceso directo al sistema de archivos porque necesita escribir en tu proyecto. Eso es lo que lo hace útil y lo que lo hace difícil de productizar. Una versión alojada requeriría una integración de repositorio — app de GitHub, permisos de escritura, flujo de trabajo de PR. Eso es un producto real, no un proyecto paralelo.

Por ahora es una herramienta que corro contra mis propios sitios. igindin.com es el caso de prueba principal. El agente de schema ha escrito datos estructurados para cada página principal. El agente de publicación ha generado y hecho commit de varios artículos. El agente de indexación corre cada vez que publico contenido nuevo.

El camino al SaaS es una integración de GitHub que crea una rama, escribe los archivos, abre un PR para revisión. Obtienes la ejecución autónoma sin darle a una herramienta de terceros acceso de escritura directo a main. Esa es la arquitectura correcta. Todavía no la he construido.

Qué sigue

A corto plazo: un ciclo de retroalimentación más ajustado entre el seguimiento de citas y la generación de contenido. Si un artículo específico está siendo citado por Perplexity, quiero saber qué sección está siendo tomada y escribir más contenido alrededor de ese enfoque.

A mediano plazo: la integración con GitHub. Parsed como servicio que corre según un programa, abre PRs, y te permite aprobar el trabajo sin tocar un entorno local.

A largo plazo: no estoy seguro. Las herramientas de SEO son un espacio saturado. Pero “escribe en tu codebase” es una categoría diferente a “te muestra un reporte”. El valor está en la brecha de ejecución, y esa brecha es real.

La herramienta existe. Corre. Ha producido output medible. Eso es suficiente para seguir construyendo.