Googlebot, HTTP/3 und der Rückfall ins Jahr 2002

Ich habe kürzlich die Entdeckung gemacht, dass Besucher nur bedingt von HTTP/3 profitieren (zumindest in Deutschland), der Googlebot dafür aber umso mehr: Die TTFB (Time To First Byte) halbierte sich in meinem ersten Test fast.

Diese These ist auch weiterhin gültig – allerdings muss ich sie heute um ein dickes, fettes „Wenn“ erweitern: Das gilt nur, wenn Googlebot HTTP/3 auch tatsächlich verwendet.

Was – wie es aussieht – weder garantiert noch wahrscheinlich ist.

Die Ernüchterung in der Search Console

Ende Dezember schaute ich nach sechs Wochen in die Google Search Console und stellte fest, dass auf der Webseite aus dem ersten Artikel (nennen wir sie „Film-Seite“) der Wert für die TTFB aus Sicht des Googlebots massiv sank und dort auch blieb. Siehe: HTTP/3 hilft bei SEO – aber ganz anders, als du denkst.

Über Weihnachten habe ich einer zweiten Webseite („Auto-Seite“) ebenfalls das volle Programm spendiert: nginx, HTTP/3 und WP Rocket. Das bedeutet: Auch Seite 2 liefert jetzt gecachte HTML-Files aus, anstatt bei jedem Aufruf die Datenbank zu bemühen. Die Erwartungshaltung war klar: Die Kurve muss nach unten zeigen.

In der Search Console sieht das aber so aus:

Wie sich gut erkennen lässt, ist die „durchschnittliche Reaktionszeit“ zwar gesunken – ziemlich genau um die 200 Millisekunden, die der PHP-FPM-Worker zuvor mit dem Generieren der Seite beschäftigt war. Aber halbiert hat sich hier nichts. (Und nein, ich weiß nicht, welchen Schluckauf Google am 13. Januar hatte, dass die TTFB kurz auf 875 Millisekunden hochschnellte).

Zum Vergleich hier nochmal die „Film-Seite“, auf der der im anderen Artikel beschriebene Effekt gut sichtbar ist. Die TTFB ist halbiert und seither konstant niedrig:

Bei der Auto-Seite (kein H3-Effekt) geht es um Leasing-Deals, auf der Film-Seite (H3-Effekt) um Kritiken. Das Thema sollte technisch keine Rolle spielen, würde man meinen. Aber hier kommt der Plot-Twist.

Wo ist der Unterschied?

Ich habe die Access-Logs analysiert, und der Unterschied liegt schlicht im verwendeten Protokoll:

• Film-Seite: Der Googlebot kommt fast immer via HTTP/3.
• Auto-Seite: Der Googlebot kommt meistens mit HTTP/1.1 – „like it‘s 2002“.

In Ausnahmefällen traut er sich bei der Auto-Seite mal HTTP/2 zu, aber das ist eher selten. Das erklärt die Unterschiede in den Graphen perfekt (Latenz USA -> DE), aber die spannendere Frage ist: Warum tut Googlebot das?

Theorie: Googlebot ist eine Effizienz-Maschine

Ich habe höhere Mächte konsultiert, um diese Frage zu beantworten. Denn ich weiß es selbst nicht und vermutlich weiß es niemand genau (außer den Google-Engineers). Aber wenn man sich die nackten Zahlen ansieht, ergibt sich eine Theorie, die erschreckend plausibel klingt.

Schauen wir uns die Crawling-Anfragen der letzten 90 Tage an:

• Auto-Seite: 467.000 Anfragen (Ø ~5.000 / Tag).
• Film-Seite: 7,63 Millionen Anfragen (Ø ~85.000 / Tag).

Die Film-Seite hat also statistisch fast jede Sekunde eine Anfrage. Da der Bot meist in Wellen kommt, feuert er wahrscheinlich Dutzende Requests pro Sekunde ab und bleibt „auf der Leitung“.

Overhead vs. Connection Reuse

Hier liegt der Hund begraben. Googlebot hält die Auto-Seite nicht für „frequentiert“ genug, um den Aufwand für HTTP/3 zu rechtfertigen. Er nimmt in Kauf, dass HTTP/1.1 etwas langsamer überträgt, will dafür aber lieber die Garantie eines etablierten, simplen TCP-Handshakes.

Ein QUIC-Handshake (für HTTP/3) erzeugt CPU-Last und Overhead beim Verbindungsaufbau (UDP Encryption). QUIC ist zwar schneller in der Übertragung, aber initial „teurer“ in der Rechenleistung. Dass QUIC einen gewissen Overhead erzeugt, spielt nur bei Skalierungen auf dem Niveau eines Googlebots eine Rolle. Für den normalen Client lässt sich das vernachlässigen – er holt sich ja auch keine 100 Seiten pro Sekunde.

Das lohnt sich für Google nur, wenn man die Verbindung dann auch lange offen hält und hunderte Requests darüber schiebt (Multiplexing / Connection Reuse).

• Bei der Film-Seite: Der Bot ist Dauergast. Er öffnet die „teure“ HTTP/3-Verbindung einmal und jagt tausende URLs durch. Das ist maximale Effizienz.
• Bei der Auto-Seite: Der Bot schaut nur kurz für ein paar URLs rein. Hier lohnt sich der Invest in den Handshake nicht. Er nimmt den Standardweg (HTTP/1.1), holt sich die Daten und verschwindet wieder.

Plot Twist: Google riecht das Verfallsdatum

Es gibt noch eine zweite Ebene. Offenbar macht Google große Unterschiede, ob es eine Seite wert ist, oft gecrawlt zu werden – selbst wenn die Frequenz neuer Inhalte identisch ist. Denn beide Seiten schieben täglich etwa zehn neue Texte nach.

Der Unterschied ist die Halbwertszeit:

• Auto-Seite: Berichtet über Leasing-Angebote. Ein abgelaufener Deal ist wenige Wochen später wertloser Datenmüll („Expired Content“).
• Film-Seite: Bringt Kritiken. Die altern gut. Ob „Titanic“ ein sehenswerter Film ist, hat sich seit 1997 kaum geändert. Das ist klassischer „Evergreen-Content“.

Es scheint also, als ob Google bestrebt ist, bleibende Inhalte aggressiv aktuell zu halten (via HTTP/3), während flüchtige Deals, die ohnehin bald „Schnee von gestern“ sind, nur das Nötigste an Crawl-Ressourcen (HTTP/1.1) abbekommen.

Technisch sind beide (fast) gleich

Um „User Error“ auszuschließen: Sowohl die Auto-Seite als auch die Film-Seite sind technisch Zwillinge.

• Caching: Beide nutzen statisches HTML-Caching (WP Fastest Cache vs. WP Rocket), ausgeliefert direkt via nginx ohne PHP-Umweg.
• Server: Identische Hardware, Debian Trixie, gemanaged von Froxlor, nginx aus dem Sury-Repo.
• H3-Config: Beide senden den Alt-Svc-Header und haben im DNS den neumodischen HTTPS-Record gesetzt. TLS 1.3 ist an.

Client wie Bot haben also die bestmöglichen Chancen, direkt auf die modernste Technologie zu gehen. Echte User-Browser tun das auch. Googlebot aber nicht.

Und jetzt?

Was ist nun mit der These aus dem ersten Artikel, dass HTTP/3 beim technischen SEO hilft, weil Googlebot den Server für „gelangweilter“ hält, wenn die TTFB runtergeht?

Das gilt weiterhin!

Allerdings mit einer wichtigen Nuance: Googlebot denkt nicht primär in absoluten Millisekunden, sondern in Stabilität und Kapazität pro Ressourceneinheit.

Der Punkt ist: WENN sich Googlebot dazu herablässt, HTTP/3 zu verwenden, sinkt die TTFB drastisch. Das ist für den Bot das Signal: „Dieser Server antwortet blitzschnell, der hat noch Reserven.“ Und genau dieses Signal ist Gold wert für das Crawl-Budget.

Aber wir lernen heute: Wir können als Admins nur die Tür aufmachen (Server-Config). Ob der Googlebot durchgeht (HTTP/3) oder lieber wie im Jahr 2002 durchs Fenster klettert (HTTP/1.1), entscheidet er anhand seiner eigenen Ressourcen-Planung.