Aby odświeżyć buforowaną stronę publiczną, opublikuj zaktualizowany dokument, wyczyść wszelki wspólny bufor, który go serwuje, i zweryfikuj wynik w przeglądarce na Macu. Jeśli Google nadal wyświetla starą treść, zażądaj ponownego indeksowania osobno; odświeżenie przeglądarki nie aktualizuje indeksu Google.

Ten przewodnik jest dla osoby zarządzającej publicznym dokumentem, która potrzebuje, aby czytelnicy otrzymywali jego zrewidowaną treść pod istniejącym adresem URL. Kroki dla komputerów stacjonarnych używają Chrome na macOS. Syntetyczny „Przewodnik po Kształtach Papierowych”, zmieniający się z „Rewizja A: koła” na „Rewizja B: koła i kwadraty”, zapewnia prosty sposób na rozróżnianie wersji w całym przepływie pracy.

Dlaczego edycja źródła nie odświeża każdej buforowanej strony?

Unieważnienie HTTP usuwa zapisaną odpowiedź lub sprawia, że walidacja staje się obowiązkowa przed ponownym użyciem. RFC 9111 wymaga, aby bufor unieważnił docelowy URI po udanym żądaniu zmieniającym stan przechodzącym przez ten bufor, ale jawnie stwierdza, że nie unieważnia to kopii globalnie. Przepływ pracy publikacji musi więc uwzględniać bufory poza ścieżką żądania edycji. RFC 9111: Invalidating Stored Responses.

Dla Przewodnika po Kształtach Papierowych stwórz krótką listę kontrolną wyjść objętych edycją. Jeśli zrewidowany tekst pojawia się też na stronie kolekcji, dołącz tę stronę. Jeśli zmienia się tylko przewodnik, ogranicz listę do tego dokumentu. Ta lista zależności jest pomocą redakcyjną: zacznij od zmienionego źródła i zidentyfikuj każdy opublikowany dokument, który powinien teraz pokazywać co innego.

Użyj poniższej sekwencji, aby wybrać następną czynność. Traktuj każdy wynik jako wskazówkę diagnostyczną, a nie dowód na to, że każdy czytelnik otrzymuje tę samą odpowiedź.

Co obserwujesz Co sprawdzić dalej
System publikacji wciąż pokazuje Rewizję A we swoim wydaniu Potwierdź, że Rewizja B została opublikowana lub przebudowana pomyślnie.
Wydanie to Rewizja B, ale ponowne ładowanie sieciowe w przeglądarce otrzymuje Rewizję A Zbadaj wspólny bufor lub dokument serwowany przez hosta.
Ponowne ładowanie sieciowe pokazuje Rewizję B, a zwykłe ponowne ładowanie pokazuje Rewizję A Zbadaj lokalne buforowanie przeglądarki i politykę buforowania odpowiedzi.
Strona publiczna pokazuje Rewizję B, ale zindeksowane informacje Google pozostają stare Użyj testu na żywo w Search Console, a następnie rozważ zgłoszenie do indeksowania.

Google udokumentowało rozróżnienie za ostatnim wierszem: początkowy raport Inspekcji URL opisuje zindeksowaną wersję, podczas gdy jego test na żywo pobiera aktualną stronę. Stary raport zindeksowany może więc współistnieć z skorygowanym dokumentem publicznym. Narzędzie Inspekcji URL.

Opublikuj zmieniony dokument przed wyczyszczeniem jego bufora

Najpierw zanotuj dokładny publiczny URL i oczekiwaną zmianę. Dla tego przykładu syntetycznego oczekiwanym zdaniem jest „Rewizja B: koła i kwadraty”. Użyj charakterystycznego zdania już odpowiedniego dla dokumentu; celem jest rozpoznanie nowego wydania bez polega na tym, jak niedawno otwarto kartę.

Opublikuj edycję przez swój istniejący system publikacji. Jeśli ten system buduje dokumenty z plików źródłowych, potwierdź, że jego wydanie zawiera zrewidowane zdanie. Zapisanie treści źródłowej i wytworzenie dokumentu publicznego to osobne punkty kontrolne w tym przepływie; postępuj zgodnie z udokumentowaną procedurą publikacji swojej platformy.

Następnie unieważnij wspólny bufor, jeśli jest obecny. Kolejność ma znaczenie: Cloudflare na przykład udokumentowuje, że żądania po wyczyszczeniu pobierają zasób z pochodzenia i dodają go z powrotem do bufora CDN. Wyczyszczenie, gdy pochodzenie wciąż serwuje stary dokument, może ponownie napełnić bufor tym starym dokumentem. Wyczyszczenie pojedynczego pliku.

Udokumentowany przykład panelu dla Cloudflare

Jeśli Twoja strona publiczna używa buforowania Cloudflare, jego udokumentowane wyczyszczenie pojedynczego pliku zapewnia konkretną ścieżkę opartą na przeglądarce:

  1. Otwórz panel Cloudflare odpowiedniej witryny i przejdź do Configuration.
  2. W obszarze Purge Cache wybierz Custom Purge.
  3. W polu Purge by wybierz URL.
  4. Wprowadź dokładny publiczny URL każdego objętego dokumentu.
  5. Przejrzyj wpisy i wybierz Purge.

Te etykiety i kroki pochodzą z instrukcji wyczyszczenia pojedynczego pliku Cloudflare.

Sprawdź udokumentowane granice przed powtórzeniem wyczyszczenia. Wyczyszczenie przekierowania czyści odpowiedź przekierowania, więc wyczyść URL celu, aby odświeżyć jego treść. Niektóre niestandardowe klucze bufora nie mogą zostać wyczyszczone przez formularz panelu URL; Cloudflare dokumentuje wyczyszczanie prefiksów lub tagów wśród alternatyw. Wyczyszczenie pojedynczego pliku również nie akceptuje symboli wieloznacznych. Ograniczenia i alternatywy wyczyszczenia.

Jeśli używasz innego hosta lub CDN, użyj udokumentowanej kontroli unieważnienia tego dostawcy. Procedura Cloudflare jest przykładem warunkowym, a nie uniwersalnym interfejsem. Jeśli Twoja usługa publikacji nie udostępnia operacji wyczyszczenia, sprawdź jej udokumentowany czas życia bufora i zachowanie odświeżania, zamiast wymyślać URL wyczyszczenia lub zakładać, że przycisk przeglądarki kontroluje jego serwery.

Zweryfikuj publiczną odpowiedź na swoim Macu

Otwórz istniejący publiczny URL strony w Chrome. Naciśnij Command–Option–I, aby otworzyć Narzędzia deweloperskie, a następnie wybierz Network. Chrome udokumentowuje ten skrót na Maca i rozróżnia normalne ponowne ładowanie, twarde ponowne ładowanie i ponowne ładowanie z opróżnieniem pamięci podręcznej. Otwórz Narzędzia deweloperskie Chrome.

Z otwartymi Narzędziami deweloperskimi wybierz Disable cache w panelu Network i ponownie załaduj stronę. Chrome udokumentowuje, że to ustawienie sprawia, że normalne ponowne ładowania omijają jego pamięć podręczną. Trzymaj Narzędzia deweloperskie otwarte podczas sprawdzania. Ponowne ładowanie z pamięcią podręczną lub bez niej.

Wybierz główne żądanie dokumentu na liście sieci. Otwórz Headers, aby zbadać nagłówki odpowiedzi, i Response, aby przejrzeć zwróconą treść. Szukaj oczekiwanego zdania Rewizji B w tym dokumencie. Samouczek sieciowy Chrome wyjaśnia, jak inspektować poszczególne żądania, nagłówki i treść odpowiedzi. Inspekcja aktywności sieciowej.

Zanotuj trzy obserwacje: żądany URL, czy zwrócony dokument zawiera Rewizję B, i nagłówki buforowania dostarczone z nim. To daje Ci użyteczne porównanie po wyczyszczeniu. Pomyślna operacja panelu to jeden punkt kontrolny; otrzymanie zamierzonego dokumentu to punkt kontrolny, który odpowiada na natychmiastowe zadanie czytelnika.

Następnie wyłącz Disable cache i załaduj ponownie. Porównaj wynik z testem sieciowym. Jeśli oba się nie zgadzają, zachowaj obie obserwacje przy przeglądzie polityki odpowiedzi. Wielokrotne czyszczenie przeglądarki bez rejestrowania różnicy utrudnia identyfikację przyczyny.

Standard WHATWG Fetch wyjaśnia, dlaczego tryby pobierania przeglądarki mają znaczenie. Jego tryb reload omija pamięć podręczną HTTP przeglądarki w drodze do sieci i aktualizuje tę pamięć podręczną z odpowiedzi. Jego tryb no-cache wykonuje żądanie warunkowe, gdy istnieje buforowana odpowiedź. To są zachowania żądań, więc żaden z nich nie stanowi globalnego wyczyszczenia współdzielonych buforowanych stron. Fetch Standard: request cache modes.

Wybierz politykę buforowania pasującą do przyszłych edycji

Dla dokumentu publicznego, który powinien być sprawdzany przed każdym ponownym użyciem, rozważ dyrektywę odpowiedzi Cache-Control: no-cache. Pozwala ona na przechowywanie, ale wymaga pomyślnej walidacji przed ponownym użyciem. Cache-Control: no-store zabrania przechowywania. max-age odpowiedzi określa jej czas życia świeżości; must-revalidate dotyczy po tym, jak stanie się nieświeża. Te dyrektywy adresują różne wymagania. RFC 9111: Response Cache-Control Directives.

Jako ilustracyjna decyzja, załóżmy, że Przewodnik po Kształtach Papierowych zmienia się okazjonalnie i sprawdzanie aktualizacji przy każdej wizycie jest akceptowalne. Rewalidacja jest rozsądną polityką do dyskusji z osobą konfigurującą hosta. Jeśli preferowane jest ponowne użycie bez sprawdzania sieciowego, wybierz czas życia świeżości zgodny z tym, jak długo stara rewizja może pozostać akceptowalna, i zachowaj udokumentowaną procedurę wyczyszczenia dla wcześniejszych aktualizacji.

Zmiana polityki na nowo opublikowanej odpowiedzi nie może powiadomić przeglądarki, która wciąż ponawia użycie starszej świeżej odpowiedzi bez kontaktowania się z serwerem. Istniejące kopie buforowane pozostają więc częścią przejścia. Wynika to z reguł świeżości i ponownego użycia HTTP; dlatego nowy ustawienie nagłówka powinno towarzyszyć jawnego planowi dla istniejących kopii. RFC 9111: Constructing Responses from Caches.

Upewnij się, że walidacja rozpoznaje rewizję

ETag identyfikuje reprezentację do walidacji. Last-Modified dostarcza czas jej modyfikacji. Niech serwer generuje walidatory odzwierciedlające opublikowaną reprezentację, w tym istotne zmiany w treści złożonej z innych źródeł. RFC 9110 opisuje oba walidatory i wyjaśnia, że tagi encji mogą odróżniać reprezentacje niezawodniej niż daty modyfikacji w niektórych okolicznościach. RFC 9110: Validator Fields.

Odpowiedź 304 Not Modified mówi odbiorcy, by ponownie użyła poprawnej zapisanej reprezentacji zamiast ponownie przesyłać dokument. Jest to normalne, gdy zapisana rewizja pozostaje aktualna. Jeśli otrzymasz ten wynik, wciąż widząc Rewizję A po potwierdzonej zmianie treści, zbadaj, którą reprezentację i walidator ocenił serwer. RFC 9110: 304 Not Modified.

Poproś Google o ponowne odwiedzenie skorygowanej strony

Gdy dokument publiczny spójnie serwuje Rewizję B, zbadaj jego pełny URL we właściwej własności Search Console. Wybierz Test live URL, aby zbadać aktualną stronę. Porównaj ten wynik z raportem zindeksowanym, który może opisywać wcześniejsze skanowanie. Test na żywo sprawdza aktualną stronę; nie ustanawia on sam, że indeks Google został zaktualizowany. Narzędzie Inspekcji URL.

Dla indywidualnie zaktualizowanej strony wybierz Request indexing w jej wyniku inspekcji. Musisz być właścicielem lub pełnym użytkownikiem własności Search Console. Google mówi, że skanowanie może potrwać od kilku dni do kilku tygodni, powtarzalne żądania nie przyspieszają tego, a żądanie skanowania nie gwarantuje uwzględnienia w wynikach wyszukiwania. Poproś Google o ponowne skanowanie Twoich URL-i.

Dla wielu zaktualizowanych stron Google zaleca przesłanie mapy witryny. Utrzymaj jej wartości <lastmod> dokładne: Google mówi, że powinny one odzwierciedlać znaczące zmiany, takie jak aktualizacje treści głównej, a nie rutynowe zmiany daty praw autorskich. Mapa witryny pomaga komunikować zmienione dokumenty; nie czyści kopii przeglądarki ani CDN. Tworzenie i przesyłanie mapy witryny.

Zakończ małym zapisem publikacji: objęte URL-e, oczekiwane zdanie rewizji, sprawdzenie wydania, działanie na współdzielonym buforze i wynik weryfikacji przeglądarki. Śledź każde żądanie ponownego skanowania Google oddzielnie. To utrzymuje bezpośredni cel — serwowanie zrewidowanego dokumentu publicznego — obserwowalnym, pozostawiając jasny następny krok tam, gdzie starsza wersja wciąż pojawia się.

Źródła