304 Nie zmodyfikowano

TL;DR — Odpowiedź 304 Not Modified to sposób serwera na powiedzenie: „już to masz — Twoja kopia jest nadal aktualna, nie pobieraj jej ponownie”. To nie jest błąd i mimo przynależności do rodziny kodów 3xx „przekierowań” nie wysyła nikogo pod nowy adres URL. Występuje dopiero, gdy klient (przeglądarka lub crawler) najpierw wysyła żądanie warunkowe z pytaniem „czy od ostatniego razu coś się zmieniło?”. Dla SEO nie zmienia rankingów, ale na dużych witrynach może pomóc wyszukiwarkom efektywniej wykorzystywać zasoby.

Czym naprawdę jest 304

Każda odpowiedź serwera zaczyna się od trzycyfrowego kodu stanu. 200 OK oznacza „oto strona, wraz z całą treścią”. 304 Not Modified oznacza coś bardziej konkretnego: klient wysłał warunkowe żądanie — takie, które mówi „daj mi tę stronę, ale tylko jeśli się zmieniła” — a serwer ustalił, że się nie zmieniła, więc zamiast 200, który w innym razie by wysłał, odpowiada 304 bez żadnego ciała. Właściwa reguła brzmi: 304 jest wyłącznie odpowiedzią na warunkowe GET/HEAD, którego warunek okazał się fałszywy.

Druga wizyta jest typowym sposobem, w jaki do tego dochodzi, i pomaga to sobie wyobrazić: przy pierwszym pobraniu strony przeglądarka lub crawler otrzymuje zwykłe 200 z pełną treścią oraz kilkoma małymi nagłówkami „odcisku palca”. Przy następnej wizycie klient pokazuje serwerowi ten odcisk i pyta: „nadal jest tak samo?”. Jeśli nic się nie zmieniło, serwer odpowiada 304 i nie wysyła żadnego ciała strony, a klient po prostu używa kopii, którą już ma. „Druga wizyta” jest jednak przykładem, a nie regułą protokołu — 304 wyzwala samo żądanie warunkowe, niezależnie od tego, jak dotarło.

Dlaczego należy do rodziny „przekierowań”, ale nie jest przekierowaniem

304 zaczyna się od 3, czyli cyfry klasy używanej przez HTTP dla przekierowań. To nieustannie wprowadza ludzi w błąd. 304 nie ma jednak nagłówka Location i nie wysyła nikogo pod inny adres — nikt nigdzie nie przechodzi. Wskazuje klientowi jedynie jego własną zapisaną kopię. „Rodzina przekierowań” to więc ciekawostka numeracji, a nie opis działania.

Czy 304 jest problemem?

Nie. Widoczne w karcie sieciowej przeglądarki albo w raporcie crawlowania odpowiedzi 304 oznaczają, że cache działa — dokładnie tego chcesz. Wiele krążących porad „błąd 304, jak go naprawić” traktuje to jak awarię po Twojej stronie. Tak nie jest. To prawidłowy, zamierzony wynik poprawnie działającego cache.

Czy pomaga w SEO?

Nie bezpośrednio w rankingach. Google ma już treść z poprzedniego crawlowania strony — 304 tylko potwierdza, że nic się nie zmieniło, więc Google nadal używa tego, co zapisało (Search może wciąż przeliczać sygnały adresu URL, ale sam 304 nie jest premią rankingową ani indeksacyjną). Pomaga natomiast w wydajności zasobów: jeśli wyszukiwarka nie musi ponownie pobierać niezmienionych stron, oszczędza przepustowość i obliczenia po obu stronach; Google mówi, że może to pośrednio poprawiać efektywność crawlowania — nie gwarantuje jednak, że zaoszczędzony wysiłek zostanie automatycznie skierowany na nowe lub zaktualizowane strony. Najbardziej liczy się to na dużych witrynach z wieloma rzadko zmienianymi stronami.

Chcesz poznać prawdziwe mechanizmy — ETagi, If-None-Match, silne i słabe walidatory, implementację oraz to, co faktycznie powiedziało Google? Przejdź do karty Advanced.

TL;DR — 304 jest odpowiedzią na warunkowe GET/HEAD, którego warunek ocenia się jako fałszywy i które w przeciwnym razie otrzymałoby 200 (RFC 9110 §15.4.5). Należy do klasy 3xx, ale nie jest przekierowaniem: nie ma Location, nowego adresu URL ani — normatywnie — ciała („it cannot contain content or trailers” (tłumaczenie) „nie może zawierać treści ani trailerów”). Warunek przenosi If-None-Match (względem ETag) i/lub If-Modified-Since (względem Last-Modified); jeśli walidator nadal pasuje, serwer zwraca 304, a klient używa cache. Wpływ na SEO: brak bezpośredniego efektu rankingowego — Google ma już treść, choć Search może nadal przeliczyć sygnały adresu URL — oraz oszczędność zasobów na dużych witrynach (Google mówi, że może to pośrednio poprawiać efektywność crawlowania; nie obiecuje automatycznego przekazania budżetu crawlowania innym adresom URL). Infrastruktura crawlowania Google obsługuje oba walidatory i zaleca ETag jako podstawowy, bo nie niesie problemów z formatowaniem daty. Odróżnij go od 301/302/307/308 (które przenoszą adres URL) i od 204 (również bez ciała, ale dlatego, że rzeczywiście nie ma nic do wysłania).

Co 304 oznacza w specyfikacji

RFC 9110 (HTTP Semantics) §15.4.5 definiuje go precyzyjnie: “The 304 (Not Modified) status code indicates that a conditional GET or HEAD request has been received and would have resulted in a 200 (OK) response if it were not for the fact that the condition evaluated to false.” (tłumaczenie) „kod stanu 304 (Not Modified) oznacza, że otrzymano warunkowe żądanie GET lub HEAD, które dałoby odpowiedź 200 (OK), gdyby warunek nie został oceniony jako fałszywy.” To rzeczywisty, normatywny wyzwalacz — warunkowe GET/HEAD, którego warunek okazał się fałszywy i które w innym razie otrzymałoby 200. Mówiąc prosto: klient poprosił „daj mi tę stronę, ale tylko jeśli się zmieniła”, serwer ustalił, że się nie zmieniła, więc pomija ciało. „Druga wizyta” to codzienny przykład tego, jak żądanie staje się warunkowe (klient dołącza walidator zapisany z wcześniejszej odpowiedzi), ale nie jest regułą — specyfikacja nie wymaga wcześniejszej wizyty, tylko żądania warunkowego.

Specyfikacja używa w tej sekcji nawet słowa „redirecting”: “the server is therefore redirecting the client to make use of that stored representation as if it were the content of a 200 (OK) response” (tłumaczenie) „serwer przekierowuje więc klienta, aby użył zapisanej reprezentacji tak, jakby była treścią odpowiedzi 200 (OK)” — ale czytaj uważnie: klient wraca do własnego cache, a nie pod inny adres URL. Nie ma nagłówka Location ani nowego adresu. To jedno zdanie odpowiada za większość zamieszania wokół pytania, czy 304 „jest przekierowaniem”. W sensie HTTP nie jest.

Liczą się jeszcze dwa punkty normatywne:

• Nigdy żadnego ciała. RFC 9110: “A 304 response is terminated by the end of the header section; it cannot contain content or trailers.” (tłumaczenie) „odpowiedź 304 kończy się na końcu sekcji nagłówków; nie może zawierać treści ani trailerów.” 304 z ciałem narusza specyfikację, a część klientów może obsłużyć go nieprawidłowo. To twarda reguła, a nie kwestia stylu.
• Niesie te same metadane, co 200. Serwer “MUST generate any of the following header fields that would have been sent in a 200 (OK) response to the same request: Content-Location, Date, ETag, and Vary” (tłumaczenie) „MUSI wygenerować wszystkie z tych pól nagłówka, które zostałyby wysłane w odpowiedzi 200 na to samo żądanie: Content-Location, Date, ETag i Vary”, a także Cache-Control i Expires, gdy mają zastosowanie. 304 to więc nagłówki odpowiedzi 200 bez ładunku.

Jak 304 naprawdę działa: żądania warunkowe

Serwer nigdy nie wysyła 304 bez powodu. To zawsze odpowiedź na żądanie warunkowe — takie, które klient uczynił warunkowym, dołączając walidator zapisany z poprzedniej odpowiedzi. Istnieją dwa walidatory.

ETag i If-None-Match

ETag (znacznik encji) to nieprzezroczysty token, który serwer dołącza do odpowiedzi 200 — pomyśl o nim jak o odcisku wersji dokładnej reprezentacji adresu URL. Przy następnym żądaniu tego adresu URL klient odsyła zapisaną wartość w nagłówku If-None-Match. Serwer porównuje wartości: jeśli bieżący ETag nadal pasuje, nic się nie zmieniło, więc zwraca 304; jeśli jest inny, zwraca świeże 200 z nową treścią i nowym ETag.

Last-Modified i If-Modified-Since

Alternatywa oparta na dacie: serwer wysyła znacznik czasu Last-Modified w odpowiedzi 200. Następnym razem klient odsyła go w nagłówku If-Modified-Since, a serwer porównuje daty — jeśli zasób nie zmienił się od tego czasu, zwraca 304. To prostsze, ale mniej precyzyjne (dokładność ogranicza się do znacznika czasu) i wrażliwe na dokładne formatowanie daty HTTP, co często powoduje błędy. Gdy obecne są oba walidatory, If-None-Match (ETag) ma pierwszeństwo przed If-Modified-Since.

Silne i słabe ETagi

ETag może być silny lub słaby, a różnica ma znaczenie. Zgodnie z wytycznymi MDN dotyczącymi żądań warunkowych: “strong validation consists of guaranteeing that the resource is, byte to byte, identical to the one it is compared to.” (tłumaczenie) „silna walidacja polega na zagwarantowaniu, że zasób jest bajt po bajcie identyczny z porównywanym.” Słaby ETag ma prefiks W/ (np. ETag: W/"abc123") i zapewnia tylko równoważność semantyczną — przykład MDN mówi, że strona różniąca się od innej wyłącznie datą w stopce albo inną reklamą może być uznana za identyczną przy słabej walidacji. Silne ETagi (bez prefiksu) są wymagane między innymi przy żądaniach zakresowych potrzebujących dopasowania bajtowego; słabe są użyteczne, gdy kompresja, białe znaki lub błahe różnice bez znaczenia merytorycznego nie powinny wymuszać pełnego pobrania. Pułapka praktyczna: jeśli ETag zmienia się przy każdym ponownym kompresowaniu gzip/Brotli albo różni się między serwerami za load balancerem, wywołasz niepotrzebne ponowne crawlowania — wybierz silny lub słaby wariant świadomie i utrzymuj wartość stabilną dla rzeczywiście niezmienionej treści.

Pełne uzgadnianie krok po kroku

1. Pierwsze żądanie → serwer zwraca 200 OK z treścią oraz ETag i/lub Last-Modified.
2. Klient zapisuje treść i te walidatory.
3. Następne żądanie → klient wysyła If-None-Match i/lub If-Modified-Since z zapisanymi wartościami.
4. Serwer decyduje: brak zmiany → 304 Not Modified, bez ciała, klient używa cache; zmiana → 200 OK z nowym ciałem i świeżymi walidatorami. Evidence for this claim RFC 9111 defines validation as checking whether a stored response remains current, typically with a conditional request that can receive 304 Not Modified. Scope: HTTP cache validation; it does not create a Search ranking benefit. Confidence: high · Verified: 2026-07-14 IETF: RFC 9111 §4.3 — Validation

Jeśli chcesz głębiej potraktować cache i walidatory jako dźwignię efektywności crawlowania — całą historię żądań warunkowych i ich związek z budżetem crawlowania — to temat towarzyszący; ten artykuł skupia się na kodzie stanu.

304 i SEO: brak wpływu na ranking, rzeczywisty wpływ na efektywność crawlowania

To cała historia SEO, węższa niż sugeruje wiele blogowych ogólników. 304 nie ma bezpośredniego wpływu na ranking, a własne wytyczne Google dotyczące wpływu kodów stanu na crawlowanie i indeksowanie ograniczają również wpływ na indeksowanie: Search może nadal przeliczać sygnały adresu URL, ale poza tym 304 nie zmienia sposobu indeksowania strony. Google ma treść z poprzedniego crawlowania; 304 tylko potwierdza, że nic się nie zmieniło, więc nadal jej używa. Zwracanie 304 nie daje premii rankingowej.

To, co 304 rzeczywiście daje, to oszczędność zasobów, która może pośrednio poprawić efektywność crawlowania. W grudniowym wpisie Search Central Google z 2024 roku o cache HTTP Gary Illyes ujął to jasno: “Especially if you have a large site with rarely-changing content under individual URLs, allowing caching locally may help your site be crawled more efficiently. Google’s crawling infrastructure supports heuristic HTTP caching as defined by the HTTP caching standard, specifically through the ETag response- and If-None-Match request header, and the Last-Modified response- and If-Modified-Since request header.” (tłumaczenie) „Szczególnie gdy masz dużą witrynę z rzadko zmieniającą się treścią pod poszczególnymi adresami URL, lokalne cache może pomóc w efektywniejszym crawlowaniu witryny. Infrastruktura crawlowania Google obsługuje heurystyczne cache HTTP zgodnie ze standardem cache HTTP, konkretnie przez nagłówek odpowiedzi ETag i nagłówek żądania If-None-Match oraz nagłówek odpowiedzi Last-Modified i nagłówek żądania If-Modified-Since.”

Ten sam wpis precyzyjnie wyjaśnia mechanizm 304 i to, dlaczego puste ciało jest sednem: jeśli ETag wysłany przez crawler “matches the current value the server generated, your server should return an HTTP 304 (Not modified) status code with no HTTP body” (tłumaczenie) „pasuje do bieżącej wartości wygenerowanej przez serwer, serwer powinien zwrócić kod 304 bez ciała HTTP”, a część „no HTTP body” ma znaczenie, ponieważ “your server doesn’t have to spend compute resources on actually generating content” i “doesn’t have to transfer the HTTP body” (tłumaczenie) „serwer nie musi zużywać zasobów obliczeniowych na faktyczne generowanie treści ani przesyłać ciała HTTP” — oszczędzasz obliczenia i przepustowość po obu stronach. Własne sformułowanie Google dotyczące korzyści jest warunkowe: te oszczędności zasobów mogą pośrednio poprawić efektywność crawlowania. To nie obietnica automatycznego przekazania zaoszczędzonego wysiłku na nowe lub zaktualizowane adresy URL — traktuj to jako mechanizm oszczędzania zasobów z prawdopodobnym, ale niegwarantowanym efektem ubocznym.

Dlaczego ma to większe znaczenie na dużych witrynach

Jeśli masz kilkaset stron, jest to w dużej mierze teoria — Google wygodnie przeczłapie całą witrynę niezależnie od tego. Korzyść rośnie wraz z rozmiarem: witryna z setkami tysięcy lub milionami adresów URL, z których wiele rzadko się zmienia, zyskuje materialnie, gdy crawlery mogą pominąć ponowne pobieranie wszystkich niezmienionych stron. Do takich odbiorców kierowany jest wpis Google i tak należy go uczciwie przedstawiać — nie sprzedawaj 304 jako taktyki dla małej witryny.

ETag czy Last-Modified i co liczy się jako „zmiana”

Google zaleca ETag jako podstawowy walidator: “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value).” (tłumaczenie) „Zdecydowanie zalecamy ETag, ponieważ jest mniej podatny na błędy i pomyłki — w przeciwieństwie do Last-Modified jego wartość nie ma struktury.” Ustawienie obu jest poprawne i zalecane. Jeśli używasz Last-Modified, data “must be formatted according to the HTTP standard” (tłumaczenie) „musi być sformatowana zgodnie ze standardem HTTP” — Google zaleca format “Weekday, DD Mon YYYY HH:MM:SS Timezone,” np. “Fri, 4 Sep 1998 19:15:56 GMT” — w przeciwnym razie może zostać po cichu zignorowana. Google sugeruje też ustawienie pola max-age w Cache-Control, aby pomóc crawlerom zdecydować, kiedy wykonać ponowne crawlowanie.

To Ty decydujesz, co jest zmianą wartą unieważnienia cache, a rada Google brzmi, aby rezerwować to dla zmian merytorycznych: “Our recommendation is that you require a cache refresh on significant changes to your content; if you only updated the copyright date at the bottom of your page, that’s probably not significant.” (tłumaczenie) „Zalecamy wymagać odświeżenia cache przy istotnych zmianach treści; jeśli zaktualizowano tylko datę praw autorskich na dole strony, prawdopodobnie nie jest to istotne.”

Co Googlebot i Bingbot naprawdę robią z tym kodem

Nie każde żądanie crawlera jest warunkowe. Dokumentacja crawlowania Google zaznacza, że obsługa cache przez poszczególne crawlery i fetchery Google zależy od produktu, któremu służą — Googlebot obsługuje cache podczas ponownego crawlowania adresów URL dla Search, a niektóre inne fetchery Google obsługują je tylko w określonych warunkach — dlatego nawet przy poprawnie skonfigurowanych nagłówkach nie oczekuj, że 100% żądań będzie zawierać If-None-Match/If-Modified-Since. Bing również obsługuje żądania warunkowe. Jego crawler wspierał warunkowe GET (wysyłanie If-Modified-Since i, gdy dostępne, If-None-Match oraz akceptowanie 304 przy niezmienionej treści) co najmniej od wpisu Live Search z 2008 roku — choć Bing nie opublikował współczesnego odpowiednika wpisu Google z 2024 roku. Traktuj mechanizm jako ogólne zachowanie HTTP dotyczące obu wyszukiwarek.

Jak wdrożyć obsługę 304

1. Wysyłaj walidatory przy 200. Skonfiguruj serwer, CDN lub aplikację tak, aby do zwykłych odpowiedzi 200 dołączała nagłówek ETag (zalecany) i/lub poprawnie sformatowany Last-Modified. Wiele serwerów i frameworków robi ETagi automatycznie dla plików statycznych; odpowiedzi dynamiczne zwykle wymagają jawnego włączenia.
2. Obsługuj nagłówki warunkowe przy kolejnym żądaniu. Gdy żądanie przychodzi z If-None-Match/If-Modified-Since, porównaj je z bieżącym walidatorem i zwróć 304 (bez ciała), gdy nadal pasuje, albo świeże 200, gdy nie pasuje. Serwery plików statycznych często robią to za Ciebie; trasy aplikacji i workery brzegowe często nie, dopóki ich nie skonfigurujesz.
3. Zdecyduj, co oznacza „zmiana” i utrzymuj ETag stabilny dla rzeczywiście niezmienionej treści — nie pozwalaj, aby ponowna kompresja lub różnice między serwerami zmieniały go bez potrzeby.
4. Uważaj na klasyczne błędne konfiguracje:
   • Zawsze 200 — brak walidatorów, więc żadne żądanie nie jest warunkowe i nie ma oszczędności.
   • Niestabilne ETagi — wartość zmienia się, choć treść nie, na przykład przez load balancery lub ponowną kompresję, co wymusza ciągłe pobrania.
   • Nieaktualne 304 — najgroźniejszy przypadek: serwer nadal zwraca 304 (albo niezmieniony ETag) po rzeczywistej zmianie treści, przez co crawlery i cache nigdy nie pobierają aktualizacji. To błąd do wykrycia w analizie logów, a nie wrodzona wada 304.

304 a inne kody stanu

304 a 301 / 302 / 307 / 308

To są prawdziwe przekierowania. 301/308 (stałe) albo 302/307 (tymczasowe) niosą nagłówek Location i przenoszą klienta pod inny adres URL — a 301/308 przekazują również sygnał kanonizacji. 304 nie ma Location, nikogo nie przenosi i nie przekazuje sygnału rankingowego. Ta sama rodzina 3xx według numeru, zupełnie inna funkcja. Szczegóły poszczególnych kodów przekierowań znajdują się w osobnych artykułach (zobacz artykuł o przekierowaniu 301 i podcentrum przekierowań).

304 a 204 No Content

Oba są pozbawione ciała, ale z całkiem innych powodów. 204 No Content to sukces 2xx z celowo pustym ciałem, bo serwer ma rzeczywiście nic do wysłania — na przykład po udanym API DELETE/PUT albo w beaconie analitycznym. 304 również nie wysyła ciała, ale nie dlatego, że nic nie ma do wysłania; chodzi o to, że “you already have it and it’s still valid.” (tłumaczenie) „już to masz i nadal jest aktualne.” Nie mieszaj ich: 204 pod adresem URL strony może zostać potraktowany jak soft 404, bo nie ma indeksowalnej treści, podczas gdy 304 potwierdza ważność treści, którą Google już posiada. Artykuł o 204 No Content omawia ten kod w całości.

Typowe mity o 304

1. “304 is a redirect.” (tłumaczenie) „304 jest przekierowaniem”. Brak nagłówka Location, nikt nigdzie nie przechodzi. Klient używa własnej kopii z cache. “redirecting the client to make use of that stored representation” (tłumaczenie) „przekierowanie klienta, aby użył zapisanej reprezentacji” z RFC 9110 oznacza wskazanie cache, a nie innego adresu URL.
2. “304 is an error I need to fix.” (tłumaczenie) „304 to błąd do naprawienia”. To prawidłowy, zamierzony wynik działającej konfiguracji żądań warunkowych. 304 w crawlu lub DevTools oznacza, że cache działa — to jedno z najczęstszych nieporozumień w SERP-ach.
3. “304 helps rankings.” (tłumaczenie) „304 pomaga w rankingach”. Nie ma bezpośredniego wpływu na ranking, a Google ogranicza również wpływ na indeksowanie — Search może przeliczyć sygnały adresu URL, ale poza tym 304 nie zmienia indeksowania. Korzyść to oszczędność zasobów, która według Google może pośrednio poprawiać efektywność crawlowania na bardzo dużych witrynach, ale nie jest sygnałem rankingowym ani gwarancją przekazania oszczędności na inne adresy URL.
4. “If my server returns 304, Google will use stale content forever.” (tłumaczenie) „Jeśli serwer zwraca 304, Google będzie wiecznie używać starej treści”. 304 działa tylko, dopóki walidator pasuje. Gdy treść rzeczywiście się zmieni, poprawnie wdrożony serwer zwróci świeże 200 z nowymi walidatorami. Prawdziwym ryzykiem jest błędnie skonfigurowany serwer, który po zmianie treści nadal zwraca 304 — to błąd, a nie cecha 304. Evidence for this claim RFC 9111 defines validation as checking whether a stored response remains current, typically with a conditional request that can receive 304 Not Modified. Scope: HTTP cache validation; it does not create a Search ranking benefit. Confidence: high · Verified: 2026-07-14 IETF: RFC 9111 §4.3 — Validation
5. “ETag and Last-Modified are interchangeable.” (tłumaczenie) „ETag i Last-Modified są wymienne”. Oba są walidatorami, ale Last-Modified zależy od formatu daty i ma dokładność znacznika czasu, podczas gdy ETag jest nieprzezroczysty i precyzyjny (choć przy nieostrożnej implementacji może różnić się między serwerami lub po ponownej kompresji). Google zaleca ETag jako podstawowy, a najlepiej ustawić oba.

Najczęstsze pytania

Czy HTTP 304 jest błędem? Nie — to sygnał sukcesu oznaczający, że cache działa. Kopia klienta nadal jest aktualna.

Czy 304 Not Modified jest przekierowaniem? Nie. Należy do klasy 3xx z powodu numeracji, ale nie ma nagłówka Location i nie przenosi klienta pod nowy adres URL.

Czy 304 pomaga w SEO lub rankingach? Nie ma bezpośredniego wpływu na ranking ani wpływu na indeksowanie poza możliwością przeliczenia przez Google sygnałów adresu URL. Oszczędza przepustowość i obliczenia, pozwalając crawlerom pomijać niezmienione strony, co według Google może pośrednio poprawiać efektywność crawlowania na dużych witrynach.

Jaka jest różnica między ETag a Last-Modified? ETag to nieprzezroczysty odcisk wersji dopasowywany przez If-None-Match; Last-Modified to znacznik czasu dopasowywany przez If-Modified-Since. Google zaleca ETag jako mniej podatny na błędy.

Czym różni się słaby ETag od silnego? Silny ETag potwierdza treść identyczną bajt po bajcie; słaby ETag (z prefiksem W/) potwierdza równoważność semantyczną i toleruje błahe różnice, takie jak kompresja lub zmieniona data w stopce.

Dlaczego widzę 304 w logach lub raportach crawlowania? Ponieważ klienci wysyłają żądania warunkowe, a serwer poprawnie potwierdza, że treść się nie zmieniła. To oczekiwane i prawidłowe.

Jak sprawić, aby serwer poprawnie zwracał 304? Wysyłaj ETag/Last-Modified przy 200, a przy następnym żądaniu obsługuj If-None-Match/If-Modified-Since, zwracając 304 bez ciała, gdy walidator nadal pasuje.

Jaka jest różnica między 304 a 204? Oba są pozbawione ciała; 204 dlatego, że nie ma nic do wysłania, a 304 dlatego, że klient ma już nadal aktualną kopię.

Czy Googlebot wysyła nagłówki warunkowe przy każdym żądaniu? Nie — obsługa cache różni się między crawlerami, więc nie każde żądanie będzie warunkowe, nawet przy skonfigurowanych nagłówkach.

Czy odpowiedź 304 może mieć ciało? Nie. RFC 9110 mówi: “it cannot contain content or trailers.” (tłumaczenie) „nie może zawierać treści ani trailerów.” Odpowiedź 304 z ciałem narusza specyfikację.

Podsumowanie AI

Skrót wersji Advanced:

• 304 Not Modified jest odpowiedzią na warunkowe GET/HEAD, którego warunek ocenia się jako fałszywy i które w innym razie otrzymałoby 200 (RFC 9110 §15.4.5). Należy do klasy 3xx, ale NIE jest przekierowaniem: nie ma nagłówka Location, nowego adresu URL ani — normatywnie — ciała: “it cannot contain content or trailers.” (tłumaczenie) „nie może zawierać treści ani trailerów”. Druga wizyta to typowy przykład tego, jak żądanie staje się warunkowe, a nie reguła protokołu.
• To odpowiedź na żądanie warunkowe. GET/HEAD z If-None-Match (porównywanym z ETag) i/lub If-Modified-Since (porównywanym z Last-Modified). Jeśli walidator nadal pasuje, serwer zwraca 304, a klient używa kopii z cache.
• Słowo “redirecting” (tłumaczenie) „przekierowywanie” w specyfikacji jest metaforą — wskazuje klientowi jego własny cache, a nie inny adres URL. To zdanie powoduje większość zamieszania wokół pytania “is 304 a redirect” (tłumaczenie) „czy 304 jest przekierowaniem”.
• ETag a Last-Modified: ETag to nieprzezroczysty token wersji (dopasowywany przez If-None-Match); Last-Modified to data (dopasowywana przez If-Modified-Since, z wymaganym dokładnym formatem daty HTTP). Gdy obecne są oba, pierwszeństwo ma If-None-Match. Silny ETag = identyczność bajtowa; słaby ETag (prefiks W/) = równoważność semantyczna.
• Brak bezpośredniego wpływu na ranking ani wpływu na indeksowanie poza możliwością przeliczenia przez Google sygnałów adresu URL. Google ma już treść; 304 tylko potwierdza brak zmian. Jak ujął to Gary Illyes, cache “may help your site be crawled more efficiently” (tłumaczenie) „może pomóc efektywniej crawlować witrynę” — korzyść to oszczędność zasobów, która może pośrednio poprawiać efektywność crawlowania na dużych witrynach, a nie gwarantowane przekazanie budżetu crawlowania ani sygnał rankingowy.
• Google zaleca ETag jako podstawowy (“less prone to errors and mistakes” (tłumaczenie) „mniej podatny na błędy i pomyłki”); można ustawić oba. Last-Modified musi używać formatu “Weekday, DD Mon YYYY HH:MM:SS Timezone” (tłumaczenie) „Dzień tygodnia, DD Mon RRRR GG:MM:SS Strefa czasowa”; cache unieważniaj dopiero przy istotnych zmianach, nie przy dacie praw autorskich w stopce.
• Obsługa cache różni się między crawlerami — nie każde żądanie Googlebota jest warunkowe. Bing obsługuje warunkowe GET co najmniej od wpisu Live Search z 2008 roku; to ogólne zachowanie HTTP.
• Nie myl go z 301/302/307/308 (prawdziwymi przekierowaniami przenoszącymi adres URL) ani z 204 No Content (również bez ciała, ale dlatego, że rzeczywiście nie ma nic do wysłania).
• Prawdziwym ryzykiem nie jest sam 304, lecz błędnie skonfigurowany serwer zwracający 304 po faktycznej zmianie treści — wykryj to w analizie logów. Prawidłowy 304 może też wyglądać jak błąd w niektórych bibliotekach klienta lub warstwach cache platformy, choć nic rzeczywiście nie jest nie tak.

Oficjalna dokumentacja

Źródła pierwotne opisujące, czym jest 304 i jak wyszukiwarki go wykorzystują.

Specyfikacja HTTP i dokumentacja przeglądarek

• RFC 9110 §15.4.5 — 304 niezmodyfikowany — autorytatywna definicja: żądanie warunkowe, brak ciała i wymagane nagłówki.
• MDN — 304 niezmodyfikowany — przystępne wyjaśnienie, wyzwalacze If-None-Match/If-Modified-Since i lista nagłówków, które 304 musi przenosić.
• MDN — żądania warunkowe HTTP — wyjaśnienie silnej i słabej walidacji.
• MDN — ETag — nagłówek ETag, w tym składnia słaba (W/) i silna.

Google Search Central

• Crawling December: HTTP caching — wpis Gary’ego Illyesa z 9 grudnia 2024 r.: jak ETag/If-None-Match i Last-Modified/If-Modified-Since powodują 304 oraz dlaczego pomagają w efektywności crawlowania.
• Google Crawler (User Agent) Overview — które crawlery Google obsługują cache i rekomendacja ETag zamiast Last-Modified.
• Jak kody stanu HTTP wpływają na crawlery Google — bieżący wiersz Google o 304, w tym zastrzeżenie, że Search może przeliczać sygnały adresu URL, choć 304 poza tym nie wpływa na indeksowanie.
• Rozwiązywanie błędów crawlowania Google Search — źródło warunkowego sformułowania Google, że oszczędności zasobów z żądań warunkowych “may indirectly” (tłumaczenie) „mogą pośrednio” poprawiać efektywność crawlowania oraz że Google nie wysyła nagłówków warunkowych przy każdej próbie crawlowania.

Bing

• Ogłoszenie ulepszeń crawlera Live Search — dawny wpis Bing/Live Search potwierdzający obsługę warunkowego GET (If-Modified-Since/If-None-Match → 304) od 2008 roku.

Cytaty ze źródła

Wypowiedzi zapisane wprost. Każdy link jest głębokim odnośnikiem prowadzącym do cytowanego fragmentu strony, w którym źródło uzasadnia dane stwierdzenie.

Specyfikacja HTTP

• “The 304 (Not Modified) status code indicates that a conditional GET or HEAD request has been received and would have resulted in a 200 (OK) response if it were not for the fact that the condition evaluated to false.” (tłumaczenie) „Kod stanu 304 (Not Modified) oznacza, że otrzymano warunkowe żądanie GET lub HEAD, które dałoby odpowiedź 200 (OK), gdyby warunek nie został oceniony jako fałszywy.” — RFC 9110, HTTP Semantics, §15.4.5. Przeczytaj sekcję
• “A 304 response is terminated by the end of the header section; it cannot contain content or trailers.” (tłumaczenie) „Odpowiedź 304 kończy się na końcu sekcji nagłówków; nie może zawierać treści ani trailerów.” — RFC 9110, §15.4.5 (normatywna reguła „nigdy żadnego ciała”). Przeczytaj sekcję

MDN Web Docs

• “The HTTP 304 Not Modified redirection response status code indicates that there is no need to retransmit the requested resources.” (tłumaczenie) „Kod stanu odpowiedzi przekierowania HTTP 304 Not Modified oznacza, że nie ma potrzeby ponownie przesyłać żądanych zasobów.” Przejdź do cytatu
• “Strong validation consists of guaranteeing that the resource is, byte to byte, identical to the one it is compared to.” (tłumaczenie) „Silna walidacja polega na zagwarantowaniu, że zasób jest bajt po bajcie identyczny z porównywanym.” — MDN, „HTTP conditional requests”. Przeczytaj poradnik

Gary Illyes, Google — „Crawling December: HTTP caching” (9 grudnia 2024 r.)

• “Especially if you have a large site with rarely-changing content under individual URLs, allowing caching locally may help your site be crawled more efficiently. Google’s crawling infrastructure supports heuristic HTTP caching as defined by the HTTP caching standard, specifically through the ETag response- and If-None-Match request header, and the Last-Modified response- and If-Modified-Since request header.” (tłumaczenie) „Szczególnie przy dużej witrynie z rzadko zmieniającą się treścią pod poszczególnymi adresami URL lokalne cache może pomóc w efektywniejszym crawlowaniu. Infrastruktura crawlowania Google obsługuje heurystyczne cache HTTP zgodnie ze standardem, konkretnie przez nagłówki ETag/If-None-Match i Last-Modified/If-Modified-Since.” Przeczytaj wpis
• “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value).” (tłumaczenie) „Zdecydowanie zalecamy ETag, ponieważ jest mniej podatny na błędy i pomyłki — jego wartość nie ma struktury, w przeciwieństwie do Last-Modified.” Przeczytaj wpis
• “If the ETag value sent by the crawler matches the current value the server generated, your server should return an HTTP 304 (Not modified) status code with no HTTP body.” (tłumaczenie) „Jeśli ETag wysłany przez crawler pasuje do bieżącej wartości wygenerowanej przez serwer, serwer powinien zwrócić kod 304 bez ciała HTTP.” Przeczytaj wpis
• “Our recommendation is that you require a cache refresh on significant changes to your content; if you only updated the copyright date at the bottom of your page, that’s probably not significant.” (tłumaczenie) „Zalecamy wymagać odświeżenia cache przy istotnych zmianach treści; sama aktualizacja daty praw autorskich w stopce prawdopodobnie nie jest istotna.” Przeczytaj wpis

Patrick Stox — poradnik Ahrefs

• “304 Not Modified – Says the page hasn’t been modified. Typically used for caching.” (tłumaczenie) „304 Not Modified — mówi, że strona nie została zmodyfikowana. Zwykle służy do cache.” — z mojego poradnika Kody stanu HTTP i ich wpływ na SEO (ten artykuł rozwija wpis, który wcześniej nie doczekał się pełnego omówienia). Przejdź do cytatu

304 w kontekście: bezciałowe kody i kody 3xx, z którymi bywa mylony

304 a jego sobowtóry

Pułapka: 304 i 204 są oba pozbawione ciała, a 304/301/302/307/308 należą do 3xx — ale 304 jest wyjątkiem na obu osiach. To jedyny kod 3xx, który nikogo nie przenosi, i jedyny kod bez ciała oznaczający „już to masz”, a nie „nie ma nic do wysłania”.

Dwa walidatory

Gdy obecne są oba, If-None-Match ma pierwszeństwo przed If-Modified-Since.

Szybkie fakty

• 304 nigdy nie ma ciała — RFC 9110 ustanawia to normatywnie.
• 304 jest kodem 3xx, ale nie jest przekierowaniem (brak Location, brak nowego adresu URL).
• Brak bezpośredniego wpływu na ranking ani wpływu na indeksowanie poza możliwością przeliczenia przez Google sygnałów adresu URL — korzyścią jest oszczędność zasobów, która może pośrednio poprawiać efektywność crawlowania na dużych witrynach.
• Google zaleca ETag jako podstawowy; ustawienie obu, ETag i Last-Modified, jest poprawne.
• Last-Modified musi używać formatu „Weekday, DD Mon YYYY HH:MM:SS Timezone”, bo inaczej może zostać zignorowany.
• Unieważniaj cache przy istotnych zmianach treści, nie przy dacie praw autorskich w stopce.
• Nie każde żądanie crawlera jest warunkowe — obsługa cache różni się między crawlerami.
• Bing obsługuje warunkowe GET → 304 od 2008 roku; to ogólne zachowanie HTTP.
• Prawdziwym ryzykiem jest nieaktualny 304 (serwer zwraca 304 po zmianie treści) — wykryj go w analizie logów.

Uzgadnianie żądania warunkowego w surowym HTTP

Konkretne łańcuchy żądań i odpowiedzi pokazujące, jak powstaje 304. (Wartości nagłówków są ilustracyjne.)

ETag / If-None-Match — pierwsze pobranie (200)

GET /blog/my-article/ HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html
ETag: "a1b2c3d4"
Cache-Control: max-age=3600

<full page body here>

Klient zapisuje ciało oraz wartość ETag.

ETag / If-None-Match — następne pobranie, treść niezmieniona (304)

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-None-Match: "a1b2c3d4"

HTTP/1.1 304 Not Modified
ETag: "a1b2c3d4"
Cache-Control: max-age=3600

Brak ciała. ETag pasuje, więc serwer oszczędził obliczeń potrzebnych do wygenerowania strony i przepustowości potrzebnej do jej wysłania. Klient używa kopii z cache.

Last-Modified / If-Modified-Since — odpowiednik oparty na dacie

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-Modified-Since: Fri, 4 Sep 1998 19:15:56 GMT

HTTP/1.1 304 Not Modified
Last-Modified: Fri, 4 Sep 1998 19:15:56 GMT

Zwróć uwagę na dokładny format daty HTTP — „Weekday, DD Mon YYYY HH:MM:SS Timezone” — który Google zaleca, aby uniknąć problemów z parsowaniem.

Gdy treść SIĘ zmieniła — świeże 200, a nie 304

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-None-Match: "a1b2c3d4"

HTTP/1.1 200 OK
Content-Type: text/html
ETag: "e5f6g7h8"          ← new value: content changed

<updated page body here>

Zapisany ETag już nie pasuje, więc serwer wysyła nową treść i nowy walidator. Cache się aktualizuje. Właśnie dlatego poprawnie wdrożony 304 nie może „uwięzić” crawlera na nieaktualnej treści — gdy treść się zmienia, zmienia się walidator, a następne żądanie otrzymuje prawdziwe 200.

Słaby a silny ETag

ETag: "a1b2c3d4"      ← strong: asserts byte-for-byte identity
ETag: W/"a1b2c3d4"    ← weak: asserts semantic equivalence (the W/ prefix)

Praktyczna zasada: jeśli prowadzisz dużą witrynę z wieloma rzadko zmieniającymi się adresami URL, wysyłanie stabilnego ETag (i respektowanie If-None-Match) przy odpowiedziach 200 pozwala crawlerom tanio i bez ciała potwierdzać „nadal jest tak samo” przez 304 — oszczędzając przepustowość i obliczenia, które według Google mogą pośrednio poprawić efektywność crawlowania reszty witryny. Jeśli ETag zmienia się przy każdej ponownej kompresji albo między serwerami za load balancerem, tracisz tę korzyść.

Błędy 304, które psują cache warunkowy

Zmienianie ETag przy niezmienionej reprezentacji

ETag związany z instancją serwera, przebiegiem kompresji lub czasem żądania niweczy działanie walidatora: niezmieniona treść ciągle zwraca pełne 200. Wygeneruj stabilny walidator z reprezentacji albo celowo użyj słabego ETag, gdy różnice bajtowe nie mają znaczenia.

Zwracanie 304 po zmianie treści

Nieaktualny walidator może ukryć rzeczywistą aktualizację przed klientami i crawlerami. Unieważnij ETag albo przesuń Last-Modified przy każdej zmianie reprezentacji, a następnie potwierdź, że stare żądanie warunkowe otrzymuje świeże 200 i ciało.

Wysyłanie 304 bez pasującego żądania warunkowego

Serwer nie powinien zgadywać, że klient ma kopię w cache. Zwracaj 304 dopiero po przeanalizowaniu If-None-Match lub If-Modified-Since; zwykłe pierwsze żądanie potrzebuje pełnej odpowiedzi.

Traktowanie 304 jak przekierowania lub pustej strony

304 nie ma nagłówka Location ani ciała odpowiedzi. Nie kieruj go przez logikę przekierowań i nie zastępuj prawdziwie pustego zasobu kodem 304; użyj statusu opisującego rzeczywistą odpowiedź.

Typowe problemy z 304

Serwer zawsze zwraca 200

Objaw: kolejne żądania pobierają pełne ciało, nawet gdy nic się nie zmieniło. Prawdopodobna przyczyna: pierwsza odpowiedź nie ma walidatora albo aplikacja ignoruje nagłówki żądania warunkowego. Naprawa: wysyłaj ETag i/lub poprawny Last-Modified, a następnie zaimplementuj pasujące sprawdzanie If-None-Match lub If-Modified-Since. Potwierdź, że niezmienione żądanie zwraca bodyless 304.

Różne serwery źródłowe generują różne ETagi

Objaw: ten sam niezmieniony adres URL naprzemiennie zwraca 200 i 304 za load balancerem. Prawdopodobna przyczyna: każdy węzeł generuje własny walidator. Naprawa: wyprowadź ETag ze współdzielonego stanu treści, a nie z węzła obsługującego, i powtórz to samo żądanie warunkowe wobec kilku odpowiedzi.

Zaktualizowana treść nadal zwraca 304

Objaw: przeglądarka lub crawler zachowuje starą reprezentację po wdrożeniu. Prawdopodobna przyczyna: walidator nie został unieważniony wraz z treścią. Naprawa: popraw logikę klucza cache lub wdrożenia, wyczyść odpowiedni cache, gdy trzeba, i udowodnij, że stary ETag otrzymuje teraz 200 z nowym walidatorem.

Last-Modified wygląda na ignorowany

Objaw: If-Modified-Since nigdy nie daje 304. Prawdopodobna przyczyna: nieprawidłowa data HTTP, zbyt mała precyzja znacznika czasu albo ETag mający pierwszeństwo. Naprawa: sprawdź surowe nagłówki, popraw format daty i przetestuj każdy walidator osobno.

304 wygląda jak błąd w kodzie aplikacji

Objaw: skrypt lub aplikacja zgłasza wyjątek albo loguje „błąd” przy żądaniu, które faktycznie otrzymało 304. Prawdopodobna przyczyna: niektóre biblioteki klientów HTTP traktują każdy status inny niż 200 — w tym prawidłowy 304 — jak warunek podobny do wyjątku, jeśli jawnie nie skonfigurujesz ich do obsługi przekierowań lub odpowiedzi „not modified”; to dziwactwo biblioteki klienta, a nie problem protokołu ani serwera. Naprawa: sprawdź konkretną obsługę 304 w bibliotece (nie tylko reakcję na 4xx/5xx) i potwierdź, że surowa odpowiedź HTTP jest poprawnym 304 bez ciała, zanim uznasz serwer za winny.

Warstwa cache platformy (np. cache wyjściowy IIS) zaciemnia obraz

Objaw: aplikacja źródłowa wygląda poprawnie, ale zachowanie 304 nadal wydaje się błędne. Prawdopodobna przyczyna: warstwa cache specyficzna dla platformy hostingu — jednym udokumentowanym przykładem jest cache wyjściowy IIS — znajduje się między aplikacją a klientem i sama generuje lub przechwytuje odpowiedzi 304. Naprawa: traktuj ją jako jedną z kilku możliwych warstw (aplikacja źródłowa, CDN, load balancer, cache platformy), a nie domyślnego podejrzanego; odizoluj ją kontrolowanym testem, który zmienia walidator w każdej warstwie po kolei, zanim stwierdzisz, która warstwa odpowiada.

Prompt: audytuj ślad żądania warunkowego

Wklej nagłówki żądania i odpowiedzi z pierwszego oraz powtórnego pobrania.

Act as an HTTP caching reviewer. I will paste two request/response header traces for
the same URL: an initial fetch and a conditional repeat. Identify the validator used,
check whether If-None-Match or If-Modified-Since was evaluated correctly, verify that
a 304 has no body or Location header, and flag unstable or stale-validator risks.
Return: observed flow, pass/fail checks, likely cause of each failure, and the exact
next request I should run. Do not infer headers that are not present.

[PASTE BOTH TRACES]

Prompt: przejrzyj implementację ETag

Wklej odpowiednią konfigurację aplikacji, CDN-u lub serwera.

Review this ETag/Last-Modified implementation for conditional GET correctness. Trace
the 200 -> conditional request -> 304 path, explain what causes the validator to
change, and test mentally for multiple origin nodes, compression variants, and real
content updates. Separate protocol violations from efficiency issues. Give a minimal
fix and a curl-based validation plan. Do not invent platform behavior.

[PASTE CONFIGURATION OR CODE]

Shell: odtwórz ETag jako żądanie warunkowe

Uruchom to w terminalu macOS/Linux. Skopiuj ETag dokładnie, wraz z cudzysłowami.

URL='https://example.com/page'
curl -sS -D - -o /dev/null "$URL"
curl -sS -D - -o /dev/null -H 'If-None-Match: "PASTE_ETAG_HERE"' "$URL"

Pierwsza odpowiedź powinna ujawnić walidator. Druga powinna zwrócić 304, gdy reprezentacja się nie zmieniła, i 200, gdy wklejony ETag jest nieaktualny.

PowerShell: przetestuj Last-Modified

Uruchom w PowerShell po zastąpieniu adresu URL i znacznika czasu.

$url = 'https://example.com/page'
$headers = @{ 'If-Modified-Since' = 'Tue, 14 Jul 2026 12:00:00 GMT' }
Invoke-WebRequest -Uri $url -Headers $headers -SkipHttpErrorCheck

Konsola DevTools: wyświetl walidatory zasobów strony

Uruchom w konsoli przeglądarki. Raportuje wpisy o czasie zasobów; użyj panelu Network, aby sprawdzić faktyczne nagłówki ETag, Last-Modified i statusu.

console.table(performance.getEntriesByType('resource').map(r => ({name: r.name, transferSize: r.transferSize, encodedBodySize: r.encodedBodySize})));

Narzędzia do sprawdzania zachowania 304

• HTTP Header Checker: sprawdź ETag, Last-Modified, Cache-Control, Vary oraz odciski CDN-u/brzegu w zwykłej odpowiedzi, zanim odtworzysz walidator.
• Panel Network w DevTools przeglądarki: wyłącz „Disable cache”, odśwież stronę i porównaj nagłówki żądania oraz odpowiedzi. DevTools pokazuje też HSTS i zachowanie lokalnego cache, więc odróżnij zachowanie przeglądarki od tego, co wysłało źródło.
• curl: wyślij dokładny nagłówek If-None-Match lub If-Modified-Since bez wpływu stanu cache przeglądarki.
• Logi dostępu: zmierz, które żądania crawlerów były warunkowe i czy zakończyły się 304, czy pełnym 200.

Udowodnij, że odpowiedzi warunkowe działają po zmianie

Test niezmienionej reprezentacji

Test do wykonania: pobierz adres URL, skopiuj jego ETag, a następnie powtórz żądanie przez curl -I -H 'If-None-Match: "VALUE"' URL. Oczekiwany wynik: 304, pasujący walidator oraz brak ciała i Location. Interpretacja niepowodzenia: serwer zignorował warunek albo wygenerował niestabilny walidator. Okno monitorowania: natychmiast. Warunek wycofania: zmiana cache sprawia, że zwykłe żądania tracą pełną odpowiedź 200.

Test zmienionej reprezentacji

Test do wykonania: wdroż prawdziwą zmianę treści, a następnie odtwórz stary ETag. Oczekiwany wynik: 200 ze zaktualizowanym ciałem i nowym walidatorem. Interpretacja niepowodzenia: unieważnianie cache jest nieaktualne. Okno monitorowania: natychmiast po dotarciu wdrożenia do każdego źródła. Warunek wycofania: dowolne źródło nadal zwraca 304 dla starego walidatora po zakończeniu wdrożenia.

Test stabilności wielu źródeł

Test do wykonania: powtórz te same zwykłe i warunkowe żądania wystarczająco wiele razy, aby trafić do puli obsługującej, zapisując ETag i status. Oczekiwany wynik: niezmienione reprezentacje używają zgodnych walidatorów i konsekwentnie zwracają 304. Interpretacja niepowodzenia: walidatory różnią się między węzłami lub kodowaniami bez pasującej strategii Vary. Okno monitorowania: natychmiast, w całej wdrożonej puli. Warunek wycofania: nowa logika walidatora serwuje nieaktualną treść albo miesza reprezentacje między klientami.

Mierz kondycję cache warunkowego

Wskaźnik udanych ponownych walidacji warunkowych

Metryka: żądania warunkowe kończące się 304 w porównaniu z pełnym 200. Co mówi: czy niezmienione zasoby unikają niepotrzebnych transferów. Jak pobrać: pogrupuj żądania z logów dostępu zawierające If-None-Match lub If-Modified-Since według statusu odpowiedzi i klasy adresu URL. Benchmark / realistyczny zakres: ustal bazę według typu treści; często zmieniane strony nie powinny być sztucznie zbliżane do wskaźnika zasobów statycznych. Częstotliwość: co tydzień podczas wdrożenia, następnie co miesiąc.

Bajty zaoszczędzone przy niezmienionych pobraniach

Metryka: szacowana liczba bajtów ciała odpowiedzi, których nie przesłano przy prawidłowych odpowiedziach 304. Co mówi: o przepustowościowej stronie korzyści z efektywności crawlowania. Jak pobrać: połącz liczbę 304 z logów z najnowszym rozmiarem pełnej odpowiedzi dla tej samej klasy adresów URL. Benchmark / realistyczny zakres: porównaj z własną bazą sprzed zmiany; nie ma uniwersalnego celu odpowiedniego dla każdego zestawu treści. Częstotliwość: co miesiąc.

Awarie nieaktualnego walidatora

Metryka: zmienione adresy URL, które nadal akceptują stary walidator. Co mówi: czy efektywność nie odbywa się kosztem świeżości. Jak pobrać: wykonaj małą próbę po wdrożeniu, odtwarzając ETagi sprzed wdrożenia. Benchmark / realistyczny zakres: każda potwierdzona nieaktualna odpowiedź wymaga zbadania. Częstotliwość: przy każdym wdrożeniu zmieniającym cache lub generowanie walidatorów.

Sprawdź się: 304 Not Modified

Pięć krótkich pytań o znaczenie i działanie 304. Wybierz odpowiedź na każde, a następnie sprawdź wynik.

Dziennik zmian