Technisches SEO · SEO-Nachschlagewerk

Kurz gefasst — Technisches SEO sorgt dafür, dass eine Suchmaschine eine Seite abrufen, rendern und indexieren kann; das Ranking ist der Schritt danach und entscheidet sich an Relevanz, nicht an Technik. Fast nichts in diesem Kapitel ist ein direkter Ranking-„Boost”. Es ist Infrastruktur: Sie verhindert Verluste, verschwendet kein Crawl-Budget und stellt sicher, dass die richtige URL mit dem richtigen Status und dem richtigen Inhalt im Index landet. Das ist der unspektakuläre, aber entscheidende Teil.

Vier getrennte Schritte — kein einzelner Vorgang. Jeder Pfeil ist ein Tor: robots.txt steuert, ob gecrawlt wird; noindex und canonical steuern die Indexierung; das Ranking entscheidet dann Relevanz und Qualität. Der Zyklus beginnt laufend von vorn.

Crawling, Rendering, Indexing, Ranking — vier getrennte Schritte

Googlebot entdeckt und ruft URLs ab (Crawling), führt JavaScript aus (Rendering), analysiert und speichert die Seite (Indexing) und sortiert sie erst dann für eine konkrete Suchanfrage (Ranking). Der häufigste Denkfehler ist, diese Schritte zu verschmelzen: gecrawlt heißt nicht indexiert, und indexiert heißt nicht gerankt.

Das Rendering läuft in zwei Wellen: Google crawlt zuerst das Roh-HTML und stellt die Seite für die JavaScript-Ausführung in eine Render-Queue. Diese zweite Welle kann warten. Der Web Rendering Service Fachbegriff (WRS) ist dabei nichts anderes als ein aktueller Headless-Chrome, der modernes JS/ES6 verarbeitet. R1

robots.txt steuert das Crawling — nicht den Index

Die robots.txt ist eine Crawl-Anweisung: Sie sagt, welche Pfade ein Bot abrufen darf. Sie ist kein Werkzeug, um Seiten aus dem Index zu halten. Eine per Disallow gesperrte URL kann über externe Links trotzdem im Index landen — Google sieht dann nur die URL, nicht den Inhalt.

Eine verwandte Unterscheidung: noindex ist eine Direktive (Google befolgt sie verbindlich). nofollow, sponsored und ugc sind seit 2019/2020 dagegen nur noch Hints, die Google überstimmen kann. Wer Indexierung steuern will, nutzt noindex, nicht nofollow. R1

Index-Steuerung per Meta-Tag und `X-Robots-Tag`

Für HTML-Seiten setzt man die robots-Direktiven als Meta-Tag im <head>. Für alles andere — PDFs, Bilder, beliebige Nicht-HTML-Ressourcen — geht das nur per HTTP-Header X-Robots-Tag. Google bestätigt ausdrücklich, dass Header und Meta-Tag „the same effect” haben. Der Header kann jede Meta-Robots-Regel ausdrücken (noindex, nofollow, noarchive, max-snippet, unavailable_after …). R11

Treffen mehrere Direktiven aufeinander — etwa ein Header index und ein Meta-Tag noindex —, gewinnt die restriktivste: noindex schlägt index. Das ist eine häufige, unbeabsichtigte Konfliktquelle, wenn Edge und Origin beide Header setzen.

Sitemaps gehören in dieselbe Familie: Sie sind ein Discovery-Hilfsmittel, keine Index-Garantie. Hinein gehören nur 200-OK-, indexierbare, kanonische URLs — keine weitergeleiteten, noindex- oder parameter-duplizierten Adressen. Tägliches erneutes Einreichen bringt keinen Vorteil. R1

Crawl-Budget: für die meisten Sites kein Thema

Crawl-Budget Fachbegriff ist real, aber relevant nur für große Sites (über ~1 Mio. URLs) und mittlere Sites (über ~10.000 URLs, täglich aktualisiert). Für kleinere Sites ist es praktisch kein Thema — Sitemap aktuell halten und den Index-Coverage-Report prüfen reicht. R1

Das Budget setzt sich aus zwei Größen zusammen: Crawl-Kapazität (was der Server verträgt, ohne langsam zu werden) und Crawl-Demand (wie viel Google crawlen will — nach Popularität, Inventar, Aktualität). Die wirksamsten Hebel sind banal: schnelle Serverantworten, saubere Statuscodes und das Konsolidieren von Duplikaten. Faceted Navigation ist laut Gary Illyes für rund die Hälfte aller Crawl-Probleme verantwortlich. R6

Statuscodes & Redirects: die Aussage an die Maschine

Ein Statuscode ist eine Aussage an die Suchmaschine über den Zustand einer URL. Den richtigen zu wählen, entscheidet, welche URL im Index bleibt und welche Signale erhalten bleiben.

Was ist mit der URL passiert?

301

Dauerhaft umgezogen

Ziel-URL wird indexiert, die alte fällt aus dem Index. Der Standard für Migrationen.

302· 307

Nur temporär woanders

Die alte URL bleibt im Index. Ein 302 für einen dauerhaften Umzug ist der häufigste Migrationsfehler. 307 = HTTP/1.1, methoden-erhaltend.

404

Nicht gefunden — kommt evtl. zurück

Kein Strafsignal. Interne Broken Links trotzdem aufräumen — wegen Nutzererfahrung und Crawl-Effizienz, nicht aus Angst vor einer Strafe.

410

Endgültig entfernt

Wie 404, nur ein etwas stärkeres Signal für den schnelleren Drop aus dem Index.

Soft‑404

200 OK, aber Inhalt fehlt

Anti-Pattern: verschwendet Crawl-Budget. Einen echten 404/410-Status liefern statt einer 200-„Nicht gefunden"-Seite.

Der Statuscode ist eine Aussage an die Suchmaschine — wähle ihn nach Absicht, nicht nach Bequemlichkeit. Ketten auf einen Hop reduzieren, intern direkt auf die Ziel-URL verlinken, Loops vermeiden.

Der hartnäckigste Mythos hier ist der angebliche PageRank-Verlust bei 301-Weiterleitungen. Er ist überholt:

Ketten und Loops sind die eigentliche Gefahr: Jeder Hop kostet Crawl-Kapazität und Latenz (ein LCP-Risiko). Ketten auf einen Hop reduzieren, intern direkt auf die finale Ziel-URL verlinken, Loops vermeiden. Eine besonders tückische Variante entsteht, wenn Edge und Origin beide Redirect-Regeln setzen (z. B. eine trailingSlash-Logik auf beiden Ebenen) — das Ergebnis ist eine Endlosschleife. Regel: Redirect-Logik in einer Schicht zentralisieren. R11

Duplicate Content & Canonical

Auch hier ein zählebiger Mythos — die „Duplicate-Content-Strafe”:

rel="canonical" ist ein Signal, keine Direktive — Google kann eine andere kanonische URL wählen, was in der Search Console als „Duplikat, Google hat eine andere Canonical gewählt” sichtbar wird. Weitere Canonical-Signale: HTTPS vor HTTP, konsistente interne Verlinkung, Sitemaps, hreflang-Cluster. Jede indexierbare Seite sollte per Self-Canonical Fachbegriff auf sich selbst zeigen.

www/non-www, http/https und Trailing-Slash erzeugen technisch unterschiedliche URLs — eine Variante wählen und konsistent darauf kanonisieren bzw. weiterleiten. R1 Bei der Pagination zeigt jede Seite per Self-Canonical auf sich selbst (nicht auf Seite 1), mit crawlbaren <a href>-Links — „Load more”/Infinite Scroll braucht echte verlinkte URLs, weil Googlebot nicht klickt. R6

hreflang: international ohne Selbstsabotage

hreflang annotiert sprachliche/regionale Varianten. Syntax: Sprachcode zuerst (ISO 639-1), optional gefolgt vom Regionscode (ISO 3166-1 Alpha-2) — hreflang="de-DE", hreflang="en-gb" (nicht „en-uk”, ein klassischer Fehler). Absolute URLs sind Pflicht. x-default markiert die Fallback-/Sprachwähler-Seite und kommt nur einmal pro Cluster vor. Jede Variante muss jede andere referenzieren (Return-Tags) und sich selbst einschließen. R1

Ein hreflang-Cluster ist ein wechselseitiges Netz: Jede Variante (de-DE, en-GB, en-US) referenziert jede andere und sich selbst — die Return-Tags. x-default benennt einmal pro Cluster die Fallback-/Sprachwähler-Seite. Bestätigt eine Seite die Verknüpfung nicht zurück, verwirft Google die Annotation — schon ein fehlendes Return-Tag lässt das Paar ins Leere laufen.

Wie X-Robots-Tag lassen sich Canonical und hreflang auch per HTTP-Header setzen — für Nicht-HTML-Dateien (PDF) ist der Header sogar die einzige Methode. Wichtig: Header- und HTML-Variante synchron halten, sonst entstehen widersprüchliche Signale („Configuration Drift”). R11

JavaScript-SEO & Rendering-Strategien

Reines Client-Side Rendering kann Indexierung verzögern oder verhindern, wenn kritischer Inhalt erst nach der JS-Ausführung erscheint. Faustregel: kritische Seiten (Home, Produkt, Artikel, Landing) server- oder statisch rendern; <title>, Meta und canonical ins ausgelieferte HTML schreiben, nicht per JS nachträglich ändern. Die Wahl der Rendering-Architektur bestimmt direkt Crawlbarkeit und Performance:

Modell	JS beim ersten Laden	Hydration	Eignung für Googlebot
CSR (klassische SPA)	hoch (alles im Client)	—	mittel — landet in der Render-Queue
Klassisches SSR	mittel	ganze Seite	gut — HTML ist sofort da
Islands (Astro)	niedrig (nur „Inseln”)	partiell	exzellent
RSC + Streaming (Next.js)	mittel	reduziert	exzellent
Resumability (Qwik)	nahezu null	keine	exzellent

Bei Streaming-SSR müssen die indexierungsrelevanten Daten (title, Meta, canonical, strukturierte Daten) in den ersten HTML-Chunks im <head> ankommen, nicht am Dokumentende. Bricht der Stream ab, sollte der Server einen 500 senden (erzwingt Re-Crawl) statt einen 200 mit unvollständigem Inhalt zu hinterlassen. Hydration-Mismatches — etwa durch Math.random()/new Date() im Render-Body oder ungültiges HTML-Nesting (<div> in <p>) — zwingen das Framework, den DOM zu verwerfen und client-seitig neu zu rendern, was die Crawler-Last verdoppelt. Technical-SEO

Core Web Vitals: LCP, INP, CLS

Die Core Web Vitals Fachbegriff messen reale Nutzererfahrung über das 75. Perzentil echter Felddaten (CrUX): LCP < 2,5 s (Ladewahrnehmung), INP < 200 ms (Reaktivität), CLS < 0,1 (visuelle Stabilität). Mindestens 75 % der Besuche müssen „Good” sein.

INP optimiert man am Main Thread: lange Tasks (über 50 ms) aufbrechen, mit scheduler.yield() Kontrolle zurückgeben, Layout Thrashing vermeiden und mit content-visibility: auto Off-Screen-Rendering überspringen. Zur Diagnose im Feld liefert die Long Animation Frames API (LoAF) die Attribution, welches Skript blockiert hat. Technical-SEO Core Web Vitals sind ein bestätigtes, aber leichtes Ranking-Signal — ein Tiebreaker zwischen ähnlich relevanten Ergebnissen, kein Ersatz für Relevanz. (TTFB ist selbst kein Core Web Vital, beeinflusst aber LCP.)

Strukturierte Daten: Eligibility, kein Ranking-Boost

Strukturierte Daten (Schema.org, bevorzugt als JSON-LD) helfen Maschinen, eine Seite zu verstehen, und machen sie für Rich Results eligibel — Pflicht-Properties müssen vorhanden sein, sonst keine Eligibility.

Der strategisch sinnvolle Fokus liegt damit auf Commerce-Typen (Product, Offer, Review) und Entitäten-Markup (Organization, sameAs zu Wikidata/Profilen) — Letzteres stärkt die Entitätsauflösung und ist gerade für KI-Antworten relevant.

Architektur, HTTPS & Klicktiefe

Für die interne Architektur zählt nicht die URL- oder Verzeichnistiefe, sondern die Verlinkung: Prioritätsseiten sollten in ≤ 2–3 Klicks von der Startseite erreichbar sein, keine verwaisten Seiten, fokussierte und beschreibend verankerte interne Links statt „link to everything”. Die Startseite ist der stärkste Equity-Verteiler — gezielt auf Top-Inhalte verlinken, nicht gleichrangig auf alles.

R-Verifikation

Steuerung an der Edge / Middleware-Ebene

Die Edge-/Middleware-Schicht läuft pro Request vor der Antwort, geografisch verteilt in CDN-Knoten nahe am Nutzer. Sie ist der natürliche Konvergenzpunkt für Redirects, X-Robots-Tag, Canonical-/hreflang-Header und Security-Header — performant, weil ohne Origin-Roundtrip. R11

CSP × Rendering — der zentrale Gotcha

Der größte technische Fallstrick an der Edge sind nicht Redirects, sondern die Content-Security-Policy. Der WRS ist ein Headless-Chromium: Eine zu strikte CSP kann ihm das Laden von JS/CSS verwehren — dann fehlt der per JavaScript erzeugte Inhalt im gerenderten DOM und ist nicht indexierbar. Martin Splitt: blockierte Ressourcen seien zwar kein Cloaking, aber „… we can’t index it”, wenn der Inhalt nur mit ihnen erscheint. Lösung bei SSR: pro Request einen Nonce im server-gerenderten HTML, vorab mit Content-Security-Policy-Report-Only testen, dann das gerenderte DOM im URL-Inspection-Tool gegenprüfen.

R11

Geo-/Locale-Routing: Auswahl statt Zwang

Bots verifizieren — nicht am User-Agent

Der User-Agent ist fälschbar. Verifizierten Googlebot erkennt man per Forward-confirmed reverse DNS: Die zugreifende IP rück-auflösen (Hostname muss auf googlebot.com/google.com/googleusercontent.com enden) und diesen Hostnamen wieder vorwärts auflösen — er muss zur Original-IP zurückführen. Alternativ gegen Googles offizielle IP-JSON-Ranges matchen; die Verifikation am Edge cachen (DNS ist teuer). Eine WAF oder ein Bot-Fight-Mode darf den verifizierten Googlebot nie blocken, sonst brechen Crawl und Rendering. R11

Eine letzte, banale, aber tödliche Falle: die versehentliche noindex-Auslieferung in Produktion, etwa weil eine Staging-Edge-Regel mitkopiert wurde. Das ist der häufigste Totalausfall der Indexierung — und der Grund, warum der nächste Abschnitt zählt.

Verifikation: was Googlebot wirklich sieht

Technisches SEO ist nur so gut wie seine Überprüfung. Drei Werkzeuge reichen für das meiste:

URL-Inspection (Search Console), Live-Test: zeigt gecrawltes HTML, das gerenderte DOM, einen Screenshot, die HTTP-Response-Header (X-Robots-Tag, canonical, Status) und geblockte Ressourcen. Der Inhalt muss im gerenderten DOM erscheinen.
curl -I: inspiziert die rohen Response-Header — inklusive ungewollter Ergänzungen durch Reverse-Proxies oder CDN. (Genau so wird auch das noindex dieser Site live geprüft.)
Page-Indexing-Report: zeigt, von welchen Seiten Google noindex extrahiert hat und wo 4xx/Blockaden auftreten.

Das größere Bild. Kaum etwas in diesem Kapitel ist ein direkter Ranking-Faktor — und das ist der Punkt. robots.txt, Statuscodes, Canonical, hreflang, Rendering, strukturierte Daten und Edge-Header sind die Klempnerei, die Verluste verhindert und der Suchmaschine ihre Arbeit trivial macht. „Kein Ranking-Faktor” heißt eben nicht „irrelevant”: Diese Dinge wirken über Crawlbarkeit, Eligibility und vermiedene Selbstsabotage. Wer sie beherrscht, schafft die Voraussetzung dafür, dass Relevanz und Qualität überhaupt zur Geltung kommen.