KI-gebaute Website: Warum interne Verlinkung ausser Kontrolle geraet
Eine grosskfig mit KI erstellte Website funktioniert schnell, doch interne Verlinkung scheitert, weil sie ein seitenuebergreifender Zustand ist, den jede isoliert generierte Seite nicht kennt. Der Autor hat deshalb zunaechst den kompletten Link-Graphen abgebildet, bevor er etwas geaendert hat.
Meine Website wird inzwischen großteils von KI erstellt, sowohl der Code als auch die Inhalte. Sie ist schnell, und ich werde nicht zurückgehen. Aber nach einigen Monaten ist mir etwas aufgefallen, vor dem niemand warnt: Interne Verlinkung ist der eine Hebel, den die KI nie in den Griff bekommen hat, weil es sich dabei um einen seitenweiten Zustand handelt, nicht um den Zustand einer einzelnen Seite.
Jede Seite wurde isoliert erzeugt, nur mit lokalem Kontext. Jede einzelne wirkt gut verlinkt, mit sinnvollen verwandten Links, Breadcrumbs und einem Navigationsmenü. Niemand, weder ich noch das Modell, hat ein Verzeichnis über den gesamten Graphen geführt. Multipliziert man das mit Hunderten von Seiten, ergibt sich genau das, was ich vorfand:
Ich plane eine Runde der Link-Konsolidierung, also das Zusammenführen fast identischer Seiten und die Umleitung von Links auf die Seiten, die bereits gut ranken. Bevor ich irgendetwas bearbeite, wollte ich den tatsächlichen Graphen sehen: jede Verbindung von Quelle zu Ziel, aus dem gerenderten HTML, nicht aus dem, was die Templates vorgeben zu tun.
Ich suchte nach einem Tool zur Visualisierung interner Links, das ich einfach auf eine Seite richten kann. Kommerzielle Crawler liefern einem einen Bericht über die Links; ich wollte den rohen Graphen, von der Sorte, die man nach einer Änderung vergleichen, mit Search-Console-Daten verknüpfen oder einem LLM übergeben kann. Selbstgeschriebene Skripte machten durchweg denselben Fehler: die Navigation. Links in Header und Footer erscheinen auf jeder Seite, daher besagen die rohen Zahlen, dass alles mit allem verlinkt ist, und verbergen die rund 5 Prozent der Links, die tatsächlich Bedeutung tragen.
Also baute ich das Werkzeug, das ich brauchte, und habe es als Open Source veröffentlicht: internal-links-export. Es crawlt eine Website (über die Sitemap oder mit BFS als Fallback), trennt die seitenweite Navigation mithilfe einer datengetriebenen Regel von den Inhaltslinks (jedes Ziel, das von mindestens 90 Prozent der gecrawlten Seiten verlinkt wird, wird als Chrome behandelt, also ohne hartcodierte Navigationslisten) und fasst alles in einem einzigen offline nutzbaren HTML-Bericht samt Exporten zusammen. Null Abhängigkeiten, MIT-Lizenz. Das ist die ganze Angebotsbeschreibung; der Rest dieses Beitrags handelt davon, was der Graph mir tatsächlich verraten hat, denn genau das lässt sich auf Ihre Website übertragen.
Meine eigene Website, petguidecalc.com, eine englische Ratgeber- und Rechnerseite rund um Haustiere mit 231 Seiten, ebenfalls mit KI erstellt, lieferte ein ernüchterndes, aber beherrschbares Bild: die verwaisten Seiten, die thematischen Zwillinge, die sich die eingehenden Links teilen, die austauschbaren Hub-Seiten. Aber ich wollte kein Werkzeug, das nur in diesem Maßstab funktioniert, also habe ich es einem absichtlich widerspenstigen Ziel unterzogen, das mir nicht gehört: einer großen E-Commerce-Website eines Drittanbieters, deren Link-Graph sich auf 4.868 Seiten auflöst, davon 3.931 flache Produkt-URLs nach dem Muster /products/{slug}, also ohne Kategorie im Pfad und ohne etwas, wonach man gruppieren könnte. Als ein Graph: ein Haarball. Als Tabelle: bedeutungslos.
Das Tool rekonstruierte die faktische Taxonomie aus der Linkstruktur selbst: Jede Nicht-Hub-Seite wurde unter ihrer stärksten inhaltlichen Quellseite der eingehenden Links gruppiert, also jener Kategorie, die am häufigsten auf sie verweist. Daraus entstanden 268 Kategoriegruppen, die 92 Prozent der Produkte abdecken und jeweils klein genug sind, um sie tatsächlich lesen zu können. Das war der Moment, in dem das Werkzeug nützlich wurde: Die echte Informationsarchitektur der Website existiert in ihren Links, selbst wenn sie nirgendwo sonst existiert.
Drei Ansichten tragen den Großteil der diagnostischen Aussagekraft:
Nach dem Export des Graphen (Seiten als CSV plus Kantenliste als CSV) läuft mein Arbeitsablauf so:
Schritt 5 ist der Grund, warum mir Exporte so viel bedeuteten und nicht ein hübscher Bericht. Ein Graph, den man nicht vergleichen kann, ist ein Screenshot; ein Graph, den man vergleichen kann, ist ein Messinstrument.
Die Ironie ist mir nicht entgangen: Das Chaos entstand durch die Erzeugung auf Seitenebene ohne globale Sicht, und die Bereinigung läuft nun ebenfalls KI-unterstützt, aber dieses Mal bekommt das Modell den gesamten Graphen zu sehen. Man exportiert die internen Links als Kantenliste (eine Zeile pro from, to, count und type), übergibt sie einem LLM zusammen mit der Search-Console-Tabelle und bittet um Kandidaten für Zusammenführungen und Vorschläge zur Umleitung von Links. Es ist derselbe Trick wie beim Erzeugungsfehler, nur umgekehrt: globaler Zustand, der als Kontext geliefert wird. GEXF- und GraphML-Exporte gibt es für die Tage, an denen ich mir den Graphen lieber in Gephi ansehen möchte.
Das Repository lautet partick33/internal-links-export, mit Crawler, Ein-Datei-Bericht, CSV/GEXF/GraphML/JSON-Exporten, 12 Tests und MIT-Lizenz. Es ist ein Mittel, kein Produkt: Der Punkt war nie das Werkzeug, sondern den Graphen auf den Tisch zu bekommen, bevor man eine Website umstrukturiert, die schneller gewachsen ist, als es ihre Verlinkung mitgehen lassen konnte.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
My site is built largely by AI now — code and content. It's fast, and I'm not going back. But a few months in I noticed something nobody warns you about: internal linking is the one lever AI never managed, because it's site-wide state, not page state.
Every page was generated in isolation, with local context only. Each one looks well-linked — sensible related links, breadcrumbs, a nav menu. Nobody, me or the model, was keeping a ledger of the whole graph. Multiply that by hundreds of pages and you get what I got:
I'm planning a round of link consolidation — merging near-duplicate pages and re-pointing links toward the pages that already rank. Before editing anything, I wanted to see the actual graph: every from → to, from rendered HTML, not from what the templates claim they do.
I looked for an internal link visualization tool I could just point at a site. Commercial crawlers give you a report about your links; I wanted the raw graph — the kind you can diff after a change, join against Search Console data, or hand to an LLM. Homegrown scripts got one thing consistently wrong: navigation. Header/footer links appear on every page, so raw counts say "everything links to everything" and hide the ~5% of links that actually carry meaning.
So I built the instrument I needed, and open-sourced it: internal-links-export. It crawls a site (sitemap or BFS fallback), separates site-wide navigation from content links using a data-driven rule (any target linked from ≥ 90% of crawled pages is treated as chrome — no hardcoded nav lists), and compiles everything into a single offline HTML report plus exports. Zero dependencies, MIT. That's the whole pitch; the rest of this post is what the graph actually told me, because that's the part that transfers to your site.
My own site — petguidecalc.com, an English pet-care guide and calculator site, 231 pages, AI-built like the rest — produced a sobering but manageable picture: the orphans, the topic twins splitting in-links, the uniform hubs. But I didn't want an instrument that only works at that scale, so I stress-tested it against a deliberately hostile target I don't own: a large third-party e-commerce site whose link graph resolves to 4,868 pages, 3,931 of them flat product URLs at /products/{slug} — no category in the path, nothing to group by. As one graph: hairball. As a table: meaningless.
The tool recovered the de-facto taxonomy from the link structure itself: every non-hub page grouped under its strongest content in-link source — whichever category page links to it most. That reconstructed 268 category groups covering 92% of products, each small enough to actually read. This was the moment the tool became useful: the site's real information architecture exists in its links, even when it exists nowhere else.
Three views carry most of the diagnostic weight:
With the graph exported (pages CSV + edge list CSV), the workflow I'm running is:
Step 5 is why I cared so much about exports rather than a pretty report. A graph you can't diff is a screenshot; a graph you can diff is an instrument.
The irony isn't lost on me: the mess came from page-level generation with no global view, and the cleanup is now AI-assisted too — but this time the model gets to see the whole graph. Export internal links as an edge list (one row per from, to, count, type ), hand it to an LLM with the Search Console table, and ask for merge candidates and re-pointing proposals. It's the same trick as the generation failure, reversed: global state supplied as context. GEXF and GraphML exports are there for the days I want to look at it in Gephi instead.
The repo is partick33/internal-links-export — crawler, single-file report, CSV/GEXF/GraphML/JSON exports, 12 tests, MIT. It's a means, not a product: the point was never the tool, it was getting the graph on the table before restructuring a site that grew faster than its linking could keep up.