Przestój serwera a SEO: co powinno zwracać proxy

Gdy chodzi o przestój serwera a SEO, zasada jest krótka. Kiedy serwer źródłowy leży, proxy powinno zwracać kod 5xx, najlepiej 503. Nigdy stronę błędu z kodem 200 i nigdy 404. Ten poradnik jest dla właścicieli stron, których serwer źródłowy od czasu do czasu pada i którzy nie wiedzą, co w tym czasie dostają roboty wyszukiwarek. A sprawa wygląda tak: podczas awarii serwer źródłowy w ogóle nie odpowiada, więc o tym, co zobaczy Googlebot, decyduje to, co stoi przed nim (zwykle reverse proxy). Gdy za proxy stoi WordPress, równie ważne jest, żeby proxy w normalnej pracy poprawnie obsługiwało przekierowania i ruch HTTPS. To samo proxy obsługuje całe połączenie z robotem, łącznie z wyborem protokołu, więc warto wiedzieć, jak Googlebot korzysta z HTTP/2.

Co widzi Googlebot, gdy serwer źródłowy przestaje działać?

Widzi kod stanu z warstwy proxy, która stoi przed serwerem źródłowym. Tylko tyle. Jeśli serwer źródłowy odrzuca połączenia albo się wysypuje, NGINX i podobne proxy odpowiadają kodem 502 Bad Gateway. Jeśli serwer przyjmuje żądanie, ale nigdy go nie kończy, zwykle dostaniesz 504 Gateway Timeout. Niektóre konfiguracje pokazują zamiast tego własną stronę błędu, a ta może mieć dowolny kod stanu.

Dla indeksowania liczy się wyłącznie kod stanu. Widoczny tekst nie ma znaczenia. Strona z napisem „chwilowo niedostępna”, która zwraca 200? Dla robota to zwykła, działająca strona. Taka rozbieżność to jedna z typowych awarii warstwy proxy, które zwykle umykają uwadze, dopóki nie spadną pozycje.

Jak Google traktuje błędy 5xx i tempo crawlowania

Według dokumentacji Google o kodach HTTP odpowiedzi 5xx i 429 sprawiają, że roboty Google tymczasowo zwalniają, a treść odpowiedzi 5xx jest ignorowana. Adresy URL, które już są w indeksie, zostają w nim przez jakiś czas, ale ostatecznie wypadają, a adresy, które stale zwracają błąd serwera, są usuwane. Spowolnienie jest tym większe, im więcej pojedynczych adresów zwraca błąd serwera. Gdy serwer znów odpowiada kodem 2xx, Google stopniowo zwiększa tempo crawlowania.

Ta sama strona wrzuca 500, 502 i 503 do jednej grupy błędów serwera. Nie opisuje osobnego traktowania 502 i 503. Więc nie, żaden z nich nie ochroni twoich pozycji lepiej od drugiego.

Dlaczego strona serwisowa z kodem 200 lub 404 szkodzi bardziej niż 503

Kod 200 mówi Google, że twoja strona błędu to prawdziwa treść. Kod 404 mówi, że strony już nie ma. Podczas awarii oba są błędne. Dokumentacja kodów stanu Google podaje, że treść z odpowiedzi 2xx może zostać wzięta pod uwagę przy indeksowaniu, a to znaczy, że komunikat „zaraz wracamy” może zastąpić twój artykuł w indeksie. Słabo. Ta sama dokumentacja mówi, że zaindeksowane adresy zwracające 4xx są usuwane z indeksu i z czasem crawlowane rzadziej.

Właściwy kod stanu dla strony serwisowej to więc 5xx. Przyjazną stronę dla odwiedzających możesz zostawić - po prostu serwuj ją z kodem 503.

Konfiguracja NGINX, żeby podczas awarii zwracał 503 z Retry-After

Możesz to ustawić na własnym NGINX albo serwerze źródłowym za pomocą jednego pliku statycznego i kilku dyrektyw. Tę część konfigurujesz po swojej stronie, nie w proxy.

1. Utwórz statyczny plik serwisowy, na przykład /var/www/errors/maintenance.html, niezależny od aplikacji i bazy danych.
2. Przekieruj na niego błędy upstreamu dyrektywą error_page i włącz proxy_intercept_errors, żeby przechwytywać też błędy zwracane przez sam serwer źródłowy.
3. Wymuś kod odpowiedzi 503 składnią =503.
4. Dodaj nagłówek Retry-After z parametrem always, żeby NGINX wysyłał go także przy odpowiedziach z błędem.
5. Zdecyduj, jak ma się zachowywać robots.txt. Upewnij się, że nie zamienia się w twoją stronę HTML z kodem 200, i przetestuj go osobno.

location / {
    proxy_pass http://origin;
    proxy_intercept_errors on;
    error_page 502 504 =503 /maintenance.html;
}

location = /maintenance.html {
    root /var/www/errors;
    internal;
    add_header Retry-After 1800 always;
}

Retry-After to standardowy nagłówek HTTP, który mówi klientom, kiedy wrócić. Podlinkowana wyżej strona Google nie mówi, jak używają go jej roboty, więc traktuj go jako uprzejmość, a nie dźwignię rankingową. Sprawdzenie efektu jest proste: zatrzymaj serwer źródłowy i uruchom curl -I https://example.com/. Powinieneś zobaczyć linię statusu 503 i nagłówek Retry-After. Dokładnie to dostałby robot.

Planowane prace a nieoczekiwane awarie: co sprawdzić

Planowane prace to łatwy przypadek. Świadomie przełączasz na 503, trzymasz krótkie okno i jak najszybciej wracasz do 2xx. Bałagan zaczyna się przy nieoczekiwanych awariach, bo domyślna odpowiedź błędu może pochodzić z CMS-a albo panelu hostingu, który chętnie serwuje ładnie ostylowaną stronę z kodem 200. Po każdym incydencie sprawdź:

• jaki kod stanu faktycznie zwraca twoja strona błędu,
• co zwraca robots.txt, gdy serwer źródłowy nie działa,
• błędy indeksowania w Search Console w kolejnych dniach,
• czy monitoring dostępności cię powiadomił i jak szybko.

Ta sama dyscyplina obowiązuje zresztą przy zmianie serwerów lub adresów. Ten przypadek omawia poradnik o migracji bez utraty pozycji.

Gdzie w tym wszystkim jest warstwa proxy

Reverse proxy pozostaje osiągalne, gdy serwer źródłowy za nim pada. Dlatego to ono decyduje o odpowiedzi, którą dostają roboty. Jalvo to reverse proxy NGINX z adresami IP w UE i USA, panelem do kierowania domen, rotacją IP, geotargetowaniem i opcjonalnym hostingiem. Opisana wyżej obsługa błędów nadal należy do konfiguracji twojego serwera. Na stronie dostępność i wydajność proxy znajdziesz, co obejmuje usługa.

Podsumowanie: właściwy kod stanu przy przestoju serwera a SEO

Serwer źródłowy nie działa? Zwracaj 503 albo inny kod 5xx, nigdy stronę z kodem 200 ani 404, i jak najszybciej wróć do odpowiedzi 2xx. Przetestuj konfigurację curl-em przed następną awarią, a nie w jej trakcie. Nie wiesz, jak zachowuje się twój stos? Zapytaj nas o swoją konfigurację, a sprawdzimy, jak skierowane są twoje domeny. Szczerze mówiąc, kilka linijek konfiguracji to wszystko, co dzieli nieszkodliwy przestój od utraty pozycji, i dlatego ten punkt powinien być na każdej liście kontrolnej przestoju serwera a SEO.

FAQ