Manchmal entstehen Missverständnisse in der SEO-Welt aus kleinen Details – technische Feinheiten, die man übersieht oder falsch interpretiert. Einer dieser Bereiche betrifft Resource Hints, also Hinweise wie preload, prefetch oder dns-prefetch. Viele Entwickler fügen sie in der Hoffnung hinzu, dass Googlebot dadurch Seiten schneller crawlt oder indexiert. Doch laut Gary Illyes von Google ist das ein Trugschluss.
In einem Gespräch im bekannten „Search Off the Record“-Podcast erklärte Illyes detailliert, warum die Crawling-Infrastruktur von Google ganz anders funktioniert als ein klassischer Browser – und warum Hinweise, die für Nutzer hilfreich sind, für Googlebot keinen Unterschied machen. Ich finde das spannend, weil es zeigt, wie oft wir technische Standards mit menschlicher Nutzung gleichsetzen, obwohl Googles Systeme in einer komplett optimierten Umgebung arbeiten.
Warum Googlebot keine Resource Hints braucht
Vielleicht hast du auf deiner Seite schon einmal mit preconnect oder preload gearbeitet, um Inhalte schneller bereitzustellen. Das ist gut für User – keine Frage – aber für Googlebot völlig irrelevant. Illyes erklärte, dass Googles Systeme keine Internet-Latenz haben, wie wir sie gewohnt sind. Der Bot läuft innerhalb des Google-Netzwerks, das blitzschnell auf DNS-Server zugreifen kann. Das heißt, sogenannte „DNS Prefetches“ bringen keinen Vorteil.
Er meinte sinngemäß: Wenn man ein schlechtes oder langsames Internet hat, ist DNS-Prefetching hilfreich. Googlebot aber kann extrem schnell mit sämtlichen DNS-Stufen kommunizieren – dort gibt es keinen Engpass. Ein bisschen so, als würdest du versuchen, einem Rennwagen zu erklären, dass er beim Losfahren die Reifen vorheizen soll – nützlich auf der Landstraße, aber unnötig auf der Rennstrecke.
Ein weiterer Punkt: Googlebot lädt Ressourcen wie Bilder, CSS oder Skripte nicht exakt so, wie ein Browser es tut. Stattdessen werden sie oft gecacht und getrennt verarbeitet, um den Server des Websitebetreibers nicht zu überlasten. Das heißt: Resource Hints, die Browsern sagen sollen, was sie „vorab laden“ sollen, werden von Google einfach ignoriert. Der Bot will schließlich Inhalte indexieren, keine ganze Website in Echtzeit rendern.
Dennoch – und das ist wichtig – bedeutet das nicht, dass solche Hints unwichtig sind. Für echte Nutzer machen sie oft den Unterschied zwischen einer Seite, die sich in einer Sekunde öffnet, und einer, die zehn Sekunden braucht. Nur: Das ist ein Performancefaktor, kein SEO-Faktor.
Der Unterschied zwischen Browsern und Googlebot
Man könnte sagen: Der Browser kämpft mit der physischen Welt – Servergeschwindigkeiten, Netzwerkpfade, Endgeräte. Googlebot dagegen lebt in einer Cloud-Welt, in der solche Hindernisse kaum existieren. Das erklärt auch, warum Google kein Interesse hat, zusätzliche DNS-Anfragen oder Vorab-Ladevorgänge zu interpretieren: Sie helfen schlicht nicht beim Indexieren.
Illyes brachte es leicht spöttisch auf den Punkt: „Wenn wir nicht synchron laden müssen, brauchen wir auch keinen Preload.“ Und damit ist das Thema eigentlich erledigt.
Meta-Daten und ihr richtiger Platz – warum der Head zählt
Ein weiteres Thema, das viele übersehen: Wo im Dokument bestimmte SEO-relevante Elemente stehen. Illyes und sein Kollege Martin Splitt waren sich einig – Meta-Daten wie hreflang, canonical oder meta robots gehören ausschließlich in den Head-Bereich einer HTML-Seite. Alles andere kann zu Fehlern führen.
Splitt erzählte eine spannende Anekdote: In einem Projekt hatte ein Entwickler korrekt nach Standard gearbeitet – aber ein Skript im Head erzeugte dynamisch ein Iframe-Element. Damit erkannte der Browser diesen Punkt fälschlicherweise als Ende des Head-Bereichs und schob alle nachfolgenden Tags (darunter hreflang) in den Body. Das Resultat: Google ignorierte sie komplett.
Warum so streng? Illyes erklärte, dass Elemente wie meta name="robots" laut HTML-Spezifikation nur im Head erlaubt sind. Das gilt auch für link rel="canonical". Wenn man Google erlauben würde, sie irgendwo im Body zu akzeptieren, wäre das ein potenzielles Sicherheitsproblem. Denn dann könnten Angreifer per Script eine andere Canonical einfügen und so Einfluss auf das Ranking nehmen – im schlimmsten Fall eine Hijacking-Lücke.
Deshalb ist Google hier kompromisslos. Und ehrlich gesagt – das macht Sinn. Es zeigt, dass Google sich lieber an den Standard hält, als Interpretationen zuzulassen, die von Website zu Website unterschiedlich umgesetzt wären. Wenn du also feststellst, dass deine hreflang-Tags oder Canonicals nicht wirken – prüf genau, ob sie wirklich in der Head-Sektion sitzen. Schon ein JavaScript, das den Head versehentlich „schließt“, kann alles aushebeln.
Kleine Ursache, große Wirkung
Ich selbst habe in Beratungsgesprächen schon erlebt, dass genau solche Details wochenlange SEO-Probleme gelöst haben. Ein falsch platzierter Canonical – plötzlich werden URLs gar nicht mehr indexiert. Der Teufel steckt wirklich im Detail.
HTML-Validität: Kein Ranking-Faktor
Ein anderes beliebtes SEO-Thema ist die HTML-Validierung. Es gibt Tools, die jede kleinste Unsauberkeit bemängeln – ein fehlender schließender Tag, ein Attribut an der falschen Stelle, ein doppelt gesetztes ID-Attribut. Viele denken dann automatisch: „Oh, mein HTML ist nicht valide, das muss mein Ranking beeinträchtigen.“ Aber laut Gary Illyes ist das schlicht falsch.
Seine Begründung ist überzeugend: Validität ist binär – entweder ist das HTML gültig oder nicht. Aber Websites sind komplexe Gebilde. Fast jede große Seite enthält kleine Ungenauigkeiten im Quellcode, die keinerlei Einfluss auf das Nutzererlebnis haben. Für den Googlebot ist entscheidend, ob er den Inhalt zuverlässig lesen kann – nicht, ob jedes Zeichen formal korrekt ist.
Ein fehlender </span>-Tag macht eine Seite nach strengem Standard „ungültig“. Aber für das Crawling spielt das keine Rolle. Der Text bleibt lesbar, der Inhalt klar. Illyes meinte dazu: „Das wird für den Nutzer nichts ändern.“ Und genau das ist der Kernpunkt: Google will das Beste für den Nutzer, nicht den valideren Quellcode.
Auch Martin Splitt betonte, dass semantisch sauberes HTML – etwa eine perfekte Überschriftenstruktur oder malerisch korrekte Verwendung von <main> und <aside> – zwar gut für Barrierefreiheit und Struktur ist, aber keinen direkten Einfluss auf das Ranking hat. Es kann dir helfen, deine Inhalte sauberer zu organisieren, aber Google bewertet nur das Ergebnis, nicht die Schönheit des Codes.
Was du daraus mitnehmen kannst
Wenn du eine technische Website-Analyse durchführst, wirst du viele Empfehlungen finden: „Verbessere Validität“, „Füge Resource Hints hinzu“, „Optimiere DNS-Abfragen“ – und das ist alles grundsätzlich nicht falsch. Nur musst du unterscheiden, für wen du optimierst: den Nutzer oder den Googlebot.
Für Google wichtig:
- Der Head-Bereich muss sauber strukturiert sein. Meta-Elemente gehören dorthin, nicht in den Body.
- Vermeide dynamische Scripte, die Head und Body ungewollt trennen.
- Nutze gültige Canonical- und hreflang-Tags, um Indexierungs- und Sprachprobleme zu vermeiden.
- ETags und sauberes Caching helfen Google, deinen Server effizient zu crawlen – das spart dir Ressourcen.
Für den Nutzer wichtig:
- Verwende Resource Hints, um Ladezeiten zu verkürzen. Das beeinflusst die Nutzererfahrung direkt.
- Sorge für semantisch saubere Struktur, damit Screenreader, Browser und Tools besser arbeiten können.
- Optimiere Performance, aber nicht in der Hoffnung, den Crawler zu „überlisten“ – das funktioniert nicht.
Wenn du also deine Prioritäten setzt, fang beim Head deiner Seite an, nicht bei Mikro-Optimierungen im Netzwerkbereich. Die Reihenfolge der Optimierungsschritte ist oft der eigentliche Trick erfolgreicher technischer SEO.
Ein Blick in die Zukunft
Interessant ist, dass Google in dem Gespräch auch kurz anklingen ließ, dass Themen wie Client Hints und Header-Felder wie Accept-CH oder Sec-CH-UA zukünftig spannender werden könnten. Diese neueren Standards könnten Google helfen, Informationen über Geräte, Browser-Fähigkeiten oder Layoutpräferenzen zu verstehen – ohne in Cookies oder User-Agent-Strings zu greifen. Das zeigt: Auch Google entwickelt sich in Richtung datensparender, aber intelligenterer Kommunikation zwischen Browsern und Bots.
Es ist daher gut möglich, dass zukünftige SEO-Optimierungen neue Formen annehmen werden – stärker im Bereich API- und Header-Kommunikation, weniger in klassischen HTML-Tweaks.
Mein persönliches Fazit
Aus meiner Sicht steckt in dieser Diskussion eine wichtige Erinnerung: Technische SEO ist kein reines Codespiel. Es geht darum, zu verstehen, wie Suchmaschinen wirklich funktionieren – nicht, was man ihnen beibringen möchte. Wer sauber strukturiert, klar kommuniziert und Standards respektiert, hat langfristig die Nase vorn.
Also, wenn du das nächste Mal im Quellcode herumfummelst, um irgendwo ein preconnect einzufügen oder drei Validator-Warnungen zu beseitigen – frag dich: Wem helfe ich damit eigentlich? Dem Nutzer? Dem Googlebot? Oder nur meinem eigenen Perfektionismus?
Das Verständnis dieser Unterschiede spart dir Zeit, Nerven und wahrscheinlich auch ein paar graue Haare.
