Werk een gecachte openbare pagina bij door het bijgewerkte document te publiceren, gedeelde caches die de pagina leveren te wissen en het resultaat te controleren in je browser op de Mac. Als Google nog oude inhoud toont, vraag dan afzonderlijk om een nieuwe crawl; je browser vernieuwen werkt de index van Google niet bij.

Deze gids is bedoeld voor iemand die een openbaar document beheert en wil dat lezers de herziene inhoud op de bestaande URL te zien krijgen. De desktopstappen gebruiken Chrome op macOS. Een synthetische ‘Handleiding voor papieren vormen’, die verandert van ‘Revisie A: cirkels’ in ‘Revisie B: cirkels en vierkanten’, biedt een eenvoudige manier om de versies tijdens de hele workflow van elkaar te onderscheiden.

Waarom wordt niet elke gecachte pagina bijgewerkt als ik de bron bewerk?

HTTP-invalidering verwijdert een opgeslagen reactie of maakt validatie verplicht voordat die opnieuw wordt gebruikt. RFC 9111 vereist dat een cache de doel-URI ongeldig maakt nadat een geslaagd verzoek dat de status wijzigt via die cache is gegaan, maar vermeldt uitdrukkelijk dat dit kopieën niet wereldwijd ongeldig maakt. Daarom moet een publicatieworkflow rekening houden met caches die niet op het pad van het bewerkingsverzoek liggen. RFC 9111: Stored responses ongeldig maken.

Maak voor de Handleiding voor papieren vormen een korte checklist van de uitvoer die door de bewerking is beïnvloed. Als de herziene tekst ook op een verzamelpagina staat, neem die pagina dan op. Als alleen de handleiding verandert, beperk de checklist dan tot dat document. Deze afhankelijkheidschecklist is een redactioneel hulpmiddel: begin bij de gewijzigde bron en bepaal welke gepubliceerde documenten nu iets anders moeten tonen.

Gebruik de volgende reeks om je volgende actie te bepalen. Beschouw elk resultaat als een diagnostische aanwijzing, niet als bewijs dat iedere lezer dezelfde reactie krijgt.

Wat je ziet Wat je daarna controleert
Het publicatiesysteem toont nog Revisie A in de gepubliceerde uitvoer Controleer of Revisie B is gepubliceerd of opnieuw is opgebouwd.
De gepubliceerde uitvoer is Revisie B, maar een herladen pagina via het netwerkverzoek ontvangt Revisie A Onderzoek de gedeelde cache of het document dat door de host wordt aangeboden.
Een herladen pagina via het netwerkverzoek toont Revisie B, maar een gewone herlaadactie toont Revisie A Onderzoek de lokale browsercache en het cachebeleid van de reactie.
De openbare pagina toont Revisie B, maar de geïndexeerde informatie van Google is nog oud Gebruik de live test van Search Console en overweeg daarna een indexeringsverzoek.

Google licht het onderscheid achter de laatste rij toe: het eerste rapport van URL-inspectie beschrijft de geïndexeerde versie, terwijl de live test de huidige pagina ophaalt. Een oud geïndexeerd rapport kan dus samengaan met een gecorrigeerd openbaar document. Tool URL-inspectie.

Publiceer het gewijzigde document voordat je de cache wist

Noteer eerst de exacte openbare URL en de verwachte wijziging. In dit synthetische voorbeeld is de verwachte zin ‘Revisie B: cirkels en vierkanten.’ Gebruik een onderscheidende zin die al bij het document past; zo herken je de nieuwe uitvoer zonder af te gaan op hoe lang geleden een tabblad is geopend.

Publiceer de bewerking via je bestaande publicatiesysteem. Als dat systeem documenten opbouwt op basis van bronbestanden, controleer dan of de gepubliceerde uitvoer de herziene zin bevat. Broninhoud opslaan en het openbare document opleveren zijn afzonderlijke controlepunten in deze workflow; volg de gedocumenteerde publicatieprocedure van je platform.

Maak vervolgens de gedeelde cache ongeldig, als die aanwezig is. De volgorde is van belang: Cloudflare documenteert bijvoorbeeld dat verzoeken na een cacheverwijdering de bron ophalen en die weer aan de CDN-cache toevoegen. Als je de cache wist terwijl de bron nog het oude document aanbiedt, kan dat oude document de cache opnieuw vullen. Cache wissen voor één bestand.

Een gedocumenteerd dashboardvoorbeeld voor Cloudflare

Als je openbare pagina gebruikmaakt van Cloudflare-caching, biedt de gedocumenteerde methode om één bestand te wissen een concrete werkwijze via de browser:

  1. Open het Cloudflare-dashboard van de betreffende site en ga naar Configuration.
  2. Kies onder Purge Cache de optie Custom Purge.
  3. Kies onder Purge by de optie URL.
  4. Voer de exacte openbare URL van elk getroffen document in.
  5. Controleer de vermeldingen en selecteer Purge.

Deze labels en stappen komen uit de instructies van Cloudflare voor het wissen van één bestand.

Controleer de gedocumenteerde beperkingen voordat je de cache opnieuw wist. Als je een omleiding wist, wordt de omleidingsreactie verwijderd; wis dus de bestemmings-URL om de inhoud ervan bij te werken. Sommige aangepaste cachesleutels kunnen niet worden gewist via het URL-formulier op het dashboard; Cloudflare noemt wissen op basis van voorvoegsel of tag als alternatieven. Je kunt bij het wissen van één bestand ook geen jokertekens gebruiken. Beperkingen en alternatieven voor wissen.

Gebruik je een andere host of CDN, gebruik dan de gedocumenteerde invalideringsfunctie van die provider. De Cloudflare-procedure is een voorwaardelijk voorbeeld, geen universele interface. Als je publicatieservice geen functie biedt om de cache te wissen, controleer dan de gedocumenteerde cacheduur en het verversingsgedrag in plaats van zelf een URL voor cacheverwijdering te bedenken of ervan uit te gaan dat een browserknop de servers van de service aanstuurt.

Controleer de openbare reactie op je Mac

Open de bestaande openbare URL van de pagina in Chrome. Druk op Command–Option–I om DevTools te openen en selecteer daarna Network. Chrome documenteert deze sneltoets voor de Mac en maakt onderscheid tussen normaal herladen, hard herladen en herladen waarbij de cache wordt geleegd. Chrome DevTools openen.

Terwijl DevTools geopend is, selecteer je Disable cache in het deelvenster Network en laad je de pagina opnieuw. Chrome documenteert dat deze instelling ervoor zorgt dat normaal herladen de cache niet gebruikt. Laat DevTools tijdens de controle geopend. Herladen met of zonder cache.

Selecteer het verzoek voor het hoofddocument in de netwerklijst. Open Headers om de reactiekoppen te bekijken en Response om de ontvangen inhoud te onderzoeken. Zoek in dat document naar de verwachte zin van Revisie B. De netwerktutorial van Chrome legt uit hoe je afzonderlijke verzoeken, koppen en reactie-inhoud controleert. Netwerkactiviteit inspecteren.

Noteer drie observaties: de opgevraagde URL, of het ontvangen document Revisie B bevat en welke cachekoppen zijn meegeleverd. Zo kun je na het wissen van de cache een nuttige vergelijking maken. Een geslaagde dashboardbewerking is één controlepunt; het ontvangen van het bedoelde document is het controlepunt dat antwoord geeft op de directe behoefte van de lezer.

Schakel daarna Disable cache uit en laad de pagina opnieuw. Vergelijk het resultaat met de netwerktest. Als de twee resultaten verschillen, bewaar dan beide observaties bij het beoordelen van het reactiebeleid. De browser steeds opnieuw wissen zonder het verschil vast te leggen maakt het moeilijker om de oorzaak te achterhalen.

De WHATWG Fetch Standard legt uit waarom de ophaalmodi van de browser van belang zijn. De modus reload omzeilt de HTTP-cache van de browser op weg naar het netwerk en werkt die cache bij op basis van de reactie. De modus no-cache verstuurt een voorwaardelijk verzoek als er een gecachte reactie bestaat. Dit zijn verzoekgedragingen, dus geen van beide wist wereldwijd gedeelde gecachte pagina’s. Fetch Standard: cachemodi voor verzoeken.

Kies een cachebeleid dat bij toekomstige bewerkingen past

Overweeg voor een openbaar document dat vóór elk hergebruik moet worden gecontroleerd de reactierichtlijn Cache-Control: no-cache. Opslag is toegestaan, maar vóór hergebruik is succesvolle validatie vereist. Cache-Control: no-store verbiedt opslag. De max-age van een reactie geeft de geldigheidsduur aan; must-revalidate geldt nadat die is verlopen. Deze richtlijnen beantwoorden verschillende behoeften. RFC 9111: Cache-Control-richtlijnen voor reacties.

Stel ter illustratie dat de Handleiding voor papieren vormen af en toe verandert en het acceptabel is om bij elk bezoek op updates te controleren. Hervalidatie is dan een redelijk beleid om te bespreken met degene die de host configureert. Als hergebruik zonder netwerkcontrole de voorkeur heeft, kies dan een geldigheidsduur die past bij hoe lang een oude revisie nog aanvaardbaar mag blijven en houd een gedocumenteerde procedure voor cacheverwijdering achter de hand voor eerdere updates.

Als je het beleid van een nieuw gepubliceerde reactie wijzigt, worden browsers die nog een oudere, geldige reactie hergebruiken niet op de hoogte gebracht zolang ze geen contact maken met de server. Bestaande gecachte kopieën blijven dus deel uitmaken van de overgang. Dit volgt uit de HTTP-regels voor geldigheid en hergebruik en verklaart waarom een nieuwe instelling van een header gepaard moet gaan met een expliciet plan voor bestaande kopieën. RFC 9111: Reacties samenstellen vanuit caches.

Zorg dat validatie de revisie herkent

Een ETag identificeert een representatie voor validatie. Last-Modified geeft het tijdstip van wijziging aan. Laat de server validators genereren die de gepubliceerde representatie weerspiegelen, inclusief relevante wijzigingen in inhoud die uit andere bronnen wordt samengesteld. RFC 9110 beschrijft beide validators en legt uit dat entiteitstags representaties in sommige omstandigheden betrouwbaarder kunnen onderscheiden dan wijzigingsdatums. RFC 9110: Validatorvelden.

Een reactie 304 Not Modified vertelt de ontvanger een geldige opgeslagen representatie opnieuw te gebruiken in plaats van het document opnieuw over te dragen. Dat is normaal als de opgeslagen revisie nog actueel is. Ontvang je dit resultaat terwijl je na een bevestigde inhoudswijziging nog Revisie A ziet, onderzoek dan welke representatie en validator de server heeft beoordeeld. RFC 9110: 304 Not Modified.

Vraag Google om de gecorrigeerde pagina opnieuw te bekijken

Inspecteer de volledige URL in de juiste Search Console-property zodra het openbare document consequent Revisie B aanbiedt. Selecteer Test live URL om de huidige pagina te bekijken. Vergelijk het resultaat met het geïndexeerde rapport, dat een eerdere crawl kan beschrijven. De live test controleert de huidige pagina, maar bevestigt op zichzelf niet dat de index van Google is bijgewerkt. Tool URL-inspectie.

Selecteer Request indexing op het inspectieresultaat om een verzoek in te dienen voor een afzonderlijk bijgewerkte pagina. Je moet eigenaar of volledige gebruiker van de Search Console-property zijn. Google zegt dat crawlen enkele dagen tot enkele weken kan duren, dat herhaalde verzoeken dit niet versnellen en dat een crawlverzoek geen opname in de zoekresultaten garandeert. Vraag Google je URL’s opnieuw te crawlen.

Voor veel bijgewerkte pagina’s raadt Google aan een sitemap in te dienen. Houd de waarden van <lastmod> actueel: volgens Google moeten ze belangrijke wijzigingen weerspiegelen, zoals updates van de hoofdinhoud, en geen routinematige wijzigingen van een copyrightdatum. Een sitemap helpt gewijzigde documenten door te geven; die wist geen browser- of CDN-kopieën. Een sitemap maken en indienen.

Sluit af met een kort publicatieregister: de getroffen URL’s, de verwachte revisiezin, de controle van de gepubliceerde uitvoer, de actie voor de gedeelde cache en het resultaat van de browsercontrole. Houd een eventueel verzoek om een nieuwe Google-crawl afzonderlijk bij. Zo blijft het directe doel—het herziene openbare document aanbieden—zichtbaar en is er een duidelijke volgende stap wanneer ergens nog een oudere versie verschijnt.

Bronnen