Cache w reverse proxy a SEO: roboty bez nieaktualnych stron

Roboty widzą nieaktualne strony, gdy proxy wciąż wydaje zapisane kopie i nigdy nie sprawdza ich z serwerem źródłowym. Poprawne SEO przy cache w reverse proxy to krótki TTL dla HTML, nietknięte nagłówki ETag i Last-Modified oraz prawidłowa obsługa odpowiedzi 304. Google wciąż pokazuje stare tytuły? Nieaktualne canonicale albo przekierowania, które usunąłeś kilka tygodni temu? A może roboty jeszcze długo dostawały z cache błąd 404 lub 5xx, choć serwer źródłowy dawno działał? Wtedy winne jest prawie zawsze któreś z poniższych ustawień. Zanim zaczniesz je poprawiać, sprawdź też, czy ruch w ogóle trafia do proxy, czyli czy rekordy DNS kierują domenę na właściwy serwer. Z cache warto też wyłączyć ścieżkę /.well-known/acme-challenge/, bo przez nią przechodzi wydawanie certyfikatów Let’s Encrypt.

Jak to się dzieje, że reverse proxy podaje Googlebotowi nieaktualne treści?

Proxy zwraca zapisaną odpowiedź, dopóki nie minie jej własny TTL, bez względu na to, co w tym czasie zmieniło się na serwerze źródłowym. Zwykle przyczyną jest ustawienie, które przy wdrażaniu wyglądało niewinnie:

• długi proxy_cache_valid obejmujący każdy kod statusu, a nie tylko 200
• proxy_ignore_headers Cache-Control Expires, które wyrzuca do kosza zasady świeżości ustalone przez serwer źródłowy
• proxy_cache_use_stale włączone dla wszystkich błędów, bez limitu czasu
• klucz cache bez hosta lub schematu, przez co jedna witryna (albo protokół) dostaje stronę innej

Najgorzej jest z błędami. Dwuminutowa awaria może zamienić się w zapisany w cache błąd 5xx, na który boty trafiają godzinami. Chcesz to potwierdzić? Porównaj to, co zwraca serwer źródłowy, z tym, co faktycznie dostały boty, i zacznij od problemów z crawlowaniem w logach.

Jakie nagłówki Cache-Control powinny wysyłać strony HTML?

HTML potrzebuje krótkiego max-age, dopasowanego do tego, jak często strona naprawdę się zmienia. Zasoby statyczne mogą długo leżeć w cache. CSS, JavaScript i obrazki z wersją w nazwie pliku bezpiecznie znoszą długi czas życia, bo nowe wydanie i tak oznacza nowy URL. Ze stronami jest inaczej. Ten sam URL, inna treść.

Google radzi używać max-age, żeby powiedzieć robotom, kiedy wrócić, i ustawić go na liczbę sekund, przez które treść ma się nie zmieniać. W wpisie o tym, jak roboty Google korzystają z cache jako przykład podano Cache-Control: max-age=94043. Najwięcej robią tu trzy dyrektywy. s-maxage dotyczy tylko współdzielonych cache, takich jak Twoje proxy. max-age obejmuje przeglądarki i roboty. A no-cache? Wbrew nazwie pozwala zapisać kopię - trzeba ją tylko zweryfikować przed każdym użyciem.

ETag i Last-Modified, czyli 304 zamiast starej kopii dla robotów

Walidatory pozwalają robotowi zapytać „czy coś się zmieniło?”, a jeśli nie, serwer odpowiada 304 Not Modified bez treści. Według wskazówek Google Search Central o cache Googlebot wysyła zapisany ETag w nagłówku If-None-Match, a pasująca wartość powinna dostać 304 bez treści HTTP. Jeśli jeden URL serwuje kilka wersji, na przykład mobilną i desktopową, każda potrzebuje własnego ETagu. Last-Modified z If-Modified-Since działa tak samo.

Właśnie tu proxy najczęściej coś psują. Kompresja gzip w locie albo przepisywanie HTML potrafią usunąć ETag, osłabić go albo zostawić jeden tag dla dwóch różnych reprezentacji. Niedobrze. Standard cache w HTTP pozwala cache połączyć tagi klienta z własnymi przy rewalidacji. Jeśli więc serwer źródłowy odpowie 304 z tagiem, którego klient nigdy nie wysłał, cache musi zbudować pełną odpowiedź 200 z zapisanej kopii. To poprawna rewalidacja (i właśnie ona powstrzymuje proxy przed wysłaniem ślepego 304 dla treści, której klient nigdy nie miał).

Bezpieczna konfiguracja proxy_cache w nginx dla stron indeksowanych przez roboty

Trzymaj HTML w cache krótko, rewaliduj zamiast pobierać od nowa i nigdy nie przechowuj długo odpowiedzi z błędami. Podstawowe dyrektywy:

1. proxy_cache_key $scheme$host$request_uri; rozdziela protokoły i nazwy hostów.
2. proxy_cache_valid ustawiony osobno dla każdego statusu: krótko dla 200, bardzo krótko albo wcale dla 404 i 5xx.
3. proxy_cache_revalidate on; odświeża wygasłe wpisy żądaniami warunkowymi.
4. proxy_cache_use_stale updating error timeout; obejmuje tylko te przypadki, z czasem życia wybranym świadomie.
5. proxy_cache_background_update on; odświeża wpisy tak, że odwiedzający nie musi czekać.
6. proxy_cache_lock on; wysyła do serwera źródłowego tylko jedno żądanie dla brakującego klucza.

Nie włączaj proxy_ignore_headers dla HTML, chyba że serwer źródłowy wysyła kompletnie bezsensowne nagłówki. Dodaj add_header X-Cache-Status $upstream_cache_status; i zapisuj tę wartość w logach, żeby przy każdym żądaniu bota było widać HIT, MISS albo STALE. W praktyce to jedno pole w logu oszczędza sporo zgadywania. Wszystko to ustawiasz zresztą na własnym serwerze źródłowym albo w NGINX. Zarządzane proxy NGINX może kierować ruch Twoich domen i IP, ale reguły cache ustalasz sam.

Czyszczenie i unieważnianie cache po zmianie treści

Kliknięcie „Opublikuj” powinno od razu czyścić zmienione URL-e, a nie czekać, aż minie TTL. Masz kilka możliwości: proxy_cache_purge przez moduł zewnętrzny albo NGINX Plus, segment wersji w kluczu cache, usunięcie pliku cache dla danego klucza oraz krótki TTL jako zabezpieczenie. Czyść powiązane strony razem - artykuł, jego listingi i strony kategorii, mapę witryny i feed. Zmiana statusu też wymaga natychmiastowego czyszczenia. Strona zamieniła się w 404 albo 410? Dostała nowe 301? Roboty będą widzieć stary status, dopóki ten wpis nie zniknie z cache.

Nie różnicuj cache pod boty: roboty i użytkownicy mają widzieć to samo

Osobna wersja z cache dla Googlebota, wybierana po user agencie albo IP, ociera się o cloaking, więc roboty powinny korzystać z tego samego cache co odwiedzający. Różnicuj tylko po tym, co naprawdę zmienia reprezentację, czyli Accept-Encoding i ewentualnie język. Nigdy po User-Agent. Zalogowane sesje i ciasteczka personalizacji dostają własne reguły omijania cache, żeby prywatne strony nigdy nie trafiły do współdzielonego cache. Więcej o ryzyku w naszym poradniku o unikaniu cloakingu w SEO.

Jak sprawdzić, czy roboty dostają świeże strony

Testuj z zewnątrz żądaniami warunkowymi, a od środka przez logi:

• Uruchom curl -I dwa razy i porównaj X-Cache-Status w obu odpowiedziach.
• Wyślij If-None-Match albo If-Modified-Since i oczekuj 304 z pustą treścią.
• Zmień stronę i sprawdź, czy wraca teraz jako 200 z nowym ETagiem.
• Odfiltruj w logach dostępu Googlebota i pogrupuj żądania według statusu cache i kodu odpowiedzi.
• Użyj Sprawdzania adresu URL w Search Console, żeby zobaczyć pobranie na żywo.

Dobre SEO przy cache w reverse proxy sprowadza się do czterech nawyków: krótki TTL dla HTML, nienaruszone walidatory, błędy poza cache i czyszczenie przy każdej publikacji. I tyle. Powiązane poradniki znajdziesz w naszej kategorii technicznego SEO.

FAQ