Wie ich als Nicht-Programmierer eine eigene SEO-Wissensbibliothek gebaut habe

Was mache ich mit mehreren hundert SEO-Quellen, wenn ich zwar ungefähr weiß, wer etwas zu einem Thema veröffentlicht hat, die richtige Stelle allerdings nicht mehr finde? Vor dieser Frage stand ich im Frühjahr 2026.

Über die Jahre hatte ich Fachartikel, YouTube-Transkripte, Google-Patente, Research Papers, Vorträge und PDFs gesammelt. Gelesen hatte ich den größten Teil davon. Viele Erkenntnisse waren auch in meine tägliche Arbeit eingeflossen. Das Wissen lag jedoch auf verschiedenen Festplatten, in Browser-Lesezeichen und zu einem nicht unerheblichen Teil in meinem Kopf.

Durchsuchbar war dieser Bestand lediglich innerhalb einzelner Dateien. Benötigte ich drei Aussagen verschiedener Autoren zu einem SEO-Konzept, musste ich daher zunächst wissen, in welchen Dokumenten ich suchen sollte. Bei 50 Quellen funktionierte das noch einigermaßen. Mit mehreren hundert Dokumenten wurde aus einer Fachfrage hingegen schnell eine längere Suche.

Deswegen wollte ich eine eigene SEO-Wissensbibliothek bauen. Sie sollte meine Quellen nach exakten Begriffen wie auch nach ihrer Bedeutung durchsuchen, die gefundenen Stellen anzeigen und daraus ein dauerhaftes Wiki pflegen. Vor allem aber wollte ich jederzeit sehen können, auf welcher Quelle eine Aussage beruht.

Eine kleine Schwierigkeit gab es dabei allerdings: Ich bin kein Programmierer.

Was ich mit meiner SEO-Wissenssammlung machen wollte

Für meine SEO-Fachartikel und Studien arbeite ich meist mit Primärquellen. Dazu zählen beispielsweise Patente, offizielle Dokumentationen, Forschungsarbeiten und Originalpublikationen von Personen, die ein bestimmtes Fachgebiet geprägt haben.

Bei einer Recherche benötige ich in der Regel nicht das gesamte Dokument. Gesucht wird womöglich ein einzelner Absatz, in dem eine Quelle ein Konzept definiert. An anderer Stelle interessieren mich mehrere Passagen, weil verschiedene Autoren dasselbe Phänomen unterschiedlich erklären. Und gelegentlich will ich lediglich prüfen, ob eine vermeintlich bekannte Aussage in der angegebenen Quelle überhaupt vorkommt.

Mein erster Gedanke war ein eigenes KI-Modell, das nur meine Quellen kennt. Im Gespräch mit Claude stellte sich dieser Ansatz jedoch recht schnell als unpassend heraus. Ein lokal trainiertes Sprachmodell hätte weiterhin ein Verfahren benötigt, mit dem es die passenden Informationen findet. Zugleich wären Training, Betrieb und Evaluation ohne entsprechende Hardware für meinen Zweck unverhältnismäßig gewesen.

Was ich tatsächlich brauchte, war eine Suche, die einem leistungsfähigen Sprachmodell bei jeder Frage die richtigen Quellenstellen zur Verfügung stellt. Das Modell musste mein gesamtes Wissen also nicht erlernen. Es musste auf die jeweils relevanten Ausschnitte zugreifen können.

Dieses Prinzip wird als Retrieval Augmented Generation bzw. RAG bezeichnet. Ein System durchsucht dabei zunächst einen vorhandenen Wissensbestand. Anschließend erhält das Sprachmodell die gefundenen Inhalte zusammen mit der eigentlichen Frage. Wer meine Artikelreihe zur KI-Suche kennt, dürfte das Grundprinzip wiedererkennen.

Weshalb hochgeladene Dokumente für mich nicht ausreichten

Natürlich hätte ich meine Dokumente auch in Claude Projects, ChatGPT oder NotebookLM laden können. Als ich die Bibliothek aufbaute, gaben mir diese Lösungen allerdings nicht die Kontrolle, die ich für meine Arbeit haben wollte.

Für mich war wichtig, welche Passagen ein Modell bei einer Antwort verwendet. Ebenso wollte ich den Suchindex selbst pflegen, neue Quellen gezielt ergänzen und nachvollziehen können, wann eine Wiki-Seite aufgrund welcher Quelle verändert wurde. Bei mehr als 300 Dokumenten kam außerdem ein manuelles Zusammenstellen des Kontexts nicht mehr infrage.

Diese Anforderungen sind spezieller als die allgemeine Frage, ob man sich mit hochgeladenen Dokumenten unterhalten kann. Die genannten Produkte können sich seit meinem damaligen Test zudem verändert haben. Meine Entscheidung beschreibt daher meinen Anwendungsfall im Frühjahr 2026 und keinen dauerhaften Produktvergleich.

Was meine SEO-Wissensbibliothek heute umfasst

Am 20. August 2026 enthält die Bibliothek 364 Rohdateien. Aus diesen Dokumenten wurden 30.831 Textabschnitte, sogenannte Chunks, für die Suche indexiert. Das Wiki besteht aus 31 inhaltlichen Seiten. Zusätzlich liegen fünf ältere Fassungen in der Versionshistorie.

Auf die Bibliothek greife ich inzwischen sowohl mit Claude als auch mit Codex zu. Ermöglicht wird dies durch das Model Context Protocol, kurz MCP. Über diesen offenen Standard können KI-Agenten festgelegte Werkzeuge verwenden. In meinem Fall dürfen sie beispielsweise Quellen suchen, Wiki-Seiten lesen oder einen Qualitätscheck starten.

Schreibende Funktionen existieren ebenfalls. Sie werden jedoch nur aufgerufen, wenn ich eine Änderung anstoße und freigebe. Dass Claude die Bibliothek zuerst genutzt hat, schließt Codex somit nicht aus. Beide Systeme arbeiten mit demselben Quellenbestand, ohne dass dafür zwei getrennte Bibliotheken gepflegt werden müssen.

Wie findet die Suche relevante Quellen?

Stelle ich eine Fachfrage, werden zwei Suchverfahren miteinander kombiniert. Die Begriffssuche findet exakte Wörter und Wortfolgen. Suche ich nach „NavBoost“, erhalte ich dadurch Passagen, in denen dieser Name tatsächlich vorkommt.

Die Vektorsuche verarbeitet Texte dagegen als sogenannte Embeddings, also mathematische Repräsentationen ihrer Bedeutung. Eine deutsche Frage kann dadurch auch zu einem englischen Quellentext passen. Ebenso lassen sich Abschnitte über thematische Autorität finden, obwohl in meiner Frage womöglich nur von der fachlichen Tiefe einer Website die Rede war.

Beide Verfahren liefern zunächst mögliche Fundstellen. Ein Cross-Encoder bewertet diese Kandidaten anschließend noch einmal im Verhältnis zu meiner vollständigen Frage. Hierdurch soll eine Passage, die lediglich ein passendes Wort enthält, hinter einem Abschnitt landen, der die Frage tatsächlich beantwortet.

Der Aufbau ähnelt damit einer verbreiteten Form des Hybrid Retrieval. Google oder andere große Suchsysteme sind allerdings wesentlich komplexer. Aus der Verwendung von Vektorsuche, Begriffssuche und Reranking folgt daher nicht, dass meine lokale Bibliothek dieselbe Architektur wie eine kommerzielle Suchmaschine besitzt.

Weshalb beide Suchwege nötig sind, zeigt ein einfaches Beispiel. Bei einer Suche nach Googles Bewertung der thematischen Tiefe einer Website findet die Vektorsuche auch verwandte Abschnitte zu Topical Authority oder Site Focus. Für einen Eigennamen wie NavBoost ist die exakte Begriffssuche hingegen meist zuverlässiger. Zusammen gleichen beide Verfahren ihre jeweiligen Schwächen zumindest teilweise aus.

Wie entsteht aus den Rohquellen ein Wiki?

Mit der Suche war mein ursprüngliches Problem erst zur Hälfte gelöst. Sie findet Quellenstellen, beginnt bei einer neuen Frage allerdings wieder von vorn. Zusammenhänge, die bereits einmal erarbeitet wurden, bleiben dadurch nicht automatisch als strukturierter Wissensstand erhalten.

Deswegen gibt es neben den Rohdaten und dem Suchindex ein Wiki aus Markdown-Dateien. Jede Seite beschreibt ein SEO-Konzept, nennt ihre Quellen und verweist auf verwandte Themen. Wird eine neue Veröffentlichung importiert, kann Claude oder Codex prüfen, welche vorhandenen Seiten davon betroffen sind. Vorgeschlagene Ergänzungen lassen sich anschließend mit einem Änderungsgrund und einer neuen Version speichern.

Wichtig bleibt dabei, dass weder Claude noch Codex ungefragt das Wiki verändert. Ich stoße den Vorgang an, prüfe die Änderungen und entscheide, was übernommen wird. Der Wissensbestand wächst somit unter meiner Aufsicht.

Für die Pflege existiert außerdem eine Lint-Funktion. Ein sogenannter Lint prüft Dateien anhand festgelegter Regeln. In meinem Wiki sucht er nach toten Querverweisen, verwaisten Seiten, fehlenden Metadaten, sehr kurzen Einträgen, fehlenden Quellen und Seiten, die seit mehr als 90 Tagen nicht kontrolliert wurden.

Fehlerfrei wird die Wissensbibliothek dadurch nicht. Beim aktuellen Lauf meldete der Lint beispielsweise zwei tote Links, obwohl die Zielseiten vorhanden sind. Wahrscheinlich verarbeitet die Prüfung die verwendete Alias-Schreibweise falsch. Eine neue Seite zu Query Templates erkannte er dagegen zutreffend als verwaist, weil noch keine andere Wiki-Seite auf sie verweist.

Gerade dieses Beispiel ist für mich aufschlussreich. Die automatisierte Prüfung findet Probleme, ihre Ergebnisse müssen allerdings ebenfalls geprüft werden. Bei einer Wissensdatenbank wäre es ziemlich widersinnig, ausgerechnet den Qualitätscheck ungefragt als wahr zu behandeln.

Welche Fehler ich beim Aufbau gemacht habe

Beschreibt man das fertige System, klingt der Weg dorthin erstaunlich geordnet. Tatsächlich bin ich über Wochen von einem Fehler zum nächsten gestolpert.

Bereits bei der Installation von Python hatte ich die Option „Add to PATH“ übersehen. Windows fand Python deswegen anschließend nicht. Gelöst wurde das Problem über die Umgebungsvariablen, deren Bedienung für einen Nicht-Programmierer ungefähr so intuitiv war, wie es sich anhört.

Bei der ersten Quelle verwendete ich dann die falsche Domain eines Autors. Nachdem dieser Fehler aufgefallen war, lieferte die richtige Website komprimierte Daten in einem Format, das mein Skript nicht verarbeiten konnte. Mit einer weiteren Bibliothek ließ sich die Seite schließlich laden. Der Artikelinhalt wurde trotzdem nicht erkannt, weil die HTML-Struktur von der erwarteten Struktur abwich.

Für einen einzigen Artikel waren damit bereits mehrere Korrekturen nötig. Claude schrieb ein kleines Diagnose-Skript, untersuchte die Seitenstruktur und passte die Auswahl des eigentlichen Artikeltextes an. Erst danach lag die erste Quelle in der Datenbank.

Beim Import vieler Quellen wiederholte sich dieses Muster. Die verwendete YouTube-Schnittstelle hatte sich gegenüber der Version verändert, für die der erste Code geschrieben worden war. JavaScript-lastige Webseiten lieferten zunächst leere Dokumente, weil ihr Inhalt erst im Browser aufgebaut wurde. Für solche Seiten musste daher ein Browser im Hintergrund gestartet werden, der den Inhalt vollständig lädt.

Auch die inkrementelle Indexierung benötigte drei Anläufe. Zuerst sollte das Änderungsdatum einer Datei zeigen, ob sie neu verarbeitet werden muss. Da der Import die Dateien bei jedem Lauf neu schrieb, änderte sich allerdings auch dieses Datum. Danach wurde der Fortschritt erst am Ende des gesamten Durchlaufs gespeichert. Brach der Import vorher ab, war der Zwischenstand verloren.

Funktioniert hat schließlich eine Prüfsumme des Dateiinhalts, die nach jeder verarbeiteten Quelle gespeichert wird. Derartige Lösungen hätte ich selbst kaum programmieren können. Beschreiben konnte ich hingegen, was passiert war, was ich erwartet hatte und welche Fehlermeldung angezeigt wurde. Auf dieser Grundlage ließen sich die nächsten Schritte mit Claude erarbeiten.

Zum Programmierer bin ich dadurch weiterhin nicht geworden. Gelernt habe ich allerdings, technische Probleme so zu zerlegen, dass ein Coding-Agent sinnvoll damit arbeiten kann. Ebenso habe ich gelernt, erzeugten Code und fachliche Ergebnisse nicht allein deshalb für richtig zu halten, weil sie funktionieren oder plausibel klingen.

Was Andrej Karpathy im April 2026 veröffentlichte

Am 4. April 2026 veröffentlichte Andrej Karpathy auf GitHub ein Idea File mit dem Titel „LLM Wiki“. Einige Tage zuvor hatte ich meine eigene Bibliothek erstmals funktionsfähig bekommen. Interessiert hat mich an seiner Veröffentlichung daher vor allem, wie ähnlich die beschriebenen Probleme waren.

Karpathys Konzept besteht aus drei Schichten. Unveränderliche Rohquellen bilden die Grundlage. Dazwischen liegt ein Wiki aus miteinander verknüpften Markdown-Dateien. Gesteuert wird die Pflege über ein Schema, das einem Agenten die Struktur und die erlaubten Arbeitsabläufe vorgibt.

Neue Quellen werden in diesem Modell nicht lediglich für eine spätere Suche indexiert. Der Agent liest sie, ergänzt bestehende Seiten, vermerkt Widersprüche und aktualisiert Querverweise. Bereits erarbeitete Zusammenhänge bleiben dadurch erhalten, sodass komplexe Fragen nicht bei jeder Anfrage vollständig neu aus den Rohdokumenten zusammengesetzt werden müssen.

In der ursprünglichen Fassung dieses Artikels hatte ich Karpathy ein eigenes Wiki mit rund 100 Artikeln und 400.000 Wörtern zugeschrieben. Diese Angabe lässt sich aus seinem Gist nicht ableiten. Dort nennt er ungefähr 100 Quellen und mehrere hundert Wiki-Seiten lediglich als Größenordnung, bei der ein gepflegter Index noch gut funktionieren könne.

Auch der damalige Verlauf der Verbreitung lässt sich rückblickend nicht allein anhand der heutigen Sterne belegen. Feststellen lässt sich, dass GitHub am 20. August 2026 mehr als 5.000 Sterne anzeigt. Wie viele davon in den ersten Stunden oder Tagen hinzukamen, habe ich nicht dokumentiert.

Die aktuelle Fassung des Gists nennt für größere Wikis inzwischen sogar ein optionales Suchwerkzeug, das BM25, Vektorsuche und ein LLM-Reranking kombiniert. Damit ähnelt die dort beschriebene Erweiterung meiner Lösung stärker als das reine Markdown-Wiki. Karpathys Konzept benötigt eine derartige Suchschicht allerdings erst, wenn der Bestand entsprechend wächst.

Mein System ist unabhängig davon entstanden. Einen besonderen Anspruch leite ich daraus nicht ab. Für mich zeigt die zeitliche Nähe vielmehr, dass Menschen mit größeren Wissensbeständen an derselben Stelle auf ein grundsätzlich ähnliches Problem stoßen: Eine Suche findet Informationen, bewahrt jedoch noch keinen gepflegten Wissensstand.

Was meine Wissensbibliothek kann und wo ihre Grenzen liegen

Mit der Bibliothek kann ich heute eine Fachfrage stellen und erhalte konkrete Passagen aus den Quellen, die zu dieser Frage passen. Zu jeder Passage werden Dokument, Abschnitt und Herkunft angezeigt. Eine Antwort lässt sich dadurch wesentlich einfacher kontrollieren als eine Zusammenfassung, bei der die verwendeten Fundstellen unsichtbar bleiben.

Quellengebunden bedeutet allerdings nicht fehlerfrei. Bereits das Retrieval kann eine relevante Passage übersehen oder einen weniger geeigneten Abschnitt bevorzugen. Anschließend kann ein Sprachmodell die gefundenen Stellen falsch zusammenfassen oder aus ihnen mehr ableiten, als dort tatsächlich steht.

Deswegen dient mir das System als Recherche-Instrument. Es liefert Fundstellen, ordnet Wissen vor und weist auf mögliche Widersprüche hin. Die fachliche Bewertung bleibt bei mir. Dies gilt insbesondere für SEO-Wissen, denn hier liegen offizielle Dokumentationen, Patente, Forschungsarbeiten, Gerichtsunterlagen, Leaks, Fallstudien und persönliche Modelle oftmals direkt nebeneinander. Eine plausible Erklärung ist dadurch noch keine dokumentierte Funktionsbeschreibung von Google.

Dasselbe Problem zeigt sich im Wiki. Einige ältere Seiten berufen sich auf meine eigenen Blogartikel. Würde ich diese Artikel später nur anhand des Wikis prüfen, könnten sie sich selbst bestätigen. Für ein fachliches Lektorat muss ich daher bis zur ursprünglichen externen Quelle zurückgehen.

Die gesamte Suchinfrastruktur läuft lokal auf meinem Windows-Rechner und benötigt keine eigene GPU. Kosten können trotzdem entstehen, wenn ein externes Sprachmodell Quellen verarbeitet, Wiki-Seiten aktualisiert oder Antworten formuliert. Eine pauschale Angabe von ungefähr einem Euro, wie sie in der ersten Artikelfassung stand, beschreibt daher lediglich einen früheren Importlauf und keine dauerhaften Gesamtkosten.

Ebenso wenig ist die Bibliothek ein Produkt, das andere Personen einfach installieren und ohne Anpassung verwenden können. Karpathy bezeichnet derartige Lösungen treffend als eine Sammlung von Skripten. Meine Bibliothek wurde für einen konkreten Quellenbestand, meine Arbeitsweise und meine Anforderungen entwickelt. In diesem Rahmen funktioniert sie, wodurch jedoch noch keine allgemeine Softwarelösung entsteht.

Für welche Wissensbestände eignet sich das Prinzip?

Gebaut habe ich die Bibliothek für SEO-Recherchen. Das zugrunde liegende Prinzip ist allerdings nicht auf die Suchmaschinenoptimierung beschränkt.

Ein Steuerberater könnte damit Urteile, Schreiben des Bundesfinanzministeriums und fachliche Kommentierungen durchsuchen. Für medizinische Forschung ließen sich Studien zu einem Krankheitsbild mit ihrem Veröffentlichungsstand und ihren Widersprüchen ordnen. In einem Unternehmen könnten Protokolle, Produktdokumentationen und Entscheidungen in einen dauerhaft gepflegten Wissensbestand einfließen.

Je sensibler ein Fachgebiet ist, desto wichtiger werden allerdings Datenschutz, Zugriffsrechte und die menschliche Prüfung. Dass ein Sprachmodell Quellen zusammenfassen kann, macht es weder zum Arzt noch zum Steuerberater. Die Bibliothek verbessert den Zugriff auf vorhandenes Wissen. Sie ersetzt nicht die fachliche Verantwortung für eine Entscheidung.

Was ich als Nicht-Programmierer daraus gelernt habe

Ohne Claude hätte ich diese SEO-Wissensbibliothek nicht bauen können. Inzwischen kann ich sie zusätzlich mit Codex verwenden, während Claude weiterhin auf denselben Bestand zugreift. Für mich ist gerade diese Austauschbarkeit wichtig, weil die Quellen und das Wiki nicht in einem einzelnen Chat oder Produkt eingeschlossen sind.

Meine fehlenden Programmierkenntnisse waren dabei ein Hindernis, allerdings kein endgültiger Ausschlussgrund. Benötigt habe ich eine konkrete Vorstellung davon, welches Problem gelöst werden soll. Danach musste ich jeden Fehler möglichst genau beschreiben, die vorgeschlagene Lösung testen und so lange nachfragen, bis ich zumindest verstanden hatte, was sich dadurch verändert.

Am Ende entstand ein Werkzeug, dessen Code ich weiterhin nicht fachlich beurteilen kann. Über seinen Nutzen, seine Fehler und die Qualität der ausgegebenen Quellen kann ich dagegen sehr wohl entscheiden. Und für meine tägliche Arbeit ist diese Grenze wesentlich wichtiger, als nachträglich so zu tun, als hätte ich innerhalb weniger Wochen programmieren gelernt.

Die Bibliothek hat meinen Umgang mit KI dadurch stärker verändert als viele neue Modelle. Wenn ich heute eine SEO-Frage recherchiere, muss ich einem Sprachmodell nicht allein vertrauen. Ich kann prüfen, welche meiner Quellen es gefunden hat, was dort tatsächlich steht und an welcher Stelle meine eigene Interpretation beginnt.