Hauptbereich
Agency
technisches-seo

Technisches SEO — was Google wirklich crawlen, rendern und indexieren muss

Redaktion ·

Worum es geht — und warum technisches SEO oft unsichtbar versagt

Technisches SEO ist die Schicht, die niemand sieht, wenn sie funktioniert — und die alles andere kaputt macht, wenn sie schweigt. Eine Site kann hervorragenden Content haben, fundierte Backlinks und ein sauberes UX-Design — wenn der Googlebot drei Klicks tief hängenbleibt, das Rendering-Budget für eine Single-Page-App aufbraucht oder das mobile Layout beim ersten Scroll zerspringt, landen die Seiten trotzdem nicht oben. Oder gar nicht erst im Index.

Der Themenbogen ist breit, aber er hat eine klare Reihenfolge: Finden → Crawlen → Rendern → Indexieren → Bewerten. Jeder Schritt hat eigene Stolperfallen, jeder hat sein eigenes Budget, und an jedem Übergang fallen Seiten heraus, die theoretisch hätten ranken können. Dieser Artikel führt dich durch die fünf Schichten — als Landkarte, an der du die Hebel deiner eigenen Site zuordnen kannst.

Schicht 1 — Finden: Sitemap, interne Links, Discovery

Bevor irgendetwas indexiert werden kann, muss Google die URL überhaupt kennen. Drei Wege führen dorthin: interne Verlinkung, externe Backlinks und die XML-Sitemap. Sitemap und interne Links sind die beiden Hebel, die du selbst kontrollierst.

Sitemap-Realität. Die Sitemap ist kein Indexierungsbefehl, sondern ein Vorschlag — „hier sind alle URLs, die ich für indexierungswürdig halte”. Google liest sie, gleicht sie mit dem internen Discovery-Modell ab und entscheidet selbst. Heißt: URLs, die ausschließlich über die Sitemap erreichbar sind und sonst nirgends verlinkt werden, ranken meistens schwach. Sitemap ersetzt keine Linkstruktur, sie ergänzt sie.

Interne Links — die unterschätzte Currency. Eine Seite, die von der Startseite in zwei Klicks erreichbar ist, wird häufiger gecrawlt und stärker bewertet als eine, die fünf Klicks tief liegt. Die Klicktiefe ist kein offizielles Ranking-Signal, aber sie korreliert sehr stark mit Crawl-Frequenz und Indexierungs-Wahrscheinlichkeit. Faustregel: Wichtige Seiten ≤ 3 Klicks von der Startseite, niemals tiefer als 5.

Orphan Pages. Seiten, die in der Sitemap stehen, aber keinen einzigen internen Link bekommen, sind aus Google-Sicht Außenseiter. Manche werden indexiert, viele nicht. Wer regelmäßig in der Search Console „Gefunden, derzeit nicht indexiert” sieht, hat oft genau dieses Problem.

Schicht 2 — Crawlen: Robots, Crawl-Budget, Crawl-Rate

Sobald Google eine URL kennt, schickt es einen Crawler. Bei großen Sites wird das schnell zur Mengen-Frage — und das ist der Punkt, an dem das Crawl-Budget ins Spiel kommt.

Crawl-Budget verstehen. Google teilt jeder Site ein implizites Budget zu — wie viele URLs pro Tag der Bot dort abholt. Das Budget ergibt sich aus zwei Faktoren: Crawl-Rate-Limit (was der Server verträgt, ohne unter Last zu kommen) und Crawl-Demand (wie wertvoll Google die Site einschätzt). Kleine Sites unter 1.000 URLs sehen davon nie etwas — Google crawlt einfach alles. Ab 10.000+ URLs, vor allem mit dynamisch generierten Filter-/Sortier-Seiten, wird Budget knapp.

Was Budget verbrennt.

  • Endlose Filter-URLs. /produkte?farbe=blau&groesse=m&sort=preis — wenn jede Kombination eine eigene URL erzeugt, hat Google plötzlich Millionen URLs zu crawlen, die alle dasselbe Inventar zeigen.
  • Pagination ohne Ende. Seiten 1 bis 4.000 mit jeweils zehn Produkten — der Bot crawlt brav und kommt nie zu den eigentlich wichtigen Detailseiten.
  • Soft 404s und Redirect-Ketten. Jede Weiterleitung kostet einen Crawl. Drei verkettete Redirects sind drei verschwendete Anfragen.
  • Zu langsame Antwortzeiten. Wenn der Server unter Last ins Stocken kommt, drosselt Google die Crawl-Rate — gut für den Server, schlecht für die Indexierungs-Aktualität.

Robots.txt — was wirklich passiert. Die robots.txt ist eine Crawling-Anweisung, keine Indexierungs-Anweisung. Eine in der robots.txt blockierte URL wird nicht gecrawlt — kann aber trotzdem indexiert werden, wenn sie über externe Links bekannt ist. Google zeigt dann im Suchergebnis den Hinweis „Für diese Seite sind keine Informationen verfügbar”. Wer eine Seite aus dem Index haben will, braucht ein noindex-Meta-Tag oder einen X-Robots-Tag-Header — und die Seite muss crawlbar sein, sonst kann der Bot das noindex nicht lesen. Häufiger Anfänger-Fehler: Seite per robots.txt blockieren und noindex setzen — das noindex greift nie.

X-Robots-Tag für Nicht-HTML. PDFs, Bilder, Feeds — alles was kein HTML-Meta-Tag tragen kann, wird über den HTTP-Header X-Robots-Tag gesteuert. Klassischer Use Case: PDF-Whitepaper, die zwar erreichbar bleiben sollen (für Direktlinks), aber nicht in der Google-Suche auftauchen — X-Robots-Tag: noindex setzen, fertig.

Schicht 3 — Rendern: Was Googlebot mit deinem JavaScript macht

Hier wird es heikel — und für JavaScript-lastige Sites ist es oft die teuerste Schicht. Der Googlebot crawlt in zwei Phasen: erst das initiale HTML, dann — wenn nötig — eine zweite Welle, in der eine Headless-Chrome-Instanz das JavaScript ausführt und das gerenderte DOM extrahiert.

Die Zwei-Wellen-Realität.

  1. Erste Welle: HTML-Crawl, sofort. Wenn der Content schon im HTML steht, wird er sofort indexiert.
  2. Zweite Welle: JavaScript-Rendering. Kann Stunden bis Tage dauern, bis Google den Renderer schickt. In der Zwischenzeit ist die Seite mit dem leeren HTML-Skelett indexiert — also praktisch ohne Inhalt.

Heißt konkret: Eine reine Client-Side-Rendering-Site (klassische React-SPA ohne SSR) ist langsamer indexierbar als eine SSR-Site, und in der Zwischenzeit unsichtbar. Google rendert sie irgendwann — aber eben nicht sofort, und nicht zuverlässig bei jedem Crawl.

Drei Rendering-Strategien im Vergleich:

| Strategie | Was Googlebot in Welle 1 sieht | Indexierungs-Geschwindigkeit | Stolperfalle | |---|---|---|---| | SSR (Server-Side Rendering) | Vollständiges HTML | Sofort | Server-Last, kompliziertes Caching | | SSG (Static Site Generation) | Vollständiges HTML | Sofort | Build-Zeit bei großen Sites | | CSR (Client-Side Rendering) | Leeres <div id="app"> | Verzögert (Welle 2) | Content unsichtbar bis Render | | Hybrid / Hydration | HTML + JS-Hydration | Sofort (HTML) | Hydration-Mismatch-Risiko |

Was den Renderer scheitern lässt. Lazy-Loading, das nur auf Mausbewegung triggert. Content, der erst nach Klick auf einen Tab erscheint. Routing, das pushState nutzt, aber keine echten Server-URLs. Cookie-Banner, die alles dahinter verstecken. Der Googlebot kommt mit diesen Fällen mal mehr, mal weniger gut zurecht — Verlass ist nicht.

Schicht 4 — Indexieren: Canonical, Duplicate Content, noindex

Der Crawler hat die Seite, der Renderer hat den Inhalt — jetzt entscheidet Google, ob die URL überhaupt in den Index wandert.

Canonical — der wichtigste unsichtbare Tag. Das <link rel="canonical"> sagt Google: „Wenn du diese Seite unter mehreren URLs findest, ist das hier die richtige.” Klassische Fälle: Produktseiten mit Filter-Parametern (?color=red zeigt aufs Original), Print-Versionen, AMP-Varianten, Mehrfach-Pfade durch Kategorien.

Was passiert, wenn das Canonical fehlt oder falsch ist. Google rät selbst — und entscheidet manchmal anders, als du gedacht hättest. Das Phänomen „Canonical chosen by Google ≠ User-declared canonical” sieht man in der Search Console als „Duplikat — Google hat eine andere kanonische URL gewählt als der Nutzer”. Häufige Ursache: schwache Inhalte auf der gewünschten Canonical, sodass Google die Variante mit mehr Backlinks bevorzugt.

noindex vs. Canonical — nicht verwechseln.

  • noindex: „Diese Seite gehört nicht in den Index.” Suchergebnisse: keine.
  • canonical: „Diese Seite gehört in den Index, aber unter dieser anderen URL.” Ranking-Signale werden auf das Canonical übertragen.

Beides gleichzeitig zu setzen ist ein Widerspruch. Google folgt meistens dem noindex. Das noindex-Tag gehört auf Suchergebnisseiten, Login-Bereiche, Tag-Listen mit dünnem Content, Filter-Permutationen — alles, was technisch erreichbar sein muss, aber im Index keinen Mehrwert hat.

Duplicate Content — meistens kein „Penalty”-Problem. Google straft Duplicate Content nicht ab — Google sortiert ihn. Heißt: Von zwei identischen Seiten landet eine im Index, die andere fällt heraus oder wird zusammengelegt. Das Problem entsteht, wenn die falsche Variante im Index landet. Sauberes Canonical und konsistente interne Verlinkung lösen 90 % der Fälle.

Schicht 5 — Bewerten: Mobile-First, Core Web Vitals, TTFB

Sobald die Seite im Index ist, beginnt die Bewertungsphase. Google misst, wie die Seite sich bei echten Nutzern verhält (Field-Daten via Chrome User Experience Report) und ergänzt das mit Lab-Daten (PageSpeed Insights). Die zentrale Metriken-Familie sind die Core Web Vitals.

Mobile-First-Indexing — das mobile HTML ist das Original

Seit der Umstellung auf Mobile-First-Indexing bewertet Google ausschließlich die mobile Version einer Site. Die Desktop-Version wird ignoriert. Das hat Konsequenzen, die viele unterschätzen:

  • Content, der auf Desktop sichtbar, auf Mobile aber hinter „Mehr lesen”-Buttons verborgen ist, gilt als versteckt — und kann schwächer ranken.
  • Strukturierte Daten, die nur auf Desktop ausgespielt werden, zählen nicht.
  • Interne Links, die nur in der Desktop-Navigation auftauchen (etwa weil das mobile Hamburger-Menü reduziert ist), werden nicht für die interne Linkstruktur gewertet.

Wer eine separate m.example.com-Mobile-Site betreibt (das machen heute fast nur noch alte Setups), muss damit leben, dass die die Hauptversion ist — alle Optimierungen, die nur auf Desktop greifen, sind verschenkt.

Core Web Vitals — drei Kennzahlen, drei Stolperfallen

Die Core Web Vitals haben sich seit 2024 stabilisiert auf drei Metriken, die echte User-Experience messen sollen:

LCP — Largest Contentful Paint. Wann erscheint das größte Inhaltselement? Ziel: ≤ 2,5 Sekunden. Häufigste Ursachen für schlechtes LCP: langsamer TTFB (Server zu langsam), render-blocking Resources (CSS/JS im <head> ohne defer), nicht-optimierte Hero-Bilder (3 MB JPEG ohne width/height und ohne moderne Formate).

CLS — Cumulative Layout Shift. Wie sehr springen Elemente während des Ladens? Ziel: ≤ 0,1. Klassische CLS-Killer: Bilder ohne width/height-Attribute, Webfonts, die FOIT/FOUT auslösen, dynamisch eingeschobene Banner, Cookie-Consent-Layer, die nach 800 ms aufploppen und alles nach unten schieben.

INP — Interaction to Next Paint. Wie schnell reagiert die Seite auf Interaktionen (Klick, Tap, Tastatur)? Ziel: ≤ 200 ms. INP hat 2024 FID (First Input Delay) abgelöst. Häufige Ursachen für schlechtes INP: schwerer JavaScript-Main-Thread (lange Tasks > 50 ms), zu viele Event-Listener, Hydration, die den Main-Thread für eine Sekunde lahmlegt.

Der Hebel hinter allem — TTFB

Time To First Byte ist die Reaktionszeit deines Servers auf die erste Anfrage. Sie geht in LCP direkt ein und beeinflusst, wie schnell der Browser überhaupt anfangen kann zu rendern. Ziel: ≤ 600 ms, idealerweise unter 300 ms. Wer ein TTFB von 1,2 Sekunden hat, kann am Frontend optimieren wie er will — LCP wird nie unter 2,5 Sekunden kommen.

Klassische TTFB-Killer: WordPress ohne Cache, dynamisch generierte Seiten ohne CDN, Datenbank-Queries pro Pageview, fehlende Cache-Control-Header. Ein gut eingestelltes Static-Site-Setup (oder SSG mit CDN davor) liegt typischerweise bei 50–150 ms — Größenordnung 10× besser als ein typisches LAMP-Setup ohne Tuning.

Praxis: Drei typische Sites, drei Fehler-Cluster

Site A — kleine B2B-Site, ~80 Seiten. Crawl-Budget irrelevant, JS-Rendering meist kein Thema (klassisches CMS). Die echten Hebel hier: TTFB unter 300 ms (Caching, CDN), saubere Canonicals (vor allem bei /de/, /en/-Varianten), Mobile-Layout ohne CLS. Core Web Vitals dominieren das Ranking-Bild.

Site B — Shopware-Shop mit 12.000 Produkten und Filtern. Crawl-Budget wird zur Zentralfrage. Filter-URLs müssen über robots.txt ausgeschlossen oder per noindex und Canonical gebändigt werden. Pagination braucht eine Strategie (entweder konsequent indexierbar oder konsequent canonicalisiert auf Seite 1). Sitemap muss aktuell sein. Render-Performance ist sekundär, weil Shopware serverseitig rendert.

Site C — Next.js-SaaS-Landingpage mit Dashboard. Klare Trennung der Rendering-Strategien: Marketing-Seiten als SSG (sofort indexierbar), App-Bereich als CSR mit noindex (gehört nicht in den Index). Hydration-Performance ist der INP-Killer Nummer eins — wer hier nicht aufpasst, hat schöne LCP-Werte und katastrophales INP. Mobile-Layout muss bei Hydration nicht „springen”, sonst CLS.

Stolperfallen, die immer wieder auftauchen

  • noindex in robots.txt blockierten URLs. Wird nie gelesen, also nie wirksam.
  • Canonical auf eine noindex-Seite. Widersprüchlich — Google ignoriert das Canonical.
  • Sitemap mit URLs, die 404 oder 301 sind. Verbrennt Crawl-Budget und gilt als Qualitätssignal in die falsche Richtung.
  • Hreflang-Loops zwischen DE/EN-Versionen ohne Selbst-Referenz. Jede Sprachvariante muss sich auch selbst per hreflang referenzieren.
  • CDN, das den User-Agent ignoriert und Googlebot Cookie-Consent-Banner zeigt. Der Bot sieht dann das Banner statt des Contents.
  • HTTP/2 Server Push für CSS — der Browser hatte das CSS oft schon im Cache. Push ist seit 2022 in Chrome praktisch tot, manche Setups versuchen es trotzdem noch.
  • Lazy-Loaded Bilder ohne loading="lazy"-Attribut. Manuelles Lazy-Loading per IntersectionObserver wird vom Crawler gerne übersehen — natives loading="lazy" ist sicher.

Diagnose-Werkzeuge in der richtigen Reihenfolge

  1. Search Console — Abdeckungsbericht. Zeigt, was indexiert ist, was abgelehnt wurde, und warum. Ist die erste Anlaufstelle für jedes „Warum rankt das nicht”-Problem.
  2. URL-Prüfung in der Search Console. Live-Test einer einzelnen URL: gerendertes HTML, Screenshot, JavaScript-Konsole. Klärt 80 % der Rendering-Fragen.
  3. PageSpeed Insights / Lighthouse. Lab- und Field-Daten zu Core Web Vitals. Field-Daten sind das, was wirklich zählt — Lab-Daten zeigen, warum es schief geht.
  4. Logfile-Analyse. Was crawlt Googlebot tatsächlich, wie oft, mit welchem Statuscode? Bei großen Sites unverzichtbar — bei kleinen meist Overkill.
  5. Screaming Frog / Sitebulb / JetOctopus. Crawler, die deine Site so durchgehen wie der Bot es würde. Findet kaputte Canonicals, Redirect-Ketten, fehlende hreflang.

Fazit

Technisches SEO ist kein einzelner Hebel, sondern eine Kette: Wenn ein Glied bricht, ist alles dahinter verloren. Die richtige Reihenfolge — Finden, Crawlen, Rendern, Indexieren, Bewerten — ist gleichzeitig die Reihenfolge, in der du Probleme diagnostizieren solltest. Es bringt nichts, an Core Web Vitals zu schrauben, wenn die Seite gar nicht im Index landet, weil das Canonical falsch zeigt. Und es bringt nichts, das Canonical zu fixen, wenn Googlebot die Seite nie crawlt, weil sie 6 Klicks tief liegt.

Für die meisten produktiven Sites lohnt sich folgende Priorisierung: Erst die Indexierungs-Lücken in der Search Console schließen (Schichten 1–4), dann die Core Web Vitals optimieren (Schicht 5). Performance-Optimierung auf einer Site, die nicht im Index ist, ist Kosmetik im Wartesaal.

Wer SSR oder SSG nutzt, hat den Großteil der JavaScript-Rendering-Probleme automatisch gelöst — und kann sich auf Crawl-Budget, Canonicals und Core Web Vitals konzentrieren. Wer eine reine SPA ohne SSR betreibt, sollte sich ehrlich fragen, ob die SEO-relevanten Bereiche nicht in eine SSG-Schicht gehören. Die Migration ist Aufwand, aber sie ist die einzige saubere Lösung — alles andere bleibt ein Wartespiel mit Googles zweiter Render-Welle.

Themenuebersicht

Technisches SEOCrawling & IndexierungCore Web VitalsJavaScript SEOPageSpeed & Performance