Resumo

  • A rota News & Announcements da AFRINIC respondeu HTTP 200 em 31 de agosto, com título, H1, lista de 2026 e JSON-LD próprios de uma página de notícias.
  • O canonical, a descrição comum, o título e a URL Open Graph e o título do Twitter na mesma resposta descreviam a Política de Privacidade.
  • A página real de privacidade existe separadamente, e o sitemap da AFRINIC lista notícias e privacidade em entradas distintas.
  • O achado comprova uma identidade de publicação divergente. Não comprova desindexação, perda de tráfego nem um cartão social efetivamente exibido.

O conteúdo entregue não é o conteúdo declarado

Às 05h46 UTC de 31 de agosto, a página de notícias da AFRINIC estava acessível. O título do navegador dizia “News & Announcements”, o H1 repetia essa função e o corpo abria a lista “Latest News & Announcements (2026)”. Havia comunicados recentes sobre o Appeal Committee, o CEO designate, a pesquisa com membros e outros assuntos institucionais.

O JSON-LD também descrevia uma página News & Announcements e usava uma URL de notícias. Navegação e breadcrumb apontavam para News. Nada nessa observação sustenta que o arquivo estivesse fora do ar, vazio ou substituído pela Política de Privacidade.

Mas o <head> traz outra identidade. O canonical aponta para https://afrinic.net/privacy.html. A description se apresenta como a página oficial da Privacy Policy. Os títulos Open Graph nomeiam a Política de Privacidade, a URL absoluta Open Graph vai para ela e o título do Twitter repete o mesmo papel.

A rota entrega uma coisa e declara outra a dois conjuntos de consumidores automáticos.

A Política de Privacidade não é uma variante da lista de notícias

A página de Privacy Policy também respondeu HTTP 200. Seu título, seu H1 e seu canonical são coerentes entre si. Portanto, o destino não é um link quebrado: é um documento público válido, só que com outra finalidade.

O sitemap da AFRINIC mantém /news e /privacy em entradas separadas. O sitemap não mostra o que o Google indexou e não deve ser confundido com um Google News Sitemap. Ele oferece uma comparação mais limitada e segura: na própria lista de descoberta da AFRINIC, as duas rotas continuam sendo recursos diferentes.

Também há diferenças de host e extensão entre os endereços. Elas merecem ser registradas, mas não explicam o problema central. Mesmo que todos os endereços fossem normalizados para o mesmo host, notícias e política de privacidade continuariam sendo papéis editoriais distintos.

O que canonical pode — e não pode — demonstrar

O RFC 6596 define a relação canonical para conteúdo duplicado. O destino precisa repetir o conteúdo da página de origem ou ser uma versão que o contenha como subconjunto. Aplicações podem então concentrar o processamento no recurso preferido.

Os corpos capturados não formam esse par. Uma lista de notícias não é uma cópia da política de privacidade, e a política não é uma versão “ver tudo” das notícias. A declaração é incompatível com a relação semântica observada.

Isso não torna canonical uma ordem infalível. Ele não redireciona o navegador. O RFC reconhece que uma aplicação pode ignorar uma declaração imprópria e aplicar suas próprias heurísticas. Sem evidência de console de busca, não se pode afirmar que a página sumiu dos resultados, perdeu sinais ou teve menos audiência.

O fato sólido é anterior: a fonte serviu uma preferência por outro objeto.

Um segundo erro de identidade para o compartilhamento

O Open Graph protocol define og:title como o título do objeto no grafo e og:url como a URL canônica usada como seu identificador permanente. Os valores da página de notícias descreviam a Política de Privacidade.

Essa constatação não autoriza inventar um cartão visto no Facebook, no X ou em outra plataforma. Serviços podem usar cache, escolher campos alternativos ou recusar valores incoerentes. O que está comprovado é a entrada publicada; a saída de cada serviço exige uma observação própria.

O JSON-LD, por sua vez, continuava correto para notícias. A divergência é múltipla: identidade visível e estruturada de um lado, canonical e identidade social de outro. Não faltam metadados. Falta uma comparação que confirme que todos descrevem o mesmo objeto.

Um recibo que acompanha cada rota

Uma publicação institucional precisa de um recibo de identidade por rota. Ele deve unir URL solicitada e resolvida, papel editorial aprovado, title e H1, canonical e justificativa de conteúdo duplicado ou mais abrangente, description, Open Graph, Twitter, tipo/nome/URL do dado estruturado, entrada no sitemap, versão ou hash implantado, resultado da validação, exceções e histórico de correção.

Checar apenas se o destino canonical responde 200 seria insuficiente aqui: ele responde. Checar apenas se og:title existe também seria insuficiente: ele existe. O teste precisa perguntar se os valores descrevem a mesma página que o leitor recebeu.

O reparo mínimo preserva os dois documentos. A AFRINIC pode alinhar o canonical, a descrição e a identidade social de /news ao conteúdo de notícias que já está publicado, registrar os hashes antes e depois e marcar o horário da mudança. Reprocessamento por mecanismos externos deve ser acompanhado como etapa posterior, não presumido como concluído.

Três relógios, uma conclusão proporcional

O relógio da disponibilidade marcou 200. O relógio da identidade da fonte registrou a divergência. O relógio das plataformas externas não foi observado. Um quarto relógio, o da correção, só começa quando novos bytes forem capturados e comparados.

Essa separação evita dois erros. A página não deve ser absolvida apenas porque carrega. Tampouco deve ser tratada como desindexada sem prova. A notícia é sobre um controle que falhou em uma superfície escondida e sobre como fechar essa lacuna sem remover conteúdo público.

Fontes