504 Przekroczenie czasu bramy

TL;DR — 504 Gateway Timeout oznacza, że coś przed witryną — CDN, load balancer lub proxy — czekało na odpowiedź serwera i zrezygnowało, bo trwało to zbyt długo. To przekroczenie czasu, a nie uszkodzona odpowiedź. Pojedynczy 504 od czasu do czasu jest w porządku; problemem jest powtarzanie się błędów, bo wyszukiwarki crawlują wtedy witrynę rzadziej i ostatecznie mogą usunąć strony.

Co naprawdę oznacza 504

Podczas ładowania strony żądanie często nie trafia bezpośrednio do serwera WWW. Zwykle najpierw przechodzi przez bramę — CDN, load balancer lub reverse proxy. Brama przekazuje żądanie serwerowi za nią (upstream lub źródło), czeka na odpowiedź i przekazuje ją dalej.

504 Gateway Timeout to odpowiedź bramy, gdy czekała na upstream i nie otrzymała odpowiedzi na czas. Źródło może powoli wykonywać zapytanie do bazy, czekać na zewnętrzne API albo być przeciążone — z punktu widzenia bramy upłynął jednak limit. Evidence for this claim A 504 response means a gateway or proxy did not receive a timely response from an upstream server. Scope: RFC 9110 defines the timeout semantics; it does not determine why the upstream response was delayed. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.5 — 504 Gateway Timeout

Kluczowe słowo to timeout. Nic nie musiało być „zepsute”. Odpowiedź po prostu nie nadeszła wystarczająco szybko.

Czym różni się od rodzeństwa 5xx

Ludzie stale je ze sobą mylą:

• 502 Bad Gateway — brama otrzymała odpowiedź ze źródła, ale była ona nieprawidłowa lub zniekształcona.
• 503 Service Unavailable — serwer wprost powiedział „w tej chwili jestem niedostępny” (często celowo, na przykład podczas konserwacji).
• 504 Gateway Timeout — brama nie otrzymała na czas odpowiedzi od upstreamu. To węższe stwierdzenie niż „nic nie wróciło” — upstream może nadal pracować, tylko nie odpowiedział w czasie oczekiwania.

504 jest więc niemal zawsze objawem wydajności: coś po stronie upstreamu działa zbyt wolno.

Czy 504 szkodzi SEO?

Nie bezpośrednio i nie jest to kara. Google nie ocenia treści — dosłownie nie może pobrać strony. Istnieje jednak rzeczywisty koszt pośredni:

• Jeśli Googlebot stale trafia na wolne odpowiedzi i przekroczenia czasu, wycofuje się i crawluje witrynę rzadziej, aby nie pogorszyć przeciążenia.
• Pojedynczy 504 podczas skoku ruchu zostanie ponowiony i w większości zignorowany.
• 504 powtarzające się przez wiele dni prowadzą do usunięcia stron z indeksu — Google nie może ich niezawodnie pobierać. Evidence for this claim Google reduces crawling when server errors or slow responses indicate a site is having trouble responding. Scope: Google's documentation supports automatic crawl throttling for server trouble; it does not attribute a specific 504 to any particular bottleneck. Confidence: high · Verified: 2026-07-14 Google: Troubleshoot crawling errors

Co z tym zrobić

• Odśwież raz lub dwa razy — jednorazowy 504 może być tylko chwilową przerwą.
• Sprawdź logi serwera i błędów, aby zobaczyć, co działało wolno (zapytanie do bazy, zewnętrzne API, przeciążony proces aplikacji).
• Nie zwiększaj po prostu limitu czasu i nie uznawaj sprawy za zamkniętą — ukrywa to wolną odpowiedź zamiast ją naprawiać (więcej o tym w karcie Advanced).
• Utrzymuj szybkość serwera: cache, szybsze zapytania i wystarczająca pojemność to prawdziwa prewencja.

Chcesz poznać pełną wersję techniczną — skąd 504 pochodzi w łańcuchu żądania, jak działa ograniczanie crawlowania Googlebota i dlaczego warto obserwować TTFB? Przejdź do karty Advanced.

TL;DR — 504 to brama/proxy informujące, że serwer upstream nie odpowiedział w oknie limitu — przekroczenie czasu, inne niż 502 (błędna odpowiedź) i 503 (jawna niedostępność). To problem dostępności, a nie kara. Przekroczenia czasu trafiają do tej samej grupy co 429/500/503: Googlebot wycofuje się po ich zaobserwowaniu, a utrzymujące się 504 stwarzają ryzyko usunięcia z indeksu. Trwałą naprawą jest czas odpowiedzi serwera (TTFB), a nie dłuższy limit — jego zwiększenie zwykle maskuje wolny upstream i może pogorszyć sytuację pod obciążeniem.

Skąd 504 pochodzi w łańcuchu żądania

Nowoczesna ścieżka żądania wygląda mniej więcej tak: przeglądarka → CDN/krawędź → load balancer → reverse proxy (np. Nginx) → serwer aplikacji (PHP-FPM, Node itd.) → baza danych / zewnętrzne API. 504 generuje ten komponent, który czekał na komponent znajdujący się za nim, gdy wygasł jego limit. To pierwsze pytanie diagnostyczne: Evidence for this claim A 504 response means a gateway or proxy did not receive a timely response from an upstream server. Scope: RFC 9110 defines the timeout semantics; it does not determine why the upstream response was delayed. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.5 — 504 Gateway Timeout

• CDN/krawędź przekracza czas oczekiwania na źródło → naprawą jest wydajność źródła albo ostrożne podniesienie limitu upstreamu CDN-u.
• Load balancer przekracza czas oczekiwania na serwer aplikacji → sprawdź kondycję serwera aplikacji i autoskalowanie.
• Reverse proxy przekracza czas oczekiwania na proces aplikacji → sprawdź proxy_read_timeout / fastcgi_read_timeout Nginxa oraz wolne zapytanie lub proces, który rzeczywiście jest za nimi.

Właściwe ustalenie warstwy ma znaczenie, bo „napraw limit czasu na krawędzi” i „napraw wolne zapytanie do bazy na źródle” to zupełnie różne zadania.

Co powoduje 504s

Sam kod stanu nie dowodzi przyczyny — mówi tylko, że brama przekroczyła czas oczekiwania na upstream. To typowi podejrzani, których warto sprawdzić, a nie fakty wynikające z samego 504; zanim zadziałasz, potwierdź je w logach i śladach:

• Wolne zapytania do bazy lub wywołania upstream API. Jedno niezindeksowane zapytanie albo opóźniona zależność zewnętrzna może wypchnąć czas odpowiedzi poza limit.
• Przeciążenie serwera/aplikacji i wyczerpanie zasobów. Przy wystarczającym ruchu równoległym żądania ustawiają się w kolejce, procesy robocze zapełniają się, a odpowiedzi nie docierają na czas.
• Źle skonfigurowane limity czasu w Nginx, Apache, load balancerze lub CDN-ie — często różniące się między warstwami, tak że jedna rezygnuje wcześniej niż druga.
• Skoki ruchu, fale botów lub DDoS, które chwilowo przeciążają pojemność.

504s często pojawiają się sporadycznie i zależą od obciążenia

To właśnie czyni je trudnymi. W przeciwieństwie do całkowitej awarii 504 często pojawia się dopiero pod obciążeniem — monitor dostępności pingujący w spokojnym oknie może być w 100% zielony, podczas gdy Googlebot przy większych falach crawlowania po cichu zbiera przekroczenia czasu. W URL Inspection Google Search Console możesz zobaczyć to jako warunek „Hostload exceeded”, a nie czysty, stały błąd. Jeśli monitoring mówi, że wszystko jest w porządku, a Statystyki crawlowania mówią coś innego, 504 zależne od obciążenia jest głównym podejrzanym.

Jak Googlebot (i Bingbot) obsługują przekroczenia czasu

Google nie traktuje 504 jako oceny jakości treści — to sygnał dostępności, a reakcją jest automatyczne ograniczenie crawlowania. Dokumentacja dotycząca crawlowania mówi wprost: “Googlebot will scale back its crawling if it detects that your servers are having trouble responding to crawl requests.” (tłumaczenie) „Googlebot ograniczy crawlowanie, jeśli wykryje, że Twoje serwery mają problemy z odpowiadaniem na żądania crawlowania.” Przewodnik po budżecie crawlowania dla dużych witryn mówi to samo w kategoriach budżetu: “If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (tłumaczenie) „Gdy witryna zwalnia lub odpowiada błędami serwera, limit spada, a Google crawluje mniej.” Evidence for this claim Google reduces crawling when server errors or slow responses indicate a site is having trouble responding. Scope: Google's documentation supports automatic crawl throttling for server trouble; it does not attribute a specific 504 to any particular bottleneck. Confidence: high · Verified: 2026-07-14 Google: Troubleshoot crawling errors

Najświeższe ujęcie, łączące to bezpośrednio z powolnymi odpowiedziami i przekroczeniami czasu, pochodzi z wyjaśnienia Inside Googlebot Google z marca 2026 r., w którym Gary Illyes mówi: “If your server is struggling to serve bytes, our crawlers will automatically back off to avoid overloading your infrastructure, which will drop your crawl frequency.” (tłumaczenie) „Jeśli serwer ma trudności z dostarczaniem bajtów, nasze crawlery automatycznie się wycofają, aby nie przeciążać infrastruktury, co obniży częstotliwość crawlowania.” (Jak relacjonuje Search Engine Land — jeśli cytujesz to gdzie indziej, warto potwierdzić treść w oryginalnym nagraniu lub transkrypcji.) 504 uwidacznia właśnie taką trudność.

Warto rozumieć jeden niuans: Google nie zawsze widzi dosłowny „504” tak jak przeglądarka. Jeśli limit wygasa, zanim Googlebot otrzyma jakikolwiek wiersz statusu, w Statystykach crawlowania zostaje to zapisane jako przekroczenie czasu/błąd sieci, a nie czysty 5xx. Gdy jednak pośredniczące proxy lub CDN przekroczy limit i samo wygeneruje 504, Googlebot otrzymuje standardowy błąd serwera 5xx. W obu przypadkach efekt jest taki sam: ograniczenie szybkości crawlowania, a przy utrzymywaniu się problemu — usunięcie z indeksu.

Bing dokumentuje przekroczenia czasu jako osobną kategorię błędów crawlowania, odrębną od błędów serwera — Bingbot przestaje próbować otwierać strony, gdy odpowiedzi są zbyt wolne — a jego stała rekomendacja to sprawdzenie czasu odpowiedzi serwera, aktualizacja oprogramowania, optymalizacja wolnych zasobów i odczyt logów pod kątem wzorców systemowych, a nie pojedynczych przerw. Bing nie opublikował tak szczegółowego opisu ograniczania i odzyskiwania jak Google, więc traktuj oba mechanizmy jako zasadniczo podobne w intencji, a nie potwierdzone jako identyczne.

Pętla: ograniczenie, a potem odzyskanie

Uspokajające jest to, że ta pętla jest automatyczna i samokorygująca. Google ogranicza crawlowanie, gdy widzi błędy i przekroczenia czasu, a następnie stopniowo zwiększa jego tempo, gdy odpowiedzi znów są prawidłowe. Po naprawieniu przyczyny nie trzeba ręcznie naciskać przycisku „odblokowania” — jak zauważył John Mueller: _“Once things settle down on the server, the crawl rate will return to normal automatically.”_ (tłumaczenie) „Gdy sytuacja na serwerze się uspokoi, tempo crawlowania automatycznie wróci do normy.” Zwrócił też uwagę na asymetrię: ograniczenie tempa następuje szybko, aby rozwiązać bezpośredni problem, a jego ponowne zwiększanie przebiega ostrożnie.

To czas trwania zmienia chwilową przerwę w problem indeksowania

Krótkie, sporadyczne 504 — kilka podczas skoku, szybko rozwiązanych — są ponawiane i w dużej mierze tolerowane. Ryzyko usunięcia z indeksu dotyczy utrzymującego się wzorca przekroczeń czasu przez dłuższy okres. Udokumentowana przez Google mechanika „wróć później” — w której celowo zwracasz 503 lub 429 przy przeciążeniu — opisuje około dwudniowy horyzont, zanim adresy URL zaczną znikać, ale ta liczba jest udokumentowana z nazwy dla 503/429, nie dla 504. Szersze wytyczne Google dotyczące 5xx mówią, że szybkość crawlowania spada proporcjonalnie do liczby błędnych adresów URL i stopniowo wraca, gdy odpowiedzi są zdrowe, bez podania stałego horyzontu dla 504. Przeniesienie dwóch dni na 504 jest rozsądnym wnioskiem, a nie faktem z dokumentacji — traktuj to tak: krótkie 504 da się przetrwać, a utrzymujący się przez wiele dni wzorzec to zakres do obaw, nie gwarantowana data wyzwolenia.

Dlaczego ma to większe znaczenie w dużych i e-commerce witrynach

Jeśli masz małą witrynę, której strony są crawlowane tego samego dnia, prawie tego nie zauważysz. Jednak w dużych lub szybko zmieniających się witrynach — dużych katalogach e-commerce, serwisach informacyjnych i marketplace’ach — budżet crawlowania już jest ograniczeniem, a fala 504s przy szczytowym obciążeniu może pozbawić crawlowania stron, które naprawdę powinny zostać ponownie odwiedzone. Przy dużej skali przekroczenia czasu i budżet crawlowania to ta sama rozmowa.

Czas odpowiedzi serwera i TTFB są silną dźwignią prewencji — dla przyczyn po stronie źródła

Oto punkt pomijany przez większość artykułów o 504: czekanie na pojawienie się błędów, a potem grepowanie logów jest reaktywne. Ciągłe monitorowanie czasu odpowiedzi serwera, aby zobaczyć dryf, zanim przejdzie w timeout, jest proaktywne. Serwer, który dziś jest wolny, ale jeszcze nie przekracza limitu, jutro przy odrobinę większym obciążeniu albo odrobinę wolniejszej zależności staje się serwerem generującym 504. Obserwowanie TTFB (time to first byte) jako stałego sygnału wczesnego ostrzegania — nie tylko metryki po fakcie — pozwala wychwycić ten dryf.

Zastrzeżenie: monitoring TTFB dotyczy powolności po stronie źródła. Nie wykryje CDN-u przekraczającego czas na zdrowym źródle, źle skonfigurowanego load balancera rezygnującego zbyt szybko ani problemu ścieżki sieciowej między warstwami — najpierw trzeba ustalić warstwę wystawiającą (sekcja „Skąd 504 pochodzi” powyżej lub drzewo decyzji poniżej). TTFB jest prawdziwą, trwałą naprawą typowego przypadku rzeczywiście wolnego upstreamu, ale nie rozwiązaniem uniwersalnym. Po potwierdzeniu, że wąskim gardłem jest źródło, optymalizuj przez cache (strony, obiektów i krawędzi CDN), szybsze zapytania i właściwe indeksowanie bazy, autoskalowanie oraz rozsądne strojenie limitu upstreamu CDN.

Dlaczego „po prostu zwiększ limit czasu” to zły odruch

Zwiększenie proxy_read_timeout albo limitu upstreamu CDN-u może sprawić, że 504 przestanie być widoczny — ale nie przyspiesza odpowiedzi upstreamu. Co gorsza, przy obciążeniu dłuższe okno oczekiwania powoduje, że żądania na dłużej ustawiają się w kolejce i zajmują procesy robocze oraz połączenia, co może pogorszyć spiralę przeciążenia. Czasem podniesienie limitu jest właściwe (przy rzeczywiście długiej, dobrze zrozumianej operacji), ale jako odruch maskuje prawdziwy problem.

Gdy przestój jest planowany albo celowo zrzucasz obciążenie, właściwym narzędziem nie jest pozwalanie stronom zwracać 504 — zwróć 503 (z nagłówkiem Retry-After), aby wysłać wyszukiwarkom czysty, zamierzony sygnał „wróć później”, zamiast chaotycznego przekroczenia czasu.

Diagnozowanie 504 w praktyce

Zanim zaczniesz zgadywać przyczynę, ustal warstwę wystawiającą — na tym polega różnica między naprawą prawdziwego problemu a naprawą objawu:

• Odtwórz problem i ustal, która warstwa odpowiedziała. Otwórz stronę w przeglądarce; wykonaj curl i obserwuj time_starttransfer dla TTFB; uruchom crawler, np. Ahrefs Site Audit lub Screaming Frog, aby sprawdzić, czy problem obejmuje całą witrynę, czy jest odosobniony. Jeśli możesz, przetestuj bezpośrednio źródło (z pominięciem CDN/proxy), aby zobaczyć, czy samo źródło kończy żądanie.
• Odczytaj logi. Logi serwera i proxy mówią, która warstwa przekroczyła limit i — idealnie — na czym; może to być wolne zapytanie, zablokowany upstream lub wyczerpana pula procesów. Koreluj warstwy według czasu i identyfikatora żądania, zamiast zakładać.
• Sprawdź Search Console. Statystyki crawlowania pokazują skoki kodów odpowiedzi i średni czas odpowiedzi; raport indeksowania stron i URL Inspection pokazują, czy Google trafia na przekroczenia czasu (w tym „Hostload exceeded”).

Ważne jest pogodzenie narzędzi: 504 w przeglądarce, 5xx w Ahrefs Site Audit i timeout w GSC mogą opisywać tę samą wolną przyczynę źródłową widzianą z różnych punktów obserwacji. Nie zakładaj, że trzy narzędzia oznaczają trzy problemy.

Powiązane kody

504 należy do małej rodziny. 500 jest ogólnym błędem serwera bez bardziej szczegółowego kodu; 502 jest błędną/zniekształconą odpowiedzią upstreamu; 503 to jawne, często zamierzone „niedostępne”. Wiedza o tym, który kod rzeczywiście zwracasz — i celowe zwracanie właściwego podczas planowanej niedostępności — to połowa sukcesu.

Podsumowanie AI

Skrót wersji Advanced:

• 504 = timeout, a nie uszkodzona odpowiedź. Brama/proxy (CDN, load balancer, reverse proxy) czekało na serwer upstream i nie otrzymało odpowiedzi na czas — niekoniecznie nigdy. Różni się od 502 (błędna odpowiedź) i 503 (jawna niedostępność). Sam kod nie dowodzi, która warstwa lub przyczyna zawiniła; przed naprawą ustal warstwę wystawiającą.
• To nie kara. To problem dostępności — Google nie może pobrać strony, więc strata rankingu/indeksowania jest skutkiem pośrednim, a nie karą.
• Timeouty uruchamiają ograniczenie crawlowania. Google mówi, że Googlebot ograniczy crawlowanie, gdy wykryje problem z odpowiadaniem serwerów. Gary Illyes (według relacji Search Engine Land z marca 2026 r.) mówi o automatycznym wycofaniu crawlerów, które zmniejsza częstotliwość crawlowania.
• Czas trwania ma znaczenie, ale „2 dni” nie jest udokumentowaną liczbą Google dla 504. Ten horyzont dotyczy celowo zwracanych 503/429 przy przeciążeniu. Szersze wytyczne 5xx mówią o proporcjonalnym spadku i stopniowym odzyskaniu, bez stałego harmonogramu dla 504 — pojedyncze 504 są ponawiane, a długi wzorzec stwarza ryzyko usunięcia z indeksu.
• Pętla sama się koryguje. Po odzyskaniu odpowiedzi szybkość crawlowania wraca automatycznie — bez ręcznego odblokowania.
• Często jest sporadyczne i zależne od obciążenia — niewidoczne dla monitoringu pingującego spokojne okna; w URL Inspection może pojawić się jako „Hostload exceeded”.
• Czas odpowiedzi serwera (TTFB) jest silną dźwignią prewencji dla przyczyn po stronie źródła, obserwowaną jako sygnał wczesnego ostrzegania — ale nie uniwersalnym rozwiązaniem: 504 może pochodzić także z CDN-u, load balancera lub proxy, więc najpierw ustal warstwę. Zwiększenie limitu czasu nie jest naprawą; maskuje wolny upstream i może pogorszyć przeciążenie.
• Przy planowanej niedostępności zwróć 503 z Retry-After, a nie 504.

Oficjalna dokumentacja

Pierwotna dokumentacja dotycząca przekroczeń czasu, błędów serwera i reakcji crawlerów.

Definicja

• MDN — 504 Gateway Timeout — autorytatywna definicja i różnica względem 502.

Google

• Diagnozowanie błędów crawlowania — jak Googlebot wycofuje się przy problemach serwera oraz kiedy przy przeciążeniu zwracać 503/429.
• Optymalizacja budżetu crawlowania — jak wolne odpowiedzi i błędy serwera obniżają limit crawlowania.
• Raport statystyk crawlowania — kategorie „Błąd serwera (5XX)” i „Przekroczenie czasu strony” oraz sposób, w jaki Googlebot ogranicza crawlowanie, aby uniknąć przeciążenia.

Bing / Microsoft

• Bing Webmaster Tools — alerty o błędach crawlowania — sposób oznaczania przez Bing błędów serwera i przekroczeń czasu jako osobnych kategorii błędów crawlowania.

Cytaty ze źródeł

Wypowiedzi źródłowe. Każdy link prowadzi bezpośrednio do cytowanego fragmentu strony źródłowej.

MDN — definicja

• “The HTTP 504 Gateway Timeout server error response status code indicates that the server, while acting as a gateway or proxy, did not get a response in time from the upstream server in order to complete the request. This is similar to a 502 Bad Gateway, except that in a 504 status, the proxy or gateway did not receive any HTTP response from the origin within a certain time.” (tłumaczenie) „Kod odpowiedzi błędu serwera HTTP 504 Gateway Timeout oznacza, że serwer działający jako brama lub proxy nie otrzymał na czas odpowiedzi od serwera upstream, aby zakończyć żądanie. Jest to podobne do 502 Bad Gateway, z tym że przy 504 proxy lub brama nie otrzymały w określonym czasie żadnej odpowiedzi HTTP od originu.” Przejdź do cytatu

Google — crawlowanie i przekroczenia czasu

• “Googlebot will scale back its crawling if it detects that your servers are having trouble responding to crawl requests.” (tłumaczenie) „Googlebot ograniczy crawlowanie, jeśli wykryje, że Twoje serwery mają problemy z odpowiadaniem na żądania crawlowania.” — Google Search Central, „Rozwiązywanie problemów z crawlowaniem”. Przejdź do cytatu
• “If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (tłumaczenie) „Gdy witryna zwalnia lub odpowiada błędami serwera, limit spada, a Google crawluje mniej.” — Google Search Central, „Optymalizacja budżetu crawlowania”. Przejdź do cytatu

Gary Illyes, Google

• “If your server is struggling to serve bytes, our crawlers will automatically back off to avoid overloading your infrastructure, which will drop your crawl frequency.” (tłumaczenie) „Jeśli serwer ma trudności z dostarczaniem bajtów, nasze crawlery automatycznie się wycofają, aby nie przeciążać infrastruktury, co obniży częstotliwość crawlowania.” Przejdź do cytatu

John Mueller, Google (Reddit, relacja Search Engine Journal, sierpień 2025 r.)

• “I’d only expect the crawl rate to react that quickly if they were returning 429 / 500 / 503 / timeouts.” (tłumaczenie) „Tak szybkiej reakcji tempa crawlowania oczekiwałbym tylko wtedy, gdy serwer zwracałby błędy serwera lub przekroczenia czasu.” Przejdź do cytatu Search Engine Journal przytacza odpowiedź Muellera z Reddita i jej kontekst.

Lista kontrolna czasu odpowiedzi serwera / TTFB

Celem jest utrzymanie odpowiedzi na tyle szybkich, aby 504 nigdy się nie uruchomił — i wychwycenie dryfu, zanim do tego dojdzie. Pracuj od góry do dołu:

• Ustalono bazowe TTFB przez curl -w "%{time_starttransfer}" (albo monitoring syntetyczny) i zapisano, jak wygląda „norma” dla każdego szablonu.
• TTFB jest monitorowane stale, nie tylko po incydencie — alarm reaguje na dryf w górę, a nie wyłącznie na twarde awarie.
• Wykonano test obciążenia przy realistycznej (i szczytowej) równoległości — 504 zwykle zależy od obciążenia, więc spokojne okno go nie ujawni.
• Zprofilowano najwolniejszą pracę upstreamu — niezindeksowane zapytania do bazy, zapytania N+1 i blokujące wywołania zewnętrznych API są typowymi winowajcami.
• Agresywnie użyto cache — stron, obiektów i krawędzi CDN-u — aby większość żądań nie trafiała na wolną ścieżkę.
• Sprawdzono spójność limitów czasu między warstwami (CDN, load balancer, proxy_read_timeout / fastcgi_read_timeout Nginxa, aplikacja), aby jedna warstwa nie rezygnowała wcześniej niż inna.
• Potwierdzono autoskalowanie / zapas pojemności na skoki ruchu i crawlowania.
• Przejrzano Statystyki crawlowania GSC pod kątem skoków timeoutów i 5XX oraz rosnącego średniego czasu odpowiedzi.
• Sprawdzono logi serwera i proxy, aby ustalić, która warstwa przekracza czas i na czym.
• Zweryfikowano, że monitoring dostępności obejmuje szczytowe obciążenie, a nie tylko pingi poza godzinami.
• Przy planowanej niedostępności używany jest 503 + Retry-After, zamiast pozwalać stronom zwracać 504.

Mity i błędy dotyczące 504, których należy unikać

Najczęstsze pułapki — kilka z nich to szeroko powtarzane mity, które warto sprostować:

• „504 to kara Google”. Nie. To problem dostępności/crawlowania, a nie działanie algorytmu. Google nie ocenia treści — nie może pobrać strony. Utrata rankingu jest pośrednim skutkiem niedostępności, a nie karą.
• „Każdy 504 natychmiast usunie stronę z indeksu”. Nie. Krótkie, sporadyczne 504 są ponawiane i tolerowane. Ryzyko dotyczy utrzymujących się, częstych 504 przez dłuższy okres.
• „504 i 503 są zasadniczo tym samym — używaj ich wymiennie”. Nie. 503 może być celowym, kontrolowanym sygnałem (Google wyraźnie go wspiera przy planowanej niedostępności); 504 jest timeoutem, prawie zawsze nieplanowanym objawem wolnego upstreamu. Przy planowanej niedostępności zwróć 503 z Retry-After — nie pozwalaj stronom zwracać 504.
• „To Googlebot jest zbyt agresywny”. Zwykle jest odwrotnie. Serwer, który niezawodnie zwraca Googlebotowi 504 przy jego szybkości crawlowania, będzie też degradował obsługę prawdziwych użytkowników przy podobnym obciążeniu. Timeout ujawnia rzeczywisty problem pojemności/wydajności („Hostload exceeded” się zdarza, ale jest wyjątkiem, nie regułą).
• „Naprawa polega tylko na zwiększeniu limitu czasu”. Zwiększenie proxy_read_timeout maskuje wolny upstream zamiast go naprawiać, a dłuższy limit przy obciążeniu zajmuje procesy robocze dłużej i może pogorszyć przeciążenie. Napraw wolną odpowiedź, nie wydłużaj cierpliwości.
• „Monitoring jest zielony, więc nie mamy problemu 504”. 504 często zależy od obciążenia. Monitor w spokojnym oknie może przegapić timeouty zbierane przez Googlebota przy większych falach crawlowania. Ufaj Statystykom crawlowania i logom, nie pingom poza godzinami.

Która warstwa przekracza limit czasu?

Prompt: sklasyfikuj partię incydentów 504

Wklej oczyszczone wiersze z adresem URL, znacznikiem czasu, nagłówkami odpowiedzi, TTFB lub czasem całkowitym, wynikiem z publicznej krawędzi, wynikiem bezpośrednio ze źródła, śladem aplikacji, czasem bazy i sygnałami zasobów. Nie wklejaj danych uwierzytelniających, ciasteczek, prywatnych adresów ani danych użytkowników.

You are triaging HTTP 504 Gateway Timeout incidents. Classify each row into one of:
slow application or query, upstream dependency timeout, resource exhaustion,
gateway/origin timeout mismatch, CDN or network path, intermittent with insufficient
evidence, or not actually a 504.

For each row:
- quote the supplied evidence behind the classification;
- identify the missing observation that would most change the conclusion;
- separate response latency from the gateway's configured timeout;
- do not recommend increasing a timeout unless the evidence shows healthy work that
  legitimately needs longer;
- group rows sharing timestamps, routes, upstreams, or resource spikes.

Return a table with URL, likely cause, confidence, evidence, next diagnostic, and
incident group. Then list the first three engineering checks for the highest-impact
group. Do not invent thresholds or monitoring data.

DATA:
[PASTE SANITIZED INCIDENT DATA HERE]

Traktuj wynik jako kolejkę hipotez. Potwierdź go w telemetrii bramy, aplikacji, bazy danych i infrastruktury.

Zmierz status i czas do pierwszego bajtu

Uruchom to w powłoce macOS/Linux. Zwraca końcowy kod odpowiedzi i TTFB dla pojedynczego żądania bez drukowania ciała.

curl -sS -o /dev/null \
  -w 'status=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
  https://www.example.com/slow-path

Powtórz kilka razy, aby zobaczyć, czy timeout jest stały, czy zależy od obciążenia:

for i in {1..5}; do
  curl -sS -o /dev/null \
    -w 'status=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
    https://www.example.com/slow-path
done

Odpowiednik w PowerShell:

1..5 | ForEach-Object {
  $watch = [System.Diagnostics.Stopwatch]::StartNew()
  try {
    $response = Invoke-WebRequest -Uri 'https://www.example.com/slow-path' -SkipHttpErrorCheck
    $watch.Stop()
    [pscustomobject]@{ Attempt = $_; Status = $response.StatusCode; TotalMs = $watch.ElapsedMilliseconds }
  } catch {
    $watch.Stop()
    [pscustomobject]@{ Attempt = $_; Status = 'request-failed'; TotalMs = $watch.ElapsedMilliseconds }
  }
}

Wersja PowerShell mierzy całkowity czas żądania, a nie TTFB. Gdy potrzebujesz rozbicia do pierwszego bajtu, użyj polecenia powłoki albo telemetrii aplikacji.

Narzędzia do odtwarzania i określania zakresu 504s

• Website Down Checker — przetestuj dostępność z zewnętrznego punktu obserwacji i zbierz czas odpowiedzi, przekierowanie oraz ograniczone dowody DNS. Ustal, czy incydent można odtworzyć publicznie.
• Masowy checker kodów stanu HTTP — sprawdź reprezentatywny zestaw tras, porównaj opóźnienie i wyeksportuj zawodną podgrupę. Pomaga oddzielić jeden wolny punkt końcowy od problemu upstreamu w całej witrynie.
• Logi CDN-u/load balancera — znajdź bramę, która wystawiła 504, i skoreluj jej identyfikator żądania oraz timeout z próbą upstreamu.
• Śledzenie aplikacji i logi wolnych zapytań bazy — pokazują, gdzie żądanie spędziło czas po dotarciu do źródła.
• Monitoring infrastruktury — porównaj okno incydentu z nasyceniem CPU, pamięci, puli procesów, połączeń i zależności, zamiast zgadywać na podstawie kodu stanu.

TTFB według trasy i percentyla

Metryka: czas do pierwszego bajtu dla reprezentatywnych tras, podzielony według użytecznych percentyli, a nie tylko średniej.

Co mówi: rosnące opóźnienie ogona jest wczesnym ostrzeżeniem, że żądania zbliżają się do limitu bramy, zanim zaczną zwracać 504.

Jak pobrać: użyj monitoringu rzeczywistych użytkowników/serwera albo logów bramy; do punktowych kontroli użyj skryptu curl z karty Scripts, a nie zamiast telemetrii produkcyjnej.

Zakres bazowy/realistyczny: ustal bazę dla każdej trasy i ścieżki infrastruktury. Znaczącym alarmem jest trwała zmiana względem bazy albo przesunięcie w stronę rzeczywiście skonfigurowanego limitu bramy, a nie uniwersalna liczba SEO.

Częstotliwość: monitoruj stale; przeglądaj trendy na poziomie tras co tydzień i podczas każdego incydentu 504.

Odsetek odpowiedzi 504

Metryka: żądania zwracające 504 podzielone przez wszystkie żądania, z podziałem — jeśli dane są dostępne — na trasę, bramę, źródło i klasę crawler/user-agent.

Co mówi: czy timeouty są odosobnione, skupione w jednej ścieżce, czy na tyle szerokie, że wpływają na crawlowanie i użytkowników.

Jak pobrać: agreguj logi CDN-u, load balancera lub dostępu serwera według kodu stanu i wymiarów żądania.

Zakres bazowy/realistyczny: zdrowym celem jest brak niewyjaśnionych 504. Dla czułości alarmów użyj własnej normalnej bazy bez incydentów, ponieważ mieszanka ruchu i zachowanie ponowień różnią się między stosami.

Częstotliwość: alarmuj stale; w czasie odzyskiwania przeglądaj codziennie oraz w regularnym tygodniowym raporcie niezawodności.

Ukończenie upstreamu a timeout bramy

Metryka: rozkład czasów ukończenia upstreamu w porównaniu ze skonfigurowanym limitem każdej warstwy.

Co mówi: czy wolna praca rzeczywiście zbliża się do limitu, czy krótszy limit bramy odcina zdrowe odpowiedzi upstreamu.

Jak pobrać: połącz pola czasowe bramy ze śladami aplikacji przez identyfikator żądania lub śladu.

Zakres bazowy/realistyczny: utrzymuj normalne ukończenie bezpiecznie wewnątrz skonfigurowanego limitu, z miejscem na oczekiwaną zmienność. Określ to miejsce na podstawie produkcyjnych rozkładów; nie wymyślaj ogólnego procentu.

Częstotliwość: przejrzyj po zmianach konfiguracji lub zależności oraz zawsze, gdy rośnie opóźnienie ogona albo odsetek 504.

Sprawdź się: 504 Gateway Timeout

Pięć krótkich pytań o znaczenie 504 i wpływ na crawlowanie. Wybierz odpowiedź na każde, a następnie sprawdź wynik.

Zasoby warte Twojego czasu

Moje powiązane teksty

• Poradnik technicznego SEO dla początkujących — miejsce kondycji serwera i crawlowania w szerszym obrazie.
• Nowe crawlery internetowe: boty AI zbliżają się do botów wyszukiwarek — kto naprawdę odwiedza Twój serwer i dlaczego obciążenie ma znaczenie.

Moje wystąpienia

• Jak działa wyszukiwarka (SlideShare) — omówienie crawlowania, renderowania, indeksowania i rankingu, w tym wpływu odpowiedzi serwera na szybkość crawlowania. (Obowiązuje moje stałe zastrzeżenie: “This is my understanding of systems… not going to be 100% complete or accurate.” (tłumaczenie) „To moje rozumienie systemów… nie będzie w 100% kompletne ani dokładne.”)

Z branży

• MDN — 504 Gateway Timeout — kanoniczna definicja i różnica względem 502.
• Google — diagnozowanie błędów crawlowania — sposób wycofywania się Googlebota przy problemach serwera.
• Google — zarządzanie budżetem crawlowania dużych witryn — sposób, w jaki wolne odpowiedzi obniżają limit crawlowania.
• Google wyjaśnia, jak działa crawlowanie w 2026 r. (Search Engine Land) — cytat Illyesa łączący problemy serwera ze zmniejszeniem częstotliwości crawlowania.
• Spadek crawlowania Googlebota? Mueller wskazuje błędy serwera (Search Engine Journal) — Mueller grupuje timeouty z 429/500/503 jako błędy szybko obniżające szybkość crawlowania.
• Jak naprawić błąd 504 Gateway Timeout (Kinsta) — solidne techniczne omówienie łańcucha żądania i diagnozy z logów po stronie hosta.

Filmy

• Google Search Central (YouTube) — seria How Google Search Works i wyjaśnienia Martina Splitta dotyczące crawlowania, przydatne do zrozumienia interakcji odpowiedzi serwera z szybkością crawlowania. Kanał

Dziennik zmian