Website-Architektur für Crawling und Indexierung

Eine gute Website-Architektur hilft Menschen und Crawlern, Inhalte zu finden, einzuordnen und wieder aufzurufen. Sie besteht nicht aus einer magischen maximalen Klicktiefe. Entscheidend ist, dass wichtige kanonische URLs über stabile HTML-Links erreichbar sind, ähnliche Inhalte logisch gruppiert werden und technische Varianten keine unbegrenzten URL-Räume erzeugen.

Die Architektur löst dabei drei unterschiedliche Aufgaben:

1. Entdeckung: Ein Crawler findet eine URL über interne Links oder eine Sitemap.
2. Crawling: Der Server erlaubt und beantwortet den Abruf zuverlässig.
3. Indexierung: Die Suchmaschine bewertet Inhalt, Canonical, Qualität und weitere Signale.

Eine URL in der Sitemap ist deshalb nicht automatisch indexiert. Ebenso behebt robots.txt keine Qualitäts- oder Canonical-Probleme.

Von Nutzeraufgaben zu Seitenhierarchie

Beginnen Sie nicht mit URL-Ordnern, sondern mit den Aufgaben, die die Website erfüllen soll. Ein B2B-Angebot könnte zum Beispiel so strukturiert sein:

• Leistungen
  • individuelle Softwareentwicklung
  • Datenplattformen
  • DevOps
• Branchen
  • Fintech
  • Gesundheitswesen
• Wissen
  • Performance
  • Softwarearchitektur
  • Compliance

Jede Ebene braucht eine eigene Funktion. Eine Hub-Seite sollte Orientierung geben, Unterthemen verbinden und auf die wichtigsten Detailseiten führen. Sie sollte nicht nur eine Liste von Links sein und nicht denselben Suchintent wie alle Detailseiten wiederholen.

Klicktiefe als Diagnose, nicht als Dogma

Wichtige Seiten sollten ohne unnötige Umwege erreichbar sein. Eine starre Regel wie „jede Seite in höchstens drei Klicks“ passt aber nicht zu jedem Produktkatalog oder Wissenssystem. Relevanter sind diese Fragen:

• Ist die Seite von einem passenden Hub aus verlinkt?
• Gibt es Sackgassen oder verwaiste URLs?
• Spiegelt der Pfad die Nutzerlogik wider?
• Erhalten neue oder geschäftskritische Inhalte sichtbare Einstiege?
• Bleibt die Navigation auch mobil und ohne clientseitige Interaktion crawlbar?

Ein Crawl-Graph kann Tiefe, eingehende Links und isolierte Bereiche sichtbar machen. Die Zahl allein entscheidet nicht, ob eine Seite wichtig oder indexierbar ist.

Interne Links als Navigations- und Kontextsystem

Suchmaschinen entdecken Links am zuverlässigsten als <a>-Element mit auflösbarem href. Buttons, klickbare <div>-Elemente oder reine JavaScript-Handler sind kein gleichwertiger Ersatz.

Ein belastbares System kombiniert:

• Hauptnavigation für zentrale Bereiche,
• Breadcrumbs für die Hierarchie,
• kontextuelle Links im Inhalt,
• Hub- und Übersichtsseiten,
• gezielte „Weiterlesen“-Links, wenn sie wirklich thematisch passen.

Es gibt keine allgemeingültige optimale Anzahl interner Links. Zusätzliche Links „verwässern“ nicht automatisch einen festen SEO-Wert. Sie können aber Navigation und Bedeutung unklar machen, wenn jede Seite wahllos auf alles verweist. Verlinken Sie deshalb nach Nutzerbedarf und thematischer Beziehung.

Anchor-Texte verständlich formulieren

Der Linktext sollte Ziel und Kontext benennen. „Mehr erfahren“ ist in einer Kartenliste manchmal verständlich, im Fließtext aber schwächer als „Core-Web-Vitals-Audit“. Variieren Sie Linktexte natürlich; eine künstliche Wiederholung exakter Keywords ist nicht nötig.

Orphan Pages finden

Vergleichen Sie mindestens vier URL-Quellen:

1. intern gecrawlte URLs,
2. XML-Sitemap,
3. Analytics- oder Serverlog-URLs,
4. indexierte beziehungsweise in Search Console bekannte URLs.

Eine URL, die nur in der Sitemap vorkommt, ist technisch nicht zwingend unsichtbar, besitzt aber keinen normalen Navigationspfad. Entscheiden Sie: sinnvoll intern verlinken, zusammenführen, noindex setzen oder entfernen.

Crawl-Fallen und unbegrenzte URL-Räume vermeiden

Große Risiken entstehen, wenn Funktionen nahezu unendlich viele crawlbare Varianten erzeugen:

• Filter und Sortierungen in beliebiger Kombination,
• interne Suchergebnisse,
• Kalender mit unbegrenzter Vor- und Rückwärtsnavigation,
• Session- oder Tracking-Parameter,
• facettierte Navigation,
• Endlosscrollen ohne crawlbare Pagination,
• fehlerhafte relative Links, die Pfade vervielfachen.

Die Lösung beginnt in der Anwendung: Nur nützliche, stabile Zustände sollten eigenständige indexierbare URLs erzeugen. Nicht jede Filterkombination braucht einen Link, eine Sitemap-Aufnahme oder einen Canonical auf sich selbst.

Mögliche Maßnahmen sind:

• Parameter in der Linkgenerierung vermeiden,
• wertvolle Filter-Landingpages explizit definieren,
• unwichtige Varianten nicht intern verlinken,
• Duplikate konsistent kanonisieren,
• endlose Komponenten durch echte paginierte Links ergänzen,
• gelöschte Zustände mit 404 oder 410 beantworten.

robots.txt sollte nicht die erste Reparatur für ein unkontrolliertes URL-Modell sein. Sonst bleiben Varianten intern verlinkt, können aber nicht mehr gecrawlt und bewertet werden.

XML-Sitemaps richtig einsetzen

Eine Sitemap unterstützt die Entdeckung und nennt URLs, die der Betreiber als kanonisch betrachtet. Google betont, dass sie nur ein Hinweis ist und keine Indexierung garantiert.

Eine saubere Sitemap enthält:

• absolute, kanonische URLs,
• nur indexierbare Seiten mit erfolgreichem Status,
• keine Redirects, 404-Seiten oder noindex-URLs,
• korrekte Sprachvarianten, wenn das Format dafür genutzt wird,
• ein <lastmod> nur nach einer wesentlichen Änderung.

Google verwendet <lastmod>, wenn der Wert konsistent und überprüfbar korrekt ist. Ein täglich aktualisiertes Datum ohne Inhaltsänderung entwertet das Signal. Die offizielle Anleitung zum Erstellen und Einreichen einer Sitemap beschreibt außerdem die Größenlimits und Sitemap-Indizes.

Für kleinere, gut intern verlinkte Websites ist eine Sitemap nützlich, aber keine Kompensation für eine kaputte Navigation.

robots.txt, noindex und Zugriffsschutz unterscheiden

Diese Mechanismen lösen verschiedene Aufgaben:

Eine per robots.txt blockierte URL kann laut Google weiterhin ohne Inhalts-Snippet in Ergebnissen erscheinen, wenn externe oder interne Links auf sie zeigen. Google kann außerdem ein noindex auf einer blockierten Seite nicht sehen. Um eine öffentliche Seite aus dem Index zu halten, muss der Bot sie abrufen und das noindex lesen können. Vertrauliche Inhalte gehören hinter Authentifizierung, nicht nur in eine Robots-Datei.

Die offizielle Einführung in robots.txt empfiehlt die Datei vor allem zur Steuerung von Crawler-Traffic, nicht als Geheimhaltungs- oder Indexierungswerkzeug.

Canonicals und Duplikate konsistent behandeln

Doppelte oder sehr ähnliche Inhalte entstehen durch Protokoll- und Hostvarianten, Parameter, Druckansichten, Produktzuordnungen oder Testumgebungen. Google wählt letztlich selbst eine kanonische URL; Betreiber können eine Präferenz signalisieren.

Google ordnet die Signale grob so ein:

• permanente Redirects: stark,
• rel="canonical": stark,
• Aufnahme in die Sitemap: schwach.

Kombinieren Sie Signale konsistent:

• interne Links zeigen auf die kanonische URL,
• die Sitemap enthält dieselbe URL,
• Canonicals sind selbstreferenziell und absolut,
• hreflang verweist auf kanonische Sprachseiten,
• alte oder unnötige Varianten redirecten direkt zum endgültigen Ziel.

Ein Canonical ist kein sicherer Löschmechanismus und sollte auf wirklich doppelte oder sehr ähnliche Inhalte zeigen. Google kann widersprüchliche oder unplausible Angaben ignorieren. Details stehen in der offiziellen Dokumentation zur Kanonisierung doppelter URLs.

Statuscodes, Redirects und Soft 404

Architektur ist auch Serververhalten:

• 200 für eine erfolgreiche Seite,
• 301 oder 308 für eine dauerhafte Verschiebung,
• 302 oder 307 für eine tatsächlich vorübergehende Umleitung,
• 404 oder 410 für nicht vorhandene Inhalte,
• 5xx für einen vorübergehenden Serverfehler.

Eine Fehlerseite mit 200 kann als Soft 404 erkannt werden. Lange Redirect-Ketten erhöhen Latenz und erschweren Wartung. Redirecten Sie alte URLs möglichst direkt auf das inhaltlich passende Endziel und vermeiden Sie Umleitungen auf die Startseite, wenn es keinen Ersatz gibt.

Crawl Budget realistisch einordnen

Googles ausführliche Crawl-Budget-Hinweise richten sich an sehr große oder häufig aktualisierte Websites. Ein normaler Unternehmensblog mit einigen hundert sauberen URLs braucht meist kein eigenes Crawl-Budget-Projekt. Hier sind Content-Qualität, interne Links, Statuscodes und konsistente Canonicals wichtiger.

Bei großen Plattformen lohnt eine Log- und Crawl-Analyse. Prüfen Sie:

• wie viele Requests auf Parameter und Duplikate entfallen,
• ob 5xx und langsame Antworten die Crawl-Kapazität begrenzen,
• ob aktualisierte wichtige Seiten regelmäßig abgerufen werden,
• ob Serverkapazität und Cache stabil sind.

Mehr Geschwindigkeit allein erzwingt keine Indexierung. Google erklärt in seinem Crawl-Budget-Leitfaden, dass Crawl-Kapazität und Crawl-Nachfrage gemeinsam wirken und gecrawlte Seiten anschließend trotzdem bewertet werden.

Architektur-Audit: praktische Prüfliste

• Jede indexierbare Kernseite ist über einen normalen internen Link erreichbar.
• Hubs und Detailseiten haben klar getrennte Aufgaben.
• Navigation und Links funktionieren auch mobil und im gerenderten HTML.
• Filter, Suche und Parameter erzeugen keinen unbegrenzten URL-Raum.
• Die Sitemap enthält nur kanonische, indexierbare 200-URLs.
• <lastmod> entspricht einer wesentlichen tatsächlichen Änderung.
• robots.txt, noindex, Auth und Canonical werden nicht verwechselt.
• Interne Links, Sitemap, Canonical und hreflang sind konsistent.
• Alte URLs redirecten ohne Kette auf ein passendes Ziel.
• Nicht vorhandene Inhalte liefern 404 oder 410.
• Log- und Crawl-Budget-Analyse wird nur bei passender Seitengröße priorisiert.

Fazit

Crawl-Effizienz entsteht nicht durch eine einzelne Sitemap oder Robots-Regel. Sie ist das Ergebnis eines begrenzten URL-Modells, sinnvoller Hubs, crawlbarer interner Links, konsistenter Canonicals und korrekter Serverantworten.

Die beste Architektur macht Prioritäten für Menschen verständlich und für Crawler technisch überprüfbar. Wo beides auseinanderfällt, sollte zuerst die Informations- und URL-Logik repariert werden — nicht nur der nächste SEO-Tag ergänzt werden.