Technisches SEO

Nach diesem Level kannst du bei jeder URL, die in Google fehlt, genau benennen, an welcher Stelle die Kette gerissen ist. Diese Kette hat drei Glieder, und die meisten behandeln sie als eines: Googlebot muss die URL crawlen können, Google muss sich für die Indexierung entscheiden, und erst danach kann die Seite überhaupt ranken. Ein Fehler im ersten Glied wird auf dem Server, in der robots.txt oder über die interne Verlinkung behoben. Ein Fehler im zweiten Glied lässt sich fast nie über Konfiguration beheben.

Genau diese Vermischung ist der häufigste Denkfehler in der technischen Suchmaschinenoptimierung. Technisches SEO wird als Liste behandelt, die man einmal abhakt (Sitemap eingereicht, robots.txt vorhanden, HTTPS aktiv), obwohl es eine Diagnosedisziplin ist. Die nützliche Frage lautet nie „habe ich eine Sitemap?“, sondern „welche URLs ruft Googlebot diese Woche ab, welche indexiert Google bewusst nicht, und was haben diese URLs gemeinsam?“. Wer das beantworten kann, löst echte Probleme. Wer Häkchen setzt, löst die Probleme einer fremden Website.

Der zweite verbreitete Irrtum ist die Annahme, ein technisches Problem melde sich mit einer Fehlermeldung. Das tut es nicht. Die teuren Fehler im technischen SEO sind leise. Eine Weiterleitungskette funktioniert für Besucherinnen und Besucher tadellos. Ein falsch gesetzter Canonical Tag leert innerhalb weniger Wochen einen ganzen Bereich aus dem Index. Ein Filterparameter erzeugt Hunderttausende URLs, die niemand bestellt hat. Der Browser beschwert sich nie. Die Google Search Console meldet es spät. Ein eigener Crawl und die Logfiles des Servers sehen es früh.

Dieses Level ist zum Anwenden geschrieben, nicht nur zum Lesen. Jede Lektion endet in einer konkreten Handlung: ein Crawl mit Screaming Frog, eine Auswertung über eine Logdatei, eine bestimmte Prüfung in der Google Search Console, eine Checkliste, die du abarbeitest, bevor jemand den Server anfasst.

Was dieses Level abdeckt

• Eine robots.txt schreiben und prüfen, die Googlebot und die KI-Crawler steuert, ohne versehentlich Ressourcen zu sperren, die Google zum Rendern braucht.
• Ein Crawling-Problem von einem Indexierungsproblem und von einem Qualitätsproblem trennen und den Bericht in der Google Search Console benennen, der es belegt.
• Einen vollständigen Screaming-Frog-Crawl lesen: Statuscodes, Canonical Tags, Klicktiefe, Duplicate Content und Weiterleitungsketten.
• Core Web Vitals anhand der von Google dokumentierten Schwellenwerte einordnen und entscheiden, ob sich Performance-Arbeit bei dir lohnt.
• Eine JavaScript-Website diagnostizieren: was Googlebot nach dem Rendering sieht und was nie im ausgelieferten HTML landet.
• Einen Website-Relaunch oder eine neue URL-Struktur planen, ohne Rankings zu verlieren, mit Checkliste davor und systematischer Kontrolle danach.

Crawling, Rendering und Indexierung sind drei getrennte Entscheidungen

Google trifft zu jeder URL drei getrennte Entscheidungen, und wer sie zu einer zusammenzieht, stellt fast immer die falsche Diagnose. Die erste betrifft das Crawling: Googlebot fordert die URL an, und der Server antwortet oder eben nicht. Die zweite betrifft das Rendering: Bei Seiten, die auf JavaScript angewiesen sind, führt Google den Code in einer Chromium-Instanz aus und erhält das endgültige HTML. Die dritte betrifft die Indexierung: Google entscheidet, ob diese Seite einen Platz im Index verdient.

Jede dieser Entscheidungen scheitert aus eigenen Gründen. Crawling scheitert an der robots.txt, an 5xx-Antworten, an langsamen Serverantwortzeiten oder daran, dass die URL schlicht nirgends verlinkt ist. Rendering scheitert, wenn Inhalte von einer Anfrage abhängen, die Googlebot nicht ausführt, wenn die Hydration zu lange dauert oder wenn interne Links keine echten Anker-Elemente mit href-Attribut sind. Indexierung scheitert, wenn Google die Seite sehr wohl gesehen hat und zu dem Schluss kommt, dass sie nichts beiträgt.

Der letzte Fall sorgt für die größte Frustration. Der Status „Gecrawlt – zurzeit nicht indexiert“ in der Google Search Console ist kein technischer Fehler, den eine erneut eingereichte Sitemap behebt. Er ist ein Urteil. Google hat Ressourcen investiert, um die Seite abzurufen, und befunden, dass sie den Speicherplatz nicht rechtfertigt. Erneutes Einreichen, eine Indexierungsanfrage oder nachträglich ergänzte strukturierte Daten ändern dieses Urteil nicht. Es ändert sich nur, wenn die Seite etwas sagt, was eine besser platzierte Seite nicht schon sagt.

Core Web Vitals und was Ladezeit wirklich wert ist

Ladezeit ist ein moderater Rankingfaktor und ein großer Geschäftsfaktor, und so solltest du sie behandeln. Google dokumentiert drei Core Web Vitals mit öffentlichen Schwellenwerten: LCP (Largest Contentful Paint) bei höchstens 2,5 Sekunden, INP (Interaction to Next Paint) bei höchstens 200 Millisekunden und CLS (Cumulative Layout Shift) bei höchstens 0,1. Google bewertet diese Werte im 75. Perzentil echter Seitenaufrufe, nicht in einem isolierten Labortest.

Die praktische Folge dieses Perzentils ist unbequem: Eine Website kann auf dem Entwicklerlaptop blitzschnell wirken und trotzdem durchfallen. Felddaten stammen von echten Nutzerinnen und Nutzern, mit echten Smartphones und echten Verbindungen. Ein Performance-Audit, das nur einen lokalen Lighthouse-Lauf betrachtet, bleibt deshalb unvollständig. Es liefert einen Laborwert, und der Laborwert ist nicht der Wert, den Google verwendet.

Die zweite Folge betrifft die Reihenfolge. Wenn eine Seite nicht indexiert ist, ist ihr LCP bedeutungslos. Wenn ein ganzer Bereich in der robots.txt gesperrt ist, ist sein CLS bedeutungslos. Performance wird optimiert, sobald Crawling und Indexierung funktionieren, und nicht vorher. In diesem Level steht Ladezeit deshalb genau dort: nach den Lektionen zu Crawling und Indexierung und vor jeder kosmetischen Politur.

Die Änderungen, die leise kaputtgehen

Weiterleitungen, Canonical Tags und ein Website-Relaunch teilen eine gefährliche Eigenschaft: Schlecht gemacht funktioniert die Website für Menschen weiterhin. Wer auf einer Kette aus drei Weiterleitungen landet, sieht die Zielseite und merkt nichts. Googlebot merkt es, denn jeder Sprung kostet eine Anfrage, und eine lange Kette wird irgendwann wie eine Sackgasse behandelt.

Canonical Tags haben dasselbe Risikoprofil. Ein vom Template erzeugter Canonical Tag, der jede Produktseite auf ihre Kategorieseite zeigen lässt, entfernt diese Produktseiten aus dem Index, ohne einen einzigen Browserfehler zu erzeugen. Das Symptom kommt Wochen später als Trafficrückgang, den niemand mit dem Deployment des Vormonats verbindet. Die Absicherung ist ein regelmäßiger Crawl mit Screaming Frog, der jede gecrawlte URL mit der von ihr deklarierten Canonical-URL vergleicht.

Ein Website-Relaunch bündelt all diese Risiken auf einmal, und genau deshalb bekommt er eine eigene Lektion. Ein Wechsel von Domain, CMS oder URL-Struktur ohne vollständige und getestete Weiterleitungsmatrix ist der schnellste bekannte Weg, Sichtbarkeit zu verlieren. Was einen Relaunch rettet, ist nicht die Heldentat am Launch-Wochenende. Es ist die vorher vorbereitete Checkliste und die systematische Kontrolle danach.

Facetten, Paginierung und Crawl Budget im Onlineshop

Ein Onlineshop erzeugt URLs deutlich schneller, als Googlebot sie crawlen kann, und darin liegt die Wurzel jedes Crawl-Budget-Problems. Ein Katalog mit tausend Produkten und fünf kombinierbaren Filtern bringt mühelos Hunderttausende URL-Kombinationen hervor, fast alle mit nahezu identischem Inhalt. Googlebot entdeckt sie, crawlt sie und verbraucht dafür Anfragen, die den Seiten fehlen, die tatsächlich verkaufen.

Crawl Budget ist allerdings kein universelles Problem. Eine Website mit zweihundert Seiten hat kein Crawl-Budget-Problem, so oft der Begriff auch fällt: Googlebot erfasst sie mühelos vollständig. Crawl Budget wird relevant, sobald die Zahl der crawlbaren URLs die Zahl der URLs, die existieren sollten, deutlich übersteigt. Das passiert vor allem in Onlineshops, auf Kleinanzeigenportalen und überall dort, wo die interne Suche indexierbar ist.

Die Lösung kombiniert mehrere Werkzeuge aus diesem Level, und keines wirkt allein. Die interne Verlinkung entscheidet, was zuerst entdeckt wird, die robots.txt entscheidet, was gar nicht erst gecrawlt wird, Canonical Tags konsolidieren die Dubletten, und die Logfile-Analyse ist das Einzige, was den Erfolg der Änderung bestätigt. Serverlogs zeigen exakt, was Googlebot wann angefordert hat, ohne Stichprobe und ohne Schätzung.

Triage-Reihenfolge: Symptom, wahrscheinliche Ursache, Prüfort

Eine technische Diagnose läuft von unten nach oben: erst Zugriff, dann Indexierung, dann Qualität, zuletzt Ladezeit. Diese Tabelle listet die häufigsten Symptome in der Reihenfolge, in der du sie ausschließen solltest, mit der wahrscheinlichsten Ursache und dem Ort, an dem du sie bestätigst.

Reihenfolge	Symptom	Wahrscheinliche Ursache	Wo du nachsiehst
1	URL taucht auch mit dem site:-Operator nicht in Google auf	Sperre in der robots.txt, noindex-Tag oder eine 4xx/5xx-Antwort	URL-Prüfung in der Google Search Console und ein Crawl mit Screaming Frog
2	„Gefunden – zurzeit nicht indexiert“	Googlebot kennt die URL, priorisiert sie aber nicht: schwache interne Verlinkung oder aufgebrauchtes Crawl Budget	Bericht zur Seitenindexierung und Logfiles des Servers
3	„Gecrawlt – zurzeit nicht indexiert“	Qualitätsurteil von Google, doppelte oder fast doppelte Inhalte	Direkter Vergleich mit URLs derselben Website, die indexiert werden
4	„Alternative Seite mit richtigem kanonischen Tag“ bei Seiten, die indexiert werden sollen	Vom Template erzeugter Canonical Tag auf die falsche URL	Canonical-Spalte im Screaming-Frog-Crawl
5	Plötzlicher Trafficeinbruch direkt nach einem Deployment	Verlorene Weiterleitungen, geänderte URL-Struktur oder eine Staging-robots.txt im Livebetrieb	Vergleich der Crawls vorher und nachher sowie die robots.txt im Livebetrieb
6	Google indexiert eine unvollständige Version der Seite	Per JavaScript nachgeladene Inhalte, die Googlebot beim Rendern nicht erhält	Test für Rich-Suchergebnisse und das gerenderte HTML in der URL-Prüfung
7	Tausende Parameter-URLs im Index	Crawlbare Facetten und eine indexierbare interne Suche	Bericht zur Seitenindexierung und ein Crawl im Listenmodus
8	Seite rankt, konvertiert auf dem Smartphone aber schlecht	Core Web Vitals außerhalb des Schwellenwerts in den Felddaten	Core-Web-Vitals-Bericht in der Google Search Console

Die 14 Lektionen dieses Levels

1. robots.txt 2026: der vollständige Leitfaden (inklusive KI-Bots)
2. XML-Sitemaps: wann sie zählen und wann nicht
3. Crawl Budget: wen es wirklich betrifft
4. Indexierung: warum „Gecrawlt – zurzeit nicht indexiert“ ein Qualitätsurteil ist
5. Canonical Tags, noindex und die Kunst, sich nicht zu widersprechen
6. JavaScript-SEO: Rendering, Hydration und was Googlebot sieht
7. Core Web Vitals 2026: LCP, INP, CLS – und was sie wirklich wert sind
8. Weiterleitungen: 301, 302, Ketten und stille Verluste
9. HTTP-Statuscodes für SEOs
10. Paginierung, Facetten und die Crawl-Hölle im Onlineshop
11. Logfile-Analyse: dein am stärksten unterschätztes Instrument
12. Hreflang und Internationalisierung ohne Kollateralschäden
13. Website-Relaunch: die SEO-Checkliste, die das Desaster verhindert
14. Mit Screaming Frog crawlen wie ein Profi

So arbeitest du dieses Level durch

Die Reihenfolge der Lektionen in diesem Level ist eine Diagnosereihenfolge und keine thematische Sortierung, also halte dich daran. Die ersten vier Lektionen bauen das mentale Modell von Crawling und Indexierung auf. Ohne dieses Modell wirken die Lektionen zu Canonical Tags und JavaScript wie zusammenhanglose Tricks.

• Bestätige vor dem Start deine Website in der Google Search Console und exportiere den Bericht zur Seitenindexierung. Dieser Bericht ist das Arbeitsmaterial fast aller Lektionen hier.
• Installiere Screaming Frog in der kostenlosen Version und starte heute einen vollständigen Crawl deiner Website. Hebe diesen Crawl als Ausgangswert auf, gegen den du spätere Änderungen vergleichst.
• Nimm eine Lektion pro Tag und wende sie auf deine eigene Website an, bevor du weitergehst. Zwei Lektionen hintereinander gelesen, ohne etwas umzusetzen, hinterlassen nichts.
• Frage deinen Hoster gleich zu Beginn des Levels nach Zugriff auf die rohen Serverlogs. Das dauert meist ein paar Tage, und für die Logfile-Analyse brauchst du sie.
• Heb dir die Relaunch-Lektion für einen echten Website-Relaunch auf und komm dann mit der Checkliste vor dir darauf zurück.

Wenn diese vierzehn Lektionen erledigt sind, ist deine Infrastruktur kein Engpass mehr, und du kannst die übrige Zeit in Inhalte und Verlinkung stecken, wo Rankings tatsächlich entstehen. Wie dieses Level zu den anderen passt, siehst du im vollständigen Überblick des kostenlosen SEO-Kurses, in dem die vorherigen und die folgenden Level in der empfohlenen Reihenfolge stehen.