Technische SEO optimieren: Crawling, Indexierung und Core Web Vitals

Eine schnelle Website kann unsichtbar bleiben. Der Server kann sauber antworten, während robots.txt den Abruf sperrt. Eine Seite kann rendern, aber per noindex aus dem Index fallen. Google kann außerdem eine andere URL als kanonische Hauptversion wählen.

Technische Suchmaschinenoptimierung, kurz technische SEO, beginnt deshalb vor der Performance. Core Web Vitals sind eine technische Ebene. Dieser Guide zeigt, wie Sie Erreichbarkeit, Crawling, Rendering und Indexierung getrennt prüfen. Danach priorisieren Sie Performance und spezielle AI-Abrufwege auf einer funktionierenden Grundlage.

Neue Analysen und Anleitungen

Das Wichtigste in Kürze

• Technische SEO hält relevante Inhalte erreichbar, crawlbar, verarbeitbar und eindeutig zuordenbar. Relevanz oder Autorität erzeugt sie nicht automatisch.
• Core Web Vitals messen reale Nutzererfahrung bei Laden, Interaktion und visueller Stabilität. Sie ersetzen keine Prüfung von Crawling und Indexierung.
• robots.txt, noindex, Canonicals und XML-Sitemaps erfüllen verschiedene Aufgaben. Eine Crawling-Regel ist keine verlässliche De-Indexierungsregel.
• Crawlbudget wird vor allem bei sehr großen Websites oder häufig geänderten Beständen strategisch. Kleine Websites haben meist konkretere Blocker.
• Technischer Zugriff ist eine Voraussetzung für Rankings, Retrieval oder Zitate. Er garantiert keines dieser Ergebnisse.
• llms.txt ist ein vorgeschlagenes Zusatzformat. Die Datei ersetzt weder crawlbares HTML noch etablierte Suchmaschinensteuerung.

Was ist technische SEO?

Technische SEO ist die Arbeit an der Infrastruktur, über die Suchsysteme URLs entdecken, abrufen, verarbeiten, zuordnen und ausspielen. Google beschreibt die Kernphasen als Crawling, Indexierung und Ausspielung. Discovery, Rendering und Canonicalization sind nützliche Arbeitsschritte innerhalb dieses Modells, keine zusätzlichen offiziellen Google-Phasen. Das zeigt die Google-Dokumentation zur Funktionsweise der Suche.

Für die praktische Arbeit hilft eine feinere Trennung:

1. Discovery: Ein System findet eine URL über Links oder eine Sitemap.
2. Crawling: Ein Crawler ruft die URL und benötigte Ressourcen ab.
3. Rendering: Das System verarbeitet HTML, CSS und JavaScript zu einem auswertbaren Dokument.
4. Canonicalization: Das System ordnet ähnliche URLs einer bevorzugten Hauptversion zu.
5. Indexierung: Das System analysiert und speichert Inhalte für mögliche Suchanfragen.
6. Serving oder Retrieval: Ein System verwendet eine Quelle für eine konkrete Anfrage oder Antwort.

Technische SEO erzeugt keine fachliche Substanz. Sie verhindert, dass vorhandene Substanz an Infrastrukturfehlern scheitert. Content-SEO klärt, welche Frage eine Seite beantwortet. Offpage-Signale entstehen außerhalb der Seite. Schema Markup beschreibt Entitäten und Beziehungen; die vollständige Methode steht im Guide zu Entity Maps und JSON-LD.

Core Web Vitals: wichtig, aber nicht immer der erste Hebel

Core Web Vitals messen reale Nutzererfahrung in drei Bereichen: Ladeleistung, Reaktionsfähigkeit und visuelle Stabilität. Google führt Largest Contentful Paint, Interaction to Next Paint und Cumulative Layout Shift als aktuelle Metriken. Gute Werte werden am 75. Perzentil der Felddaten beurteilt. Die Schwellenwerte dokumentieren Google Search Central und web.dev.

Metrik	Misst	„Gut“ am 75. Perzentil
LCP, Largest Contentful Paint	Zeit bis zum größten sichtbaren Inhaltselement	höchstens 2,5 Sekunden
INP, Interaction to Next Paint	Reaktionszeit über Nutzerinteraktionen	höchstens 200 Millisekunden
CLS, Cumulative Layout Shift	unerwartete visuelle Verschiebungen	höchstens 0,1

INP hat First Input Delay im März 2024 ersetzt. Prüfen Sie mobile und Desktop-Daten getrennt. Unterschiedliche Geräte, Netze und Templates können zu verschiedenen Ergebnissen führen.

Felddaten sind nicht dasselbe wie Labordaten

Der Chrome User Experience Report, kurz CrUX, enthält anonymisierte Felddaten realer Chrome-Nutzer über ein rollierendes Zeitfenster. PageSpeed Insights zeigt verfügbare Felddaten und ergänzt sie um eine Laboranalyse. Lighthouse simuliert einen einzelnen Lauf unter festgelegten Bedingungen. Das macht Lighthouse nützlich für die Fehlersuche, aber nicht zum Ersatz für CrUX.

Ein schlechter Laborlauf kann eine konkrete Ursache sichtbar machen. Ein guter Laborlauf beweist noch nicht, dass reale Nutzer den Schwellenwert am 75. Perzentil erreichen. Umgekehrt kann eine einzelne langsame Sitzung existieren, obwohl die URL-Gruppe insgesamt als „gut“ gilt.

Core Web Vitals gehören zur Page Experience. Google warnt zugleich vor einer falschen Kausalität: Eine gute Page Experience ersetzt keinen relevanten Inhalt. Perfekte Werte garantieren weder Indexierung noch eine bestimmte Position. Diese Grenze steht ausdrücklich in der Google-Einordnung zu Core Web Vitals und Suchergebnissen.

Die Reihenfolge bleibt deshalb nüchtern:

1. Antwortet die URL zuverlässig?
2. Darf ein Crawler sie abrufen?
3. Liefert sie den richtigen HTTP-Status?
4. Ist der Hauptinhalt im gerenderten Dokument vorhanden?
5. Ist die gewünschte URL indexierbar und kanonisch konsistent?
6. Erst danach optimieren Sie LCP, INP und CLS.

Core Web Vitals optimieren damit die Erfahrung auf einer Seite, die Systeme bereits erreichen und verarbeiten können. Der nächste Abschnitt zeigt, über welche technischen Wege Such- und AI-Systeme dorthin gelangen.

Von der URL bis zur Sichtbarkeit: die technische Verarbeitungskette

Eine URL durchläuft nicht automatisch eine universelle Kette. Google Search und AI-Systeme dokumentieren verschiedene Abrufwege. Für Google Search sind Crawling, Indexierung und Serving die offiziellen Phasen. AI-Anbieter können eigene Suchbots einsetzen, nutzerinitiierte Abrufe ausführen oder externe Suchindizes verwenden.

FIG 01 · ZWEI TECHNISCHE WEGE

Das Schema trennt sechs Fragen. Discovery fragt nach dem Fundweg. Crawling prüft den Abruf. Rendering prüft den verarbeiteten Inhalt. Canonicalization ordnet ähnliche URLs. Indexierung entscheidet über die Aufnahme in einen Suchindex. Serving oder Retrieval betrifft erst eine konkrete Anfrage.

Ein Fehler früh in der Kette lässt spätere Optimierungen ins Leere laufen. Ein erfolgreicher Abruf beweist aber nicht, dass die Quelle indexiert oder zitiert wird. Genau diese Trennung vertieft der Guide zu LLM Retrieval Gaps.

200 OK, Retrieval und Citation: drei verschiedene Messpunkte

Ein erfolgreicher Download durch einen AI-Bot bestätigt technischen Zugriff. Er belegt weder die Aufnahme in einen Such- oder Vektorindex noch Retrieval für einen Prompt oder eine sichtbare Citation. Genau deshalb trenne ich Serverlogs, Retrieval-Daten und die Antwortoberfläche in meinen Messungen.

Meine Datengrundlage umfasst acht laufende B2B-Sichtbarkeitsprojekte, anonymisiert als P1 bis P8. Die Projekte stammen aus Logistik und Fulfillment, industrieller Fertigung, Finanz- und Pensionsthemen sowie Tourismus und Bahn. Das Messfenster reicht vom 18. Juni bis 17. Juli 2026. Peec.ai erfasste ChatGPT, Perplexity und Google AI Overview mit ungefähr 1.200 bis 2.000 Quelldomains je Projekt.

Die Definition ist entscheidend: Retrieval bezeichnet in Peec.ai ein Ereignis, bei dem eine URL für einen getrackten Prompt in den RAG-Kontext der Engine gelangt. Die Kennzahl bildet keinen Crawl aus dem Serverlog ab. Die Retrieval-to-Citation-Conversion ist der Anteil der abgerufenen Domains, die im Messfenster mindestens einmal sichtbar zitiert wurden.

Über alle Beobachtungen lag diese Conversion bei 55,6 Prozent. Nach Engine unterschieden sich die Werte deutlich: Google AI Overview erreichte im Mittel über die acht Projekte 76,8 Prozent, Perplexity 47,7 Prozent und ChatGPT 40,9 Prozent. Das Muster trat in allen acht Projekten auf. Der Zusammenhang zwischen Engine und Citation war der stärkste statistische Effekt der Auswertung (χ² ≈ 1.772, Cramér’s V ≈ 0,32).

Zwei weitere Befunde begrenzen jede pauschale Empfehlung:

• Die zitierten Quellenpools der Engines überschnitten sich je Projekt und Engine-Paar nur mit einem Jaccard-Index von 0,12 bis 0,21.
• Der Quellentyp hing schwächer mit der Citation zusammen. Redaktionelle Quellen standen bei ChatGPT am Ende und bei Perplexity an der Spitze. Innerhalb der Engines lag Cramér’s V bei ungefähr 0,085 für ChatGPT und 0,123 für Perplexity. Bei Google AI Overview war der Zusammenhang im Datensatz nicht signifikant (p ≈ 0,08).

Das Ergebnis trägt einen klaren Autorensatz: Retrieval ist notwendig und reicht allein nicht aus. Einen universell zitierfähigen Content-Typ zeigen diese Daten ebenfalls nicht. Die vollständige Methodik, Tabellen und Grenzen stehen im offenen Working Paper The Retrieval-to-Citation Funnel in AI Search und im Beitrag Drei Engines, drei fast getrennte Quellenpools.

Ein einzelner Projektschnitt zeigt, warum die Ebenen getrennt bleiben müssen. Bei einem Anbieter industrieller Beschichtungen lag der plattformseitige Kennwert Retrieval Rate für die eigene Domain bei 0,16 und die Citation Rate bei 1,2. Ein B2B-Lieferantenverzeichnis kam auf 0,39 beziehungsweise 1,1 und war damit die meistabgerufene Quelle des gesamten Datensatzes. Zwei Fachwettbewerber lagen bei der Retrieval Rate zwischen 0,25 und 0,32. Diese Peec.ai-Kennwerte sind keine Prozentwerte und nicht mit der oben definierten Conversion gleichzusetzen.

Meine Arbeitshypothese für diesen Fall: Das Verzeichnis bietet mehr klar getrennte, maschinenlesbare Einheiten als die kompakte Anbieterwebsite. Die Messung zeigt den Abstand. Sie beweist seine Ursache nicht. Dafür braucht es den Abgleich mit Seitenstruktur, internem Linkgraphen, HTML und den Retrieval-Daten nach einer Änderung.

Robots.txt, HTTP-Statuscodes und JavaScript: Kann ein Crawler die Seite erreichen?

Technische Erreichbarkeit beginnt mit einer stabilen HTTP-Antwort, einer passenden Crawling-Regel und einem auswertbaren Dokument. Statuscode, robots.txt und Rendering beantworten verschiedene Fragen. Prüfen Sie die Ebenen getrennt.

HTTP-Statuscodes

Ein HTTP-Statuscode beschreibt das Ergebnis eines Requests. Für technische SEO reicht es nicht, nur „erreichbar“ oder „nicht erreichbar“ zu unterscheiden.

• 2xx: Der Server hat den Request erfolgreich verarbeitet. Ein 200 OK mit leerem Hauptinhalt ist trotzdem kein Erfolg für die Seite.
• 3xx: Der Server leitet auf eine andere URL weiter. Lange Ketten und Schleifen verzögern oder verhindern das Erreichen des Ziels.
• 4xx: Der Request ist auf Clientseite nicht erfüllbar. 404 und 410 kennzeichnen fehlende Ressourcen. 429 Too Many Requests signalisiert eine Überlastung oder Begrenzung.
• 5xx: Der Server konnte einen gültigen Request nicht erfüllen. Wiederholte Serverfehler veranlassen Google, das Crawling zu verlangsamen.

Google dokumentiert die Behandlung von Statuscodes in der Übersicht zu HTTP-Statuscodes sowie Netzwerk- und DNS-Fehlern. Ein Soft 404 liegt vor, wenn eine URL formal erfolgreich antwortet, der Inhalt aber eine Fehlerseite oder faktisch leere Seite darstellt. Der Statuscode und die tatsächliche Seitenaussage widersprechen sich dann.

Für die ausführliche Einordnung von Statuscodes und Crawlbudget lesen Sie den Beitrag Crawl Budget und HTTP-Statuscodes.

Wenn WAF und Bot Protection vor robots.txt entscheiden

Eine Web Application Firewall kann einen AI-Abruf am Edge mit 403 oder 429 stoppen, bevor der Request robots.txt oder den Origin erreicht. Eine Allow-Direktive löst diesen Fehler nicht. Zuerst muss die Schutzschicht den verifizierten Client passieren lassen.

In einem B2B-Projekt lagen Hauptseite und Dokumentations-Subdomain auf getrennten Vercel-Projekten. Der Kunde vermutete eine falsche robots.txt. Der reproduzierbare Befund lag eine Ebene früher: Der erste nicht browserbasierte Request erhielt HTTP 429 und den Header x-vercel-mitigated: challenge. In diesem Fall kennzeichnete der Code eine Edge-Challenge, kein mengenbasiertes Rate Limit nach vielen Requests.

Ich testete Chrome-, Googlebot-, GPTBot-, ClaudeBot- und PerplexityBot-User-Agents per curl aus einem Rechenzentrumsnetz. Alle Varianten erhielten zunächst dieselbe Challenge. Das beweist, dass ein ausgetauschter User-Agent aus diesem IP-Kontext keinen Bypass auslöste. Es beweist noch nicht, dass ein echter, über seine Anbieter-IP verifizierter Crawler genauso behandelt wird. Der Google Search Console Live Test kam durch; Google-InspectionTool wurde in diesem Setup also anders behandelt.

Die diagnostische Signatur war eindeutig:

HTTP/2 429
server: Vercel
x-vercel-mitigated: challenge
x-vercel-challenge-token: …

Der Fehler trat zeitweise auf. Cache-Misses auf zufälligen, nicht cachebaren Pfaden reproduzierten ihn an einem Vercel Point of Presence, später verschwand er. Requests aus einem anderen IP-Kontext kamen durch. Ein einzelner grüner Test schließt einen intermittierenden Edge-Block deshalb nicht aus. Test-IP, PoP, Cache-Status, Uhrzeit und Response-Header gehören ins Protokoll.

„Keine benutzerdefinierten WAF-Regeln“ ist dabei keine Entwarnung. Vercel führt Bot Protection, Attack Mode und weitere Managed Rulesets getrennt von Custom Rules. Die Vercel-Dokumentation zu Bot Management bestätigt, dass Bot Protection nicht browserbasierten Traffic per JavaScript-Challenge prüfen kann und verifizierte Bots gesondert behandelt. Für vertrauenswürdige Automation unterstützt Vercel vorgelagerte WAF-Regeln mit bypass-Aktion.

Der technische Fixplan umfasst vier Schritte:

1. Eine vorgelagerte Bypass-Regel für die benötigten, verifizierten AI-Crawler einrichten.
2. Prüfen, ob die Verified-Bot-Liste alle benötigten Search-Bots und User-Fetcher abdeckt. OpenAI verlinkt die IP-Feeds für OAI-SearchBot, GPTBot und ChatGPT-User. Anthropic veröffentlicht die eigenen Bereiche unter bots.json.
3. Rate-Limit-Regeln auf 429 für legitime Rechenzentrumsbereiche prüfen.
4. Danach robots.txt ergänzen und die Sitemap-Zeile der Dokumentations-Subdomain korrigieren.

Das Abnahmekriterium lautet: Verifizierte, gewünschte AI-Crawler erhalten auf öffentlichen Seiten 200 OK; der Anteil ihrer 4xx-Antworten bleibt im Log unter einem Prozent. Ein zweiter B2B-Fall mit einem anderen WAF lieferte 403 statt 429. Der Code variiert, die Prüflogik bleibt gleich.

Nach dem Bypass zeigte sich die nächste Schicht: FAQ-Antworten lagen nur in clientseitigen Daten und erschienen erst nach einem Klick. Nicht rendernde Crawler erhielten zwar 200, sahen aber keine Antworten im DOM. WAF-Freigabe repariert Zugriff. Server Rendering oder statisch vorhandenes HTML repariert die Auslesbarkeit.

Branchenkontext, keine Kundendaten: Vercel und MERJ berichten für die von ihnen untersuchten großen AI-Crawler, dass keiner JavaScript renderte; Gemini nutzte dagegen Googlebot-Infrastruktur. Das ist eine Anbieteranalyse mit eigenem Messnetz, keine universelle Quote. Eine häufig zitierte Angabe von 69 Prozent ließ sich in der Primärquelle nicht bestätigen und bleibt deshalb hier außen vor. ZipTie verweist auf eine ParseAI-Stichprobe von ungefähr 3.000 überwiegend US- und UK-Websites: 27 Prozent blockierten mindestens einen großen LLM-Crawler, überwiegend auf CDN- oder WAF-Ebene. Die Rohdaten waren für diesen Guide nicht unabhängig prüfbar; ich verwende den Wert nicht als Benchmark.

Robots.txt

Die robots.txt steuert den Abruf durch benannte User-Agents. Die Internet Engineering Task Force standardisierte das Robots Exclusion Protocol als RFC 9309. Eine Sperre in robots.txt ist keine verlässliche Anweisung zur De-Indexierung. Google kann eine gesperrte URL anhand externer Signale kennen und ohne gelesenen Seiteninhalt indexieren.

Das führt zu einem häufigen Konflikt: Eine Seite enthält noindex, während robots.txt ihren Abruf blockiert. Der Crawler erreicht dann die noindex-Anweisung nicht. Google erklärt diese Trennung in der Dokumentation zu robots.txt und zur Blockierung der Indexierung.

Prüfen Sie Regeln pro User-Agent. Prüfen Sie außerdem, ob notwendige CSS- oder JavaScript-Ressourcen blockiert sind. Ein freigegebenes HTML-Dokument kann falsch gerendert werden, wenn entscheidende Ressourcen fehlen.

JavaScript und Rendering

Der Quelltext und das gerenderte Document Object Model (DOM) können unterschiedliche Inhalte enthalten. Das wird kritisch, wenn Überschrift, Haupttext oder interne Links erst nach einer fehlgeschlagenen Client-Anfrage erscheinen.

Google kann JavaScript verarbeiten. Das ist keine Freigabe für beliebige Abhängigkeiten. Die Google-Grundlagen zu JavaScript-SEO empfehlen crawlbare Links als echte <a href="…">-Elemente. Rein clientseitige Navigation ohne zugängliche Ziel-URL erschwert Discovery.

Vergleichen Sie deshalb drei Zustände: die HTTP-Antwort, den gerenderten DOM und den sichtbaren Hauptinhalt. Die URL-Prüfung in der Google Search Console zeigt, was Google bei einem Live-Test abrufen und rendern kann. Ein erfolgreicher Fetch ohne Hauptinhalt bleibt ein Rendering-Problem.

XML-Sitemap, Canonical und Noindex: Welche URL soll indexiert werden?

XML-Sitemap, Canonical und noindex steuern verschiedene Teile der URL-Verarbeitung. Die Sitemap unterstützt Discovery. Das Canonical signalisiert eine bevorzugte Hauptversion. noindex weist einen Crawler an, eine abrufbare Seite nicht in Suchergebnissen zu zeigen.

XML-Sitemap

Das Sitemaps-Protokoll definiert das XML-Format. Google behandelt eine Sitemap als Hinweis, nicht als Indexierungsgarantie. Nehmen Sie bevorzugte, indexierbare URLs auf, die erfolgreich antworten. Weiterleitungen, Fehlerseiten und per noindex ausgeschlossene Seiten widersprechen diesem Zweck.

Ein Sitemap-Index verteilt größere URL-Sets auf mehrere Dateien. Eine fachliche Segmentierung nach Seitentyp oder Bereich erleichtert die Diagnose in der Search Console. Das Feld lastmod sollte eine wesentliche Änderung des Seiteninhalts abbilden. Ein bei jedem Build erneuerter Zeitstempel liefert kein belastbares Änderungssignal. Google fasst diese Regeln in der Sitemap-Dokumentation zusammen.

Canonical

Ein Canonical signalisiert die bevorzugte URL innerhalb einer Gruppe gleicher oder sehr ähnlicher Seiten. Google behandelt dieses Signal nicht als absolute Anweisung. Interne Links, Weiterleitungen und Sitemap-Einträge sollten dieselbe Hauptversion stützen.

Ein Canonical auf eine Fehlerseite ist kein sinnvolles Konsolidierungssignal. Dasselbe gilt für ein Ziel mit fachlich anderem Hauptinhalt. Prüfen Sie bei Abweichungen sowohl das deklarierte Canonical als auch das von Google gewählte Canonical. Die offizielle Grundlage steht unter Duplicate URLs konsolidieren.

Noindex

noindex steht als Meta-Robots-Anweisung im HTML-head oder als X-Robots-Tag im HTTP-Header. Ein Crawler muss die Anweisung abrufen können. Eine gleichzeitige Sperre in robots.txt verhindert genau diese Prüfung.

Verwenden Sie noindex für URLs, die erreichbar bleiben sollen, aber nicht in Suchergebnissen erscheinen sollen. Verwenden Sie robots.txt, wenn ein Bot bestimmte Pfade nicht abrufen soll. Die beiden Mechanismen sind nicht austauschbar.

Indexierungsstatus bei Google prüfen

Die URL-Prüfung der Google Search Console zeigt den bekannten Indexierungsstatus einer einzelnen URL und erlaubt einen Live-Test. Der Bericht zur Seitenindexierung gruppiert größere Mengen nach Gründen.

Trennen Sie dabei mindestens diese Fälle:

• Gefunden, zurzeit nicht indexiert: Google kennt die URL, hat sie aber noch nicht gecrawlt.
• Gecrawlt, zurzeit nicht indexiert: Google hat die URL abgerufen, aber nicht in den Index aufgenommen.
• Duplikat oder alternative Seite: Google ordnet die URL einer anderen Hauptversion zu.
• Durch noindex ausgeschlossen: Google konnte die Anweisung lesen und folgt ihr.

Der Bericht liefert eine Diagnosekategorie, keine automatische Ursachenanalyse. Prüfen Sie interne Verlinkung, Canonical-Signale und den tatsächlichen Hauptinhalt gemeinsam.

SOP: „Gecrawlt, zurzeit nicht indexiert“ diagnostizieren

Der Status „Gecrawlt, zurzeit nicht indexiert“ bestätigt einen Google-Abruf, erklärt aber nicht die Ursache der fehlenden Indexierung. Behandeln Sie den Status als Clusterdiagnose. Eine einzelne URL-Prüfung reicht bei großen Templates nicht.

Mein Ablauf verbindet fünf Datenquellen: Export des Page-Indexing-Berichts, Crawl Stats nach Antwortcode, Dateityp, Googlebot-Typ, Zweck und Host, einen vollständigen Screaming-Frog-Crawl, eine GA4-Auswertung für sehr schwach genutzte URLs und Live-Tests ausgewählter Statuscodes.

1. Status sauber trennen. Exportieren Sie „Gecrawlt, zurzeit nicht indexiert“ getrennt von „Duplikat, Google hat eine andere kanonische Seite gewählt“. Der erste Status beschreibt einen Abruf ohne Indexaufnahme. Der zweite zeigt eine Canonical-Auswahl.
2. Click Depth messen. Ermitteln Sie die kürzeste Linkdistanz von indexierbaren Hubs und prüfen Sie, ob wichtige URLs nur tief oder über Parameterpfade erreichbar sind. Abschlusskriterium: Die interne Fundstelle jeder strategischen URL ist bekannt.
3. Inhaltsvolumen und Eigenwert prüfen. Vergleichen Sie Hauptinhalt, Titel, H1, Produktdaten und interne Links innerhalb des Templates. Dünne oder nahezu identische Seiten werden als Cluster bewertet, nicht einzeln umformuliert.
4. Dubletten und Canonicals validieren. Gruppieren Sie URL-Varianten nach Inhalt, Parameter und deklarierter Hauptversion. Vergleichen Sie rel=canonical, Sitemap, interne Links und das von Google gewählte Canonical.
5. Internen PageRank verteilen. Berechnen Sie den Link Score im Crawl und vergleichen Sie indexierte mit nicht indexierten URLs desselben Templates. Prüfen Sie, ob Navigation und redaktionelle Hubs die strategischen Seiten stärken oder Linkgewicht in Filter, Suche und Sitzungs-URLs schicken.
6. Mit Logs und Live-Probes abschließen. Prüfen Sie reale Googlebot-Requests, Antwortcodes und Hostverteilung. Ein Live-Test bestätigt den Zustand der Stichprobe; Crawl Stats zeigen das wiederkehrende Muster.

Die Diagnose endet mit einer Entscheidung pro Cluster: technischer Blocker, Canonical-Konflikt, schwacher oder doppelter Inhalt, zu geringe interne Priorität oder bewusster Ausschluss. Erst danach folgt eine Maßnahme. Mehr Text hilft einer unerreichbaren URL nicht. Ein neues Canonical repariert keinen dünnen Seitentyp.

Für die meisten Websites bleibt Crawlbudget nach Googles eigener Einordnung ein Spezialthema. In einem Bestand mit mehreren Millionen ausgeschlossenen URLs wird die Unterscheidung real: „Gecrawlt, zurzeit nicht indexiert“ kann auf Qualität und Priorität verweisen, während ausufernde URL-Räume gleichzeitig Crawlkapazität binden. Beide Befunde können nebeneinander bestehen.

Hreflang: Welche Sprachversion gehört zu welchem Markt?

Hreflang kennzeichnet lokalisierte Varianten einer Seite für Sprache oder Region. Google nutzt die Angaben, um passende Versionen auszuliefern. Hreflang garantiert weder Indexierung noch eine bessere Position. Die Regeln dokumentiert Google unter lokalisierte Versionen einer Seite.

Sie können Hreflang im HTML, im HTTP-Header oder in einer XML-Sitemap angeben. Mischen Sie die Methoden nicht ohne Grund. Jede Variante verweist auf sich selbst und reziprok auf die anderen Varianten. Verwenden Sie vollständig qualifizierte URLs. x-default bezeichnet eine Fallback-Seite für Nutzer, auf die keine Sprach- oder Regionsangabe passt.

Ein kleines, illustratives Cluster kann so aussehen:

<link rel="alternate" hreflang="de" href="https://example.com/de/produkt/">
<link rel="alternate" hreflang="de-AT" href="https://example.com/at/produkt/">
<link rel="alternate" hreflang="de-CH" href="https://example.com/ch/produkt/">
<link rel="alternate" hreflang="en" href="https://example.com/en/product/">
<link rel="alternate" hreflang="x-default" href="https://example.com/product-selector/">

Das Beispiel ist kein universelles Copy-and-paste-Template. Eine reale Website braucht nur Varianten, die tatsächlich existieren und inhaltlich zur angegebenen Sprache oder Region passen. Jede der fünf Seiten müsste dasselbe vollständige Cluster ausgeben.

Canonical und Hreflang lösen verschiedene Probleme. Das Canonical bündelt gleiche oder sehr ähnliche URLs. Hreflang verbindet lokalisierte Varianten, die als eigene URLs indexierbar bleiben sollen. Ein Canonical von der österreichischen auf die deutsche Seite kann deshalb das Hreflang-Ziel unterlaufen.

Typische Fehler im DE-, AT-, CH- und EN-Cluster sind fehlende Rückverweise, relative URLs oder uneinheitliche Sprachcodes. Auch ein korrektes Cluster schafft keine Relevanz. Es ordnet vorhandene Versionen für die Ausspielung.

Wann Crawlbudget wirklich ein Problem ist

Crawlbudget ist die Menge an URLs, die Google crawlen kann und crawlen will. Google leitet das Budget aus Crawl Capacity Limit und Crawl Demand ab. Servergesundheit beeinflusst die Kapazität. Popularität und Aktualisierungsbedarf beeinflussen die Nachfrage. Die Definition steht in der offiziellen Dokumentation zum Crawlbudget.

Das Thema wird vor allem bei sehr großen Websites oder umfangreichen, häufig geänderten Beständen strategisch. Google nennt mindestens eine Million einzigartige URLs mit moderaten Änderungen als typischen Fall. Ab 10.000 einzigartigen URLs wird der Leitfaden relevant, wenn Inhalte täglich wechseln. Google bezeichnet diese Größenordnungen als grobe Orientierung, nicht als harte Grenzwerte. Eine kleine, stabil verlinkte Website braucht meist keine abstrakte Budgetkampagne.

Reale Budgetprobleme entstehen oft durch ausufernde URL-Räume:

• Facettennavigation erzeugt Kombinationen aus Filtern und Sortierungen.
• Parameter legen mehrere URLs für denselben oder sehr ähnlichen Inhalt an.
• Kalender und interne Suchergebnisse können nahezu endlose Pfade erzeugen.
• Serverfehler oder langsame Antworten reduzieren die sichere Abrufkapazität.

Der Crawl-Statistikbericht der Search Console zeigt Requests, Hoststatus und Antwortmuster. Serverlogs zeigen zusätzlich, welche URLs ein verifizierter Bot tatsächlich angefordert hat. Beides beantwortet andere Fragen als eine normale SEO-Crawl-Simulation.

Bei kleinen Websites liegen die ersten Hebel meist früher: wichtige Seiten fehlen in der internen Verlinkung, Indexierungsregeln widersprechen sich oder der Hauptinhalt ist zu schwach. Erst wenn diese Punkte sauber sind und ein großer URL-Raum vorliegt, wird Crawlbudget zur eigenen Priorität.

Praxisfall: 4,38 Millionen ausgeschlossene URLs und ein offener Parameterraum

Auf einem großen industriellen B2B-Auftritt war Crawlbudget kein abstraktes SEO-Thema. Die Architektur umfasste ungefähr 59 Locales auf vier Domains. Am 29. Mai 2026 standen 148.020 indexierten URLs 4.380.579 nicht indexierte URLs gegenüber. Die Indexierungsrate lag bei 3,3 Prozent. Seit Anfang März war die Zahl indexierter URLs von 289.727 um rund 49 Prozent gefallen.

Die größte GSC-Gruppe war „Gecrawlt, zurzeit nicht indexiert“ mit rund 2,28 Millionen URLs, 52 Prozent des nicht indexierten Bestands. Das ist ein Status, keine Ursachenangabe. Die weiteren Exporte zeigten jedoch einen ausufernden technischen URL-Raum:

• In einer auf 100.000 Zeilen begrenzten GA4-Auswertung von Seiten mit weniger als zwei Views in zwölf Monaten waren 51,2 Prozent Parameter-URLs.
• Numerische Facet-IDs wie 2134, 1957 und 2196, interne Suche (q, text), Pagination (page, pagesize), Sortierung (order, dir), gespeicherte Konfigurationen (save-id), OAuth-Parameter (session_state, code, state) und msclkid erzeugten Varianten.
• Automatisch erzeugte Konfiguratorpfade umfassten mindestens 30.428 GA4-Vorkommen für /{uuid}/configure und 7.113 für /{uuid}/request. Die Pfade waren nicht per robots.txt ausgeschlossen. Ein abgelaufener Beispielpfad lieferte live 404; die 404-Behandlung des gesamten Clusters wurde nicht vollständig verifiziert.
• In Crawl Stats entfielen 7,64 Prozent aller Googlebot-Requests auf 301. Eine direkte Kausalität zu alten Länder-Subdomains war aus den Daten nicht bewiesen.
• JavaScript und CSS belegten zusammen 39 Prozent der Requests, PDF 0,9 Prozent. Zusätzlich crawlt Googlebot öffentlich erreichbare Staging-, Intranet- und Confluence-Hosts.

Der Canonical-Konflikt entsteht, wenn Filter-URLs auf eine Kategorie als Hauptversion zeigen, aber Navigation und Templates weiter Tausende crawlbare Links zu denselben Varianten erzeugen. Das Canonical hilft bei der Konsolidierung. Es verhindert Discovery und Abruf dieser URLs nicht. Der Linkgraph sendet damit zwei Botschaften: „Nutze die Kategorie als Hauptversion“ und gleichzeitig „Diese Varianten sind wichtig genug, um sie überall zu verlinken“.

Die Korrektur beginnt deshalb an der URL-Erzeugung und internen Verlinkung:

1. Strategisch irrelevante Parameterpfade aus crawlbaren <a href>-Links entfernen.
2. Filterzustände nur dann als eigene URLs führen, wenn sie Suchnachfrage, eigenständigen Inhalt und eine klare Indexierungsentscheidung haben.
3. Sitemap, Canonical, interne Links und Hreflang auf dieselbe bevorzugte URL-Menge ausrichten.
4. Staging und interne Systeme per Authentifizierung schützen; eine robots.txt ist dort nur eine Übergangslösung.
5. Parameterregeln erst nach einer Stichprobe aller legitimen Landingpages schärfen. Ein pauschales Disallow: /*? kann echte Kampagnen- oder Funktions-URLs treffen.

Dieser Fall trennt Crawl- und Qualitätsarbeit. Die Millionen bereits gecrawlter, nicht indexierter URLs verlangen eine Template- und Wertprüfung. Die Parameter, Konfiguratorpfade und öffentlichen Service-Hosts verlangen URL-Kontrolle. Ein einziges Canonical kann beides nicht lösen.

Technische SEO für LLMs: gemeinsame Grundlage, andere Abrufwege

Technische SEO reduziert Zugriffsbarrieren für AI-Systeme, garantiert aber kein Retrieval und kein Zitat. Anbieter dokumentieren verschiedene Bots für Training, Suche und nutzerinitiierte Abrufe. Die Freigabe eines Bots gilt nicht automatisch für alle Produkte desselben Anbieters.

Die folgende Tabelle ordnet die dokumentierten User-Agent-Namen nach Anbieter, Zweck und Abrufmodell. Sie beschreibt Anbieterangaben, keine gemeinsame Architektur aller AI-Systeme.

Anbieter	User-Agent	Dokumentierter Zweck	Abrufmodell
Google	Googlebot	Suchindex und unterstützende Links in AI-Funktionen	persistenter Suchindex
OpenAI	GPTBot	mögliche Trainingszwecke	Training
OpenAI	OAI-SearchBot	Sichtbarkeit in ChatGPT Search	Suchindex
OpenAI	ChatGPT-User	nutzerinitiierte Aktionen	Echtzeitabruf
Anthropic	ClaudeBot	Training und Web-Scraping	Training
Anthropic	Claude-SearchBot	Suche für Claude	Suchabruf
Anthropic	Claude-User	nutzerinitiierte Aktionen	Echtzeitabruf
Perplexity	PerplexityBot	Aufbau und Aktualisierung des Suchindex	Suchindex
Perplexity	Perplexity-User	Abruf im Auftrag eines Nutzers	Echtzeitabruf

OpenAI beschreibt die Trennung in der offiziellen Crawler-Dokumentation. Anthropic dokumentiert eigene User-Agents im Beitrag Does Anthropic crawl data from the web?. Perplexity erklärt das Verhalten von PerplexityBot und Perplexity-User.

Training ist nicht dasselbe wie Retrieval. Ein Trainingsbot kann gesperrt sein, während ein Search-Bot Zugriff erhält. Ein Serverlog mit Bot-Request beweist nur den Request. Es beweist nicht, dass der Inhalt für einen bestimmten Prompt ausgewählt oder als Citation gezeigt wurde.

Für Google AI-Funktionen gelten die normalen technischen Anforderungen der Suche. Google nennt keine zusätzlichen technischen Anforderungen und kein spezielles AI-Markup. Eine Seite muss für unterstützende Links indexiert und für Snippets freigegeben sein. Die Details stehen in AI-Funktionen und Ihre Website.

Die gemeinsame Grundlage bleibt bescheiden: stabile HTTP-Antworten, zugängliches HTML und auslesbarer Hauptinhalt. Crawlbare Links helfen bei Discovery. Eindeutige URLs reduzieren Konflikte. Was ein System danach abruft, auswählt oder zitiert, bleibt anbieter- und anfrageabhängig.

Wo llms.txt einzuordnen ist

llms.txt ist ein vorgeschlagenes Markdown-Format, das ausgewählte Inhalte für Sprachmodelle auffindbar zusammenfasst. llms.txt ist kein Standard der Internet Engineering Task Force (IETF) oder des World Wide Web Consortium (W3C). Die Datei ersetzt weder robots.txt noch XML-Sitemaps und enthält keine allgemeine Zugriffserlaubnis.

Google erklärt im Leitfaden zur Optimierung für generative KI-Funktionen, dass Google Search solche AI-Textdateien nicht speziell verwendet. Google kann eine llms.txt wie andere Dateien entdecken und indexieren, behandelt sie aber nicht als besonderes Signal. Daraus folgt kein allgemeiner Nachweis für andere Anbieter. Für kontrollierte Dokumentations- oder Entwickler-Workflows kann der Vorschlag nützlich sein. Eine Wirkung auf Rankings oder plattformübergreifende Citation-Raten ist nicht belegt.

Die ausführliche Einordnung mit Herkunft, Aufbau und Grenzen finden Sie im llms.txt-Leitfaden.

Was sollte zuerst behoben werden?

Technische SEO folgt einer Abhängigkeit: Erst beseitigen Sie Blocker, danach widersprüchliche Steuerung. Qualitätsprobleme und Optimierungen kommen auf eine erreichbare, verarbeitbare und indexierbare Grundlage. Anbieterabhängige Experimente stehen zuletzt.

Ebene	Beispiele	Warum diese Reihenfolge gilt
1. Blocker	DNS-Ausfall, 5xx, unbeabsichtigte robots-Blockade, unbeabsichtigtes noindex	Crawler können den Inhalt oder seine Indexierungsanweisungen nicht zuverlässig abrufen.
2. Steuerung	falsches Canonical, widersprüchliche Sitemap, fehlerhaftes Hreflang	Systeme erhalten unklare Signale zu URL und Sprachversion.
3. Qualität	fehlender Hauptinhalt nach Rendering, langsame Templates, instabile Layouts	Verarbeitung oder Nutzung bleibt möglich, aber fehleranfällig.
4. Optimierung	Core Web Vitals, interne Linktiefe, Sitemap-Segmentierung	Die Maßnahme verbessert eine bereits funktionierende Grundlage.
5. Experiment	spezielle AI-Crawler-Regeln, llms.txt	Die Wirkung hängt vom Anbieter und konkreten Abrufweg ab.

FIG 02 · TECHNISCHE PRIORITÄTEN

Die Matrix ist keine automatische Severity-Bewertung für jede Website. Ein fehlerhaftes Hreflang kann für ein internationales Portal geschäftlich dringlicher sein als ein einzelner Performance-Ausreißer. Die technische Abhängigkeit bleibt trotzdem bestehen: Eine nicht erreichbare Seite lässt sich nicht sinnvoll für ihre Ausspielung optimieren.

Praktische Checkliste: technische Grundlage vor der Optimierung

Beginnen Sie mit einer strategisch wichtigen URL. Die Checkliste speichert den Fortschritt lokal in Ihrem Browser. Jeder Schritt nennt eine Prüfung, eine Datenquelle und ein Abschlusskriterium.

Arbeitsstand

Technische Grundlage in 12 Schritten

0 von 12Schritte erledigt

0 von 12

1. Strategisch wichtige URL festlegenPrüfung: Zweck und gewünschte Hauptversion dokumentieren. Werkzeug: Seiteninventar. Fertig, wenn genau eine URL mit Ziel und Seitentyp feststeht.
2. HTTP-Antwort prüfenPrüfung: Statuscode, Ziel nach Weiterleitung und wiederholte 5xx oder 429 kontrollieren. Werkzeug: Browser-Devtools oder Serverlog. Fertig, wenn die Ziel-URL stabil und ohne Schleife antwortet.
3. Robots.txt-Regeln kontrollierenPrüfung: Regel für den relevanten User-Agent und nötige Ressourcen testen. Werkzeug: robots.txt-Bericht oder RFC-9309-Validator. Fertig, wenn URL, CSS und JavaScript wie beabsichtigt abrufbar sind.
4. Noindex und X-Robots-Tag prüfenPrüfung: HTML-Head und HTTP-Header vergleichen. Werkzeug: URL-Prüfung und Header-Inspektor. Fertig, wenn keine unbeabsichtigte Indexierungssperre vorliegt.
5. Gerenderten Hauptinhalt vergleichenPrüfung: Quell-HTML, gerenderten DOM und sichtbaren Hauptinhalt abgleichen. Werkzeug: Live-Test der URL-Prüfung. Fertig, wenn Überschrift, Haupttext und wichtige Links verarbeitet werden.
6. Canonical kontrollierenPrüfung: deklariertes Canonical, interne Links und Google-Auswahl vergleichen. Werkzeug: Crawler und URL-Prüfung. Fertig, wenn alle Signale dieselbe fachlich passende Hauptversion stützen.
7. Interne Links zur URL prüfenPrüfung: crawlbare <a href>-Links und Linkziele untersuchen. Werkzeug: Website-Crawler. Fertig, wenn die URL über relevante Seiten ohne Weiterleitung erreichbar ist.
8. Sitemap-Eintrag prüfenPrüfung: URL, Statuscode, Indexierbarkeit und lastmod abgleichen. Werkzeug: Sitemap-Bericht der Search Console. Fertig, wenn nur die bevorzugte indexierbare URL enthalten ist.
9. Hreflang-Cluster validierenPrüfung: Selbstverweis, Rückverweise, Codes und vollständige URLs kontrollieren. Werkzeug: Crawler oder Hreflang-Test. Fertig, wenn jede reale Variante dasselbe vollständige Cluster ausgibt.
10. Indexierungsstatus prüfenPrüfung: bekannten Status, Live-Abruf und gewähltes Canonical lesen. Werkzeug: Google Search Console. Fertig, wenn der Status zur gewünschten Behandlung der URL passt.
11. Core Web Vitals aus Felddaten prüfenPrüfung: LCP, INP und CLS für Mobil und Desktop ansehen. Werkzeug: PageSpeed Insights oder CrUX. Fertig, wenn Datenlage, betroffene URL-Gruppe und Abweichung dokumentiert sind.
12. Serverlogs oder Crawl-Statistiken auswertenPrüfung: Requests, Statuscodes und auffällige URL-Muster untersuchen. Werkzeug: Serverlogs und Crawl-Statistikbericht. Fertig, wenn technische Blocker und nächste Priorität belegt sind.

Auswahl zurücksetzen

Die Checkliste ersetzt kein vollständiges Website-Inventar. Sie schafft zuerst einen belastbaren Befund für eine wichtige URL. Wiederholen Sie den Ablauf danach für repräsentative Templates und Seitentypen.

Häufige Fragen

Was gehört zur technischen SEO?

Technische SEO umfasst die Infrastruktur für Discovery, Crawling, Verarbeitung, Indexierung und Ausspielung. Dazu gehören HTTP-Antworten, robots.txt, interne Links, XML-Sitemaps und URL-Signale. Google beschreibt Crawling, Indexierung und Serving als Kernphasen. Content und Autorität bleiben eigene Ebenen. Quelle: Google Search Central.

Was ist der Unterschied zwischen Crawling und Indexierung?

Crawling ist der Fund und Abruf einer URL samt benötigter Ressourcen. Indexierung ist die Analyse und mögliche Speicherung des verarbeiteten Inhalts im Suchindex. Eine URL kann gecrawlt, aber durch noindex, Duplikaterkennung oder andere Gründe nicht indexiert werden. Quelle: Google Search Central.

Sind Core Web Vitals ein Rankingfaktor?

Google empfiehlt gute Core Web Vitals für Nutzererfahrung und Search. Google ordnet die Metriken zusammen mit weiteren Page-Experience-Aspekten dem ein, was die Ranking-Systeme belohnen sollen. Gute Werte garantieren keine Position. Google bewertet LCP, INP und CLS anhand realer Nutzerdaten am 75. Perzentil. Quelle: Google Search Central zu Core Web Vitals.

Verhindert robots.txt die Indexierung?

Nein. robots.txt steuert den Abruf, nicht zuverlässig die Indexierung einer URL. Google kann eine gesperrte URL über Links kennen und ohne gelesenen Inhalt indexieren. Für den Ausschluss aus Suchergebnissen braucht eine abrufbare Seite noindex im HTML oder HTTP-Header. Quellen: Google Search Central und RFC 9309.

Braucht jede Website eine XML-Sitemap?

Nein. Eine kleine, sauber intern verlinkte Website kann ohne XML-Sitemap vollständig auffindbar sein. Eine Sitemap hilft besonders bei großen Beständen, neuen Websites oder schwer verlinkbaren Inhalten. Sie unterstützt Discovery, garantiert aber keine Indexierung. Quellen: Google Search Central und Sitemaps.org.

Wann ist Crawlbudget wirklich relevant?

Crawlbudget wird bei sehr großen Websites und häufig geänderten URL-Beständen relevant. Google nennt mindestens eine Million URLs mit moderaten Änderungen oder mindestens 10.000 täglich wechselnde URLs als typische Fälle. Serverprobleme und unendliche Parameterräume verschärfen den Engpass. Kleine Websites sollten zuerst Blocker, interne Links und Indexierungsregeln prüfen. Quelle: Google-Dokumentation zum Crawlbudget.

Verbessert Hreflang das Ranking?

Hreflang ist kein allgemeiner Rankingbonus. Das Attribut hilft Google, lokalisierte Sprach- oder Regionsvarianten zu erkennen und passend auszuspielen. Selbstverweise und reziproke Links gehören zu einer vollständigen Implementierung. Indexierbarkeit und Relevanz müssen unabhängig davon stimmen. Quelle: Google Search Central zu lokalisierten Versionen.

Hilft technische SEO bei Zitaten in ChatGPT oder Perplexity?

Technische SEO reduziert Abrufbarrieren, garantiert aber kein KI-Zitat. OpenAI und Perplexity dokumentieren getrennte Suchbots und nutzerinitiierte Fetcher. Eine erfolgreiche Bot-Anfrage beweist nur Zugriff, nicht Retrieval für einen Prompt oder sichtbare Citation. Quellen: OpenAI Crawlers und Perplexity Crawlers.

Ist eine llms.txt für KI-Sichtbarkeit notwendig?

Nein. llms.txt ist ein vorgeschlagenes Zusatzformat und kein Standard der Internet Engineering Task Force (IETF) oder des World Wide Web Consortium (W3C). Google Search verwendet solche AI-Textdateien nicht als besonderes Signal. Ein Nutzen kann in kontrollierten Dokumentations-Workflows liegen. Eine allgemeine Wirkung auf Rankings oder Zitate ist nicht belegt. Quelle: Google-Leitfaden für generative KI-Funktionen.

Alle Beiträge zum Thema

• 23. Juli 2026 · 17 Min. · Praxis & Zahlen

  Die Produktseite ist nicht die ganze Gleichung: was KI-Antworten im E-Commerce wirklich zitieren

  Welche Seitentypen neben Produktseiten als Quellen in KI-Antworten erscheinen.

• 3. Juli 2026 · 13 Min. · Analyse & Einordnung

  llms.txt: Was die Datei bringt, was Google dazu sagt – und wann Sie eine anlegen sollten

  Herkunft, offizieller Google-Stand und sinnvolle Einsatzgrenzen des vorgeschlagenen Formats.

• 30. Juni 2025 · 6 Min. · Anleitung

  Crawl Budget: Wie HTTP-Status-Codes Ihr SEO-Ranking beeinflussen

  Wie Statuscodes Crawling und Serverkapazität beeinflussen und welche Fehler zuerst zählen.

Wann eine technische SEO-Analyse sinnvoll ist

Der Guide erklärt technische Ebenen und ihre Reihenfolge. Eine Analyse wird sinnvoll, wenn unklar bleibt, welche Blocker auf Ihrer Website tatsächlich auftreten oder mehrere Signale einander widersprechen.

Wenn Sie diese Ursachen für Ihre Website einordnen lassen möchten, können Sie die technischen Ursachen in einem SEO-Audit priorisieren lassen.