In Lektion 1.2 ging es um das Prinzip: Google crawlt, indexiert, rankt. Jetzt kommt die Praxis.
Genau das ist technisches SEO: alles, was darüber entscheidet, ob eine Suchmaschine deine Inhalte finden, verstehen und ausliefern kann. Der beste Text nützt nichts, wenn eine Zeile Code ihn aus dem Index hält.
Die verbreiteten Anleitungen zu diesem Thema liefern dafür lange Listen: robots.txt, Sitemap, Canonical, Ladezeit, Bilder, Struktur – meist alles gleich lang und gleich wichtig behandelt. Diese Lektion sortiert stattdessen nach Kritikalität.
Kurzantwort
Was ist technisches SEO – und was davon ist wirklich dringend?
Technisches SEO umfasst alle Einstellungen, die regeln, ob Suchmaschinen deine Seiten crawlen, indexieren und schnell ausliefern können: robots.txt, noindex, Canonical, Sitemap, Statuscodes, Weiterleitungen und Ladezeit.
Dringend ist davon nur ein kleiner Teil: alles, was wichtige Seiten aus dem Index hält oder von ihnen wegleitet. Der Rest ist meistens Kosmetik im Prüfbericht.
📌 Für wen ist das relevant: Für alle, die eine Website betreuen, ohne Entwickler zu sein – und wissen wollen, was sie selbst prüfen können.
- Ein Eintrag in der robots.txt verhindert das Crawlen, aber nicht die Indexierung
- Die häufigsten Fehler in Prüfberichten sind selten die gefährlichsten
- Core Web Vitals wirken, aber nachrangig: Google stellt Relevanz ausdrücklich über die Page Experience
Das lernst du in dieser Lektion
Du prüfst in wenigen Minuten, ob eine Seite indexierbar ist – und kennst die häufigsten Blocker.
Du verstehst, was robots.txt, Sitemap, Canonical und Statuscodes tun – und was nicht.
Du kannst Core Web Vitals einordnen: was sie messen und wie viel sie wiegen.
Du unterscheidest kritische Probleme von kosmetischen – und weißt, was du zuerst anfasst.
Inhalt
01 ·
Was technisches SEO abdeckt – und was nicht
Technisches SEO (im Englischen technical SEO) setzt nicht am Text an, sondern an der Auslieferung.
Es beantwortet drei Fragen: Darf der Crawler rein? Versteht er, welche URL zählt? Und kommt die Seite schnell beim Nutzer an?
Die Begriffe dahinter – Crawling, Indexierung, Ranking – hast du in Lektion 1.2 kennengelernt.
Drei Themen gehören nicht hierher: Title, Meta-Description und interne Verlinkung standen in Lektion 2.4, Textqualität in der Vorlektion, Backlinks folgen in Modul 3.
Die Trennung spart dir Arbeit. Wer bei einer unsichtbaren Seite am Text feilt, obwohl ein noindex-Tag im Quelltext steht, optimiert etwas, das niemand sieht.
Leg dir für diese Lektion fünf Seiten zurecht: deine Startseite, die zwei wichtigsten Leistungsseiten und zwei beliebige Unterseiten. An denen prüfst du gleich alles durch.
02 ·
Kritisch, wichtig, kosmetisch
Beim ersten Crawl deiner Website bekommst du eine erschreckende Liste. Der Reflex ist, oben anzufangen und sich nach unten durchzuarbeiten – und damit fängt die Arbeit meist an der falschen Stelle an.
Die Häufigkeit einer Warnung sagt nichts über ihre Wirkung aus. Ausgerechnet die häufigsten Punkte in Crawl-Berichten – Weiterleitungen, fehlende Meta-Descriptions, langsame Seiten – sind selten die, wegen denen du nachts wach liegen solltest.
Der Grund: Prüftools sortieren nach dem, was leicht zählbar ist, nicht nach dem, was auf deiner Website zählt. Eine Seite kann Dutzende Prüfungen nicht bestehen, ohne dass es Sichtbarkeit oder Umsatz kostet. Sortier deshalb selbst – nach der Frage, ob ein Fehler wichtige Seiten aus dem Index hält oder von ihnen wegleitet.
Technische Probleme nach Kritikalität
Drei Stufen: was du heute, was du diesen Monat und was du gar nicht anfassen musst
noindex auf wichtigen Seiten · robots.txt sperrt Bereiche, die ranken sollen · Canonical zeigt von wichtigen Seiten weg · Serverfehler (5xx) · kaputte interne Links zu umsatzrelevanten Seiten
Langsame Templates auf Seiten mit viel Traffic · Weiterleitungs-Ketten und Schleifen · Soft 404 auf echten Inhaltsseiten · veraltete Sitemap · Teilinhalte, die erst nach einem Klick nachgeladen werden
Fehlende Meta-Description auf Seiten ohne Impressionen · 404 alter URLs ohne Links und Traffic · doppelte H1 auf Hilfsseiten · HTML-Validierungsfehler auf unwichtigen Seiten · Warnungen zu bewusst gesperrten Seiten · sauber auflösende Weiterleitungen
Quellen: Ahrefs “The Most Common Technical SEO Issues” · Dan Lauer, Search Engine Land, “Technical debt in SEO” · Google Search Central – Stand 08/2026, eigene Darstellung, Ostend Digital.
Schaubild: technische Probleme nach Kritikalität statt nach Häufigkeit – eigene Darstellung, Ostend Digital.
In Stufe 1 stehen fast nur Dinge, die den Zugang zur Seite betreffen. In Stufe 3 stehen genau die Punkte, die in Prüfberichten am häufigsten auftauchen – fehlende Alt-Texte übrigens auch: Sie blockieren technisch nichts, sind für Bildersuche und Zugänglichkeit aber trotzdem sinnvoll.
Hast du schon einen Crawl-Bericht deiner Website, nimm ihn jetzt zur Hand und schreib neben jede Warnung eine Stufe. Falls nicht: Ein kostenloser Crawler wie Screaming Frog (Free-Version, bis 500 URLs) erzeugt ihn in wenigen Minuten. Was in Stufe 1 landet, ist deine Liste für heute.
💡 Merke
Derselbe Fehlertyp hat auf verschiedenen Seiten völlig verschiedene Folgen. Ein doppelter Title auf einer wichtigen Leistungsseite ist ein Problem, derselbe Fehler auf einer Tag-Übersicht keins.
Dein Prüftool kennt deine Seitenprioritäten nicht. Frag deshalb bei jeder Warnung zuerst: Auf welcher Seite steht sie?
03 ·
Sieht Google deine Seite überhaupt?
Das ist die Frage vor allen anderen: Eine Seite, die nicht im Index ist, kann nicht ranken. Beantworten kannst du sie kostenlos in der Google Search Console – zuverlässiger als mit jedem externen Tool, weil sie zeigt, was Google tatsächlich sieht.
Zwei Berichte reichen. Die URL-Prüfung sagt dir für eine einzelne Adresse, ob sie im Index ist, ob das Crawling blockiert war und wie das von Google gerenderte HTML aussieht – also die Seite so, wie Google sie nach dem Ausführen von JavaScript sieht.
Der Seitenindexierungs-Bericht macht dasselbe für die ganze Domain und nennt für jede nicht indexierte URL einen Grund: “Durch robots.txt blockiert”, “Noindex-Tag”, “Duplikat, vom Nutzer nicht als kanonisch festgelegt”, “Soft 404” oder “Serverfehler (5xx)”.
Prüfpfad: Ist meine Seite indexierbar?
Fünf Schritte in der Google Search Console, von oben nach unten
Steht dort “URL ist auf Google”, ist die Frage beantwortet. Sonst nennt die Meldung den Grund.
“Durch robots.txt blockiert” heißt: Der Crawler darf nicht hinein. Erst diese Sperre lösen.
“Noindex-Tag” heißt: Die Seite sagt selbst, dass sie draußen bleiben soll. Im SEO-Plugin nachsehen.
Weicht die von Google gewählte kanonische URL von deiner ab, gilt eine andere Seite als das Original.
Im gerenderten HTML einen markanten Satz suchen. Fehlt er, liegt das Problem beim Rendering.
Quellen: Google Search Console Hilfe · Google Search Central – Stand 08/2026, eigene Darstellung, Ostend Digital.
Schaubild: Prüfpfad zur Indexierbarkeit in fünf Schritten – eigene Darstellung, Ostend Digital.
Der teuerste Treffer auf diesem Pfad ist Schritt 3. Ein noindex-Tag ist eine Zeile, auf Testumgebungen völlig zu Recht gesetzt – und beim Livegang geht sie gern mit.
Wie teuer das wird, zeigt ein Fall bei Moz: Am 1. August 2019 rollte ein Deployment versehentlich die Staging-Konfiguration live aus, samt noindex auf jeder Seite. Bemerkt wurde das erst rund drei Tage später.
Info
Was der vergessene noindex gekostet hat (Moz, 2019):
- Rund 33,2 Prozent des Suchtraffics gingen verloren
- Die Sichtbarkeit war erst nach 6 Wochen zurück auf dem Ausgangsniveau
- Vollständig neu indexiert waren alle Seiten erst nach 8 bis 9 Wochen
Die zweite Zahl ist die lehrreichere: Ein noindex zu entfernen dauert Minuten. Die Erholung dauerte Wochen.
💡 Praxis-Tipp
Mach den Prüfpfad zur Routine nach jedem Relaunch. Nimm dafür deine fünf Seiten vom Anfang – und geh sie jetzt gleich ein erstes Mal durch.
Und sieh in den Seitenindexierungs-Bericht, sobald die Zahl indexierter Seiten fällt. Dieser Knick ist das Frühwarnsignal, das im Moz-Fall drei Tage niemand gesehen hat.
04 ·
Die robots.txt-Falle
Die robots.txt ist eine schlichte Textdatei im Wurzelverzeichnis deiner Website. Sie sagt Crawlern, welche Bereiche sie besuchen dürfen und welche nicht.
Der Denkfehler steckt in dem, was fast nie dazugesagt wird: Die robots.txt regelt das Crawling, nicht die Indexierung. Das sind zwei verschiedene Dinge, und Google wird in seiner Dokumentation ungewöhnlich deutlich.
Info
Drei Sätze aus Googles robots.txt-Dokumentation, sinngemäß übersetzt:
- Die robots.txt ist kein Mechanismus, um eine Webseite aus Google herauszuhalten.
- Nutze sie nicht als Mittel, um deine Seiten vor den Google-Suchergebnissen zu verstecken.
- Eine per robots.txt gesperrte Seite kann trotzdem indexiert werden, wenn andere Websites auf sie verlinken.
In der Praxis sieht das merkwürdig aus: Die URL erscheint im Suchergebnis, aber ohne Beschreibungstext. Google kennt die Adresse aus fremden Verlinkungen, durfte den Inhalt aber nie ansehen.
Soll eine Seite wirklich nicht auftauchen, nennt Google drei Wege: Passwortschutz, noindex-Tag oder Seite entfernen. Die robots.txt steht nicht auf dieser Liste.
Die Kombination, die alles kaputt macht
Genau hier wird der gut gemeinte Doppelschutz zum Problem. Viele setzen gleichzeitig eine robots.txt-Sperre und ein noindex-Tag, in der Annahme, doppelt hält besser.
Das Gegenteil tritt ein. Google formuliert es so: Diese Einstellungen könnten nur gelesen und befolgt werden, wenn Crawler auf die Seiten zugreifen dürfen. Ist eine Seite vom Crawling ausgeschlossen, würden Angaben zur Indexierung nicht gefunden und deshalb ignoriert.
Dein noindex wird also nie gelesen. Die Seite bleibt crawl-gesperrt, kann über fremde Links trotzdem im Index landen – und die Anweisung dagegen liegt hinter einer Tür, die du selbst zugeschlossen hast.
💡 Merke
Entweder crawlen lassen und per noindex draußen halten – oder gar nicht erst öffentlich stellen. Beides gleichzeitig hebt sich gegenseitig auf.
Willst du eine bereits gesperrte Seite aus dem Index bekommen, ist die Reihenfolge: erst die robots.txt-Sperre entfernen, dann das noindex setzen, dann warten, bis Google neu gecrawlt hat.
Eine Ergänzung noch: Für Dateien ohne HTML-Kopf – PDFs zum Beispiel – funktioniert das Meta-Tag nicht, dort brauchst du den HTTP-Header X-Robots-Tag.
Ruf jetzt deine-domain.de/robots.txt im Browser auf und lies jede Disallow-Zeile. Steht dort ein Verzeichnis, in dem Seiten liegen, die ranken sollen, hast du deinen ersten Stufe-1-Fund.
05 ·
Canonical, Sitemap und Statuscodes
Drei Bausteine bleiben, die in jeder Checkliste stehen und regelmäßig überschätzt werden.
Canonical: ein Hinweis, kein Befehl
Ein Canonical-Tag sagt Google, welche URL du bei mehreren ähnlichen Versionen als Original betrachtest – etwa dieselbe Produktseite mit und ohne Filter-Parameter.
Google gewichtet die Signale zur kanonischen URL unterschiedlich: Eine Weiterleitung gilt als starkes Signal, das rel="canonical"-Tag ebenfalls, der Sitemap-Eintrag nur als schwaches. Gibst du nichts an, wählt Google selbst die Version, die es objektiv für die beste hält.
Dein Canonical ist damit ein Vorschlag. Widersprechen sich deine Signale, entscheidet Google – möglicherweise gegen dich.
Vier Fehler nennt Google dabei ausdrücklich:
- 🚩 robots.txt zur Kanonisierung nutzen – der Crawler sieht die gesperrte Version gar nicht
- 🚩 Widersprüchliche Angaben über mehrere Techniken hinweg
- 🚩 URL-Fragmente mit # als Canonical-Ziel angeben
- 🚩 noindex einsetzen, um die Canonical-Auswahl zu beeinflussen
Sitemap: Entdeckungshilfe, kein Garantieschein
Eine XML-Sitemap ist eine Liste deiner URLs für Suchmaschinen. Der verbreitete Irrtum lautet: Sitemap eingereicht, also wird alles indexiert. Google widerspricht direkt – eine Sitemap helfe beim Entdecken von URLs, garantiere aber keine Indexierung.
Interessanter ist, wer überhaupt eine braucht. Sinnvoll ist sie laut Google bei großen Websites, bei neuen Seiten mit wenigen externen Links und bei viel Video- oder Bildmaterial. Als “klein” definiert Google ausdrücklich Websites mit etwa 500 Seiten oder weniger – dort reicht gute interne Verlinkung, und dein SEO-Plugin erzeugt die Sitemap ohnehin automatisch.
Statuscodes: was der Server antwortet
Jeden Aufruf beantwortet dein Server mit einem dreistelligen Code. Vier Fälle sind relevant.
| Code | Bedeutung | Wie Google damit umgeht |
|---|---|---|
| 301 | Dauerhaft verschoben | Starkes Signal für das Weiterleitungsziel als kanonische URL |
| 302 | Vorübergehend verschoben | Nur schwaches Signal – die ursprüngliche URL bleibt tendenziell die relevante |
| 404 / 410 | Nicht gefunden / entfernt | Google behandelt alle 4xx außer 429 gleich – ein 410 bringt gegenüber 404 keinen Vorteil |
| Soft 404 | Fehlerseite, die 200 OK meldet | Wird in der Search Console gesondert gemeldet: Inhalt und Statuscode passen nicht zusammen |
Die praktische Regel: Gibt es zu einer entfernten Seite eine passende Nachfolgeseite, leitest du per 301 dorthin. Gibt es keine, lässt du den 404 stehen statt pauschal auf die Startseite umzuleiten.
Der unauffälligste Fall ist der Soft 404 – eine leere Kategorie- oder Fehlerseite, die technisch “alles in Ordnung” meldet, obwohl inhaltlich nichts da ist.
🚩 Weiterleitungs-Ketten entstehen von selbst, über Jahre und mehrere Relaunches. Solange die Kette am Ende auf einer echten Seite ankommt und unter zehn Sprüngen bleibt, ist das laut der Ahrefs-Auswertung unproblematisch – kritisch sind lange Ketten und Schleifen.
Mach die Probe an deiner Website: Ruf eine URL auf, die vor deinem letzten Relaunch verlinkt war. Landet sie auf einer passenden Seite, in einer Kette oder auf einem 404? Das Ergebnis sagt dir, ob deine Weiterleitungen gepflegt sind.
06 ·
Core Web Vitals ehrlich eingeordnet
Irgendwann siehst du für deine Seite einen roten Ladezeit-Wert und fragst dich, wie viel Ranking dich das kostet. Die Antwort hat zwei Teile: Was die Werte messen, ist eindeutig. Wie viel sie im Ranking wiegen, ist weniger, als oft behauptet – aber mehr als nichts.
Fangen wir mit dem eindeutigen Teil an: was die drei Werte messen.
| Messwert | Was gemessen wird | Gut | Verbesserungswürdig | Schlecht |
|---|---|---|---|---|
| LCP | Ladezeit des größten Elements | bis 2,5 Sekunden | 2,5 bis 4,0 Sekunden | über 4,0 Sekunden |
| INP | Reaktionszeit auf Nutzerinteraktionen | bis 200 ms | 200 bis 500 ms | über 500 ms |
| CLS | Visuelle Stabilität (springende Layouts) | bis 0,1 | 0,1 bis 0,25 | über 0,25 |
Google bewertet dabei nicht den Durchschnitt, sondern das 75. Perzentil deiner Seitenaufrufe – also den Wert, den drei von vier Aufrufe unterbieten – getrennt nach Mobil und Desktop.
Und ein Wert hat gewechselt: INP hat im März 2024 den früheren Messwert FID abgelöst. FID maß nur die allererste Interaktion, INP alle Interaktionen über die gesamte Besuchsdauer. Für dich zählt heute nur noch der INP-Wert.
Wie viel wiegt das im Ranking?
Nach dem Page-Experience-Update 2021 galten die Werte in der Branche weithin als reiner Tie-Breaker, also nur bei Gleichstand ausschlaggebend. Im August 2021 widersprach John Mueller von Google dieser Verkürzung: Es sei ein Rankingfaktor und mehr als ein Tie-Breaker, ersetze aber die Relevanz nicht.
Heute formuliert Googles Dokumentation klarer, worauf es hinausläuft: Die Suche zeige immer die relevantesten Inhalte, selbst wenn die Page Experience unterdurchschnittlich sei. Zum Tragen kommt sie dort, wo für viele Suchanfragen ohnehin viele hilfreiche Inhalte verfügbar sind.
Auswertungen von Rankings passen dazu: Seiten auf den vorderen Positionen bestehen die Core Web Vitals etwas häufiger als Seiten weiter hinten. Das zeigt einen Zusammenhang, aber nicht, dass die Werte die Ursache sind – gut rankende Seiten sind meist insgesamt besser gemacht.
💡 Merke
Gute Werte gehen mit guten Positionen einher – sie sind aber kein Ranking-Hebel, den du isoliert ziehen kannst. Wer dir eine feste Ranking-Formel für Ladezeit verkauft, verspricht mehr, als die Werte halten.
Die Reihenfolge lautet deshalb: erst Relevanz und Indexierbarkeit, dann Geschwindigkeit.
Der bessere Grund für schnelle Seiten
Das stärkere Argument ist nicht das Ranking, sondern der Umsatz. Google hat zusammen mit Deloitte an 37 großen Marken-Websites gemessen, was 0,1 Sekunden schnellere mobile Ladezeit bewirken.
Im Handel stieg die Conversion-Rate um 8,4 Prozent und der durchschnittliche Warenkorbwert um 9,2 Prozent, bei Websites mit Lead-Generierung die Formular-Absendungen um 21,6 Prozent.
Diese Zahlen sagen nichts über dein Ranking. Sie begründen die Arbeit an der Geschwindigkeit unabhängig davon – über Anfragen und Umsatz.
Der Messfehler, der naheliegt
Wer seine Werte prüft, landet bei PageSpeed Insights – und hält dort den Punktwert von 0 bis 100 für das Core-Web-Vitals-Ergebnis. Er ist es nicht.
Dahinter stecken zwei Datenarten. Labordaten kommen aus einer simulierten Messung unter kontrollierten Bedingungen: ein Gerät, ein Netzwerk, ein Standort. Felddaten kommen aus dem Chrome User Experience Report, also von echten Chrome-Nutzern der letzten 28 Tage.
Google ist bei der Priorität eindeutig: Liegen beide Datenarten vor, priorisierst du nach den Felddaten.
Info
Dein PageSpeed-Score ist nicht deine Core-Web-Vitals-Bewertung. Der 0-bis-100-Wert ist eine Labor-Kennzahl; das Bestehen entscheidet sich an den Felddaten. Eine Seite kann einen mäßigen Punktwert haben und die Core Web Vitals trotzdem bestehen – und umgekehrt.
Neue oder wenig besuchte Seiten haben oft gar keine Felddaten. Dann zeigt dir das Tool ausschließlich Laborwerte.
📌 Für den Alltag heißt das: Der Core-Web-Vitals-Bericht der Search Console ist die Wahrheit, PageSpeed Insights nutzt du danach für die Ursachensuche. Öffne den Bericht jetzt für deine Domain und notier, ob Mobil und Desktop bestehen – das ist dein Ausgangswert. Vertiefen kannst du das mit den Ratgebern zu Google Core Web Vitals und zum Website optimieren.
Experten-Tipp aus der Agentur
Wir prüfen bei Sichtbarkeitsproblemen immer erst die Indexierbarkeit, bevor wir über Ladezeiten reden. Ein Indexierungs-Blocker kostet eine Seite ihre komplette Sichtbarkeit, ein mäßiger LCP-Wert einen Bruchteil davon.
Und eine Haltung zum Punktwert: Jage keine 100 von 100. Der Sprung von 40 auf 70 bringt echten Nutzen, der Sprung von 90 auf 100 ist meist teuer erkaufte Kosmetik.
Pascal Cabitza
Geschäftsführer Ostend Digital
07 ·
Wann JavaScript zum Problem wird
Dieses Thema klingt nach Entwickler-Gebiet, und meistens ist es das auch. Du solltest trotzdem wissen, wann es dich betrifft – die Symptome sehen von außen wie ein Content-Problem aus.
Google verarbeitet eine Seite in drei Schritten: crawlen der rohen HTML-Antwort, Rendering-Warteschlange für das JavaScript, Indexierung des gerenderten Inhalts. Zur Warteschlange schreibt Google, eine Seite könne dort einige Sekunden liegen, aber auch deutlich länger – deshalb empfiehlt Google serverseitiges Rendern oder Pre-Rendering.
Was mit Akkordeons und Tabs ist
2014 hieß es von Google noch, per Klick versteckte Inhalte würden leicht abgewertet – mit dem Mobile-First-Indexing ab 2016 wurde das korrigiert. Heute zählen Inhalte in Akkordeons und Tabs voll, solange sie im HTML vorhanden und nur per CSS ausgeblendet sind.
Die echte Gefahr liegt woanders: Wird ein Inhalt erst nach einem Klick per JavaScript nachgeladen, steht er vorher nirgends im HTML – und Googlebot klickt nicht wie ein Mensch. Genau das führt bei Page-Buildern und “Mehr laden”-Buttons zu Inhalten, die nie im Index landen.
💡 Praxis-Tipp
Du brauchst dafür kein technisches Wissen, nur Schritt 5 aus dem Prüfpfad. Ruf die URL-Prüfung auf, öffne das gerenderte HTML und such einen markanten Satz aus dem betroffenen Abschnitt.
Fehlt er dort, hast du einen belegten Befund für deinen Entwickler oder den Theme-Support.
Für klassische WordPress-Seiten mit Standard-Themes ist das selten akut, weil der Inhalt direkt im HTML steht. Relevant wird es bei Page-Buildern mit starkem Client-Side-Rendering, eingebetteten React- oder Vue-Widgets und “Mehr laden”-Listen ohne eigene URLs.
Ebenfalls wichtig: Links entdeckt Google nur, wenn es echte <a>-Elemente mit href-Attribut sind. Prüf bei deinen fünf Seiten, ob Menü und wichtige Content-Links solche echten Links sind – im gerenderten HTML siehst du es.
08 ·
KI-Crawler und llms.txt
Zu diesem Thema kursieren viele Empfehlungen. Für deine Website ist die To-do-Liste kurz.
Steuern lassen sich KI-Crawler über dieselbe robots.txt: GPTBot und OAI-SearchBot von OpenAI, ClaudeBot und Claude-SearchBot von Anthropic, PerplexityBot sowie Google-Extended.
Der letzte ist der interessanteste. Google-Extended steuert nur die Nutzung für KI-Training und KI-Antworten, nicht das Googlebot-Crawling für die Suche. Du kannst KI-Nutzung also ablehnen, ohne deine klassische Suchsichtbarkeit anzutasten.
Ob Blockieren dir schadet oder nützt, ist offen: Auch reichweitenstarke Websites, die GPTBot sperren, tauchen in KI-Antworten weiter auf. Freigeben bringt dir derzeit keinen erkennbaren Vorteil, Blockieren keinen erkennbaren Schaden.
Triff die Entscheidung deshalb nach deiner Haltung zur KI-Nutzung deiner Inhalte, nicht aus Sorge um Sichtbarkeit – und trag sie in die robots.txt ein.
Willst du einen Bot aussperren, brauchst du zwei Zeilen: User-agent: GPTBot und darunter Disallow: /. Dasselbe Muster gilt für die anderen Bot-Namen; steht nichts drin, ist der Zugriff erlaubt.
Brauchst du eine llms.txt?
Kurz gesagt: derzeit nicht. Die Datei ist ein Vorschlag, den genau die Systeme nicht unterstützen, für die sie gedacht ist.
Info
Was die Daten zu llms.txt sagen (Server-Log-Auswertung über 137.000 Domains):
- Verbreitung: 4.088 Dateien im Juni 2025, 36.120 im Mai 2026
- 97 Prozent dieser Dateien erhielten im Mai 2026 null Anfragen von KI-Systemen
- Von den Zugriffen stammten nur 1,1 Prozent von echten KI-Retrieval-Bots, 21,7 Prozent von SEO-Audit-Tools
Google stellte im Juni 2026 klar: llms.txt ist für die Google-Suche nicht erforderlich und wirkt weder positiv noch negativ auf Sichtbarkeit oder Rankings. John Mueller sagte knapper, kein KI-System nutze die Datei derzeit.
Auch OpenAI und Anthropic verweisen in ihrer Crawler-Dokumentation auf die robots.txt. Begrenzte Unterstützung gibt es nur bei einzelnen Agenten-Werkzeugen – das ist etwas anderes, als für Websuche und Sichtbarkeit ausgelesen zu werden.
Für deine Website heißt das: keine llms.txt anlegen, keine Zeit hineinstecken. Die robots.txt ist der Ort, an dem du KI-Crawler steuerst. Ausführlicher ordnet das Thema der Ratgeber zu LLM Seeding und llms.txt ein.
09 ·
Selbst machen oder abgeben
Bleibt die Frage, die hier am meisten blockiert: Was kannst du ohne Entwickler erledigen? Mehr, als die meisten denken. Die Werkzeuge dafür laufen meist auf Englisch und führen das Thema unter technical SEO, mit denselben Begriffen wie in dieser Lektion.
| Aufgabe | Selbst machbar | Womit |
|---|---|---|
| Indexierbarkeit prüfen | ✅ Ja | URL-Prüfung in der Search Console |
| noindex setzen oder entfernen | ✅ Ja | Sichtbarkeits-Einstellung im CMS oder SEO-Plugin |
| robots.txt anpassen | ✅ Meist ja | robots.txt-Editor gängiger SEO-Plugins |
| Sitemap erzeugen und einreichen | ✅ Ja | SEO-Plugin plus Search Console |
| Weiterleitungen und Canonicals setzen | ✅ Meist ja | Redirect- und Canonical-Funktion des SEO-Plugins |
| Website auf Fehler crawlen | ✅ Ja | Kostenlose Crawler wie Screaming Frog Free, bis 500 URLs pro Durchlauf |
| Soft 404 und Serverfehler beheben | Teilweise | Ursache selbst finden, Behebung oft beim Hoster |
| Ladezeit-Ursachen beheben | Teilweise | Bilder und Plugins selbst, Server und Template mit Hilfe |
| Rendering-Probleme lösen | ❌ Nein | Befund selbst erheben, Umsetzung durch Entwickler |
Die Diagnose kannst du fast immer selbst stellen, auch wenn du die Behebung abgibst. Ein präziser Befund ist für jeden Entwickler wertvoller als die Bitte, “mal nach dem SEO zu schauen”. Für eine vollständige Bestandsaufnahme hilft die SEO-Audit-Checkliste.
💡 Praxis-Tipp
Dein Abschluss-Auftrag: Geh mit deinen fünf Seiten vom Anfang den Prüfpfad aus Sektion 3 durch, lies deine robots.txt und sieh in den Core-Web-Vitals-Bericht. Notier jeden Fund mit seiner Stufe.
Behebe zuerst alles aus Stufe 1, dann plane Stufe 2 für diesen Monat – und streich Stufe 3 bewusst. Danach hast du die technischen Grundlagen geprüft und die größten Bremsen beseitigt.
Damit ist Modul 2 abgeschlossen: Du kannst Seiten aufbauen, SEO-Texte schreiben und prüfen, ob sie bei Google ankommen. In Modul 3 geht es nach außen: um Backlinks, Offpage SEO und lokale Sichtbarkeit.
10 ·
💡 Recap
Technisches SEO in 30 Sekunden:
- Häufigkeit ist nicht Kritikalität. Was wichtige Seiten aus dem Index hält, kommt zuerst – fehlende Meta-Descriptions und 404 auf trafficlosen Alt-URLs zuletzt
- Erst die Zugangsfrage klären: URL-Prüfung in der Search Console, dann Crawling, Indexierung, Canonical und gerendertes HTML in dieser Reihenfolge
- Die robots.txt regelt das Crawling, nicht die Indexierung – eine gesperrte Seite kann über fremde Links trotzdem im Index landen, und ein noindex wirkt nur, wenn Google die Seite crawlen darf
- Canonical ist ein starkes Signal, aber kein Befehl, und eine Sitemap ist eine Entdeckungshilfe ohne Indexierungsgarantie
- Core Web Vitals wirken, aber nachrangig: Google stellt Relevanz ausdrücklich über die Page Experience. Erst Relevanz und Indexierbarkeit, dann Geschwindigkeit – die lohnt sich vor allem für Anfragen und Umsatz
- Dein PageSpeed-Score ist eine Labor-Kennzahl, das Bestehen der Core Web Vitals entscheidet sich an den Felddaten echter Nutzer
11 ·
Selbstcheck: kannst du das beantworten?
Eine wichtige Unterseite taucht in Google nicht auf. Wie prüfst du das – und in welcher Reihenfolge?
Mit der URL-Prüfung in der Search Console. Sie sagt dir, ob die Seite im Index ist, und nennt bei einem Nein den Grund. Die Reihenfolge danach:
- Crawling per robots.txt blockiert?
- Noindex-Tag auf der Seite?
- Canonical auf eine andere URL?
- Inhalt im gerenderten HTML vorhanden?
Erst wenn alle vier Punkte sauber sind, lohnt sich Arbeit am Text oder an der Ladezeit.
Du hast eine Seite in der robots.txt gesperrt und zusätzlich ein noindex gesetzt. Sie steht trotzdem in den Suchergebnissen. Warum?
Weil sich beide Maßnahmen aufheben. Die robots.txt verhindert nur das Crawling – laut Google ist sie kein Mittel, eine Seite aus der Suche herauszuhalten, und eine gesperrte Seite kann über fremde Links trotzdem indexiert werden.
Dein noindex würde das verhindern, wird aber nie gelesen. Die Lösung: erst die Sperre entfernen. Soll die Seite gar nicht öffentlich sein, ist Passwortschutz der sauberere Weg.
PageSpeed Insights zeigt für deine Startseite 48 von 100 Punkten. Wie ernst ist das?
Erst einmal gar nicht: Dieser Punktwert ist eine Labor-Kennzahl aus simulierter Messung. Ob du die Core Web Vitals bestehst, entscheiden die Felddaten echter Nutzer.
Sieh also in den Core-Web-Vitals-Bericht der Search Console. Die Schwellen dort: LCP bis 2,5 Sekunden, INP bis 200 Millisekunden, CLS bis 0,1. Und selbst bei schlechten Werten gilt: Relevanz steht über der Page Experience.
Dein Crawl-Bericht meldet 340 Warnungen. Womit fängst du an – und was lässt du liegen?
Nicht oben in der Liste, sondern bei den Zugangsproblemen: noindex auf wichtigen Seiten, gesperrte Bereiche die ranken sollen, wegzeigende Canonicals, Serverfehler und kaputte interne Links zu umsatzrelevanten Seiten.
Liegen lassen kannst du fehlende Meta-Descriptions auf Seiten ohne Impressionen, 404 alter URLs ohne Traffic, doppelte H1 auf Hilfsseiten und Warnungen zu bewusst gesperrten Seiten. Der Grund: Prüftools sortieren nach dem, was leicht zählbar ist, nicht nach dem, was auf deiner Website wichtig ist.
Quellen und Stand (18 Einträge)
- Google Search Central: “Introduction to robots.txt” – robots.txt ist “not a mechanism for keeping a web page out of Google”; “Don’t use a robots.txt file as a means to hide your web pages from Google Search results”; eine gesperrte Seite “can still be indexed if linked to from other sites”; empfohlene Alternativen Passwortschutz, noindex, Entfernen der Seite (developers.google.com, abgerufen 15.08.2026)
- Google Search Central: “Robots meta tag, data-nosnippet, and X-Robots-Tag specifications” – noindex als Meta-Tag und als HTTP-Header; “these settings can be read and followed only if crawlers are allowed to access the pages that include these settings”; bei robots.txt-Sperre werden Indexierungsanweisungen “not be found and will therefore be ignored”; X-Robots-Tag für Nicht-HTML-Dateien (abgerufen 15.08.2026)
- Google Search Central: “Consolidate duplicate URLs” – ohne Canonical-Angabe wählt Google selbst die “objectively the best version”; Signalstärke Weiterleitung stark, rel=canonical stark, Sitemap-Eintrag schwach; explizit gewarnte Fehler robots.txt zur Kanonisierung, widersprüchliche Angaben, URL-Fragmente, noindex zur Beeinflussung der Canonical-Auswahl (abgerufen 15.08.2026)
- Google Search Central: “Sitemaps overview” – Kriterien für und gegen eine Sitemap, Definition kleiner Websites als “about 500 pages or fewer”, Hinweis “A sitemap helps search engines discover URLs on your site, but it doesn’t guarantee that all the items in your sitemap will be crawled and indexed” (abgerufen 15.08.2026)
- Google Search Central: “How HTTP status codes, and network and DNS errors affect Google Search” – 301 als starkes, 302 als schwaches Canonical-Signal; “All 4xx errors, except 429, are treated the same”; Soft-404-Definition und Meldung im Seitenindexierungs-Bericht (abgerufen 15.08.2026)
- Google Search Central: “JavaScript SEO basics” – dreistufiger Ablauf Crawling, Rendering-Warteschlange, Indexierung; “The page may stay on this queue for a few seconds, but it can take longer than that”; Empfehlung serverseitiges oder Pre-Rendering; “Google can only discover your links if they are <a> HTML elements with an href attribute” (abgerufen 15.08.2026). Medianzeit von fünf Sekunden zwischen Crawling und Rendering: Google-Aussage vom Chrome Developer Summit im November 2019, sekundär dokumentiert
- Google Search Central: “Understanding page experience in Google Search results” – “Google Search always seeks to show the most relevant content, even if the page experience is sub-par”; Page Experience wird relevant, wenn für viele Suchanfragen viele hilfreiche Inhalte verfügbar sind (abgerufen 15.08.2026)
- web.dev / Google: Artikel zu LCP, INP und CLS – Schwellenwerte LCP bis 2,5 s gut, 2,5 bis 4,0 s verbesserungswürdig, über 4,0 s schlecht; INP bis 200 ms gut, 200 bis 500 ms verbesserungswürdig, über 500 ms schlecht; CLS bis 0,1 gut, 0,1 bis 0,25 verbesserungswürdig, über 0,25 schlecht; Bewertung am 75. Perzentil, getrennt Mobile und Desktop; INP als Nachfolger von FID seit März 2024, misst alle Interaktionen statt nur der ersten (abgerufen 15.08.2026)
- web.dev / Google: “Why lab and field data can be different” – Labordaten aus kontrollierter Umgebung (ein Gerät, ein Netzwerk, ein Standort), Felddaten aus dem Chrome User Experience Report über die letzten 28 Tage; “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts”; “Field data is not just one number, it’s a distribution of numbers” (abgerufen 15.08.2026)
- web.dev / Google, Deloitte und 55: “Milliseconds make millions” – 37 große Marken-Websites in Europa und den USA, über 30 Millionen Nutzersessions, stündliche Messung über 30 Tage Ende 2019, ohne parallele UX-Redesigns; bei 0,1 Sekunden mobiler Geschwindigkeitsverbesserung Retail Conversion-Rate +8,4 Prozent und Warenkorbwert +9,2 Prozent, Lead-Generierung Formular-Absendungen +21,6 Prozent. Ausdrücklich eine Conversion-Studie, keine Ranking-Studie; methodisch sauber angelegt (stündliche Messung, kein paralleles Redesign), Ergebnisse gelten für große Marken-Websites und sind auf kleine Websites nur als Richtung übertragbar (abgerufen 15.08.2026)
- Ahrefs: “The Most Common Technical SEO Issues [Study]” – Auswertung von 1.002.165 Domains; 3XX-Redirect 95,2 Prozent, fehlende Meta Description 72,9 Prozent, langsame Seite 72,3 Prozent, fehlende H1 59,5 Prozent; Kernaussage “the ones you see the most aren’t necessarily the ones you should be losing sleep over”; Redirects unproblematisch, solange sie auf eine andere Seite auflösen und unter zehn Sprüngen bleiben (ahrefs.com, abgerufen 15.08.2026). Belegstatus: Tool-Auswertung eines Anbieters, keine Google-Zahl – Grundlage der Aussage in Sektion 2, dass die häufigsten Warnungen selten die gefährlichsten sind
- Dan Lauer (Director of SEO und GEO, Walker Sands), Search Engine Land: “Technical debt in SEO – when to fix vs. when to ignore” – “A site can fail dozens of technical checks that look alarming in a crawl report but have no measurable impact on revenue. The problem is that crawlers sort by what’s easy to count, not by what matters”; Listen sicher ignorierbarer und wirklich sichtbarkeitsrelevanter Probleme; “Same issue type, completely different stakes” (searchengineland.com, abgerufen 15.08.2026). Belegstatus: Praktiker-Einordnung, deckt sich unabhängig mit der Ahrefs-Auswertung; Grundlage der Sortierung in Sektion 2 und der Merke-Box “Auf welcher Seite steht sie?”
- Jeff Baker, Moz Blog: “This Is What Happens When You Accidentally De-Index Your Site from Google” (05.11.2019) – versehentlich ausgerollte Staging-Konfiguration mit noindex auf allen Seiten am 01.08.2019, Entdeckung nach rund drei Tagen, “We had lost about 33.2% of our search traffic”, Sichtbarkeit nach sechs Wochen zurück auf Baseline, vollständige Re-Indexierung nach acht bis neun Wochen. Dokumentierter Einzelfall; Original über Sekundärquelle verifiziert (abgerufen 15.08.2026)
- Screaming Frog: “How Many Sites Pass the Core Web Vitals Assessment?” – 2.500 Keywords über 100 Themen, rund 20.000 URLs; Position 1 mit rund zehn Prozentpunkten höherer Bestehensquote als Position 9; der Autor nennt die Stichprobe selbst klein, stellt das Ergebnis selbst infrage und bietet zwei andere Erklärungen an (schnelle Seiten ranken ohnehin besser; gut rankende Seiten sind insgesamt besser gemacht). Erhebung aus der Frühzeit des Themas, daher im Lehrtext nur als Richtung zitiert. Ergänzend: Free-Version des Crawlers mit Limit von 500 URLs pro Durchlauf (screamingfrog.co.uk, abgerufen 15.08.2026)
- Search Engine Journal: “Core Web Vitals Ranking Factor Is More Than A Tie Breaker” – John Mueller am 06.08.2021: “It is a ranking factor, and it’s more than a tie-breaker, but it also doesn’t replace relevance” (searchenginejournal.com, abgerufen 15.08.2026)
- BuzzStream, Auswertung mit dem XOFU-Tool von Citation Labs: “Do News Publishers That Block AI Crawlers Get Cited Less Often by AI?” – 4 Millionen Zitationen aus 3.600 Prompts über zehn Branchen; von Sites, die GPTBot blockieren, erscheinen 88,2 Prozent trotzdem in Zitationen, bei Google-Extended 92,3 Prozent; Autoren-Caveat “we don’t know much about how this stuff works yet”; untersucht wurden reichweitenstarke Nachrichtenseiten, ob das Ergebnis für kleinere Websites gilt, ist offen. Bisher zeigt keine belastbare Studie, dass Freigeben zu mehr Zitationen führt, und keine, die Panik vor dem Blockieren rechtfertigt (buzzstream.com, abgerufen 15.08.2026)
- ppc.land auf Basis einer Ahrefs-Server-Log-Auswertung über 137.000 Domains: “llms.txt adoption rises 8.8x but 97% of files get zero AI requests” – 4.088 Dateien im Juni 2025, 36.120 im Mai 2026; 97 Prozent der Dateien ohne jede KI-Anfrage im Mai 2026; von den Zugriffen 1,1 Prozent echte KI-Retrieval-Bots und 21,7 Prozent SEO-Audit-Tools; Google-Klarstellung vom 15.06.2026, dass llms.txt für die Google-Suche nicht erforderlich ist und Sichtbarkeit oder Rankings weder positiv noch negativ beeinflusst; John Mueller: “no AI system currently uses llms.txt”; OpenAI und Anthropic verweisen auf robots.txt (abgerufen 15.08.2026). Einordnung: Viele Artikel, die llms.txt als Pflichtbaustein empfehlen, stammen von Anbietern passender Generatoren – deshalb im Lehrtext nur die Handlungsempfehlung, keine llms.txt anzulegen
- Google Search Console Hilfe: URL-Prüfung (Index-Status, letzter Crawl, Crawling-Blockaden, gerendertes HTML, Live-Test) und Seitenindexierungs-Bericht mit Nichtindexierungs-Gründen wie “Durch robots.txt blockiert”, “Noindex-Tag”, “Duplikat, vom Nutzer nicht als kanonisch festgelegt”, “Soft 404” und “Serverfehler (5xx)”; Core-Web-Vitals-Bericht auf Basis von Felddaten (abgerufen 15.08.2026)
Unsicher, ob deine Seiten bei Google überhaupt ankommen?
Wir prüfen für Unternehmen in Stuttgart und bundesweit, welche technischen Baustellen wirklich Sichtbarkeit kosten – und sagen ehrlich, welche du liegen lassen kannst.
