Parsed: Ein SEO-Tool, das in deine Codebase schreibt

Die meisten SEO-Tools enden mit einem Bericht. Parsed fängt dort an.

Du bekommst eine Liste mit fehlendem Schema, Keyword-Lücken, nicht indizierten URLs. Dann schließt du den Tab und vergisst es. Die Arbeit ist nicht passiert — dir wurde nur gesagt, was die Arbeit ist.

Ich habe Parsed gebaut, um diesen Schritt zu überspringen.

Das Problem mit SEO-Tools

Jedes Audit-Tool, das ich benutzt habe, hat dieselbe Form: Es scannt deine Seite, zeigt dir, was falsch ist, und überlässt dir die Reparatur. Das ergab Sinn, als die Arbeit manuell war. Es ergibt weniger Sinn, wenn Agents existieren.

Die Lücke ist nicht Information. Ich weiß, dass ich JSON-LD Schema auf meinen Produktseiten brauche. Ich weiß, dass ich Keyword-Lücken in meinem Blog habe. Ich weiß, dass die Hälfte meiner Sitemap noch nicht indiziert ist. Das weiß ich seit Monaten. Der Engpass ist die Ausführung — sich hinzusetzen und jede Sache zu tun.

Parsed behandelt das als das eigentliche Problem, das es zu lösen gilt.

Was Parsed macht

Parsed ist ein lokaler Super-Agent, der neben deinem Monorepo läuft. Er verbindet sich direkt mit deiner Codebase — nicht über eine Web-UI, die dir einen Snippet zum Kopieren gibt.

Drei Kern-Agents:

Autonomer Optimierungs-Agent — scannt deine Seiten, identifiziert fehlendes oder schwaches Structured Data, generiert JSON-LD Schema-Komponenten und schreibt sie direkt in dein Projekt. Beim nächsten Deploy ist das Schema live. Kein Copy-Paste.

Publishing-Agent — findet Keyword-Lücken in deinem Content, generiert SEO-Artikel, lässt sie durch einen Human-Score-Check laufen und schreibt .md-Dateien in deinen Content-Ordner. Der Artikel existiert auf der Festplatte. Du reviewst ihn, commitest ihn, fertig.

Quick-Index-Agent — holt deine Sitemap, übermittelt jede URL an IndexNow. Google, Bing und Yandex werden sofort benachrichtigt. Kein Warten darauf, dass ein Crawler eine Seite entdeckt, die du vor drei Wochen veröffentlicht hast.

Es gibt auch Citation-Tracking — Monitoring, wie oft deine Seite von AI-Suchmaschinen zitiert wird. Echte API-Aufrufe, keine Mock-Daten.

Der Stack ist Next.js 14, Zustand, OpenRouter routing zwischen GPT-4o und Claude 3.5 Sonnet je nach Aufgabe, und IndexNow für den Submission-Layer.

AEO: das, was die meisten SEO-Tools ignorieren

Google ist nicht mehr die einzige Suchmaschine, die zählt.

ChatGPT, Perplexity und Claude ziehen signifikanten Traffic — und sie zitieren Quellen. Wenn jemand Perplexity fragt “was ist das beste Tool für X?”, zeigt es ein paar Seiten mit Inline-Zitaten. Diese Zitierungen treiben echte Klicks.

Die Optimierungslogik ist anders als bei traditionellem SEO. Google rankt Seiten basierend auf Links, Authority, technischen Signalen. AI-Engines zitieren basierend auf Content-Klarheit, Schema-Reichhaltigkeit, thematischer Autorität und wie gut dein Content eine spezifische Frage direkt beantwortet.

Parsed verfolgt beides. Die Schema-Arbeit füttert Google. Die Content-Arbeit füttert AI-Zitierungen. Sie überlappen, sind aber nicht identisch — und sie gleich zu behandeln lässt Coverage auf dem Tisch liegen.

Ich habe angefangen, das als AEO zu denken — Answer Engine Optimization. Es ist kein Rebranding von SEO, es ist eine zusätzliche Schicht. Dein Content muss in der traditionellen Suche ranken und von AI zitierbar sein. Das sind verwandte, aber unterschiedliche Ziele.

Die Humanizer-Schleife

Hier kommt der unbequeme Teil.

Ich generiere Artikel mit einer AI, lasse sie dann durch einen AI-Detector laufen, schreibe dann die markierten Abschnitte um, bis der Human Score 87% oder höher erreicht, und schreibe dann die Datei auf die Festplatte.

Das Paradox: AI nutzen, um Content zu schreiben, dann AI nutzen, um zu prüfen, ob der Content nicht wie von AI geschrieben klingt, dann AI nutzen, um die Teile zu fixen, die es doch tun.

Es funktioniert. Die Artikel bestehen. Google hat keinen zuverlässigen Detector auf Content-Ebene — es schaut auf Signale wie Links, Authority, Nutzerverhalten. Aber ich bevorzuge Content zu shippen, der sich anfühlt, als hätte ein Mensch ihn geschrieben, unabhängig davon, ob der Detector wichtig ist. Es ist einfach besseres Schreiben.

Die Humanizer-Schleife ist Teil der Pipeline des Publishing-Agents. Sie ist nicht optional. Jeder Artikel, der aus Parsed herauskommt, ist durch sie gelaufen.

Aktuelle Einschränkung

Parsed läuft lokal.

Es hat direkten Filesystem-Zugriff, weil es in dein Projekt schreiben muss. Das macht es nützlich und macht es schwer zu produktisieren. Eine gehostete Version würde eine Repo-Integration erfordern — GitHub-App, Schreibberechtigungen, PR-Workflow. Das ist ein echtes Produkt, kein Side-Projekt.

Im Moment ist es ein Tool, das ich gegen meine eigenen Seiten laufen lasse. igindin.com ist der primäre Testfall. Der Schema-Agent hat Structured Data für jede wichtige Seite geschrieben. Der Publishing-Agent hat mehrere Artikel generiert und committed. Der Index-Agent läuft, wenn ich neuen Content shippe.

Der Weg zu SaaS ist eine GitHub-Integration, die einen Branch erstellt, die Dateien schreibt und einen PR zur Überprüfung öffnet. Du bekommst die autonome Ausführung, ohne einem Drittanbieter-Tool direkten Schreibzugriff auf main zu geben. Das ist die richtige Architektur. Ich habe sie noch nicht gebaut.

Was als nächstes kommt

Kurzfristig: engere Feedback-Schleife zwischen Citation-Tracking und Content-Generierung. Wenn ein spezifischer Artikel von Perplexity zitiert wird, will ich wissen, welcher Abschnitt gezogen wird, und mehr Content rund um diese Rahmung schreiben.

Mittelfristig: die GitHub-Integration. Parsed als Service, der nach einem Zeitplan läuft, PRs öffnet und dir erlaubt, die Arbeit zu genehmigen, ohne eine lokale Umgebung anzufassen.

Langfristig: Ich bin nicht sicher. SEO-Tooling ist ein überfüllter Markt. Aber “schreibt in deine Codebase” ist eine andere Kategorie als “zeigt dir einen Bericht.” Der Wert liegt in der Ausführungslücke, und diese Lücke ist real.

Das Tool existiert. Es läuft. Es hat messbaren Output produziert. Das reicht, um weiterzubauen.