Technisches SEO: Der Leitfaden für Entwickler und Marketer

Was technisches SEO umfasst

Technisches SEO ist alles, was auf der Ebene von Server, Code und URLs dafür sorgt, dass Suchmaschinen deine Inhalte finden, abrufen, darstellen und in den Index aufnehmen können. Es ersetzt keine guten Inhalte, aber ohne dieses Fundament nützen sie wenig: Eine Seite, die Google nicht crawlen oder rendern kann, kann nicht sinnvoll ranken.

Google beschreibt den Ablauf in drei Schritten: Crawling (die URL wird abgerufen), Rendering (bei JavaScript-Seiten wird der Code ausgeführt) und Indexierung (der Inhalt wird analysiert und gespeichert). Jeder Schritt kann scheitern, und jeder hat eigene Stellschrauben. Dieser Leitfaden folgt genau dieser Reihenfolge. Alle Aussagen zu Google stützen sich auf die Search-Central-Dokumentation, Stand: Oktober 2026.

Was technisches SEO nicht kann: Rankings garantieren. Es beseitigt Hindernisse. Ob eine technisch saubere Seite gut platziert wird, hängt von Relevanz, Inhalt und Wettbewerb ab.

Crawling: robots.txt und Sitemaps

robots.txt: Crawling steuern, nicht Indexierung

Die Datei robots.txt sagt Crawlern, welche URLs sie abrufen dürfen. Google nennt als Hauptzweck, den Server nicht mit Anfragen zu überlasten. Sie muss im Stammverzeichnis des jeweiligen Hosts liegen und gilt nur für genau dieses Protokoll, diesen Host und diesen Port: Eine Datei auf example.com deckt weder http://example.com noch eine Subdomain wie m.example.com ab.

User-agent: *
Disallow: /suche/
Disallow: /warenkorb/

Sitemap: https://www.example.com/sitemap.xml

Der wichtigste Denkfehler: robots.txt ist laut Google „kein Mechanismus, um eine Webseite aus Google herauszuhalten". Eine gesperrte URL kann trotzdem indexiert werden, wenn andere Seiten auf sie verlinken, dann meist ohne Beschreibung. Wer eine Seite aus dem Index haben will, braucht noindex oder einen Passwortschutz, siehe den Abschnitt zur Indexierung.

Wichtig: Sperre in der robots.txt keine Skripte oder Stylesheets, die Google zum Verstehen der Seite braucht. Bei JavaScript-Seiten rendert Google laut Dokumentation weder JavaScript aus blockierten Dateien noch Inhalte auf blockierten Seiten.

Sitemaps: Hinweis auf die gewünschten URLs

Eine Sitemap listet die URLs, die du indexiert sehen willst. Sie ist ein Hinweis, keine Garantie. Nach Googles Dokumentation gilt:

• Formate: XML, RSS/Atom oder eine einfache Textdatei mit einer URL pro Zeile.
• Grenzen: höchstens 50 MB unkomprimiert oder 50.000 URLs pro Datei. Darüber hinaus teilst du auf und nutzt eine Sitemap-Indexdatei.
• Nur kanonische URLs aufnehmen, jeweils absolut, die Datei in UTF-8.
• <lastmod> nutzt Google nur, wenn es konsistent und nachprüfbar stimmt. Es soll echte inhaltliche Änderungen abbilden, kein neues Copyright-Jahr.
• <priority> und <changefreq> ignoriert Google.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.com/leitfaden/</loc>
    <lastmod>2026-10-28</lastmod>
  </url>
</urlset>

Und das Crawl Budget?

Googles Dokumentation zum Crawl Budget richtet sich an große Seiten: ab etwa einer Million einzigartiger URLs mit wöchentlichen Änderungen, ab etwa 10.000 mit täglichen Änderungen oder bei vielen URLs im Status „Gefunden – zurzeit nicht indexiert". Die Schwellen sind grobe Schätzungen. Für kleinere Seiten genügt laut Google eine aktuelle Sitemap und der Blick in den Seitenindexierungsbericht. Die Empfehlungen für große Seiten sind trotzdem allgemein sinnvoll: Duplikate zusammenführen, endgültig entfernte Seiten mit 404 oder 410 beantworten, Soft 404 beheben, lange Weiterleitungsketten vermeiden.

Statuscodes und Weiterleitungen

Der HTTP-Statuscode ist das Erste, was Google über eine URL erfährt. Nach der Google-Dokumentation zu HTTP-Statuscodes:

Google folgt standardmäßig bis zu 10 Weiterleitungen hintereinander und verarbeitet den Inhalt des Ziels, nicht den der weiterleitenden URL. Für Umzüge und endgültige URL-Änderungen nimmst du also 301 oder 308 serverseitig. Einen Meta-Refresh mit 0 Sekunden liest Google als dauerhaft, eine JavaScript-Weiterleitung nennt die Dokumentation einen Notbehelf, weil das Rendering scheitern kann. Weiterleitungsketten vermeidest du, indem alte URLs direkt auf das endgültige Ziel zeigen.

Soft 404 nennt Google Seiten, die mit 200 antworten, aber wie eine Fehlerseite aussehen oder leer sind. Sie bekommen in der Search Console einen eigenen Status und verbrauchen Crawling, ohne indexiert zu werden. Eine Fehlerseite muss wirklich 404 (oder 410) senden, nicht nur so aussehen.

Rendering

Seiten, die ihre Inhalte erst per JavaScript aufbauen, durchlaufen bei Google zusätzlich eine Rendering-Phase. Das ist machbar, aber fehleranfälliger als direkt ausgeliefertes HTML. Wie das genau funktioniert und worauf du achten musst, steht im Artikel JavaScript-SEO: So sieht Google deine JS-Seite. Als Faustregel gilt: Alles, was für die Indexierung wichtig ist (Inhalt, Links, Statuscode, Canonical, noindex), gehört nach Möglichkeit schon in das initiale HTML.

Indexierung steuern

noindex

Mit noindex sagst du Google, dass eine Seite nicht in den Suchergebnissen erscheinen soll. Zwei Wege sind dokumentiert: das Robots-Meta-Tag im HTML und der HTTP-Header X-Robots-Tag, der auch für PDFs und Bilder funktioniert.

<meta name="robots" content="noindex">

X-Robots-Tag: noindex

Die Falle: Google findet die Anweisung nur, wenn es die URL crawlen darf. Blockiert die robots.txt die Seite, bleibt noindex unsichtbar. Beides gleichzeitig zu setzen, ist ein klassischer Fehler.

Canonical und Duplikate

Gleiche oder sehr ähnliche Inhalte unter mehreren URLs (Parameter, http und https, mit und ohne www, Trailing Slash) gehören zu den häufigsten technischen Befunden. Google wählt dann selbst eine kanonische URL. Mit Weiterleitungen, rel="canonical" und Sitemap-Einträgen gibst du Signale unterschiedlicher Stärke. Details, Beispiele und typische Fehler findest du im Artikel zum Canonical Tag.

Seitenarchitektur, interne Links und URLs

Google entdeckt Seiten vor allem über Links. Nach der Dokumentation folgt Googlebot im Allgemeinen nur <a>-Elementen mit href-Attribut. Navigation, die nur über onclick, span-Elemente oder routerLink funktioniert, wird möglicherweise nicht erkannt. Jede Seite, die indexiert werden soll, sollte von mindestens einer anderen Seite deiner Website verlinkt sein. Beschreibende Linktexte helfen Nutzern und Google, „hier klicken" tut es nicht.

Zur URL-Struktur nennt Google unter anderem diese Punkte:

• sprechende Pfade statt langer ID-Ketten, Wörter mit Bindestrichen trennen
• URLs sind case-sensitiv: Entscheide dich für eine Schreibweise
• Parameter, die den Inhalt nicht ändern (Tracking, Sortierung, Session-IDs), vermeiden
• keine Inhalte hinter Fragmenten (#/seite), stattdessen die History API verwenden
• kombinierbare Filter können riesige Mengen an Beinahe-Duplikaten erzeugen

Entscheide dich außerdem früh für eine Variante von Protokoll, Host und Slash-Schreibweise und leite alle anderen darauf weiter. Das folgt daraus, dass für Google Protokoll, Host und Port zur Identität einer URL gehören, wie schon die robots.txt zeigt, die je Protokoll und Host gilt. Wie du Tracking-Parameter einsetzt, ohne Duplikate zu fördern, zeigt der Artikel über UTM-Parameter.

Performance und Page Experience

Zur Rolle der Ladezeit ist Google zurückhaltend: Die Core Web Vitals werden von den Ranking-Systemen genutzt, aber gute Werte garantieren keine Spitzenplätze, und ein perfekter Score nur aus SEO-Gründen ist nach Google nicht unbedingt der beste Einsatz deiner Zeit. Andere Aspekte der Page Experience helfen laut Dokumentation nicht direkt beim Ranking, sind aber für Nutzer relevant. Behandle Performance deshalb als Qualitätsthema mit Nutzenargument, nicht als SEO-Hebel. Wie sich Messung und Tagging architektonisch auf den Server verlagern lassen, beschreibt der Artikel zu Server-Side Tracking. Die Metriken, Grenzwerte und konkreten Fixes erklärt Core Web Vitals: LCP, INP und CLS.

Strukturierte Daten und hreflang in Kürze

Strukturierte Daten beschreiben Inhalte maschinenlesbar. Welche Typen sich lohnen und wie du sie validierst, behandelt der Artikel zu strukturierten Daten mit JSON-LD.

Für mehrsprachige Seiten gibt es hreflang. Die Kernregeln aus Googles Dokumentation: Jede Sprachversion listet sich selbst und alle anderen, die Verweise müssen gegenseitig sein, die URLs sind vollständig inklusive Protokoll, und x-default benennt eine Auffangseite. Eine Methode genügt (HTML, HTTP-Header oder Sitemap).

<link rel="alternate" hreflang="de" href="https://example.com/de/">
<link rel="alternate" hreflang="en" href="https://example.com/en/">
<link rel="alternate" hreflang="x-default" href="https://example.com/">

Die Search Console als Kontrollinstrument

Die Search Console zeigt, was Google tatsächlich sieht. Das URL-Prüftool liefert für eine URL den Indexierungsstatus, die von dir angegebene und die von Google gewählte kanonische URL, ob Crawling und Indexierung erlaubt sind, sowie das gerenderte HTML der zuletzt gecrawlten Version. Der Live-Test prüft die aktuelle Version, ermittelt aber nicht die von Google gewählte kanonische URL. Wenn die robots.txt das Crawling blockiert, steht bei „Indexierung zulässig" immer „Ja", weil Google ein noindex gar nicht sehen kann. Ergänzend schaust du in den Seitenindexierungsbericht, die Sitemap-Berichte und den Core-Web-Vitals-Bericht.

Ein eigener Check für deinen Build

Vieles lässt sich automatisiert prüfen, bevor es live geht. Das folgende Node.js-Skript startet einen lokalen Testserver mit drei typischen Fällen (Weiterleitungskette, noindex-Header, 404) und prüft sie mit fetch und manuellem Redirect-Handling:

import http from 'node:http';

const server = http.createServer((req, res) => {
  const { pathname } = new URL(req.url, 'http://localhost');
  if (pathname === '/alt') { res.writeHead(301, { Location: '/neu' }); return res.end(); }
  if (pathname === '/neu') { res.writeHead(302, { Location: '/ziel' }); return res.end(); }
  if (pathname === '/ziel') {
    res.writeHead(200, { 'content-type': 'text/html' });
    return res.end('<!doctype html><title>Ziel</title><link rel="canonical" href="/ziel">');
  }
  if (pathname === '/intern') {
    res.writeHead(200, { 'content-type': 'text/html', 'x-robots-tag': 'noindex' });
    return res.end('<!doctype html><title>Intern</title>');
  }
  res.writeHead(404, { 'content-type': 'text/html' });
  res.end('Nicht gefunden');
});
await new Promise((r) => server.listen(0, r));
const base = `http://localhost:${server.address().port}`;

async function inspect(url, maxHops = 10) {
  const chain = [];
  let current = url;
  for (let i = 0; i <= maxHops; i++) {
    const res = await fetch(current, { redirect: 'manual' });
    chain.push(`${res.status} ${new URL(current).pathname}`);
    const location = res.headers.get('location');
    if (res.status >= 300 && res.status < 400 && location) {
      current = new URL(location, current).href;
      continue;
    }
    const html = res.headers.get('content-type')?.includes('text/html') ? await res.text() : '';
    const canonical = html.match(/<link[^>]+rel="canonical"[^>]+href="([^"]+)"/i)?.[1] ?? null;
    return {
      chain,
      finalStatus: res.status,
      noindexHeader: /noindex/i.test(res.headers.get('x-robots-tag') ?? ''),
      canonical,
    };
  }
  return { chain, error: 'zu viele Weiterleitungen' };
}

for (const path of ['/alt', '/intern', '/gibt-es-nicht']) {
  console.log(path, JSON.stringify(await inspect(base + path)));
}
server.close();

Die Ausgabe zeigt die Kette 301, 302, 200, den noindex-Header und den 404:

/alt {"chain":["301 /alt","302 /neu","200 /ziel"],"finalStatus":200,"noindexHeader":false,"canonical":"/ziel"}
/intern {"chain":["200 /intern"],"finalStatus":200,"noindexHeader":true,"canonical":null}
/gibt-es-nicht {"chain":["404 /gibt-es-nicht"],"finalStatus":404,"noindexHeader":false,"canonical":null}

Auffällig ist, dass der Canonical im Beispiel relativ ist (/ziel). Google unterstützt relative Pfade, empfiehlt aber absolute URLs. Das Skript ist ein Ausgangspunkt: Für echte Seiten ersetzt du den Testserver durch deine Staging-URLs, liest die URL-Liste aus der Sitemap und ergänzt eine Prüfung auf absolute Canonicals.

Release-Checkliste für Entwickler

Diese Liste fasst zusammen, was bei einem Release mit Auswirkung auf URLs oder Templates zu prüfen ist.

Nächster Schritt

Wähle fünf wichtige URLs deiner Website (Startseite, eine Kategorie, einen Artikel oder ein Produkt, eine Fehlerseite, eine häufig verlinkte alte URL) und prüfe sie mit dem Skript oben. Öffne dieselben URLs anschließend im URL-Prüftool der Search Console und vergleiche die von dir angegebene mit der von Google gewählten kanonischen URL. Jede Abweichung ist ein konkreter Arbeitsauftrag. Wenn du ein JavaScript-Framework einsetzt, lies als Nächstes den Artikel zu JavaScript-SEO. Planst du eine neue, schnelle Website, ist Astro und statische Websites ein sinnvoller Anschluss.