Cache'owanie dla SEO

TL;DR — Cache’owanie zapisuje kopię strony lub pliku, aby nie trzeba było budować i wysyłać ich od początku. Przyspiesza witrynę dla użytkowników i robotów oraz pozwala pominąć ponowne pobieranie niezmienionych stron. Sam cache nie poprawia pozycji, ale pośrednio pomaga dzięki szybkości i sprawniejszemu crawlowaniu.

Czym jest caching

Za każdym razem, gdy ktoś otwiera stronę, serwer musi wykonać pracę: zbudować HTML, wysłać obrazy, dostarczyć CSS i JavaScript. Caching przechowuje gotową kopię tych elementów, aby następna wizyta mogła ją wykorzystać ponownie, zamiast wykonywać całą tę pracę od nowa.

Istnieją trzy miejsca, w których kopia może być przechowywana i które mają znaczenie dla SEO:

1. Pamięć podręczna przeglądarki — pliki zapisane na urządzeniu odwiedzającego, dzięki czemu drugie wyświetlenie strony lub powrót na nią ładuje się niemal natychmiast.
2. Pamięć podręczna CDN (edge) — kopie przechowywane na serwerach rozproszonych po całym świecie, dzięki czemu plik jest serwowany z miejsca fizycznie bliskiego użytkownikowi (lub botowi), a nie z Twojego pojedynczego serwera źródłowego.
3. Pamięć podręczna samego crawlera — Googlebot i Bingbot pamiętają, czy strona zmieniła się od ostatniego odwiedzenia, i pomijają jej ponowne pobieranie, jeśli się nie zmieniła.

Dlaczego to ma znaczenie dla SEO

Dwa powody i warto je rozdzielić:

• Szybkość. Szybsze dostarczanie pomaga w Core Web Vitals — zwłaszcza w szybkości odpowiedzi serwera (TTFB) i szybkości wyświetlania głównej treści (LCP). Szybkość jest częścią sygnałów doświadczenia strony w Google.
• Wydajność indeksowania. Gdy bot może stwierdzić, że strona się nie zmieniła, nie marnuje na nią pobierania. Na dużej stronie uwalnia to bota, aby mógł poświęcić czas na nowe i zaktualizowane strony.

Jedna rzecz, którą trzeba zrozumieć

„Pamięć podręczna Google” i „caching HTTP” to dwie różne rzeczy. Stary operator wyszukiwania cache: — funkcja „wyświetl zapisaną kopię tej strony w Google” — został wycofany w 2024 roku. To nie ma nic wspólnego z cachingiem, o którym mowa w tym artykule. Nagłówki Cache-Control i ETag są żywe, zdrowe i ważne. Brak „zapisanej wersji” Twojej strony w Google nie mówi nic o tym, czy Twoja konfiguracja cachowania jest poprawna.

Co właściwie zrobić

• Cache’uj swoje pliki statyczne (obrazy, CSS, JavaScript, czcionki) przez długi czas.
• Dodawaj wersjonowane lub hashowane nazwy plików, aby móc je natychmiast aktualizować, gdy zajdzie potrzeba.
• Użyj CDN, aby pliki ładowały się blisko Twoich użytkowników.
• Nie pozwól, aby nieaktualna lub współdzielona pamięć podręczna przypadkowo serwowała botom niewłaściwe treści (przerażający scenariusz awarii — zobacz zakładki Advanced i Anti-patterns).

Chcesz poznać szczegóły na poziomie nagłówków — dyrektywy Cache-Control, ETag vs. Last-Modified, historię szybkości indeksowania CDN i błędy cachowania, które psują indeksowanie? Przełącz się na zakładkę Advanced.

TL;DR — Cache’owanie działa na trzech warstwach istotnych dla SEO: w przeglądarce, na brzegu CDN i we własnym cache żądań warunkowych crawlera. Nie jest czynnikiem rankingowym, lecz wpływa na TTFB, LCP, powtórne nawigacje i efektywność crawlowania. Robot Google preferuje ETag względem Last-Modified, traktuje max-age tylko jako wskazówkę i stwierdza, że “other HTTP caching directives aren’t supported.” (tłumaczenie) „Inne dyrektywy cache’owania HTTP nie są obsługiwane”. CDN pomaga po rozgrzaniu cache; ryzykiem są zimne wdrożenia oraz błędne reguły CDN lub WAF.

Trzy warstwy cachowania

Caching dla SEO to nie jedna rzecz — to trzy, każda kontrolowana nieco inaczej:

1. Pamięć podręczna przeglądarki — urządzenie odwiedzającego przechowuje pliki, dzięki czemu ponowne odwiedziny pomijają sieć. To o tym mówi PageSpeed Insights w komunikacie „Serve static assets with an efficient cache policy.”
2. Pamięć podręczna CDN / edge — sieć dostarczania treści przechowuje kopie w węzłach brzegowych na całym świecie (pełne omówienie znajdziesz w artykule o CDN i SEO). Własny opis Google: CDN to pośrednik między Twoim origin a użytkownikiem, a historycznie ich największym celem jest buforowanie — przechowywanie zawartości URL-a, aby Twój serwer nie musiał przez jakiś czas ponownie serwować tego pliku.
3. Pamięć podręczna po stronie crawlera — Googlebot i Bingbot prowadzą własny zapis tego, czy treść się zmieniła, używając żądań warunkowych. To dźwignia budżetu indeksowania, a mechanika należy do artykułu o żądaniach warunkowych; tutaj pozostanę na poziomie podsumowania.

„Pamięć podręczna przeglądarki” powyżej to skrót dla więcej niż jednego mechanizmu. Według przewodnika po buforowaniu HTTP od MDN, warto rozróżniać: prywatną pamięć podręczną HTTP (per-przeglądarkową, kluczowaną żądaniem, a w nowoczesnych przeglądarkach podzieloną według witryny najwyższego poziomu, aby ograniczyć śledzenie między witrynami), pamięć podręczną w pamięci RAM używaną dla bieżącej sesji, bfcache omówione poniżej oraz — osobno — Cache Storage w service workerze, którą kontroluje własny JavaScript witryny i której nagłówki Cache-Control nie zarządzają bezpośrednio. „Sprawdź pamięć podręczną przeglądarki” może oznaczać cztery różne kroki debugowania, w zależności od tego, który mechanizm faktycznie działa nieprawidłowo.

Dlaczego buforowanie wpływa na Core Web Vitals

Pobieranie zasobów przez sieć jest wolne i kosztowne. Buforowanie usuwa opóźnienie sieciowe i koszt transferu dla wszystkiego, co się nie zmieniło. To bezpośrednio przekłada się na dwie metryki powiązane z vitals: TTFB (odpowiedź z pamięci podręcznej pomija regenerację na origin) i LCP (obrazy/CSS/czcionki z pamięci podręcznej renderują się szybciej).

Cache-Control, w dyrektywach, które mają znaczenie

Cache-Control to główny nagłówek. Te, które warto znać:

• max-age=<seconds> — jak długo świeża kopia jest ważna. Dla niezmiennych, wersjonowanych zasobów dokumentacja Lighthouse od Chrome zaleca buforowanie przez rok lub dłużej — np. Cache-Control: max-age=31536000.
• no-cache — nie „nie buforuj”. Oznacza „przechowaj, ale przed ponownym użyciem zweryfikuj z serwerem”. Nadal umożliwia lekki przepływ 304.
• no-store — to ten, który faktycznie oznacza nieprzechowywanie żadnej kopii w pamięci podręcznej HTTP. To dyrektywa buforowania, a nie ogólny przełącznik prywatności — według RFC 9111 nie jest niezawodnym sposobem na wyczyszczenie historii przeglądarki i nic nie mówi o własnym Cache Storage w service workerze.
• public / private — czy współdzielone pamięci podręczne (takie jak CDN) mogą przechowywać odpowiedź, czy tylko przeglądarka końcowego użytkownika.
• immutable — całkowicie pomiń rewalidację dopóki odpowiedź jest nadal świeża. Nie oznacza „nigdy nie traci ważności” — gdy max-age się skończy, znów obowiązują normalne zasady świeżości.
• must-revalidate — przeciwny koniec osi czasu: ma znaczenie tylko po tym, jak odpowiedź straci świeżość, i mówi pamięci podręcznej, że musi zweryfikować z origin, zamiast serwować nieświeżą kopię.
• s-maxage, stale-while-revalidate, stale-if-error — bardziej precyzyjne sterowanie głównie dla CDN i innych współdzielonych pamięci podręcznych (osobny czas świeżości dla współdzielonych pamięci podręcznych, ograniczone ponowne użycie nieświeżych danych podczas działania pobierania w tle oraz ograniczone ponowne użycie nieświeżych danych w przypadku błędu origin). Wsparcie różni się w zależności od przeglądarki/CDN, więc przed poleganiem na nich sprawdź aktualne wsparcie — a żadna z tych dodatkowych dyrektyw nie jest honorowana przez crawlera Google, jak zobaczymy.

Przełamywanie pamięci podręcznej za pomocą wersjonowanych nazw plików

Sztuczka, która pozwala agresywnie buforować i aktualizować natychmiast: umieść hash treści w nazwie pliku — style.x234dff.css. Ponieważ URL jest kluczem pamięci podręcznej, zmiana pliku zmienia URL, więc pamięci podręczne pobierają nową wersję natychmiast, podczas gdy stare wersje pozostają w pamięci podręcznej tak długo, jak chcesz. Zarówno przewodnik po buforowaniu HTTP web.dev Google, jak i opis inżynierii front-endu Binga opisują ten sam wzorzec — Bing hashuje zawartość plików do URL, tak że “the URL acts as the cache key,” (tłumaczenie) „URL pełni funkcję klucza pamięci podręcznej”, co utrzymuje spójność cache i pozwala na długie czasy wygaśnięcia.

Pułapka bfcache — gdzie no-store po cichu szkodzi CWV

Oto mało znany temat. Pamięć podręczna wstecz/do przodu (bfcache) sprawia, że kliknięcie „wstecz” przywraca stronę natychmiast. Przywrócenie z bfcache całkowicie pomija pomiar LCP/CLS/INP, więc to czysta korzyść dla danych terenowych CrUX. Ale zgodnie z przewodnikiem po bfcache Google, ustawienie Cache-Control: no-store na samym dokumencie strony historycznie powodowało, że przeglądarki odmawiały przechowywania tej strony w bfcache. Jeśli potrzebujesz świeżości dokumentu HTML, ale nie chcesz rezygnować z kwalifikowalności do pamięci wstecz/do przodu, sięgnij po no-cache lub max-age=0 zamiast no-store.

Jak pamięć podręczna decyduje, czy treść jest „wystarczająco świeża”

Zanim jakikolwiek walidator wejdzie do gry, pamięć podręczna sprawdza świeżość: czy wiek przechowywanej odpowiedzi przekroczył czas świeżości, który nadało jej Cache-Control (lub, w przypadku braku jawnego czasu życia, heurystyczny czas, który pamięć podręczna może zgadywać)? Nagłówek odpowiedzi Age informuje, jak długo współdzielona pamięć podręczna już przechowuje odpowiedź, co pozwala — w DevTools lub z logu CDN — określić, ile czasu świeżości pozostało. Świeża treść oznacza, że pamięć podręczna może jej użyć natychmiast, bez żadnego żądania. Nieświeża oznacza, że powinna zweryfikować przed ponownym użyciem, co jest dokładnie tym, gdzie ETag/If-None-Match i Last-Modified/If-Modified-Since pokazują swoją wartość — opisane dalej, dla węższej wersji tego ogólnego mechanizmu HTTP używanego przez Googlebota.

Jak Googlebot używa buforowania (kąt efektywności indeksowania)

Google w grudniu 2024 roku opublikowało niezwykle bezpośredni apel w poście Crawling December: HTTP caching: włącz buforowanie, aby jego roboty mogły pominąć ponowne pobieranie niezmienionych stron. Uderzający dany punkt w tym poście jest taki, że liczba buforowanych pobrań spada — około 0,026 % wszystkich pobrań było buforowanych 10 lat temu, a dziś ta liczba wynosi 0,017 %. Małe liczby, ale Google wyraźnie chce, aby zmierzały w przeciwnym kierunku.

ETag vs. Last-Modified — który Google woli

Infrastruktura indeksowania Google obsługuje dwa standardowe walidatory: ETag (z If-None-Match) i Last-Modified (z If-Modified-Since). Google zdecydowanie zaleca ETag, ponieważ jego wartość jest nieustrukturyzowana, a przez to mniej podatna na błędy parsowania, do których zaprasza ciąg daty — a jeśli oba są obecne, jego roboty używają wartości ETag zgodnie z wymogami standardu HTTP. Google nadal sugeruje ustawienie obu, ponieważ inne aplikacje, takie jak systemy CMS z nich korzystają. Jeśli używasz Last-Modified, data musi być zgodna z formatem HTTP (na przykład Fri, 4 Sep 1998 19:15:56 GMT), w przeciwnym razie nie zostanie sparsowana.

Gdy zapisany walidator robota wciąż pasuje, Twój serwer zwraca 304 Not Modified bez treści — o to właśnie chodzi. Jak ujmuje to Google, brak treści oznacza, że Twój serwer nie zużywa mocy obliczeniowej na generowanie treści i nie zużywa przepustowości na jej przesyłanie. (Ten mechanizm 304 to element budżetu indeksowania omówiony szczegółowo w artykule o żądaniach warunkowych; tutaj wystarczy wiedzieć, że istnieje i oszczędza pieniądze po obu stronach.)

Niuanse, które prawie wszyscy pomijają

Robot Google nie działa na pełnym zestawie dyrektyw Cache-Control w taki sposób jak przeglądarka czy CDN. Zgodnie z oficjalnym przeglądem robota, poza ETag/Last-Modified, “inne dyrektywy buforowania HTTP nie są obsługiwane.” Jedynym częściowym wyjątkiem jest to, że Google mówi, iż możesz opcjonalnie ustawić max-age, aby pomóc robotom określić, kiedy ponownie indeksować URL — to wskazówka dotycząca ponownego indeksowania, a nie twardy limit. Więc no-cache, s-maxage, stale-while-revalidate i inne wciąż kształtują zachowanie przeglądarek i CDN, ale nie zmieniają sposobu buforowania przez Googlebota. A rada Google dotycząca tego, kiedy unieważniać, jest rozsądna: wymagaj odświeżenia pamięci podręcznej przy znaczących zmianach — aktualizacja tylko daty praw autorskich w stopce nie jest znacząca.

CDN a indeksowanie

CDN daje Ci więcej niż tylko szybkość. Infrastruktura indeksowania Google jest zaprojektowana tak, aby umożliwiać wyższe tempo indeksowania witryn obsługiwanych przez CDN, wnioskowane na podstawie adresu IP serwującego URL-e — zakłada, że źródło za CDN-em może obsłużyć więcej równoczesnych żądań.

Ale jest pewien haczyk, który warto zaplanować: zimna pamięć podręczna. Przy pierwszym dostępie do URL-a pamięć podręczna CDN jest “zimna” — nikt jeszcze o niego nie prosił, więc Twoje źródło musi go obsłużyć przynajmniej raz, aby ogrzać pamięć podręczną. Google ostrzega, że uruchomienie wielu URL-i naraz jest zatem realnym obciążeniem dla budżetu indeksowania, z wysokim tempem indeksowania przez kilka dni. Jeśli planujesz duże uruchomienie lub migrację witryny, zaplanuj, że źródło przyjmie pełne obciążenie na każdy URL, zanim CDN zacznie pomagać.

Błędna konfiguracja CDN to ryzyko dla indeksowania

Najstraszniejsze problemy związane z buforowaniem to nie wolne czasy życia cache — to konfiguracje CDN i WAF, które blokują boty. Wpis Google o CDN jest jednoznaczny: w przypadku tymczasowych blokad wysyłanie kodów 503/429 jest preferowanym sposobem ich sygnalizowania, podczas gdy przekroczenia czasu sieci są traktowane jako terminalne, „twarde” błędy, które mogą spowodować usunięcie adresów URL z indeksu. Podstępny jest miękki blok: strona pośrednia z weryfikacją bota. Crawler widzi tylko stronę wyzwania, a nie Twoją witrynę — dlatego Google zdecydowanie zaleca zwracanie kodu 503 klientom zautomatyzowanym. Najłatwiejszy sposób sprawdzenia, czy CDN po cichu nie blokuje Google, to narzędzie URL Inspection w Search Console — spójrz na wyrenderowany obraz; jeśli pokazuje wyzwanie dla bota lub pustą stronę, porozmawiaj ze swoim dostawcą CDN.

Przenoszenie przekierowań na poziom CDN to technika, którą bardzo lubię. W podcaście Marketing Speak opisałem ją jako “One of my personal favorites that I don’t think it’s used enough, it’s actually just off loading your redirects to the CDN level.” (tłumaczenie) „Jedna z moich osobistych ulubionych technik, która moim zdaniem nie jest wystarczająco wykorzystywana, to po prostu przeniesienie przekierowań na poziom CDN.” (Przejdź do cytatu)

Pułapki buforowania, które szkodzą indeksowaniu i crawlingowi

To jest aspekt, który większość artykułów o „buforowaniu dla SEO” pomija. Cache nie tylko przyspiesza działanie — zły cache może serwować botowi niewłaściwe bajty i zakłócić crawling lub indeksowanie.

Prawdziwy przykład: współdzielony cache serwujący blokujący robots.txt. Zbadałem przypadek sporadycznego blokowania Googlebota, który prowadził do współdzielonego cache CDN między środowiskiem testowym a witryną produkcyjną. Jak napisałem w Indexed, though blocked by robots.txt: “One possible cause would be a shared cache between a test environment and a live environment. When the cache from the test environment is active, the robots.txt file may include a blocking directive.” (tłumaczenie) „Jedną z możliwych przyczyn może być współdzielony cache między środowiskiem testowym a produkcyjnym. Gdy cache ze środowiska testowego jest aktywny, plik robots.txt może zawierać dyrektywę blokującą.” Rozwiązaniem było rozdzielenie cache — lub wykluczenie plików .txt z cache w środowisku testowym. Błędna konfiguracja buforowania bezpośrednio spowodowała awarię crawlingu; to kategoria ryzyka, która naprawdę boli.

Inne pułapki z tej samej rodziny:

• Nieaktualny cache CDN serwujący botom przestarzałe treści. Jeśli Twój cache brzegowy przechowuje starą wersję długo po opublikowaniu zmiany, boty nadal widzą starą. Czyść cache po publikacji lub powiąż czas życia cache z tym, jak często strona faktycznie się zmienia.
• Fragmentacja cache przez Vary / User-Agent. Klucz współdzielonego cache to zwykle tylko URL; Vary dodaje do tego klucza nagłówki żądań (takie jak User-Agent czy Accept-Language), aby różne warianty były przechowywane osobno. Jeśli pominiesz nagłówek, który faktycznie zmienia odpowiedź, jeden żądający może otrzymać wariant innego — pomylenie wersji mobilnej/desktopowej lub bot/człowiek. Dodanie zbyt wielu nagłówków do Vary fragmentuje cache na tyle podobnych kluczy, że ledwo poprawia współczynnik trafień. Osobno, nowoczesne przeglądarki dzielą również własne cache według witryny najwyższego poziomu ze względu na prywatność, więc zasób zapisany w cache podczas osadzenia na jednej witrynie zwykle nie jest ponownie używany, gdy jest osadzony na innej — to inny mechanizm niż Vary, którego nie warto mylić podczas debugowania zgłoszenia „dlaczego to nie jest buforowane”.

Moja ogólna zasada dotycząca czasu trwania pochodzi z prac nad LCP: jak to ująłem w moim przewodniku Ahrefs o największym wyrenderowaniu treści: “Your cache time should be as long as you are comfortable with” (tłumaczenie) „Ustaw czas cache tak długi, jak uznasz za bezpieczny” — oraz “An ideal setup is to cache for a really long period of time but purge the cache when you make a change to a page.” (tłumaczenie) „Idealnie cache działa bardzo długo, ale jest czyszczony po zmianie strony”. Długi cache i natychmiastowe czyszczenie sprawia, że jesteś zarówno szybki, jak i aktualny.

Czy cache jest czynnikiem rankingowym?

Nie — nie bezpośrednio. Nie ma sygnału rankingowego za posiadanie ustawionych ETagów ani za dobrą politykę Cache-Control. To, co robi cache, to zasilanie dwóch rzeczy, które mają znaczenie dla widoczności: szybkości strony / Core Web Vitals (jawne kryterium doświadczenia strony) oraz wydajności indeksowania (która reguluje, jak szybko nowe i zaktualizowane treści są odkrywane i odświeżane, pośrednio wpływając na wyniki wrażliwe na świeżość). Skonfiguruj to, ponieważ sprawia, że Twoja strona jest szybka i łatwa do indeksowania — nie dlatego, że oczekujesz bezpośredniego wzrostu pozycji.

Podsumowanie AI

Skondensowane ujęcie wersji zaawansowanej:

• Cache = trzy warstwy dla SEO: cache przeglądarki, cache CDN/edge oraz własny cache żądań warunkowych robota. Każda jest kontrolowana nieco inaczej.
• Nie jest czynnikiem rankingowym — ale napędza dwie rzeczy, które mają znaczenie: szybkość strony (TTFB/LCP, plus wskaźniki przy powtórnej nawigacji przez bfcache) oraz wydajność indeksowania.
• Podstawy Cache-Control: max-age ustawia świeżość (rok+ dla niezmiennych, wersjonowanych zasobów); no-cache = “przechowuj, ale weryfikuj ponownie” (nie “nie cache’uj”); no-store = nie przechowuj wcale; public/private bramkują współdzielone/cache CDN.
• Cache-busting: umieść hash treści w nazwie pliku, aby móc agresywnie cache’ować i nadal aktualizować natychmiast (zarówno Google, jak i Bing używają tego wzorca).
• Pułapka bfcache: Cache-Control: no-store na dokumencie HTML może zdyskwalifikować stronę z cache wstecz/do przodu, cicho szkodząc wskaźnikom CrUX. Zamiast tego użyj no-cache lub max-age=0.
• Googlebot honoruje tylko ETag i Last-Modified (preferuje ETag; czyta max-age jako wskazówkę do ponownego indeksowania). Według Google, “other HTTP caching directives aren’t supported.” Pasujący walidator zwraca 304 Not Modified bez treści, oszczędzając obliczenia i przepustowość.
• CDN-y otrzymują wyższy limit szybkości indeksowania — ale tylko gdy cache jest ciepły. Uruchomienia z zimnym cache nadal trafiają do origin raz na URL; zaplanuj to przy dużych uruchomieniach i migracjach.
• Największe ryzyko to nie wolne cache’owanie — to błędna konfiguracja CDN/WAF, która blokuje boty (zwracaj 503/429 dla tymczasowych blokad; uważaj na miękkie blokady interstitial) oraz nieaktualne/współdzielone cache serwujące niewłaściwą treść (np. blokujący robots.txt).

Oficjalna dokumentacja

Dokumentacja źródłowa od wyszukiwarek i ich zespołów narzędziowych.

Google

• Grudniowe crawlowanie: cache HTTP — post Gary’ego Illyesa z grudnia 2024: ETag vs. Last-Modified, mechanika 304, malejący odsetek buforowanych pobrań oraz wskazówka max-age dotycząca ponownego indeksowania.
• Google Crawler (User Agent) Overview — sekcja HTTP Caching — żywy dokument: reguła rozstrzygania remisów ETag oraz stwierdzenie, że „inne dyrektywy buforowania HTTP nie są obsługiwane”.
• Grudniowe crawlowanie: CDN-y i pobieranie — Splitt i Illyes o cache CDN, wyższym limicie crawlowania, zimnym starcie oraz twardych i miękkich blokadach.
• Serve static assets with an efficient cache policy — audyt Lighthouse/PageSpeed oraz zalecenie „rok lub dłużej” dla niezmiennych zasobów.
• Zapobieganie zbędnym żądaniom sieciowym za pomocą cache HTTP — dokumentacja dyrektyw i wzorzec unieważniania cache za pomocą zahaszowanych nazw plików.
• Back/forward cache (bfcache) — dlaczego no-store w dokumencie HTML może pozbawić Cię kwalifikowalności do bfcache.
• Indeks serii Crawling December — pełna seria z 2024: Googlebot, buforowanie HTTP, nawigacja fasetowa i CDN.

Bing / Microsoft

• Szybka wydajność front-endu w Microsoft Bing — zespół inżynierów Bing o haszowaniu zawartości plików w adresach URL dla spójności pamięci podręcznej i długich okresów ważności oraz o roli CDN w przyspieszaniu dostarczania zasobów statycznych.
• bingbot Series: Maximizing Crawl Efficiency — logika świeżości indeksowania (indeksuj mniej, gdy treść się nie zmieniła), którą wspiera buforowanie.
• Bing Webmaster Guidelines — centrum, w którym znajdują się wytyczne Bing dotyczące CDN i wydajności.

Cytaty ze źródła

Oficjalne wypowiedzi Google i z moich własnych tekstów. Każdy link to link bezpośredni, który prowadzi do cytowanego fragmentu na stronie źródłowej.

Google — Crawling December: HTTP caching

• “While Google’s crawling infrastructure supports heuristic caching mechanisms, in fact always had, the number of requests that can be returned from local caches has decreased: 10 years ago about 0.026% of the total fetches were cacheable, which is already not that impressive; today that number is 0.017%.” (tłumaczenie) „Chociaż infrastruktura indeksująca Google wspiera heurystyczne mechanizmy buforowania, w rzeczywistości zawsze wspierała, liczba żądań, które mogą być zwracane z lokalnych pamięci podręcznych, spadła: 10 lat temu około 0,026% wszystkich pobrań było możliwych do zapisania w pamięci podręcznej, co już nie robi wrażenia; dziś ta liczba wynosi 0,017%.” Przejdź do cytatu
• “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value). And, if you have the option, set them both: the internet will thank you. Maybe.” (tłumaczenie) „Zdecydowanie zalecamy używanie ETag, ponieważ jest mniej podatny na błędy i pomyłki (wartość nie jest strukturalna, w przeciwieństwie do wartości Last-Modified). A jeśli masz taką możliwość, ustaw oba: internet ci podziękuje. Może.” Przejdź do cytatu
• “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) „Nasze zalecenie jest takie, aby wymagać odświeżenia pamięci podręcznej przy znaczących zmianach treści; jeśli zaktualizowałeś tylko datę praw autorskich na dole strony, to prawdopodobnie nie jest to znaczące.” Przejdź do cytatu

Google — Przegląd indeksatora (sekcja HTTP Caching)

• “If both ETag and Last-Modified response header fields are present in the HTTP response, Google’s crawlers use the ETag value as required by the HTTP standard.” (tłumaczenie) „Jeśli zarówno pola nagłówka odpowiedzi ETag, jak i Last-Modified są obecne w odpowiedzi HTTP, roboty Google używają wartości ETag zgodnie ze standardem HTTP.” Przejdź do cytatu
• “Other HTTP caching directives aren’t supported.” (tłumaczenie) „Inne dyrektywy buforowania HTTP nie są obsługiwane.” Przejdź do cytatu

Google — Crawling December: CDN-y a indeksowanie

• “Historically, CDNs’ biggest focus is caching, meaning that once a user requested a URL from your site, CDNs will store the contents of that URL in their caches for a time so your server doesn’t have to serve that file again for a while.” (tłumaczenie) „Historycznie rzecz biorąc, największym celem CDN-ów jest buforowanie, co oznacza, że gdy użytkownik zażąda adresu URL z Twojej witryny, CDN-y przechowują zawartość tego adresu URL w swoich pamięciach podręcznych przez pewien czas, aby Twój serwer nie musiał ponownie serwować tego pliku przez jakiś czas.” Przejdź do cytatu

Patrick Stox — o buforowaniu i CDN-ach

• “Your cache time should be as long as you are comfortable with.” (tłumaczenie) „Twój czas buforowania powinien być tak długi, jak Ci wygodnie.” — ja, w przewodniku Ahrefs o największym wyrenderowaniu treści. Przejdź do cytatu
• “One possible cause would be a shared cache between a test environment and a live environment. When the cache from the test environment is active, the robots.txt file may include a blocking directive.” (tłumaczenie) „Jedną z możliwych przyczyn byłaby współdzielona pamięć podręczna między środowiskiem testowym a środowiskiem produkcyjnym. Gdy pamięć podręczna ze środowiska testowego jest aktywna, plik robots.txt może zawierać dyrektywę blokującą.” — ja, o prawdziwej awarii indeksowania spowodowanej współdzielonym cache. Przejdź do cytatu
• “One of my personal favorites that I don’t think it’s used enough, it’s actually just off loading your redirects to the CDN level.” (tłumaczenie) „Jednym z moich osobistych faworytów, którego moim zdaniem nie używa się wystarczająco, jest po prostu przeniesienie przekierowań na poziom CDN.” — ja, w podcaście Marketing Speak. Przejdź do cytatu

Buforowanie dla SEO — ściągawka

Dyrektywy Cache-Control — wyjaśnione

Co Googlebot faktycznie honoruje

• ✅ ETag + If-None-Match (preferowany walidator Google)
• ✅ Last-Modified + If-Modified-Since (sformatuj datę zgodnie z HTTP: Fri, 4 Sep 1998 19:15:56 GMT)
• ✅ max-age — ale tylko jako wskazówka dotycząca czasu ponownego indeksowania, a nie reguła
• ❌ Wszystko inne — „inne dyrektywy buforowania HTTP nie są obsługiwane”

Szybkie fakty

• Google preferuje ETag; jeśli oba są ustawione, ETag wygrywa. Ustaw oba mimo to (systemy CMS ich używają).
• Pasujący walidator → 304 Not Modified, bez treści → oszczędza obliczenia i przepustowość.
• Chrome/Lighthouse: buforuj niezmienne zasoby na rok lub dłużej.
• CDN-y otrzymują wyższy limit szybkości indeksowania — ale tylko gdy pamięć podręczna jest rozgrzana.
• Tymczasowa blokada? Zwróć 503/429, nigdy ciche 200 z błędem lub bot interstitial.
• no-store na dokumencie HTML może dyskwalifikować bfcache → użyj no-cache/max-age=0.
• „Pamięć podręczna Google” (operator cache:) została wycofana w 2024 — nie ma związku z buforowaniem HTTP.

Mity i błędy dotyczące buforowania

Każdy z nich: dlaczego jest błędny i co zrobić zamiast tego.

Mit: „Buforowanie mojej strony zwiększy jej pozycję w wynikach wyszukiwania.” Dlaczego to błędne: Nie ma sygnału rankingowego dla konfiguracji buforowania. Zespół Google Search Relations jasno stwierdził, że buforowanie nie jest czynnikiem rankingowym. Zrób zamiast tego: Skonfiguruj buforowanie dla realnych korzyści — szybkości strony / Core Web Vitals i wydajności indeksowania — które pośrednio wpływają na widoczność. Nie oczekuj bezpośredniego wzrostu.

Mit: „Pamięć podręczna Google i buforowanie HTTP to to samo.” Dlaczego to błędne: Operator wyszukiwania cache: i podgląd zbuforowanej strony były funkcją migawki dla użytkowników, w pełni wycofaną w 2024. Buforowanie HTTP (Cache-Control/ETag) to niezwiązana infrastruktura. Zrób zamiast tego: Zignoruj brak „zbuforowanej wersji” — nie mówi to nic o Twojej konfiguracji buforowania. Oceń swoje buforowanie na podstawie nagłówków oraz zachowania podczas indeksowania i wydajności.

Mit: „no-cache oznacza nie buforuj.” Dlaczego to błędne: no-cache oznacza „przechowuj, ale ponownie waliduj z serwerem przed użyciem.” Nadal umożliwia przepływ ponownej walidacji 304. no-store to dyrektywa, która faktycznie zapobiega przechowywaniu. Zrób zamiast tego: Użyj no-cache, gdy chcesz świeżości z ponowną walidacją; zarezerwuj no-store dla naprawdę wrażliwych odpowiedzi, które nigdy nie mogą być przechowywane.

Mit: „Długi czas buforowania sprawia, że Google widzi nieaktualną treść na zawsze.” Dlaczego to błędne: Robot Google waliduje przez ETag/Last-Modified przy ponownym indeksowaniu niezależnie od Twojego max-age; max-age to wskazówka dotycząca ponownego indeksowania, a nie blokada, która powstrzymuje Google przed ponownym pobraniem. Zrób zamiast tego: Buforuj długo, ale wywołaj prawdziwe unieważnienie pamięci podręcznej (nowy ETag/Last-Modified lub URL) przy znaczących zmianach treści — dokładnie zgodnie z zaleceniem Google.

Mit: „CDN automatycznie rozwiązuje problemy z budżetem indeksowania.” Dlaczego to błędne: CDN pomaga tylko wtedy, gdy jego pamięć podręczna jest rozgrzana; origin nadal obsługuje każdy URL co najmniej raz (problem zimnej pamięci podręcznej), a źle skonfigurowany CDN może blokować roboty i pogarszać sytuację. Zrób zamiast tego: Zaplanuj obciążenie origin przy dużych premierach/migracjach i sprawdź, czy CDN nie blokuje botów (URL Inspection, i zwracaj 503/429 dla tymczasowych blokad).

Mit: „Każda dyrektywa Cache-Control, którą ustawię, zmienia sposób indeksowania przez Googlebota.” Dlaczego to błędne: Według dokumentacji Google, poza ETag/Last-Modified (i opcjonalną wskazówką max-age), „inne dyrektywy buforowania HTTP nie są obsługiwane” przez robota. Zrób zamiast tego: Użyj stale-while-revalidate, s-maxage, no-cache itp., aby dostroić zachowanie przeglądarki i CDN — ale polegaj na ETag/Last-Modified, aby wpływać na buforowanie Googlebota.

Konfiguracje buforowania, przed i po

1. Statyczny zasób bez polityki buforowania → ostrzeżenie PageSpeed zniknęło

• Przed: style.css serwowany bez Cache-Control; Lighthouse flaguje „Serve static assets with an efficient cache policy”, powtórne wizyty pobierają go ponownie.
• Po: Zmień nazwę na style.a1b2c3.css i serwuj Cache-Control: public, max-age=31536000, immutable. Powtórne wizyty pomijają pobieranie; zmiana treści oznacza nową nazwę pliku, co natychmiast unieważnia pamięć podręczną.

2. Dokument HTML, który chciałeś „świeży” → utrata bfcache

• Przed: Cache-Control: no-store w HTML, aby wymusić świeżość. Efekt uboczny: strona jest wykluczona z bfcache, więc nawigacje „wstecz” ponownie mierzą LCP/CLS/INP i obciążają dane terenowe CrUX.
• Po: Przełącz na no-cache (lub max-age=0) — nadal przeprowadzasz rewalidację dla świeżości, ale strona pozostaje kwalifikowalna do bfcache, a powtarzane nawigacje przywracają natychmiast.

3. Współdzielona pamięć podręczna między stagingiem a produkcją → sporadyczne blokowanie Googlebota

• Przed: Środowiska testowe i produkcyjne współdzielą pamięć podręczną CDN. Gdy wersja testowa jest aktywna, buforowany robots.txt zawiera dyrektywę blokującą, więc Googlebot sporadycznie widzi disallow, którego nie powinien.
• Po: Rozdziel pamięć podręczną między środowiskami — lub wyklucz pliki .txt z pamięci podręcznej środowiska testowego — aby produkcyjny robots.txt nigdy nie był serwowany z pamięci podręcznej stagingu. (To prawdziwy przypadek, który opisałem w Indexed, though blocked by robots.txt.)

4. Duże wdrożenie za CDN → nieoczekiwany skok indeksowania

• Przed: Wdrażasz 50 000 nowych adresów URL naraz, zakładając, że CDN pochłonie obciążenie. Każdy URL to chybienie zimnej pamięci podręcznej, więc origin serwuje każdy z nich co najmniej raz, a tempo indeksowania pozostaje wysokie przez dni.
• Po: Podgrzej pamięć podręczną przed wdrożeniem (lub rozłóż wdrożenie etapami) i spodziewaj się — oraz przygotuj się na — pełne obciążenie originu dla każdego URL, zanim CDN zacznie go osłaniać.

Lista kontrolna konfiguracji buforowania HTTP

• Statyczne zasoby (obrazy, CSS, JS, czcionki) mają długi max-age (rok+ dla niezmiennych/versionowanych plików).
• Używane są wersjonowane/haszowane nazwy plików, aby można było agresywnie buforować i nadal natychmiast unieważniać.
• ETag jest ustawiony (preferowany walidator Google); Last-Modified również, z poprawnie sformatowaną datą HTTP.
• Twój serwer zwraca 304 Not Modified (bez treści), gdy walidator nadal pasuje.
• Dokumenty HTML, które wymagają świeżości, używają no-cache/max-age=0, nie no-store (chroniąc kwalifikowalność do bfcache).
• Znacząca zmiana treści wyzwala prawdziwe przełamanie pamięci podręcznej (nowy ETag/Last-Modified/URL), a nie tylko zmianę daty w stopce.
• CDN jest przed originem, z ustawionym public/s-maxage, aby współdzielone pamięci podręczne mogły przechowywać to, co powinno być współdzielone.
• Pamięć podręczna jest czyszczona przy publikacji, aby boty nigdy nie otrzymywały nieaktualnych treści.
• Staging i produkcja nie współdzielą pamięci podręcznej dla robots.txt ani innych plików kontrolnych.
• Tymczasowe blokady zwracają 503/429, a nie ciche strony 200-z-błędem lub strony pośrednie dla botów.
• URL Inspection w Search Console pokazuje Twoją prawdziwą stronę (nie wyzwanie ani pustą stronę) — potwierdzając, że CDN/WAF nie blokuje Googlebota.

Zaktualizowane pliki pozostają nieaktualne po wdrożeniu

Objaw: odwiedzający nadal otrzymują stary plik CSS, JavaScript lub obraz. Prawdopodobna przyczyna: długożyjąca pamięć podręczna używa tego samego URL dla zmienionych bajtów. Rozwiązanie: publikuj niezmienne zasoby z haszowanymi nazwami plików i zaktualizuj odniesienie w HTML; wyczyść stary obiekt brzegowy tylko wtedy, gdy sam URL został ponownie użyty. Potwierdź, że nowy URL się ładuje.

Googlebot ponownie pobiera niezmienione strony

Objaw: logi pokazują powtarzane pełne odpowiedzi 200 dla niezmienionego HTML. Prawdopodobna przyczyna: brakujące lub niestabilne walidatory ETag/Last-Modified. Rozwiązanie: emituj stabilny, poprawny treściowo walidator i przetestuj żądanie warunkowe. Działająca rewalidacja zwraca 304, gdy reprezentacja się nie zmieniła.

Różni użytkownicy otrzymują niewłaściwy wariant z pamięci podręcznej

Objaw: treści językowe, urządzeniowe, zalogowane lub spersonalizowane wyciekają między użytkownikami. Prawdopodobna przyczyna: klucz współdzielonej pamięci podręcznej nie obejmuje wymiaru, który zmienia odpowiedź, lub prywatne treści zostały oznaczone jako publiczne. Rozwiązanie: popraw klucz pamięci podręcznej i zachowanie Vary, oznacz odpowiedzi prywatne odpowiednio, wyczyść zanieczyszczone obiekty i przetestuj ponownie wiele wariantów.

Pamięć podręczna CDN nigdy nie raportuje trafienia

Objaw: powtarzające się kwalifikujące się żądania nadal docierają do origin. Prawdopodobna przyczyna: no-store/private, ciasteczka, nadmiernie rozdrobniony klucz pamięci podręcznej lub reguła obejścia na brzegu sieci. Rozwiązanie: sprawdź nagłówki odpowiedzi i status pamięci podręcznej CDN, zmień tylko reguły bezpieczne dla tej klasy treści, a następnie wyślij to samo żądanie z tym samym kluczem pamięci podręcznej dwukrotnie, aby potwierdzić trafienie.

Buforuj według ryzyka reprezentacji, nie tylko według rozszerzenia pliku

Sklasyfikuj każdą odpowiedź przed przypisaniem polityki:

1. Niezmienny zasób publiczny: CSS, JS, czcionki lub obrazy z hashem treści mogą mieć długi czas życia, ponieważ zmienione bajty otrzymują nowy URL.
2. Publiczny, ale zmieniający się dokument: HTML może być przechowywany krótko lub ponownie walidowany za pomocą ETag/Last-Modified; świeżość i szybka korekta są ważniejsze niż maksymalny TTL.
3. Odpowiedź specyficzna dla użytkownika: współdzielone buforowanie jest niebezpieczne, chyba że personalizacja jest usunięta z reprezentacji lub poprawnie rozdzielona w kluczu pamięci podręcznej.
4. Wrażliwa odpowiedź: zastosuj ścisłą politykę wymaganą przez dane, akceptując kompromis wydajnościowy zamiast ujawniania treści.

Przydatne pytanie nie brzmi: „Jak długo mogę buforować ten typ?”. Brzmi: „Co mogłoby być nie tak, gdyby ta dokładna reprezentacja została ponownie użyta dla tego żądającego po tej zmianie?”

Świeżość, poprawność, wydajność

Polityka buforowania musi przejść trzy testy: świeżość (zmiany pojawiają się zgodnie z obietnicą), poprawność (właściwy żądający otrzymuje właściwy wariant) i wydajność (niezmienione bajty nie są niepotrzebnie regenerowane ani przesyłane). Wysoki współczynnik trafień nie jest sukcesem, jeśli serwuje błędną odpowiedź.

Narzędzia do inspekcji buforowania HTTP

• Panel sieci w DevTools przeglądarki — sprawdź Cache-Control, ETag, Last-Modified, Age, Vary oraz czy odpowiedź pochodzi z pamięci, dysku czy sieci.
• curl — wyślij żądania HEAD i warunkowe bez niejednoznaczności pamięci podręcznej przeglądarki; porównaj początkowy walidator z If-None-Match lub If-Modified-Since.
• PageSpeed Insights / Lighthouse — znajdź zasoby statyczne z nieefektywnymi politykami buforowania; artykuł linkuje do oficjalnych wytycznych Lighthouse dotyczących polityki pamięci podręcznej.
• Analityka i logi CDN — sprawdź statusy trafień/pudła/obejścia, klucze pamięci podręcznej, żądania origin i przeczyszczenia na warstwie, która faktycznie serwuje publiczną odpowiedź.
• Logi serwera — zweryfikuj, czy Googlebot otrzymuje rewalidacje 304 zamiast pełnych treści dla niezmienionych stron.

Udowodnij, że zmiana buforowania działa

Test żądania warunkowego

Test do wykonania: pobierz odpowiedź, skopiuj jej ETag, a następnie wyślij żądanie z If-None-Match. Oczekiwany wynik: niezmieniona reprezentacja zwraca 304 bez ciała odpowiedzi. Interpretacja błędu: walidator jest nieobecny, niestabilny lub ignorowany. Okno monitorowania: natychmiastowe. Wyzwalacz wycofania: zmieniona treść jest błędnie odpowiadana kodem 304 lub walidator koliduje między wariantami.

Test zasobu z wersjonowaniem

Test do wykonania: wdróż zmienione bajty pod nowym URL-em z hashem treści i przeładuj stronę, która go odwołuje. Oczekiwany wynik: nowy URL zwraca nowy zasób, podczas gdy stary URL może pozostać w pamięci podręcznej. Interpretacja błędu: HTML nadal odwołuje się do starego zasobu lub build nie zmienił hasha. Okno monitorowania: natychmiastowe po propagacji HTML/CDN. Wyzwalacz wycofania: zepsute style lub błędy skryptów na nowym zasobie.

Test wariantów współdzielonej pamięci podręcznej

Test do wykonania: wyślij żądanie każdego znaczącego wariantu przez CDN, powtórz każdy, a następnie porównaj treść, klucz/status pamięci podręcznej i Vary. Oczekiwany wynik: każdy żądający otrzymuje poprawną reprezentację i tylko bezpieczne warianty są ponownie używane. Interpretacja błędu: w kluczu pamięci podręcznej brakuje wymiaru lub prywatna treść jest współdzielona. Okno monitorowania: natychmiastowe plus przegląd logów produkcyjnych. Wyzwalacz wycofania: jeden użytkownik otrzymuje spersonalizowaną lub językowo specyficzną odpowiedź innego użytkownika.

Sprawdź się: Buforowanie dla SEO

Pięć szybkich pytań o buforowanie HTTP, CDN i indeksowanie. Wybierz odpowiedź na każde, a następnie sprawdź.

Dziennik zmian