Para atualizar uma página pública em cache, publique o documento atualizado, limpe qualquer cache compartilhado que o disponibilize e verifique o resultado no navegador do seu Mac. Se o Google ainda mostrar o conteúdo antigo, solicite uma nova rastreação separadamente; atualizar o navegador não atualiza o índice do Google.

Este guia é para quem mantém um documento público e precisa que os leitores recebam seu conteúdo revisado no URL existente. As etapas para computador usam o Chrome no macOS. Um “Guia de Formas de Papel” fictício, que muda de “Revisão A: círculos” para “Revisão B: círculos e quadrados”, oferece uma maneira simples de distinguir as versões durante todo o fluxo de trabalho.

Por que editar a origem não atualiza todas as páginas em cache?

A invalidação HTTP remove uma resposta armazenada ou torna obrigatória a validação antes de reutilizá-la. A RFC 9111 exige que um cache invalide o URI de destino após uma solicitação bem-sucedida que altere o estado e passe por esse cache, mas afirma explicitamente que isso não invalida cópias globalmente. Portanto, um fluxo de publicação precisa levar em conta os caches que não estão no caminho da solicitação de edição. RFC 9111: Invalidating Stored Responses.

Para o Guia de Formas de Papel, faça uma lista curta das saídas afetadas pela edição. Se o texto revisado também aparecer em uma página de coleção, inclua essa página. Se apenas o guia mudar, mantenha a lista limitada a esse documento. Essa lista de dependências é um recurso editorial: comece pela origem alterada e identifique cada documento publicado que agora deve apresentar algo diferente.

Use a sequência a seguir para escolher sua próxima ação. Trate cada resultado como uma pista de diagnóstico, não como prova de que todos os leitores recebem a mesma resposta.

O que você observa O que verificar em seguida
O sistema de publicação ainda mostra a Revisão A na saída publicada Confirme que a Revisão B foi publicada ou compilada com sucesso.
A saída publicada é a Revisão B, mas uma recarga de rede no navegador recebe a Revisão A Investigue o cache compartilhado ou o documento disponibilizado pelo host.
Uma recarga de rede mostra a Revisão B, enquanto uma recarga comum mostra a Revisão A Investigue o cache local do navegador e a política de cache da resposta.
A página pública mostra a Revisão B, mas as informações indexadas pelo Google continuam antigas Use o teste ao vivo do Search Console e, em seguida, considere solicitar a indexação.

O Google documenta a distinção por trás da última linha: o relatório inicial da Inspeção de URL descreve a versão indexada, enquanto o teste ao vivo busca a página atual. Portanto, um relatório indexado antigo pode coexistir com um documento público corrigido. Ferramenta de Inspeção de URL.

Publique o documento alterado antes de limpar o cache

Primeiro, anote o URL público exato e a alteração esperada. Neste exemplo fictício, a frase esperada é “Revisão B: círculos e quadrados”. Use uma frase distintiva que já seja apropriada para o documento; o objetivo é reconhecer a nova saída sem depender de quando uma aba foi aberta.

Publique a edição pelo sistema de publicação existente. Se esse sistema compila documentos a partir de arquivos de origem, confirme que a saída publicada inclui a frase revisada. Salvar o conteúdo de origem e gerar o documento público são etapas distintas neste fluxo de trabalho; siga o procedimento de publicação documentado para sua plataforma.

Em seguida, invalide o cache compartilhado, se houver. A ordem importa: por exemplo, a Cloudflare documenta que as solicitações feitas após uma limpeza buscam o recurso na origem e o adicionam novamente ao cache da CDN. Se você limpar o cache enquanto a origem ainda disponibiliza o documento antigo, esse documento antigo poderá voltar ao cache. Limpar um único arquivo.

Exemplo documentado de painel da Cloudflare

Se sua página pública usa o cache da Cloudflare, a limpeza documentada de um único arquivo oferece um procedimento concreto pelo navegador:

  1. Abra o painel da Cloudflare do site relevante e acesse Configuration.
  2. Em Purge Cache, selecione Custom Purge.
  3. Em Purge by, escolha URL.
  4. Insira o URL público exato de cada documento afetado.
  5. Revise as entradas e selecione Purge.

Esses rótulos e etapas vêm das instruções da Cloudflare para limpar um único arquivo.

Verifique os limites documentados antes de repetir uma limpeza. Limpar um redirecionamento remove a resposta de redirecionamento, portanto limpe o URL de destino para atualizar o conteúdo. Algumas chaves de cache personalizadas não podem ser limpas pelo formulário de URL do painel; a Cloudflare documenta a limpeza por prefixo ou tag como alternativas. A limpeza de um único arquivo também não aceita curingas. Limitações e alternativas para limpeza.

Se você usa outro host ou CDN, utilize o controle de invalidação documentado pelo provedor. O procedimento da Cloudflare é um exemplo condicional, não uma interface universal. Se seu serviço de publicação não oferecer uma operação de limpeza, consulte a duração do cache e o comportamento de atualização documentados, em vez de inventar um URL de limpeza ou presumir que um botão do navegador controla os servidores do serviço.

Verifique a resposta pública no seu Mac

Abra o URL público existente da página no Chrome. Pressione Command–Option–I para abrir o DevTools e selecione Network. O Chrome documenta esse atalho no Mac e diferencia recargas normais, recargas forçadas e recargas que esvaziam o cache. Abrir o Chrome DevTools.

Com o DevTools aberto, selecione Disable cache no painel Network e recarregue a página. O Chrome documenta que essa configuração faz com que recargas normais ignorem o cache do navegador. Mantenha o DevTools aberto durante a verificação. Recarregar com ou sem cache.

Selecione a solicitação do documento principal na lista de rede. Abra Headers para inspecionar os cabeçalhos da resposta e Response para examinar o conteúdo recebido. Procure a frase esperada da Revisão B nesse documento. O tutorial de rede do Chrome explica como inspecionar solicitações individuais, cabeçalhos e conteúdo de respostas. Inspecionar atividade de rede.

Registre três observações: o URL solicitado, se o documento recebido contém a Revisão B e os cabeçalhos de cache enviados com ele. Isso oferece uma comparação útil após a limpeza. Uma operação bem-sucedida no painel é uma etapa de verificação; receber o documento esperado é a etapa que atende à necessidade imediata do leitor.

Em seguida, desative Disable cache e recarregue novamente. Compare o resultado com o teste de rede. Se houver divergência entre os dois, guarde ambas as observações ao analisar a política da resposta. Limpar o navegador repetidamente sem registrar a diferença torna mais difícil identificar a causa.

O padrão Fetch do WHATWG explica por que os modos de busca do navegador são relevantes. Seu modo reload ignora o cache HTTP do navegador ao acessar a rede e atualiza esse cache a partir da resposta. Seu modo no-cache faz uma solicitação condicional quando existe uma resposta em cache. Esses são comportamentos de solicitação; portanto, nenhum deles equivale a limpar globalmente páginas em caches compartilhados. Padrão Fetch: modos de cache de solicitações.

Escolha uma política de cache adequada para futuras edições

Para um documento público que deve ser verificado antes de cada reutilização, considere a diretiva de resposta Cache-Control: no-cache. Ela permite o armazenamento, mas exige uma validação bem-sucedida antes da reutilização. Cache-Control: no-store proíbe o armazenamento. max-age de uma resposta especifica seu período de atualização; must-revalidate se aplica depois que ela fica desatualizada. Essas diretivas atendem a requisitos diferentes. RFC 9111: Diretivas Cache-Control de resposta.

Como decisão ilustrativa, suponha que o Guia de Formas de Papel mude ocasionalmente e que seja aceitável verificar se há atualizações a cada visita. A revalidação é uma política razoável para discutir com a pessoa que configura o host. Se for preferível reutilizar o conteúdo sem uma verificação de rede, escolha um período de atualização compatível com o tempo durante o qual uma revisão antiga pode continuar sendo aceitável e mantenha um procedimento documentado para limpar o cache após atualizações antecipadas.

Alterar a política em uma resposta recém-publicada não pode avisar um navegador que continua reutilizando uma resposta antiga ainda atualizada sem entrar em contato com o servidor. Portanto, as cópias armazenadas existentes continuam fazendo parte da transição. Isso decorre das regras HTTP de atualização e reutilização; por isso, uma nova configuração de cabeçalho deve vir acompanhada de um plano explícito para as cópias existentes. RFC 9111: Construção de respostas a partir de caches.

Garanta que a validação reconheça a revisão

Uma ETag identifica uma representação para fins de validação. Last-Modified informa seu horário de modificação. Configure o servidor para gerar validadores que reflitam a representação publicada, incluindo alterações relevantes no conteúdo reunido a partir de outras fontes. A RFC 9110 descreve ambos os validadores e explica que tags de entidade podem distinguir representações com mais confiabilidade do que datas de modificação em algumas circunstâncias. RFC 9110: Campos de validação.

Uma resposta 304 Not Modified informa ao destinatário que ele deve reutilizar uma representação armazenada válida, em vez de transferir o documento novamente. Isso é normal quando a revisão armazenada continua atual. Se você receber esse resultado e ainda vir a Revisão A após confirmar uma alteração no conteúdo, investigue qual representação e qual validador o servidor avaliou. RFC 9110: 304 Not Modified.

Peça ao Google para revisitar a página corrigida

Quando o documento público disponibilizar a Revisão B de forma consistente, inspecione seu URL completo na propriedade apropriada do Search Console. Selecione Test live URL para examinar a página atual. Compare esse resultado com o relatório indexado, que pode descrever um rastreamento anterior. O teste ao vivo verifica a página atual; por si só, ele não confirma que o índice do Google foi atualizado. Ferramenta de Inspeção de URL.

Para uma página atualizada individual, selecione Request indexing no resultado da inspeção. Você precisa ser proprietário ou usuário com acesso total à propriedade do Search Console. O Google informa que o rastreamento pode levar de alguns dias a algumas semanas, que solicitações repetidas não o aceleram e que solicitar um rastreamento não garante a inclusão nos resultados da pesquisa. Peça ao Google para rastrear novamente seus URLs.

Para muitas páginas atualizadas, o Google recomenda enviar um sitemap. Mantenha os valores de <lastmod> precisos: o Google diz que eles devem refletir alterações significativas, como atualizações do conteúdo principal, e não mudanças rotineiras na data de direitos autorais. Um sitemap ajuda a comunicar quais documentos mudaram; ele não limpa cópias no navegador ou na CDN. Criar e enviar um sitemap.

Finalize com um pequeno registro de publicação: os URLs afetados, a frase esperada da revisão, a verificação da saída publicada, a ação no cache compartilhado e o resultado da verificação no navegador. Registre separadamente qualquer solicitação de novo rastreamento ao Google. Assim, o objetivo imediato — disponibilizar o documento público revisado — continua observável, e fica claro qual é a próxima etapa quando uma versão antiga ainda aparece.

Fontes