Zurück zu allen Beiträgen
guides 9 min read

URL-Struktur und KI: Was saubere URLs tatsächlich verändern

Serap Gündoğdu ·
URL-Struktur und KI: Was saubere URLs tatsächlich verändern

URL-Struktur und KI: Was saubere URLs tatsächlich verändern

Wie viel die URL für KI-Systeme wiegt

In der Dokumentation von Google ist die URL ein schwaches Signal. Die Hinweise zur URL-Struktur empfehlen lesbare, einheitliche Adressen vor allem für das Crawling und für Menschen, die den Link lesen. Als Ranking-Hebel wird die URL dort nirgends dargestellt. KI-Suchsysteme und Antwortmaschinen lesen die Seite selbst: den Title, den Fließtext, die Überschriften, die strukturierten Daten und die internen Links, die auf die Seite zeigen.

Ein wenig Information steckt trotzdem in der URL. Ein Slug wie /blog/url-structure-ai sagt Crawler und Leser vor dem Laden der Seite, was sie erwartet, und ein Ordner wie /docs/ oder /pricing/ deutet an, um welche Art von Seite es sich handelt. Eine URL wie /p?id=48213 liefert beides nicht. Wie stark ein KI-System diesen Unterschied gewichtet, wurde öffentlich nicht gemessen. Behandeln Sie es daher als Hypothese.

Dieser Artikel behauptet nicht, dass eine sauberere URL zu mehr Zitaten führt. Uns ist keine Studie bekannt, die das belegt, und wir erfinden keine Zahl. Der größte Teil der Empfehlungen in den folgenden Abschnitten ist gewöhnliche technische SEO-Praxis, die zufällig auch für KI-Crawler gilt. Wo etwas speziell für KI gilt, sagen wir das, und wo wir vermuten, kennzeichnen wir es als Vermutung.

Slugs, Ordnerhierarchie und Kontexthinweise

Ein lesbarer Slug gibt einem Crawler und einem Sprachmodell etwas Kontext, bevor eines von beiden die Seite liest. /blog/url-structure-ai benennt das Thema, bei /a8f3k2x9 muss das System alles aus dem Inhalt ziehen. Da die Größe dieses Vorteils für KI-Systeme nicht gemessen ist, sollten Sie jeder Zahl dazu mit Skepsis begegnen. Ein guter Slug ergänzt einen weit stärkeren Satz an Belegen um einen kleinen Hinweis: Title, Überschriften, Text, strukturierte Daten und interne Links. Eine dünne Seite rettet er nicht.

Slug-Gewohnheiten, die nichts kosten:

  • Verwenden Sie Wörter, die zum Thema der Seite passen.
  • Halten Sie den Slug kurz.
  • Trennen Sie Wörter mit Bindestrichen.
  • Schreiben Sie klein.
  • Lassen Sie Datumsangaben, Sitzungsdaten und interne IDs weg, die einem Leser nichts sagen.

Ordner erzählen etwas anderes: Sie beschreiben den Aufbau der Website. /blog/, /docs/ und /pricing/ kennzeichnen den Inhaltstyp und den Bereich, zu dem eine Seite gehört. Eine einheitliche Hierarchie erleichtert zudem das Gruppieren von Seiten nach Bereichen, sei es im Bericht eines Crawlers oder in einem System, das Seiten clustert. Sprachordner wie /de/ und /es/ benennen die Sprache einer Seite. Sie funktionieren am besten zusammen mit hreflang und sollten es nicht ersetzen.

Vermeiden sollten Sie, bestehende URLs nur deshalb zu ändern, damit sie “KI-freundlich” werden. Jede Änderung bringt Weiterleitungen und das Risiko verlorener Signale mit sich, und der Nutzen ist nicht gemessen. Wählen Sie für neue Inhalte von Anfang an eine saubere Struktur. Lassen Sie alte Inhalte in Ruhe, solange sie nicht offensichtlich fehlerhaft sind, und wenn Sie doch ändern müssen, setzen Sie eine sorgfältige 301-Weiterleitung ein.

Stand der Belege:

StatusAussage
DokumentiertURLs sind laut Google nur ein schwaches Signal, und eine einheitliche, lesbare Struktur erleichtert das Crawling
PlausibelLesbare Slugs und Ordner liefern KI-Systemen leichten zusätzlichen Kontext
UnbekanntWie stark ein KI-System die URL gewichtet, wenn es eine Seite interpretiert

Einheitlichkeit, Canonical-Tags und Deduplizierung

Suchmaschinen und KI-Systeme behandeln eine URL zunächst als Kennung. Wenn eine Seite unter mehreren Adressen erreichbar ist, muss jedes System, das sie berührt, entscheiden, welche Adresse die richtige ist. An dieser Entscheidung teilen sich die Signale auf.

Für einen Crawler sind folgende Adressen jeweils verschiedene URLs, obwohl ein Mensch nur eine Seite sieht:

  • https://example.com/guide und https://example.com/guide/ (abschließender Schrägstrich)
  • /Guide und /guide (Groß- und Kleinschreibung im Pfad; Pfade unterscheiden nach RFC 3986 zwischen Groß- und Kleinschreibung, Server dürfen sie also als getrennte Ressourcen behandeln)
  • https://www.example.com/guide und https://example.com/guide (mit und ohne www)
  • /guide?utm_source=newsletter und /guide (Tracking-Parameter)

Jede Variante kann einzeln abgerufen, gespeichert und verlinkt werden. Interne Links zeigen auf eine Form, externe Links auf eine andere, und die Sitemap listet eine dritte. Linksignale und Nutzungsdaten verteilen sich dann auf Kopien, statt sich auf einer Adresse zu summieren.

Zwei Werkzeuge beheben das, und sie erfüllen unterschiedliche Aufgaben. Eine 301-Weiterleitung schickt jede Anfrage nach einer Variante auf die bevorzugte URL, sodass das Duplikat nicht mehr erreichbar ist. Ein rel="canonical"-Tag lässt die Variante erreichbar, benennt aber die bevorzugte Version. Die Dokumentation von Google beschreibt Canonical als Hinweis und nicht als Anweisung, er kann also ignoriert werden, wenn andere Signale widersprechen. Setzen Sie eine Weiterleitung für Varianten ein, die keinen Grund zu existieren haben, etwa Unterschiede bei Groß- und Kleinschreibung, Schrägstrich und www. Setzen Sie Canonical dort ein, wo die Variante erreichbar bleiben muss, etwa bei Tracking-Parametern.

Am wichtigsten ist die Einheitlichkeit. Wählen Sie eine Form und sorgen Sie dafür, dass Weiterleitung, Canonical-Tag, Sitemap und interne Links sie alle verwenden. Ein Canonical, das auf eine URL zeigt, die selbst weiterleitet, oder eine Sitemap, die die nicht kanonische Form listet, gibt Crawlern widersprüchliche Anweisungen.

Ob KI-Crawler Duplikate so auflösen wie Google, ist öffentlich nicht dokumentiert. Betrachten Sie es deshalb als nicht überprüft. Die Normalisierung auf dem Server kostet wenig und funktioniert, wie auch immer sich die Crawler verhalten.

Parametrisierter URL-Raum und KI-Crawler

Tracking-Parameter sind nur eine Quelle von Duplikaten. Filter-, Sortier- und Sitzungsparameter machen aus einer endlichen Website einen praktisch unendlichen URL-Raum. Eine Kategorieseite mit fünf Filtern, drei Sortierungen und einer Sitzungs-ID lässt sich in Tausenden Kombinationen abrufen, und fast alle zeigen dieselben Produkte in anderer Reihenfolge. Der Crawler kann das nicht wissen, bevor er sie abgerufen hat.

Das Problem ist alt. Die Crawling-Dokumentation von Google behandelt Facettennavigation und URL-Parameter als Quelle doppelter URLs und verschwendeten Crawling-Aufwands. Offen ist, wie KI-Crawler mit demselben Raum umgehen. OpenAI dokumentiert seine Crawler und deren robots.txt-Verhalten auf der Seite zur Bot-Dokumentation, doch diese Seite beschreibt User-Agents und Steuerungsmöglichkeiten. Wie ein Bot parametrisierte URLs priorisiert, dedupliziert oder aufgibt, steht dort nicht. Anthropic, Perplexity und die meisten anderen Betreiber veröffentlichen noch weniger.

Das stützt die offizielle Dokumentation, und das nicht:

StatusAussage
DokumentiertKI-Crawler geben sich über den User-Agent zu erkennen und halten sich laut ihren Betreibern an robots.txt-Regeln (RFC 9309).
Vernünftige AnnahmeEin Bot mit festem Abrufbudget verliert davon einen Teil an Parameter-Varianten, wie es bei Googlebot der Fall ist.
UnbekanntOb ein bestimmter KI-Bot Parameter zusammenführt, Canonical-Tags befolgt oder die Crawl-Tiefe begrenzt.

Die zweite Zeile ist unsere Schlussfolgerung und kein veröffentlichtes Verhalten. Prüfen Sie sie an Ihren eigenen Server-Logs, bevor Sie sich darauf verlassen.

Drei Dinge liegen in Ihrer Hand, egal was die Bots intern tun:

  1. Links. Verlinken Sie von crawlbaren Seiten nicht auf gefilterte oder sortierte Varianten, es sei denn, sie verdienen es, als eigene Seiten zu existieren.
  2. Regeln. Sperren Sie Sitzungs- und Tracking-Parameter in der robots.txt mit den Platzhaltermustern, die RFC 9309 definiert.
  3. Signale. Lassen Sie die weiterhin erreichbaren Varianten auf eine kanonische URL zeigen.

Behalten Sie die 301-Weiterleitungen für URLs bei, die bereits Links tragen. Für alles andere gilt: Je weniger Varianten ein Bot erreichen kann, desto weniger muss er raten.

Die URL als Quellenangabe, und ehrliche Grenzen

Antwortmaschinen zeigen die Quelle als URL. ChatGPT-Suche, Perplexity und die KI-Antworten von Google geben neben der zitierten Aussage einen Link aus, und dieser Link ist der einzige Teil Ihrer Website, den viele Leser sehen, bevor sie entscheiden, ob sie klicken. Ob eine saubere, lesbare Adresse sie häufiger klicken lässt, ist eine Hypothese. Uns ist keine öffentliche Studie bekannt, die das misst, und wir nennen Ihnen keinen Prozentwert.

Diese Grenze zählt, wenn Sie entscheiden, was mit bestehenden URLs geschehen soll. Wer sie umschreibt, damit sie für die KI-Suche freundlicher aussehen, löst Weiterleitungen aus, und jede Weiterleitung birgt Risiken. Ketten werden länger, eine einzige vergessene Zuordnung wird zum 404, und die angesammelten Signale der alten Adresse müssen auf die neue übergehen. Sie tauschen einen gemessenen Aufwand gegen einen Nutzen, den noch niemand gemessen hat.

Eine brauchbare Regel hat zwei Teile. Geben Sie neuen Seiten von Anfang an einen kurzen, beschreibenden Slug. Lassen Sie alte URLs in Ruhe, solange sie kein konkretes Problem verursachen, etwa Duplikate, wuchernde Parameter oder reine ID-Pfade, die niemand lesen kann. Wenn Sie eine ändern, setzen Sie eine einzige 301-Weiterleitung direkt auf die endgültige Adresse, aktualisieren Sie interne Links und Sitemap im selben Release und prüfen Sie danach die Search Console.

Prüfung per Crawl: Welche Checks Sie ausführen

Anhand von Crawl-Daten prüfen Sie, ob Ihre URL-Struktur einheitlich ist. Ein einziger Crawl beantwortet die meisten der folgenden Fragen, manuelle Stichproben sind nicht nötig.

Cluster doppelter URLs. Gruppieren Sie URLs, die sich nur durch abschließenden Schrägstrich, Groß- und Kleinschreibung, www oder nicht-www, oder http oder https unterscheiden. Jeder Cluster ist eine Seite, die unter mehreren Adressen erreichbar ist. Jeder Cluster sollte auf eine kanonische Adresse zusammenfallen.

Parameter-Explosion. Zählen Sie die verschiedenen Query-Parameter im Crawl und die Zahl der URLs, die jeder davon erzeugt. Filter-, Sortier-, Sitzungs- und Tracking-Parameter machen meist den Großteil des Überschusses aus. Ein Parameter, der URLs vervielfacht, ohne den Inhalt zu ändern, kommt für Canonicalisierung oder eine robots.txt-Regel in Frage.

Weiterleitungsketten. Listen Sie jede URL auf, die ihr Ziel erst nach mehr als einem Sprung erreicht, und jeden internen Link, der auf eine weiterleitende Adresse zeigt. Lassen Sie interne Links direkt auf die endgültige URL zeigen. Seiten, die Sie früher für “sauberere” URLs verschoben haben, tauchen hier zuerst auf.

Canonical-Abweichungen. Vergleichen Sie das Canonical-Tag jeder Seite mit der gecrawlten URL. Achten Sie auf Canonicals, die auf eine weiterleitende, nicht indexierbare oder anders formatierte Adresse zeigen, und auf Gruppen nahezu identischer Seiten, die unterschiedliche Canonicals angeben.

Verteilung der URL-Längen. Sortieren Sie URLs nach Länge und lesen Sie das lange Ende. Sehr lange URLs enthalten meist gestapelte Parameter, tief verschachtelte Ordner oder automatisch erzeugte Slugs, und jedes davon ist einen Blick wert.

Seodisias kann alle fünf Checks ausführen. Es ist ein kostenloser Desktop-Crawler für Windows, macOS und Linux, mit JavaScript-Rendering, ohne URL-Limit und ohne Registrierung, und die Crawl-Daten bleiben auf Ihrem Rechner. Das Rendering ist hier wichtig, weil der Crawl dadurch Links und Canonicals sieht, die Skripte erst nach dem Laden der Seite einfügen.

Starten Sie mit einem vollständigen Crawl Ihrer Website und exportieren Sie die URL-Liste. Sortieren Sie sie dann nach Parameteranzahl und nach Weiterleitungssprüngen und beheben Sie in beiden Listen zuerst die schlimmsten Cluster.

Suchen Sie etwas anderes?

Durchsuchen Sie alle Beiträge, ohne zur Übersicht zurückzukehren.