Viele Webmaster wundern sich, warum Googlebot manche Empfehlungen, die man in Webseiten einfügt, scheinbar einfach ignoriert. In einer technischen Gesprächsrunde erklärten zwei bekannte Google-Vertreter, Gary Illyes und Martin Splitt, einige dieser Missverständnisse – und zwar ziemlich direkt. Dabei ging es vor allem um drei Fragen: warum sogenannte Resource Hints für Google keine Rolle spielen, weshalb bestimmte Meta-Angaben ausschließlich in den Kopfteil der Seite gehören, und wieso valider HTML‑Code kein Ranking‑Bonus ist.
Googles Crawler tickt anders als dein Browser
Resource Hints wie preload, prefetch oder preconnect sind in der Frontend‑Welt beliebt, um Ladezeiten für Nutzer zu verkürzen. Der Browser kann damit frühzeitig DNS‑Einträge auflösen oder Dateien vorladen, bevor sie tatsächlich gebraucht werden. Aus Googles Sicht ist das jedoch komplett irrelevant. Illyes meinte sinngemäß, dass Googles Infrastruktur so eng mit den DNS-Servern verbunden sei, dass „Vorladen“ dort keine messbare Verbesserung bringt. Google kommuniziert direkt mit den großen Servern, in Rechenzentren – also ohne die typischen Verzögerungen, die du oder ich beim Surfen spüren.
Das ist ein interessanter Punkt, weil viele SEO‑Checklisten solche Hints immer noch empfehlen. Für Besucher ist das weiterhin sinnvoll: schnellere Seiten bedeuten bessere Nutzererfahrung, höhere Conversion‑Rates, geringere Absprungrate. Aber für den Googlebot macht es schlicht keinen Unterschied. Der Bot lädt Dateien nicht in Echtzeit über denselben Pfad wie dein Browser, sondern nutzt interne, optimierte Caching‑Systeme. Ein Preconnect‑Hint im HTML ändert sein Verhalten also gar nicht.
Was du daraus mitnehmen kannst
Wenn du deine Crawl‑Statistiken analysierst und hoffst, mit solchen Performance‑Optimierungen Einfluss auf die Indexierung zu nehmen, kannst du dir diesen Aufwand sparen. Diese Maßnahmen haben rein UX‑Wert, sind aber kein technisches Crawling‑Signal. Aus meiner Erfahrung hilft es, solche Hinweise trotzdem zu behalten, aber man sollte sie richtig einordnen – sie spielen im SEO‑Rankingprozess nur indirekt über die Nutzersignale eine Rolle.
Meta‑Informationen: Strenge Regeln für den Kopfbereich
Ein zweites Thema betrifft den Ort, an dem du <meta>‑ oder <link>‑Tags platzierst. Viele moderne Webseiten arbeiten mit JavaScript, injecten dynamisch Inhalte oder verschachteln iframes. Dadurch kann es passieren, dass Meta‑Angaben versehentlich in den Body der Seite rutschen. Laut Illyes und Splitt toleriert Google das bei rein dekorativen Links, aber nicht bei Tags, die Suchmaschinensteuerung enthalten.
Beispiel: Eine meta name="robots"-Anweisung oder ein link rel="canonical" darf nur im <head> stehen. Wenn ein Script versehentlich vorzeitig den Head‑Abschnitt schließt und die Tags danach eingefügt werden, ignoriert Google sie. Splitt beschrieb sogar einen echten Fall: Ein Script fügte beim Laden ein iframe ein, was den Parser dazu brachte, den Head zu schließen – alle hreflang‑Angaben danach landeten im Body … und waren wirkungslos.
Warum so streng? Laut Illyes hat das Sicherheitsgründe. Wenn Suchmaschinen auch Canonicals im Body berücksichtigen würden, könnte jeder über eingeschleusten Code fremde Seiten manipulieren – indem er etwa eine andere Canonical‑URL einfügt und so die echte Seite aus dem Index verdrängt. Deshalb verarbeitet Google solche Tags strikt nach Standard. Das gilt übrigens auch für robots‑Angaben oder link‑Alternates zu Sprachversionen. Kurz gesagt: Immer in den Kopf, niemals in den Body.
Falls du mit dynamischen Themes arbeitest, lohnt sich ein Blick in den gerenderten HTML‑Output (nicht nur in die Quelltext‑Ansicht). Gerade Script‑Frameworks wie React oder Vue platzieren manchmal unerwartet Elemente. Ich habe schon Seiten gesehen, deren canonical‑Tag in der Developer‑Konsole verschoben war. Für das Auge kein Problem, für den Googlebot aber schon.
Valides HTML ist kein Ranking‑Kriterium
Viele Entwickler legen Wert auf perfekt validen Code und hoffen etwas insgeheim, Google würde sauberen HTML belohnen. Gary Illyes hat diese Hoffnung ziemlich klar ausgeräumt. Google misst keine Punktzahl für „valid oder nicht“. Ein HTML‑Dokument ist laut Spezifikation entweder gültig oder fehlerhaft – und diese binäre Logik taugt nicht als Messgröße für ein Ranking‑Signal.
Was heißt das praktisch? Kleine Fehler wie ein fehlendes ‑Tag sind formal invalide, beeinträchtigen aber weder den Browser‑Renderprozess noch den Nutzer. Google kann solche Strukturen problemlos interpretieren, weil der Parser tolerant ist und den DOM häufig „repariert“. Solange der sichtbare Inhalt und die Links erkennbar bleiben, hat das keinen Einfluss auf die Bewertung. Natürlich schadet sauberes HTML nicht – es erleichtert Wartung, Barrierefreiheit und Debugging –, aber es bringt dir kein besseres Ranking.
Martin Splitt ergänzte, dass selbst semantisch korrektes Markup mit ordentlichen Überschriften‑Hierarchien oder HTML5‑Sektionen in Googles Algorithmus kein Gewicht habe. Es hilft Screenreadern und Nutzern, ja – aber die Suchmaschine versteht den Kontext auch ohne perfekte Semantik. Für Suchmaschinen‑Optimierung zählt, dass Inhalte klar lesbar sind – nicht ob jedes Attribut w3c‑konform geschrieben wurde.
Was bedeutet das für deine SEO‑Praxis?
Wenn du technische Audits durchführst, trenne sauber zwischen browserrelevanten und crawlerrelevanten Problemen. Resource Hints sind Performance‑Features für Menschen, keine Anweisungen an Google. Fehlerhafte HTML‑Validierung ist meist kosmetisch. Kritisch wird es erst, wenn deine Meta‑Direktiven vom Parser in den Body geschoben oder durch Scripte überschrieben werden.
Ein guter erster Check ist der sogenannte Rendered HTML View in der Search Console – dort siehst du, was Google nach dem Rendering tatsächlich liest. Wenn dort hreflang‑ oder canonical‑Tags fehlen, liegt der Fehler fast immer in der DOM‑Struktur. Viele Entwickler prüfen nur den Ursprungs‑Code, nicht den Endzustand nach JavaScript‑Ausführung.
Ein kleiner persönlicher Tipp
Ich schaue bei größeren Projekten gern in die Protokolle des Google‑Bots: Wie oft ruft er eine Seite ab, welche Ressourcen werden gecacht? Seit Google stärker auf Effizienz setzt, ist es wichtiger, Server‑Antworten sauber zu kennzeichnen – etwa mit ETag oder Last‑Modified. Das senkt Crawling‑Last und passt perfekt zu Illyes’ Hinweis, dass Google Seitenressourcen intern cached statt sie jedes Mal neu zu laden.
Ein Blick nach vorn
Spannend war am Rande, dass Splitt anmerkte, eigentlich hätten sie über sogenannte Client Hints sprechen wollen – also moderne Header wie Accept‑CH oder Sec‑CH-UA, die den alten User-Agent ersetzen. Offenbar plant Google hier künftig mehr Transparenz, wie der Crawler mit solchen Signalen umgeht. Bis das passiert, bleibt jedoch das Wesentliche: Priorisiere, was Nutzer sehen und erleben. Google arbeitet technisch auf einer ganz anderen Ebene – deine Optimierungen sollten das berücksichtigen.
Fazit
Wenn du das nächste Mal in einem SEO‑Audit eine lange Liste mit „fehlenden Preloads“ oder „HTML‑Fehlern“ siehst, atme kurz durch. Frag dich: Betrifft das wirklich den Googlebot – oder nur die UX? Es ist ein feiner Unterschied, aber er spart dir viel unnötige Arbeit. Aus meiner Sicht gehört diese Unterscheidung zu den wichtigsten Erkenntnissen aus diesem Gespräch: Was für Browser gilt, gilt nicht automatisch für Google.
