Tak, Googlebot potrafi crawlowa\u0107 po HTTP\/2. Domy\u015blnie jednak nadal u\u017cywa HTTP\/1.1 i przy ka\u017cdej wizycie sam wybiera wersj\u0119 protoko\u0142u. Dla administrator\u00f3w serwer\u00f3w obs\u0142uga HTTP\/2 przez Googlebota oznacza mniejsze obci\u0105\u017cenie przy crawlowaniu. Nie oznacza lepszych pozycji. Decyzja sprowadza si\u0119 wi\u0119c do tego, jak stabilne s\u0105 Tw\u00f3j serwer \u017ar\u00f3d\u0142owy i proxy.<\/p>\n\n\n\n
Obu, a domy\u015blnie HTTP\/1.1. W przegl\u0105dzie robot\u00f3w indeksuj\u0105cych Google<\/a> czytamy, \u017ce robot wybiera protok\u00f3\u0142, kt\u00f3ry daje najlepsz\u0105 wydajno\u015b\u0107 crawlowania, i mo\u017ce go zmienia\u0107 mi\u0119dzy sesjami na podstawie statystyk z wcze\u015bniejszych wizyt. W\u0142\u0105czenie HTTP\/2 tylko udost\u0119pnia ten protok\u00f3\u0142. Googlebot mo\u017ce z niego skorzysta\u0107, ale nie musi i nie zrobi tego przy ka\u017cdej wizycie. Widzisz w logach \u017c\u0105dania HTTP\/1.1 po zmianie? To normalne (ludzie panikuj\u0105 z tego powodu cz\u0119\u015bciej, ni\u017c mo\u017cna by s\u0105dzi\u0107).<\/p>\n\n\n\n Przede wszystkim oszcz\u0119dza zasoby obliczeniowe, takie jak CPU i RAM, zar\u00f3wno na Twoim serwerze, jak i po stronie Google. Wynika to z multipleksowania: jedno po\u0142\u0105czenie obs\u0142uguje wiele \u017c\u0105da\u0144 r\u00f3wnolegle, wi\u0119c to samo crawlowanie wymaga mniej uzgodnie\u0144 TCP i TLS. Google zaznacza, \u017ce chce pobra\u0107 jak najwi\u0119cej stron podczas jednej wizyty, nie przeci\u0105\u017caj\u0105c przy tym serwera. A je\u015bli Twoja maszyna i tak nie daje rady? Udokumentowanym rozwi\u0105zaniem jest obni\u017cenie tempa crawlowania, a nie zmiana protoko\u0142u. R\u00f3\u017cnic\u0119 odczujesz g\u0142\u00f3wnie na du\u017cych serwisach z intensywnym crawlowaniem, gdzie narzut na po\u0142\u0105czenia szybko si\u0119 kumuluje.<\/p>\n\n\n\n Nie. Google twierdzi, \u017ce poza zaoszcz\u0119dzonymi zasobami nie ma \u017cadnej korzy\u015bci dla konkretnych us\u0142ug, a jako przyk\u0142ad podaje \u201ebrak wzrostu pozycji w wyszukiwarce Google”. Wydajno\u015b\u0107 robota i sygna\u0142y wp\u0142ywaj\u0105ce na ranking<\/a> to dwie osobne sprawy, wi\u0119c nie w\u0142\u0105czaj HTTP\/2 w nadziei na awans w wynikach. Mimo to warto go w\u0142\u0105czy\u0107 z kilku sensownych powod\u00f3w:<\/p>\n\n\n\n Szczerze m\u00f3wi\u0105c, dla crawlowania wa\u017cniejsze s\u0105 inne rzeczy. Poprawne kody statusu. Rozs\u0105dne nag\u0142\u00f3wki cache. Google zaleca ETag zamiast Last-Modified<\/strong>, bo ETag omija problemy z formatowaniem dat.<\/p>\n\n\n\n W\u0142\u0105cz http2 w nginx dla nas\u0142uchu TLS i u\u017cyj sk\u0142adni, kt\u00f3rej oczekuje Twoja wersja NGINX. Starsze wydania przyjmuj\u0105 parametr Przed zamkni\u0119ciem po\u0142\u0105czenia HTTP\/2 serwer powinien wys\u0142a\u0107 ramk\u0119 GOAWAY, \u017ceby klient wiedzia\u0142, kt\u00f3re \u017c\u0105dania zosta\u0142y przetworzone. Specyfikacja HTTP\/2, czyli RFC 9113<\/a>, ostrzega, \u017ce klient, kt\u00f3ry nie mo\u017ce ponowi\u0107 \u017c\u0105da\u0144, traci wszystkie \u017c\u0105dania w toku, gdy po\u0142\u0105czenie zostanie zerwane. Najbardziej obrywaj\u0105 na tym po\u015brednicy, tacy jak proxy<\/a>. \u0141agodne zamkni\u0119cie odbywa si\u0119 w dw\u00f3ch 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\u017cym ruchu robot\u00f3w u\u017cywaj Skonfiguruj serwer tak, \u017ceby zwraca\u0142 kod statusu 421, gdy Google pr\u00f3buje po\u0142\u0105czy\u0107 si\u0119 ze stron\u0105 po HTTP\/2, zgodnie z opisem w dokumentacji robot\u00f3w indeksuj\u0105cych Google<\/a>. Nie mo\u017cesz tego zrobi\u0107? Mo\u017cesz skontaktowa\u0107 si\u0119 z zespo\u0142em Google odpowiedzialnym za crawlowanie, cho\u0107 samo Google nazywa to rozwi\u0105zaniem tymczasowym. Ta sama strona ostrzega, \u017ce wysy\u0142anie robotom niew\u0142a\u015bciwych kod\u00f3w statusu mo\u017ce wp\u0142yn\u0105\u0107 na to, jak witryna wy\u015bwietla si\u0119 w us\u0142ugach Google. Dlatego 421 zwracasz tylko na \u017c\u0105dania HTTP\/2. Nigdy dla ca\u0142ej witryny. Moim zdaniem rezygnacja ma sens w dw\u00f3ch przypadkach: HTTP\/2 dzia\u0142a niestabilnie na serwerze \u017ar\u00f3d\u0142owym albo proxy, albo gubisz \u017c\u0105dania w toku i nie da si\u0119 tego szybko naprawi\u0107.<\/p>\n\n\n\nCo crawlowanie po HTTP\/2 zmienia dla Twojego serwera<\/h2>\n\n\n\n
Czy HTTP\/2 daje korzy\u015b\u0107 SEO w rankingu?<\/h2>\n\n\n\n
\n
W\u0142\u0105czanie http2 w nginx bez psucia crawlowania<\/h2>\n\n\n\n
http2<\/code> w dyrektywie listen<\/code>. Nowsze wymagaj\u0105 osobnej dyrektywy http2 on;<\/code>. O jednym cz\u0119sto si\u0119 zapomina: po\u0142\u0105czenie klient-proxy i po\u0142\u0105czenie proxy-serwer \u017ar\u00f3d\u0142owy to osobne odcinki. HTTP\/2 na froncie nie zmienia sposobu, w jaki NGINX komunikuje si\u0119 z backendem. Je\u015bli Tw\u00f3j ruch przechodzi przez us\u0142ug\u0119 proxy opart\u0105 na NGINX<\/a> z adresami IP w UE i USA, sprawd\u017a osobno nas\u0142uch od strony klient\u00f3w i serwer \u017ar\u00f3d\u0142owy. Po w\u0142\u0105czeniu:<\/p>\n\n\n\n\n
curl -I --http2<\/code> na adres strony i potwierd\u017a protok\u00f3\u0142 w odpowiedzi.<\/li>\nDlaczego \u0142agodne zamykanie po\u0142\u0105cze\u0144 HTTP\/2 ma znaczenie<\/h2>\n\n\n\n
nginx -s reload<\/code> zamiast twardych restart\u00f3w.<\/p>\n\n\n\nJak zrezygnowa\u0107 z crawlowania po HTTP\/2<\/h2>\n\n\n\n