Czy Googlebot używa HTTP/2? Co to zmienia dla Twojego serwera

Tak, Googlebot potrafi crawlować po HTTP/2. Domyślnie jednak nadal używa HTTP/1.1 i przy każdej wizycie sam wybiera wersję protokołu. Dla administratorów serwerów obsługa HTTP/2 przez Googlebota oznacza mniejsze obciążenie przy crawlowaniu. Nie oznacza lepszych pozycji. Decyzja sprowadza się więc do tego, jak stabilne są Twój serwer źródłowy i proxy.

Googlebot a HTTP/2 i HTTP/1.1: którego protokołu używa?

Obu, a domyślnie HTTP/1.1. W przeglądzie robotów indeksujących Google czytamy, że robot wybiera protokół, który daje najlepszą wydajność crawlowania, i może go zmieniać między sesjami na podstawie statystyk z wcześniejszych wizyt. Włączenie HTTP/2 tylko udostępnia ten protokół. Googlebot może z niego skorzystać, ale nie musi i nie zrobi tego przy każdej wizycie. Widzisz w logach żądania HTTP/1.1 po zmianie? To normalne (ludzie panikują z tego powodu częściej, niż można by sądzić).

Co crawlowanie po HTTP/2 zmienia dla Twojego serwera

Przede wszystkim oszczędza zasoby obliczeniowe, takie jak CPU i RAM, zarówno na Twoim serwerze, jak i po stronie Google. Wynika to z multipleksowania: jedno połączenie obsługuje wiele żądań równolegle, więc to samo crawlowanie wymaga mniej uzgodnień TCP i TLS. Google zaznacza, że chce pobrać jak najwięcej stron podczas jednej wizyty, nie przeciążając przy tym serwera. A jeśli Twoja maszyna i tak nie daje rady? Udokumentowanym rozwiązaniem jest obniżenie tempa crawlowania, a nie zmiana protokołu. Różnicę odczujesz głównie na dużych serwisach z intensywnym crawlowaniem, gdzie narzut na połączenia szybko się kumuluje.

Czy HTTP/2 daje korzyść SEO w rankingu?

Nie. Google twierdzi, że poza zaoszczędzonymi zasobami nie ma żadnej korzyści dla konkretnych usług, a jako przykład podaje „brak wzrostu pozycji w wyszukiwarce Google”. Wydajność robota i sygnały wpływające na ranking to dwie osobne sprawy, więc nie włączaj HTTP/2 w nadziei na awans w wynikach. Mimo to warto go włączyć z kilku sensownych powodów:

• Mniejsze obciążenie serwera przy intensywnym crawlowaniu.
• Szybsze ładowanie stron dla Twoich własnych odwiedzających, bo przeglądarki mogą pobierać wiele zasobów przez jedno połączenie.
• Mniej otwartych połączeń do utrzymania na mocno obciążonych proxy.

Szczerze mówiąc, dla crawlowania ważniejsze są inne rzeczy. Poprawne kody statusu. Rozsądne nagłówki cache. Google zaleca ETag zamiast Last-Modified, bo ETag omija problemy z formatowaniem dat.

Włączanie http2 w nginx bez psucia crawlowania

Włącz http2 w nginx dla nasłuchu TLS i użyj składni, której oczekuje Twoja wersja NGINX. Starsze wydania przyjmują parametr http2 w dyrektywie listen. Nowsze wymagają osobnej dyrektywy http2 on;. O jednym często się zapomina: połączenie klient-proxy i połączenie proxy-serwer źródłowy to osobne odcinki. HTTP/2 na froncie nie zmienia sposobu, w jaki NGINX komunikuje się z backendem. Jeśli Twój ruch przechodzi przez usługę proxy opartą na NGINX z adresami IP w UE i USA, sprawdź osobno nasłuch od strony klientów i serwer źródłowy. Po włączeniu:

1. Uruchom curl -I --http2 na adres strony i potwierdź protokół w odpowiedzi.
2. Przefiltruj logi serwera pod kątem Googlebota i upewnij się, że kody statusu się nie zmieniły.
3. Jeśli błędy pojawiają się tylko za proxy, sprawdź, jak proxy NGINX współgra z crawlowaniem.

Dlaczego łagodne zamykanie połączeń HTTP/2 ma znaczenie

Przed zamknięciem połączenia HTTP/2 serwer powinien wysłać ramkę GOAWAY, żeby klient wiedział, które żądania zostały przetworzone. Specyfikacja HTTP/2, czyli RFC 9113, ostrzega, że klient, który nie może ponowić żądań, traci wszystkie żądania w toku, gdy połączenie zostanie zerwane. Najbardziej obrywają na tym pośrednicy, tacy jak proxy. Łagodne zamknięcie odbywa się w dwóch krokach. Najpierw GOAWAY z maksymalnym identyfikatorem strumienia i kodem NO_ERROR. Potem, po co najmniej jednym czasie obiegu (RTT), drugi GOAWAY z faktycznym ostatnim ID strumienia. Co to oznacza w codziennej pracy? Przy dużym ruchu robotów używaj nginx -s reload zamiast twardych restartów.

Jak zrezygnować z crawlowania po HTTP/2

Skonfiguruj serwer tak, żeby zwracał kod statusu 421, gdy Google próbuje połączyć się ze stroną po HTTP/2, zgodnie z opisem w dokumentacji robotów indeksujących Google. Nie możesz tego zrobić? Możesz skontaktować się z zespołem Google odpowiedzialnym za crawlowanie, choć samo Google nazywa to rozwiązaniem tymczasowym. Ta sama strona ostrzega, że wysyłanie robotom niewłaściwych kodów statusu może wpłynąć na to, jak witryna wyświetla się w usługach Google. Dlatego 421 zwracasz tylko na żądania HTTP/2. Nigdy dla całej witryny. Moim zdaniem rezygnacja ma sens w dwóch przypadkach: HTTP/2 działa niestabilnie na serwerze źródłowym albo proxy, albo gubisz żądania w toku i nie da się tego szybko naprawić.

Protokół to tylko jeden element układanki infrastrukturalnej. Warto też sprawdzić, jak dedykowane IP i HTTP/2 pasują do Twojej konfiguracji oraz czy lokalizacja serwera i opóźnienia odpowiadają temu, gdzie faktycznie są Twoi czytelnicy. Podsumowując: crawlowanie Googlebota po HTTP/2 dotyczy wydajności serwera, a nie pozycji w rankingu, więc decyzję podejmuj na podstawie stabilności i obciążenia swojego serwera.

FAQ