Indexierung: Wie kommt Ihre Seite in den Google-Index?

Wie kommt eine Seite in den Google-Index?

Google findet eine Seite über Links oder eine Sitemap, ruft sie mit einem automatischen Programm ab (Crawler), wertet ihren Inhalt aus und speichert sie im Index. Erst danach kann sie in den Suchergebnissen erscheinen. Einen Anspruch darauf gibt es nicht: Google garantiert laut eigener Dokumentation weder das Crawling noch die Indexierung einer Seite.

Gleiche oder sehr ähnliche Seiten fasst Google zusammen und wählt eine davon als Hauptadresse aus. Inhalte, die erst per JavaScript entstehen, verarbeitet Google mit einer aktuellen Chrome-Version. Dass andere Suchmaschinen und KI-Crawler JavaScript ebenso ausführen, sollten Sie nicht voraussetzen (mehr dazu im Artikel KI-Sichtbarkeit).

Diese technischen Punkte entscheiden mit, ob und unter welcher Adresse eine Seite im Index landet:

• Die Seite antwortet mit dem Statuscode 200.
• Sie enthält keine Anweisung noindex – weder im HTML noch im HTTP-Header.
• Die robots.txt sperrt die Adresse nicht für den Googlebot.
• Die Hauptadresse ist eindeutig: ein Canonical, eine Variante mit oder ohne www, eine Schreibweise mit oder ohne Slash am Ende.
• Der Head ist gültig, damit Google Canonical, robots und hreflang überhaupt liest.

Ob eine bestimmte Seite im Index ist, zeigt die kostenlose Google Search Console mit dem „URL-Prüftool“. Dort können Sie nach einer Korrektur auch „Indexierung beantragen“.

Welche Statuscodes sind für die Indexierung wichtig?

Nur Seiten mit einem Statuscode der 2xx-Gruppe – im Normalfall 200 – gibt Google an die Indexierung weiter. Inhalte von Seiten mit 4xx-Status verwendet Google nicht, und 5xx-Fehler bremsen das Crawling.

Google folgt standardmäßig bis zu zehn Weiterleitungen hintereinander, empfiehlt aber, direkt auf das endgültige Ziel weiterzuleiten – jede Station kostet Ladezeit. Wie Sie Weiterleitungen sauber einrichten, erklärt der Artikel Weiterleitungen. Auffindig bewertet den Status der letzten Station: Liefert sie einen Fehler, gibt es keinen Gesamtscore, sondern nur den Bericht zu Technik und Sicherheit.

Was bewirken noindex und X-Robots-Tag?

Die Anweisung noindex sagt Google, eine Seite nicht in die Suchergebnisse aufzunehmen – auch dann nicht, wenn andere Websites darauf verlinken. Sie steht entweder als Meta-Tag im Head oder als HTTP-Header X-Robots-Tag.

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

Für Dateien ohne HTML, etwa PDFs oder Bilder, gibt es nur den Header. Er kann auch gezielt einen Crawler ansprechen, im HTML geht das mit name="googlebot":

X-Robots-Tag: noindex
X-Robots-Tag: googlebot: noindex, nofollow

Wichtig zu wissen:

• robots.txt-Sperre hebelt noindex aus: Ist die Adresse per robots.txt gesperrt, ruft Google sie nicht ab und sieht das noindex nie. Die Adresse kann dann trotzdem – ohne Beschreibung – in den Ergebnissen auftauchen.
• Strengere Anweisung gewinnt: Widersprechen sich Meta-Tag und Header, gilt die restriktivere Angabe. none bedeutet dasselbe wie noindex, nofollow.
• Ablaufdatum: Mit unavailable_after zeigt Google die Seite nach dem angegebenen Zeitpunkt nicht mehr an. Ein vergangenes Datum wirkt also wie noindex.

Ein typischer Fall ist ein vergessenes noindex aus der Entwicklungsphase. In WordPress, Wix und ähnlichen Systemen steuern Sie die Sichtbarkeit für Suchmaschinen über die Einstellungen der Plattform, nicht im HTML.

Wie setze ich das Canonical richtig?

Das Canonical (<link rel="canonical">) nennt Google die Hauptadresse, wenn derselbe Inhalt unter mehreren Adressen erreichbar ist – etwa über Sortier- und Filterparameter oder über http und https. Setzen Sie auf jeder Seite ein absolutes Canonical auf die eigene https-Adresse; Google wertet es als starkes Signal, entscheidet aber letztlich selbst.

<link rel="canonical" href="/leistungen">
<link rel="canonical" href="http://www.example.com/leistungen/">

<link rel="canonical" href="https://www.example.com/leistungen/">

Die wichtigsten Regeln aus der Google-Dokumentation:

• Das Canonical gilt nur im <head>. Steht es im Body, ignoriert Google es.
• Pro Seite eine Hauptadresse: Nennen Sie nicht über verschiedene Wege (HTML, HTTP-Header, Sitemap) unterschiedliche Adressen.
• Keine Sprungmarke (#…) im Canonical – Google unterstützt Fragmente in der Regel nicht.
• Das Ziel sollte mit 200 antworten. Leitet es weiter oder liefert es einen Fehler, nennen Sie Google eine Hauptadresse, deren Inhalt es nicht verwenden kann – Auffindig wertet das als Problem.
• Duplikate innerhalb der eigenen Website nicht per robots.txt sperren und nicht mit noindex ausschließen – dafür ist das Canonical da.
• Für PDFs funktioniert dieselbe Angabe als HTTP-Header Link: <https://…>; rel="canonical".

Ein Sonderfall sind Slash-Varianten: Für Google sind /leistungen und /leistungen/ zwei verschiedene Adressen (nur bei der Startseite ist das egal). Leiten Sie eine Variante per 301 auf die andere um oder verweisen Sie zumindest per Canonical darauf – Details im Abschnitt Slash-Varianten.

Was ist ein Soft-404?

Ein Soft-404 ist eine Seite, die „nicht gefunden“ anzeigt oder leer ist, aber trotzdem den Statuscode 200 liefert. Richtig ist ein echter 404- oder 410-Status zusammen mit einer hilfreichen Fehlerseite.

Warum das zählt: Liefert jede beliebige Adresse Status 200, existieren beliebig viele Kopien Ihrer Fehlerseite, und Google erkennt gelöschte Seiten nicht als gelöscht. Die Search Console meldet solche Fälle im „Bericht zur Seitenindexierung“ als „Soft 404-Fehler“. Auffindig ruft dafür eine zufällige, sicher nicht vorhandene Adresse Ihrer Website auf und prüft den Status. Eine Weiterleitung aller unbekannten Adressen auf die Startseite ist ebenfalls kein echter 404 und wird als verbesserbar gewertet.

So stellen Sie den Server um, damit die eigene Fehlerseite mit Status 404 ausgeliefert wird:

# Apache (.htaccess oder Server-Konfiguration) – lokaler Pfad, keine volle URL
ErrorDocument 404 /404.html

# nginx (im server-Block)
error_page 404 /404.html;

Wichtig bei Apache: Geben Sie einen Pfad an, keine vollständige Adresse mit https://. Bei einer vollständigen Adresse schickt Apache eine Weiterleitung, und der Browser erhält nie den Status 404. Prüfen Sie auch Weiterleitungsregeln und -Plugins: Eine Regel, die alle unbekannten Adressen auf die Startseite schickt, erzeugt genau dieses Problem.

Ungültiger Head: Wann ignoriert Google Metadaten?

Google liest im <head> nur die Elemente title, meta, link, script, style, base, noscript und template. Steht dort ein anderes Element, etwa ein img oder iframe, hört Google an dieser Stelle auf zu lesen – Canonical, robots-Angaben und hreflang dahinter gehen verloren.

<head>
  <title>Leistungen | Example</title>
  <img src="https://tracker.example.net/pixel.gif" alt="">
  <link rel="canonical" href="https://www.example.com/leistungen/">
</head>

<head>
  <meta charset="utf-8">
  <title>Leistungen | Example</title>
  <link rel="canonical" href="https://www.example.com/leistungen/">
</head>

Solche Elemente gelangen etwa über Tracking-Pixel, eingebettete Widgets oder Codeschnipsel in den Head, die ein Plugin dort einfügt. Wie Google ein Bild innerhalb von <noscript> im Head behandelt, ist nicht dokumentiert; Auffindig meldet diesen Fall deshalb nur als verbesserbar.

Wie gebe ich hreflang und Sprache richtig an?

Mit hreflang verknüpfen Sie Sprach- und Länderversionen derselben Seite, etwa für Österreich (de-AT) und Deutschland (de-DE). Jede Version muss sich selbst und alle anderen nennen, und die Verweise müssen gegenseitig sein – sonst ignoriert Google sie.

<link rel="alternate" hreflang="de-AT" href="https://www.example.com/at/">
<link rel="alternate" hreflang="de-DE" href="https://www.example.com/de/">
<link rel="alternate" hreflang="x-default" href="https://www.example.com/">

Diese drei Zeilen stehen identisch auf allen drei Seiten; x-default ist die Ausweichseite für alle anderen Sprachen und Länder. Alternativ geht hreflang im HTTP-Header oder in der Sitemap – für Google sind die drei Wege gleichwertig.

Die Sprache einer Seite ermittelt Google selbst aus dem Inhalt; weder das lang-Attribut noch hreflang dienen dafür. Trotzdem sollten alle Angaben zusammenpassen: <html lang="de-AT"> brauchen Screenreader für die richtige Aussprache (mehr dazu im Artikel zur Barrierefreiheit), und Auffindig vergleicht lang, einen Content-Language-Header, og:locale und hreflang mit der erkannten Textsprache. Die Sprache per <meta http-equiv="Content-Language"> festzulegen, rät das W3C ausdrücklich ab.

Worauf kommt es bei URL, Doctype und Zeichensatz an?

Lesbare Adressen mit Bindestrichen, ein HTML5-Doctype in der ersten Zeile und UTF-8 als Zeichensatz sind einfache Grundlagen. Sie verhindern doppelte Adressen, Darstellungsfehler und zerstörte Umlaute im Suchergebnis.

• Adresse (URL): Wörter statt ID-Nummern, Bindestriche statt Unterstriche, möglichst wenige Parameter und keine Sitzungskennungen (Session-IDs). Google unterscheidet Groß- und Kleinschreibung: /Leistungen/ und /leistungen/ sind zwei Adressen. Umlaute im Pfad sollten in Links prozentkodiert sein (gemüse wird zu gem%C3%BCse).
• Doctype: <!DOCTYPE html> gehört ganz an den Anfang des Dokuments. Fehlt er, stellen Browser die Seite im sogenannten Quirks-Modus dar, der das Verhalten sehr alter Browser nachahmt.
• Zeichensatz: UTF-8 ist der einzige gültige Zeichensatz für HTML5. Die Angabe <meta charset="utf-8"> muss vollständig in den ersten 1 024 Bytes stehen, am besten als erstes Element im Head. Nennt der Server im Content-Type-Header ebenfalls einen Zeichensatz, sollte auch dort UTF-8 stehen.
• Domain: Subdomain, Länge, Bindestriche und Umlaute zeigt Auffindig nur als Info. Umlaut-Domains werden technisch in eine ASCII-Form mit dem Präfix xn-- umgewandelt (Punycode).

<!DOCTYPE html>
<html lang="de-AT">
<head>
  <meta charset="utf-8">

Ändern Sie bestehende Adressen, leiten Sie die alten per 301 auf die neuen um. Alle Grenzwerte, nach denen Auffindig diese Punkte bewertet, finden Sie unten im Abschnitt So prüft Auffindig.