Uppdatera en cachad offentlig sida genom att publicera det uppdaterade dokumentet, rensa eventuell delad cache som levererar det och verifiera resultatet i webbläsaren på din Mac. Om Google fortfarande visar gammalt innehåll begär du en ny genomsökning separat. Att uppdatera webbläsaren uppdaterar inte Googles index.

Den här guiden är avsedd för den som underhåller ett offentligt dokument och behöver se till att läsarna får det reviderade innehållet på den befintliga webbadressen. Stegen på datorn använder Chrome på macOS. En fiktiv ”Guide till pappersformer”, som ändras från ”Version A: cirklar” till ”Version B: cirklar och kvadrater”, gör det enkelt att skilja versionerna åt under hela arbetsflödet.

Varför uppdateras inte alla cachade sidor när källan redigeras?

HTTP-invalidering tar bort ett lagrat svar eller gör validering obligatorisk innan det kan återanvändas. RFC 9111 kräver att en cache invaliderar mål-URI:n efter en lyckad tillståndsändrande begäran som passerar genom cachen, men anger uttryckligen att detta inte invaliderar kopior globalt. Ett publiceringsarbetsflöde behöver därför ta hänsyn till cachar utanför redigeringsbegärans väg. RFC 9111: Invalidating Stored Responses.

För Guiden till pappersformer gör du en kort checklista över vilka resultat som påverkas av redigeringen. Om den reviderade texten också visas på en samlingssida tar du med den sidan. Om bara guiden ändras begränsar du checklistan till det dokumentet. Den här beroendechecklistan är ett redaktionellt hjälpmedel: börja med den ändrade källan och identifiera varje publicerat dokument som nu bör visa något annat.

Följ stegen nedan för att välja nästa åtgärd. Se varje resultat som en diagnostisk ledtråd, inte som ett bevis på att alla läsare får samma svar.

Det du ser Vad du bör kontrollera härnäst
Publiceringssystemet visar fortfarande version A i det publicerade resultatet Bekräfta att version B har publicerats eller byggts om korrekt.
Det publicerade resultatet är version B, men en omladdning av nätverksbegäran i webbläsaren ger version A Undersök den delade cachen eller dokumentet som värden levererar.
En omladdning av nätverksbegäran visar version B, medan en vanlig omladdning visar version A Undersök lokal webbläsarcache och svarets cachepolicy.
Den offentliga sidan visar version B, men Googles indexerade information är fortfarande gammal Använd live-testet i Search Console och överväg sedan att begära indexering.

Google beskriver skillnaden bakom den sista raden: den första rapporten i URL-inspektionen beskriver den indexerade versionen, medan live-testet hämtar den aktuella sidan. En gammal indexerad rapport kan därför finnas samtidigt som det offentliga dokumentet har korrigerats. URL Inspection tool.

Publicera det ändrade dokumentet innan du rensar dess cache

Börja med att anteckna den exakta offentliga webbadressen och den förväntade ändringen. I det här fiktiva exemplet är den förväntade meningen ”Version B: cirklar och kvadrater.” Använd en särskiljande mening som redan passar i dokumentet. Syftet är att känna igen det nya resultatet utan att förlita sig på hur nyligen en flik öppnades.

Publicera redigeringen med ditt befintliga publiceringssystem. Om systemet bygger dokument från källfiler bekräftar du att det publicerade resultatet innehåller den reviderade meningen. Att spara källinnehållet och skapa det offentliga dokumentet är två separata kontrollpunkter i det här arbetsflödet. Följ plattformens dokumenterade publiceringsförfarande.

Ogiltigförklara sedan den delade cachen, om en sådan finns. Ordningen spelar roll: Cloudflare dokumenterar till exempel att begäranden efter en rensning hämtar resursen från ursprunget och lägger tillbaka den i CDN-cachen. Om du rensar medan ursprunget fortfarande levererar det gamla dokumentet kan cachen fyllas på med den gamla versionen. Purge by single-file.

Ett dokumenterat exempel på Cloudflares kontrollpanel

Om din offentliga sida använder Cloudflare-cachning ger deras dokumenterade rensning av en enskild fil en konkret webbläsarbaserad väg:

  1. Öppna Cloudflare-kontrollpanelen för den aktuella webbplatsen och gå till Configuration.
  2. Välj Custom Purge under Purge Cache.
  3. Välj URL under Purge by.
  4. Ange den exakta offentliga webbadressen för varje berört dokument.
  5. Granska posterna och välj Purge.

Etiketterna och stegen kommer från Cloudflares single-file purge instructions.

Kontrollera de dokumenterade begränsningarna innan du upprepar en rensning. Om du rensar en omdirigering tas omdirigeringssvaret bort, så rensa målets webbadress för att uppdatera dess innehåll. Vissa anpassade cache-nycklar kan inte rensas via kontrollpanelens URL-formulär; Cloudflare dokumenterar rensning med prefix eller taggar som alternativ. Rensning av en enskild fil godtar inte heller jokertecken. Purge limitations and alternatives.

Om du använder en annan värd eller ett annat CDN använder du leverantörens dokumenterade kontroll för invalidering. Cloudflare-förfarandet är ett villkorat exempel, inte ett universellt gränssnitt. Om din publiceringstjänst saknar en rensningsfunktion kontrollerar du dess dokumenterade cachelivslängd och uppdateringsbeteende i stället för att hitta på en rensningsadress eller anta att en knapp i webbläsaren styr tjänstens servrar.

Verifiera det offentliga svaret på din Mac

Öppna sidans befintliga offentliga webbadress i Chrome. Tryck på Command–Option–I för att öppna DevTools och välj sedan Network. Chrome dokumenterar den här Mac-genvägen och skiljer mellan vanliga omladdningar, hårda omladdningar och omladdningar som tömmer cachen. Open Chrome DevTools.

Med DevTools öppet väljer du Disable cache i panelen Network och laddar om sidan. Chrome dokumenterar att den här inställningen gör att vanliga omladdningar inte använder cachen. Låt DevTools vara öppet under kontrollen. Reload with or without cache.

Välj huvudbegäran för dokumentet i nätverkslistan. Öppna Headers för att granska svarsrubrikerna och Response för att undersöka det returnerade innehållet. Leta efter den förväntade meningen från version B i dokumentet. Chromes nätverkshandledning förklarar hur du granskar enskilda begäranden, rubriker och svarsinnehåll. Inspect network activity.

Anteckna tre observationer: den begärda webbadressen, om det returnerade dokumentet innehåller version B och vilka cacherubriker som följde med svaret. Det ger dig en användbar jämförelse efter rensningen. En lyckad åtgärd i kontrollpanelen är en kontrollpunkt; att få det avsedda dokumentet är kontrollpunkten som uppfyller läsarens omedelbara behov.

Stäng sedan av Disable cache och ladda om igen. Jämför resultatet med nätverkstestet. Om resultaten skiljer sig åt sparar du båda observationerna när du granskar svarspolicyn. Om du upprepade gånger rensar webbläsaren utan att anteckna skillnaden blir det svårare att hitta orsaken.

WHATWG Fetch Standard förklarar varför webbläsarens hämtningslägen spelar roll. Läget reload kringgår webbläsarens HTTP-cache på vägen till nätverket och uppdaterar den cachen med svaret. Läget no-cache gör en villkorlig begäran när det finns ett cachat svar. Det här är beteenden för begäranden, så inget av dem utgör en global rensning av delade cachade sidor. Fetch Standard: request cache modes.

Välj en cachepolicy som passar framtida redigeringar

För ett offentligt dokument som bör kontrolleras före varje återanvändning kan du överväga svarsdirektivet Cache-Control: no-cache. Det tillåter lagring men kräver lyckad validering före återanvändning. Cache-Control: no-store förbjuder lagring. En svars max-age anger dess färskhetsperiod; must-revalidate gäller när svaret blivit inaktuellt. Dessa direktiv uppfyller olika krav. RFC 9111: Response Cache-Control Directives.

Som ett illustrativt beslutsunderlag kan du tänka dig att Guiden till pappersformer ändras ibland och att det är acceptabelt att kontrollera om den har uppdaterats vid varje besök. Validering är en rimlig policy att diskutera med den som konfigurerar värden. Om du föredrar återanvändning utan en nätverkskontroll väljer du en färskhetsperiod som stämmer med hur länge en gammal version kan godtas och behåller ett dokumenterat rensningsförfarande för tidigare uppdateringar.

Att ändra policyn i ett nyligen publicerat svar kan inte meddela en webbläsare som fortfarande återanvänder ett äldre färskt svar utan att kontakta servern. Befintliga cachade kopior är därför fortfarande en del av övergången. Detta följer av HTTP:s regler för färskhet och återanvändning och är anledningen till att en ny rubrikinställning bör kompletteras med en tydlig plan för befintliga kopior. RFC 9111: Constructing Responses from Caches.

Se till att valideringen känner igen versionen

En ETag identifierar en representation för validering. Last-Modified anger dess ändringstid. Se till att servern skapar validerare som återspeglar den publicerade representationen, även relevanta ändringar av innehåll som sammanställts från andra källor. RFC 9110 beskriver båda validerarna och förklarar att entitetstaggar i vissa fall kan skilja representationer åt mer tillförlitligt än ändringsdatum. RFC 9110: Validator Fields.

Ett svar med statuskoden 304 Not Modified talar om för mottagaren att återanvända en giltig lagrad representation i stället för att överföra dokumentet igen. Det är normalt när den lagrade versionen fortfarande är aktuell. Om du får det resultatet men fortfarande ser version A efter en bekräftad innehållsändring undersöker du vilken representation och validerare servern utvärderade. RFC 9110: 304 Not Modified.

Be Google att besöka den korrigerade sidan igen

När det offentliga dokumentet konsekvent levererar version B granskar du dess fullständiga webbadress i rätt egendom i Search Console. Välj Test live URL för att undersöka den aktuella sidan. Jämför resultatet med den indexerade rapporten, som kan beskriva en tidigare genomsökning. Live-testet kontrollerar den aktuella sidan; det bekräftar inte i sig att Googles index har uppdaterats. URL Inspection tool.

Om du har uppdaterat en enskild sida väljer du Request indexing i inspektionsresultatet. Du måste vara ägare eller fullständig användare av Search Console-egendomen. Google anger att genomsökning kan ta från några dagar till några veckor, att upprepade begäranden inte påskyndar den och att en begäran om genomsökning inte garanterar att sidan inkluderas i sökresultaten. Ask Google to recrawl your URLs.

För många uppdaterade sidor rekommenderar Google att skicka in en webbplatskarta. Se till att dess <lastmod>-värden är korrekta: Google säger att de bör återspegla betydande ändringar, till exempel uppdateringar av huvudinnehållet, snarare än rutinmässiga ändringar av upphovsrättsdatumet. En webbplatskarta hjälper till att kommunicera ändrade dokument; den rensar inte kopior i webbläsare eller CDN. Build and Submit a Sitemap.

Avsluta med en kort publiceringslogg: de berörda webbadresserna, den förväntade versionsmeningen, kontrollen av det publicerade resultatet, åtgärden för den delade cachen och resultatet av webbläsarverifieringen. Följ upp eventuella begäranden om ny genomsökning från Google separat. Då kan du se om det omedelbara målet – att leverera det reviderade offentliga dokumentet – har uppnåtts, samtidigt som nästa steg är tydligt när en äldre version fortfarande visas.

Källor