HTTP/3 hilft bei SEO – aber ganz anders, als du denkst

Mein letztes großes Projekt war es, HTTP/3 auf den Servern auszurollen. Man hört ja Gutes davon: QUIC und das alles soll schneller sein als HTTP/2, besonders bei schlechten Leitungen, und damit den Core Web Vitals helfen.

Sechs Wochen später kann ich festhalten: Ja, es hilft beim SEO. Aber völlig anders, als wir alle dachten.

Das Setup

Das Setup ist dabei in wesentlichen Teilen identisch geblieben, um den Vergleich fair zu halten:

• Server: Hetzner in Falkenstein (Deutschland).
• Besucher: Überwiegende Mehrheit aus dem DACH-Raum.
• Traffic: Ca. 20.000-30.000 Visits am Tag bei viel neuem Content (News- und Reviews-Charakter).
• Backend: WordPress mit WP Fastest Cache (statische HTML-Dateien).

Unterschiedlich ist nur der Webserver. Dieser war ursprünglich Apache, der mpm_event nutzte und seine Daten via HTTP/2 auslieferte. Jetzt ist es ein nginx, der seine Daten nach Möglichkeit per HTTP/3 an den Client schickt.

Und bevor jemand mit „kalten Caches“ und Erstkontakten kommt: Ich habe den HTTPS-Record im DNS gesetzt – ein aktueller Chrome weiß also schon bei der DNS-Abfrage, dass der Server HTTP/3 spricht, und nutzt es direkt ohne Alt-Svc-Umweg.

Den Core Web Vitals hat es nicht geholfen

Um den Elefanten im Raum direkt in die Ecke zu dirigieren: Sowohl unter Apache als auch mit nginx hat der Webserver, wenn möglich, direkt die gecachte HTML-Datei ausgeliefert und ist nicht den Umweg über PHP und MySQL gegangen. Für Apache wurden die Rewrite-Regeln genutzt, die WPFC direkt umsetzt; für nginx habe ich das Config-File aus dem rocket-nginx-Projekt als Basis genommen und angepasst.

Hier kommt der Downer: Den Core Web Vitals hat die ganze Aktion gar nicht geholfen.

Laut CrUX Vis – einer öffentlichen Datenbank über Performance-Metriken echter Nutzer (Chrome User Experience Report) – krebste der Wert für Time To First Byte (TTFB) vor der Umstellung am 16. November 2025 um die 300 Millisekunden herum – und das tat er auch danach noch.

Offensichtlich ist das Netzwerk in Deutschland eher „meh“. Mit meinem mittelguten DSL bekomme ich die ganze Seite in 80 ms heruntergeladen. Aber anscheinend ist die Round Trip Time (RTT) – aka der Ping zum Server – im „echten Leben“ draußen oft hoch. Im Terminal habe ich 15 ms, also bin ich wohl nicht repräsentativ.

Kurz gesagt: Für die Core Web Vitals (Nutzer-Sicht) waren die Änderungen enttäuschend. Man könnte zu dem Fazit kommen: Es ist den Aufwand nicht wert. Aber …

HTTP/3 hilft dem Googlebot (Tech SEO)

Was sich hingegen sehr lohnt, ist ein Blick in die Google Search Console (GSC). Dort gibt es unter Einstellungen -> Crawling-Statistiken die Grafik zur „durchschnittlichen Reaktionszeit“ – also der TTFB-Wert, wie Googlebot ihn sieht.

Und der ist deutlich besser als mit Apache und HTTP/2.

Nun könnte man einwenden, dass die Felddaten (CrUX) der offizielle Ranking-Faktor sind, insofern würde HTTP/3 für das Ranking nichts bringen. Das ist einerseits richtig, doch andererseits senden wir Googlebot mit der besseren TTFB ein anderes, extrem wichtiges Signal: „Der Server langweilt sich.“

Google versucht, aus dem Antwortverhalten abzuleiten, wie beschäftigt der Server ist (Host Load). Einerseits will der Bot so viel wie möglich crawlen, andererseits will er nicht schuld sein, wenn ein echter Besucher unter einem langsamen Server leidet. Indem der Googlebot die Seite via HTTP/3 schneller ausgeliefert bekommt, erreichen wir zwei Dinge:

1. Der Bot schafft mehr Requests in derselben Zeit (höherer Durchsatz).
2. Der Algorithmus geht davon aus, dass der Server noch Kapazitäten hat (und erhöht das Limit weiter).

Warum die Diskrepanz? (Es ist Physik!)

Warum merkt der Googlebot den Unterschied so extrem, meine Nutzer aber nicht?

1. Meine Nutzer sitzen in Deutschland. Der Weg zum Server nach Falkenstein ist kurz (geringe Latenz).
2. Googlebot kommt meist aus den USA (Mountain View). Der Weg führt über den Atlantik.

Auf dieser langen Strecke spielt HTTP/3 seine Stärken voll aus.

Während TCP für den Handshake mehrmals hin- und herfunken muss (3-Way-Handshake + TLS), ist QUIC fast sofort startklar (1-RTT). Was für den Nutzer in Berlin egal ist, spart dem Bot aus Kalifornien hunderte Millisekunden pro Request. Zudem blockiert QUIC bei Paketverlust (über den Atlantik wahrscheinlicher als im LAN) nicht die gesamte Verbindung (Head-of-Line Blocking).

Schnelle Antworten für mehr Crawl Budget

Das Ergebnis ist ein effizienteres Nutzen des Crawl Budgets (genauer: der Crawl Capacity). Seiten, die aus Zeitgründen nicht gecrawlt werden konnten, landen in der GSC oft in der ungeliebten Kategorie „Gefunden – zurzeit nicht indexiert“. Wenn deine Webseite newslastig ist, von Google Discover profitiert oder du einen Shop hast, ist das ein echter Nachteil.

Wenn man Googlebot davon überzeugen kann, dass der Server entspannt und superschnell antwortet, wird das Crawling-Limit (die Anzahl der gleichzeitigen Verbindungen) hochgesetzt. Inhalte kommen schneller in den Index.

Fazit: HTTP/3 lohnt sich (für den Bot)

Dass die Core Web Vitals gleich geblieben sind, bedeutet primär eins: Mobilfunk-Nutzer in Deutschland haben mit langsamen Netzwerken, aber stabilen Verbindungen zu tun. Hier bietet QUIC (UDP) keinen riesigen Vorteil gegenüber einem gut optimierten TCP-Stack.

Aber für Googlebot löst HTTP/3 ein reelles physikalisches Problem (Distanz) und verbessert die Performance-Metriken in der Search Console dramatisch. Wenn du deine Inhalte schnell im Index haben willst, ist das ein Gamechanger.