Protocolo WebSub

TL;DR — WebSub é uma forma de notificar assinantes quando você publica algo, em vez de esperar que eles venham verificar seu feed. Só funciona se seu site tiver um feed RSS ou Atom. Você aponta seu feed para um “hub” e, quando publica, seu site envia um ping ao hub, que repassa a atualização para os serviços assinados. Algumas plataformas de blog suportam isso automaticamente.

O que é WebSub

Normalmente, os mecanismos de busca encontram suas novas publicações voltando para verificar — eles releem seu sitemap ou seu feed RSS periodicamente em sua própria programação. O WebSub inverte isso: no momento em que você publica, seu site envia uma pequena mensagem de “ei, tenho algo novo”, e isso é repassado aos mecanismos de busca que estão ouvindo.

Antes era chamado de PubSubHubbub (sim, sério). Em 2017, foi renomeado WebSub e se tornou um padrão web oficial. Ambos os nomes significam a mesma coisa, e o sistema do Google ainda funciona com qualquer um deles.

A única coisa que você precisa saber

O WebSub só funciona com feeds RSS ou Atom. Ele não é uma forma de enviar qualquer página aleatória do seu site para o Google. Se você quiser notificar mecanismos de busca sobre uma página normal que não está em um feed, essa é uma ferramenta diferente (IndexNow para o Bing; a ferramenta URL Inspection para o Google).

E como tudo em descoberta, o WebSub só ajuda um mecanismo de busca a descobrir seu conteúdo mais rápido. Ele não garante que a página seja rastreada, indexada ou ranqueada — essas ainda são etapas separadas.

Você precisa configurá-lo?

Provavelmente não manualmente. Se você publica no WordPress (com um plugin), Blogger ou na maioria das plataformas hospedadas, o WebSub já está integrado ou a um plugin de distância, já apontado para o hub público do Google. É um recurso bom de ter para sites que publicam com frequência — não uma obrigação para todos.

Quer os detalhes do protocolo, a posição exata do Google e como o WebSub se compara ao IndexNow? Mude para a aba Avançado.

TL;DR — WebSub (antigo PubSubHubbub; uma Recomendação W3C desde janeiro de 2018, reafirmada com uma atualização focada em segurança em junho de 2026) é o complemento push ao pull de RSS/Atom. Um editor anuncia um hub em seu feed (<link rel="hub">), assinantes se registram nesse hub e, ao publicar, o editor envia um ping ao hub para que ele distribua o feed atualizado a todos os assinantes. Serviços de busca podem assinar, mas o WebSub em si não promete que qualquer mecanismo de busca rastreará ou indexará uma URL. Ele é projetado em torno de recursos de tópico, como feeds, não como uma API de indexação geral. Para mecanismos de busca participantes, o IndexNow é um protocolo separado de notificação de URL — e, a partir de meados de 2025, o Bing também parou de aceitar novas inscrições para seu próprio programa de envio de feeds de notícias (mais abaixo), o que reduz ainda mais o campo.

WebSub é a metade push dos feeds

No hub de Descoberta, dividi a descoberta em pull e push. Feeds RSS/Atom são um canal pull: o mecanismo consulta seu feed em seu próprio ritmo (o Feedfetcher do Google, por exemplo, não puxa a maioria dos feeds mais do que cerca de uma vez por hora). O WebSub é o que transforma esse pull em push — em vez de esperar ser buscado novamente, seu feed transmite a mudança no momento em que você publica.

Essa é toda a proposta de valor: notificação quase em tempo real de atualizações de feed, em vez de esperar pela próxima consulta agendada.

PubSubHubbub vs WebSub — mesmo protocolo, nome diferente

Isso confunde as pessoas em buscas por documentação. O protocolo foi originalmente chamado PubSubHubbub (abreviado PSH). Foi renomeado WebSub em outubro de 2017 e publicado como uma Recomendação W3C em janeiro de 2018. Artigos anteriores a 2018 dizem “PubSubHubbub”; artigos posteriores a 2018 dizem “WebSub.” São a mesma coisa, e o hub do Google ainda responde a ambos — o que John Mueller confirmou na época da renomeação (“Yes, finally dug it up! We support both.”). (tradução) «Sim, finalmente encontrei! Suportamos ambos.»

A própria especificação não ficou parada desde 2018: o W3C republicou o WebSub como uma nova Recomendação em 2 de junho de 2026, adicionando mitigações de cross-site scripting (XSS) à seção de Considerações de Segurança. Essa é uma atualização de endurecimento de segurança, não uma mudança de mecânica — os atores, as relações de descoberta e o fluxo de assinatura/publicação descritos abaixo são o mesmo protocolo da versão de 2018. Se você está implementando (não apenas consumindo) o WebSub, leia a Recomendação atual em vez de uma cópia do texto de 2018.

Como o WebSub funciona na prática

Há três atores:

• Publicador — seu site (especificamente, seu feed).
• Hub — um servidor de retransmissão que gerencia assinaturas e distribuição.
• Assinante — um mecanismo de busca (ou qualquer cliente) que deseja atualizações.

A especificação do W3C descreve o fluxo de forma clara: “Subscribers discover the hub of a topic URL, and makes a POST to one or more of the advertised hubs in order to receive updates when the topic changes. Publishers notify their hub(s) URLs when their topic(s) change. When the hub identifies a change in the topic, it sends a content distribution notification to all registered subscribers.” (tradução) «Assinantes descobrem o hub de uma URL de tópico e fazem um POST para um ou mais hubs anunciados para receber atualizações quando o tópico muda. Publicadores notificam as URLs de seus hubs quando seus tópicos mudam. Quando o hub identifica uma mudança no tópico, ele envia uma notificação de distribuição de conteúdo para todos os assinantes registrados.»

Na prática, para SEO:

1. Seu feed anuncia um hub com uma tag <link rel="hub" href="..."> (além de um <link rel="self" href="..."> apontando para a URL do próprio feed).
2. Assinantes (mecanismos de busca) se registram nesse hub para o seu feed.
3. Quando você publica, seu site notifica o hub de que seu feed mudou.
4. O hub busca seu feed atualizado e o distribui para cada assinante via um HTTP POST para a URL de callback deles.

O passo 2 faz mais trabalho do que “registrar” implica. A especificação divide a assinatura em estados separados: uma solicitação de assinatura, uma etapa de verificação em que o hub confirma que o assinante realmente quer o tópico (para que ninguém possa assinar a URL de callback de um estranho sem a permissão dele), uma concessão que a assinatura mantém por um tempo limitado e uma renovação que o assinante precisa fazer antes de a concessão expirar (não existe assinatura permanente) — além de um caminho explícito de cancelamento de assinatura. Nada disso é algo que você, como publicador, gerencia; é o lado do aperto de mão entre hub e assinante. Mas vale saber que isso existe, porque é por isso que “eu fiz ping no hub” e “um mecanismo de busca tem uma assinatura ativa do meu feed” são duas coisas diferentes e que podem falhar de forma independente.

O passo 3 também é menos padronizado do que a maioria dos artigos sobre WebSub dá a entender: a própria especificação diz “the specific mechanism for the publisher to inform the hub is left unspecified,” e apenas observa, como exemplo, que alguns hubs públicos — incluindo o do Google — aceitam um POST com hub.mode=publish e hub.url definido para o feed alterado. Essa convenção é universal o suficiente na prática para que “fazer ping no hub” e “fazer POST hub.mode=publish” sejam efetivamente sinônimos — mas é uma convenção amplamente adotada, documentada como exemplo, não um requisito rígido da Recomendação.

A especificação do W3C é tecnicamente mais ampla do que feeds — ela pode carregar qualquer recurso HTTP — mas a documentação do Google limita sua recomendação a feeds Atom/RSS. A especificação é ampla; o caso de uso para SEO é restrito.

WebSub e Google

O suporte do Google está registrado, na documentação Build a Sitemap: “If you use Atom or RSS, you can use WebSub to broadcast your changes to search engines, including Google.” É uma única frase subordinada — o Google não dá ao WebSub uma seção própria — mas está confirmado.

O hub do Google está em pubsubhubbub.appspot.com, operado pelo Google como um serviço — confirmei que ele ainda está ativo e respondendo em 2026-07-18. Esse é o hub que você anuncia no seu feed e ao qual faz ping na publicação. Hubs comunitários também existem, mas historicamente têm sido menos duráveis que o do Google — verifique se qualquer hub de terceiros que você está considerando ainda está realmente respondendo antes de comprometer seu feed com ele, em vez de confiar em um post de blog antigo que diz que funciona.

O rastreador por trás da cortina é o Feedfetcher (Feedfetcher-Google), que é como o Google rastreia feeds RSS/Atom para o Google News e WebSub. Uma nuance importante da própria documentação do Feedfetcher: “apenas feeds de podcast são indexados no Google Search” através desse caminho. Então, para um feed de blog normal, o WebSub acelera a consciência do Google sobre a atualização do feed, mas a indexação real de cada página ainda vem do Googlebot seguindo as URLs dentro do feed pelo pipeline normal de rastreamento → indexação. O WebSub é um acelerador de descoberta, não um atalho de indexação.

WebSub e Bing

O suporte documentado do Bing no estilo WebSub vive sob o Bing News PubHub — ou seja, é escopado para notícias/feeds, em paralelo a como o caminho do Feedfetcher do Google é orientado para Notícias e podcasts. Mas o próprio PubHub está sendo descontinuado: a Microsoft parou de aceitar novas inscrições de editores no PubHub em junho de 2025, dizendo que está movendo o Bing News para identificar e ranquear automaticamente conteúdo de notícias elegível em vez de inscrições manuais. Editores já aprovados antes disso permanecem indexados; o portal de inscrição para novos candidatos está fechado. Isso é uma aposentadoria em nível de programa da inscrição manual de notícias, não uma mudança no IndexNow.

Para enviar páginas web gerais ao Bing, a ferramenta certa é o IndexNow, não WebSub ou PubHub. O IndexNow é o push em tempo real preferido do Bing (e do Yandex, Naver, Seznam, Yep) para URLs arbitrárias, não afetado pela mudança do PubHub — e notavelmente, o Google não participa do IndexNow (confirmado na própria lista de participantes do indexnow.org nesta revisão). Então a divisão limpa é: WebSub para feeds (onde o hub do Google é a opção prática), IndexNow para páginas gerais nos mecanismos que o suportam.

Como implementar o WebSub

Passo 1 — anuncie o hub no seu feed. Adicione um link de hub e um link de self. A forma mais comum é embutida no próprio feed:

<link rel="hub" href="https://pubsubhubbub.appspot.com/" />
<link rel="self" href="https://example.com/feed.xml" />

O hub do Google também aceita o equivalente como cabeçalhos de resposta HTTP na solicitação do feed em vez de tags embutidas — útil se você não controla o XML do feed diretamente (um gerador de feed de terceiros, por exemplo):

Link: <https://pubsubhubbub.appspot.com/>; rel="hub"
Link: <https://example.com/feed.xml>; rel="self"

Qualquer uma das formas diz a um assinante a mesma coisa: com qual hub se registrar, e qual é a URL canônica deste feed. Essa segunda parte importa se você algum dia mover o feed — aponte a URL antiga para a nova com um redirecionamento HTTP e, de acordo com a especificação, um assinante renovando sua concessão seguirá o redirecionamento e pegará o novo par hub/self automaticamente, em vez de ficar silenciosamente desatualizado.

Passo 2 — faça ping no hub quando você publicar. POST para a URL do hub com o modo de publicação e a URL do seu feed — esta é a convenção amplamente usada que o hub do Google (e a maioria dos outros) espera, descrita acima:

curl -i -d "hub.mode=publish&hub.url=https://example.com/feed.xml" \
  https://pubsubhubbub.appspot.com/

Na prática, seu CMS lida com ambos os passos. O plugin PubSubHubbub do WordPress usa o hub do Google por padrão; Blogger, WordPress.com e Medium suportam WebSub nativamente. Para um site personalizado, você conecta o ping de publicação ao seu fluxo de publicação.

Verifique — mas saiba o que você está realmente confirmando. Um 2xx do hub apenas prova que o hub aceitou sua notificação; não prova que qualquer assinante a recebeu, e como editor você geralmente não pode observar esse último salto diretamente. O que você pode verificar do seu lado: publique um post de teste, confirme que o hub retorna um 2xx para seu ping, então observe o Feedfetcher-Google acessando seu feed nos seus logs de servidor logo depois — isso confirma que o hub re-rastreou, o que é o máximo que a verificação no lado do editor alcança. Veja a lente Testes de Validação para a análise completa em etapas (marcação do feed, resposta do ping, re-rastreamento do hub) com o que cada uma prova e não prova.

O que o WebSub não é

Alguns mitos que valem a pena eliminar:

• Ele não indexa páginas instantaneamente. Ele notifica o hub de uma atualização de feed; o Google ainda rastreia e indexa cada URL por meio de processos normais.
• Ele não funciona para páginas arbitrárias. Somente feeds. Para URLs que não são de feed, isso é IndexNow (Bing) ou URL Inspection (Google).
• Ele não substitui sitemaps. WebSub e sitemaps são complementares — os sitemaps cobrem o site inteiro; o WebSub envia alterações de feed em tempo real. O Google recomenda ambos.
• O hub do Google não está obsoleto. pubsubhubbub.appspot.com está ativo e é executado pelo Google — confirmado ativo em 18/07/2026. O PubHub do Bing é outra história: ele parou de aceitar novas inscrições de editores em junho de 2025 (veja WebSub e Bing acima), então não trate essa página como um caminho de integração mais, mesmo que ela ainda exista.

Quem realmente se beneficia

Editores de alta frequência — sites de notícias, podcasts e qualquer pessoa cuja janela de atualização importa — obtêm o máximo do WebSub. Para um site que publica algumas vezes por mês, a velocidade marginal em relação à sondagem normal de feeds e a uma boa interligação interna é pequena. É um padrão sensato se a sua plataforma oferecer; raramente vale a pena uma engenharia personalizada pesada por conta própria.

Para uma visão mais ampla de como as URLs são encontradas, veja o hub Discovery; para o que acontece depois que uma URL é descoberta, veja Crawling.

Resumo de IA

Uma visão condensada da versão Avançada:

• WebSub = a metade push de RSS/Atom. Os feeds são normalmente puxados no cronograma do mecanismo; o WebSub transmite a alteração no momento em que você publica.
• Antes PubSubHubbub (PSH); renomeado em outubro de 2017, Recomendação W3C em janeiro de 2018 — republicado em junho de 2026 com mitigações de segurança XSS adicionadas, mesma mecânica de protocolo. O Google suporta ambos os nomes (John Mueller: “We support both.”).
• Três atores: editor → hub → assinantes. Você anuncia um hub no seu feed (<link rel="hub"> + <link rel="self">, ou os cabeçalhos HTTP Link equivalentes), e então notifica o hub na publicação (o hub do Google e a maioria dos outros usam um POST hub.mode=publish — uma convenção documentada, não um requisito de especificação); o hub distribui o feed para os assinantes, cada um dos quais mantinha uma assinatura verificada separadamente, com limite de tempo e renovável.
• O Google suporta: “If you use Atom or RSS, you can use WebSub to broadcast your changes to search engines, including Google.” Hub do Google: pubsubhubbub.appspot.com (confirmado ativo em 18/07/2026). O Feedfetcher faz o rastreamento; observe “only podcast feeds get indexed in Google Search” por meio desse caminho.
• Dois limites rígidos: somente feeds (não páginas arbitrárias) e somente descoberta (sem rastreamento ou indexação garantidos). Um ping bem-sucedido ao hub também não é prova de entrega ao assinante — você só pode verificar até o re-busca do próprio hub.
• Bing: o suporte no estilo WebSub vivia no PubHub com escopo de notícias, que parou de aceitar novas inscrições de editores em junho de 2025. Para páginas gerais, IndexNow é o push do Bing, não afetado por isso (o Google não participa do IndexNow).
• Não substitui sitemaps; não é indexação instantânea. A maioria dos CMSs (plugin WordPress, Blogger, Medium) lida com isso automaticamente. Melhor para editores de alta frequência.

Documentação oficial

Documentação de fonte primária e a especificação do protocolo.

Google

• Criar e enviar um sitemap — o único lugar onde o Google documenta o WebSub: “If you use Atom or RSS, you can use WebSub to broadcast your changes to search engines, including Google.”
• Feedfetcher — o rastreador por trás das buscas acionadas por WebSub; observa que apenas feeds de podcast são indexados no Google Search por esse caminho.
• Hub WebSub do Google — o hub público ativo e gerenciado pelo Google que você anuncia e faz ping.
• Usar feeds RSS/Atom para descobrir novas URLs (2009) — o post seminal do Search Central apresentando o suporte do Google ao PubSubHubbub.

Bing / Microsoft

• Suporte ao Bing News PubHub — a orientação do Bing focada em feeds/notícias; a página ainda existe, mas a Microsoft parou de aceitar novas inscrições de editores no PubHub em junho de 2025.
• IndexNow / indexnow.org — o push em tempo real preferido do Bing para URLs gerais (não feeds), não afetado pela mudança no PubHub.

Padrão

• WebSub — Recomendação W3C — a especificação do protocolo, uma Recomendação W3C desde janeiro de 2018 e republicada em 2 de junho de 2026 com mitigações de XSS nas Considerações de Segurança: hubs, assinantes, editores e distribuição de conteúdo.

Citações da fonte

Declarações registradas do Google e da especificação W3C. Cada link é um link profundo que salta para a passagem citada na página de origem.

Google — Suporte a WebSub

• “If you use Atom or RSS, you can use WebSub to broadcast your changes to search engines, including Google.” (tradução) «Se você usa Atom ou RSS, pode usar o WebSub para transmitir suas alterações aos mecanismos de busca, incluindo o Google.» — Google Search Central, Criar um sitemap. Ir para a citação
• “Google accepts RSS 2.0 and Atom 1.0 feeds.” (tradução) «O Google aceita feeds RSS 2.0 e Atom 1.0.» Ir para a citação

Google — Feedfetcher (o rastreador por trás do WebSub)

• “Feedfetcher is how Google crawls RSS or Atom feeds for Google News and WebSub.” (tradução) «O Feedfetcher é como o Google rastreia feeds RSS ou Atom para o Google News e o WebSub.» — Documentação de rastreadores e buscadores do Google. Ir para a citação

W3C — como o protocolo funciona

• “Subscribers discover the hub of a topic URL, and makes a POST to one or more of the advertised hubs in order to receive updates when the topic changes. Publishers notify their hub(s) URLs when their topic(s) change. When the hub identifies a change in the topic, it sends a content distribution notification to all registered subscribers.” (tradução) «Os assinantes descobrem o hub de uma URL de tópico e fazem um POST para um ou mais hubs anunciados para receber atualizações quando o tópico muda. Os editores notificam as URLs de seus hubs quando seus tópicos mudam. Quando o hub identifica uma mudança no tópico, ele envia uma notificação de distribuição de conteúdo a todos os assinantes registrados.» — Recomendação W3C WebSub. Ir para a citação

John Mueller, Google (sobre a renomeação PubSubHubbub → WebSub, setembro de 2017)

• “Yes, finally dug it up! We support both.” — confirmando que o Google suporta tanto o nome “WebSub” quanto o anterior “PubSubHubbub”. (tradução) «Sim, finalmente encontrei! Suportamos ambos.» Transmitido pela cobertura do Search Engine Roundtable de setembro de 2017; o tweet original não está mais diretamente acessível, então trate isso como atribuído em vez de verbatim da fonte.

Lista de verificação de publicação WebSub

• Publique um feed RSS ou Atom válido com uma URL pública estável.
• Adicione tanto a relação hub quanto a relação self do feed à marcação do feed.
• Envie a URL do feed alterada ao hub anunciado após publicar ou atualizar um item.
• Confirme que o hub aceitou a solicitação e, em seguida, confirme que ele buscou o feed nos seus logs.
• Mantenha o feed acessível sem autenticação e retorne uma resposta de sucesso normal.
• Trate o ping como uma notificação de descoberta, não como prova de rastreamento, indexação ou ranqueamento.

O framework publicar → notificar → buscar

Pense no WebSub como uma transferência entre três partes:

1. Publicador: atualiza o feed e informa ao hub anunciado qual feed mudou.
2. Hub: aceita a notificação e a distribui aos assinantes.
3. Assinante: recebe a notificação e decide se busca o feed.

Cada limite precisa de evidências separadas. Um ping de publicação bem-sucedido prova apenas que o hub aceitou a notificação. Uma solicitação nos logs do servidor vinda do hub prova que o feed foi buscado. Nenhum dos dois prova que um mecanismo de busca rastreou uma URL de item ou a adicionou a um índice. Essa separação evita que falhas de descoberta sejam diagnosticadas erroneamente como falhas de indexação.

WebSub — referência rápida

Marcação de feed obrigatória (ambos os elementos, nas tags <head>/de nível de canal do feed)

O ping de publicação

Valores de hub.mode

• publish — o valor que um publicador envia, por convenção (o hub do Google e a maioria dos outros o usam; a própria especificação deixa o mecanismo de notificação do publicador não especificado). Diz ao hub “este tópico mudou, vá buscá-lo novamente.”
• subscribe / unsubscribe — estes SÃO definidos pela especificação (Recomendação W3C, parâmetro obrigatório hub.mode), usados por assinantes que se registram ou cancelam o registro para atualizações de um tópico, cada um exigindo verificação do hub e uma concessão renovável. Os mecanismos de busca lidam com isso por conta própria; você não envia isso.

Fatos rápidos

• Hub público do Google: pubsubhubbub.appspot.com — confirmado ativo em 18/07/2026.
• O WebSub funciona apenas com feeds (RSS/Atom) — não com páginas arbitrárias.
• Para URLs gerais (não-feed) em mecanismos que suportam push em tempo real, isso é IndexNow, não WebSub. O programa separado de envio de notícias PubHub do Bing parou de aceitar novas inscrições em junho de 2025.
• Renomeado de PubSubHubbub para WebSub em outubro de 2017; Recomendação W3C desde janeiro de 2018, republicado em 2 de junho de 2026 com mitigações apenas de segurança. Mesmo protocolo, ambos os nomes ainda funcionam com o hub do Google.

Erros que quebram o WebSub silenciosamente

Anunciar o hub, mas não o link rel="self". O hub precisa das duas tags — rel="hub" para saber para onde enviar os assinantes, rel="self" para confirmar exatamente qual URL de feed seu ping se refere. Envie apenas o link do hub e algumas implementações de hub não conseguirão corresponder seu ping ao seu feed de forma confiável.

Enviar ping com o hub.url errado. O valor tem que ser a URL do próprio feed (a mesma do seu link rel="self") — não a página inicial do site, não uma URL de post individual, não uma URL com parâmetros de rastreamento anexados. Um hub.url incompatível significa que o hub não pode verificar o tópico e o ping não faz nada.

Esperar que o WebSub substitua os sitemaps. Um sitemap é seu mapa abrangente de todo o site; o WebSub apenas transmite mudanças em um feed que você já anunciou. Remova o sitemap e você perde o mapa do mecanismo de tudo o que não está nesse feed.

Achar que um ping significa “indexado”. Um 2xx bem-sucedido do hub apenas significa que o hub aceitou sua notificação e vai buscar o feed novamente. Isso não diz nada sobre se o Google (ou qualquer outra pessoa) rastreou, renderizou ou indexou as páginas para as quais o feed aponta — essas são etapas separadas do pipeline.

Tentar usar WebSub para páginas que não estão em um feed. O WebSub cobre apenas o que está dentro do feed sobre o qual você enviou o ping. Para uma atualização de página única fora de qualquer feed, o WebSub não tem nada a oferecer — para isso existe o IndexNow (Bing e outros) ou a ferramenta Inspeção de URL do Google.

Confiar silenciosamente que todo ping foi bem-sucedido. Pipelines de publicação que disparam o ping e nunca verificam a resposta podem ficar meses com uma integração quebrada (URL de hub errada após uma migração, uma regra de firewall bloqueando POSTs de saída) antes que alguém perceba que as atualizações do feed pararam de se propagar. Veja Testes de Validação para saber o que verificar de fato.

Executar seu próprio hub sem proteção de callback e entrega. A maioria dos publishers nunca precisa disso — o hub do Google ou o integrado ao seu CMS cobre o caso de uso de SEO. Mas se você montar seu próprio hub (uma ferramenta interna de sindicação, por exemplo), as Considerações de Segurança da especificação apontam riscos reais que uma implementação ingênua não percebe: um hub que busca ou faz POST cegamente para qualquer URL que um cliente fornecer fica exposto a server-side request forgery (buscando endereços internos/privados), então valide e restrinja URLs de callback e tópico conforme a orientação de SSRF da OWASP. E não prometa aos assinantes entrega exatamente-uma-vez — novas tentativas de HTTP significam que um callback pode receber a mesma distribuição de conteúdo mais de uma vez, então uma implementação do lado do assinante precisa tratar a entrega como pelo-menos-uma-vez e deduplicar/processar de forma idempotente, não assumir um único POST limpo por atualização.

Envie o ping ao hub e confirme que funcionou

Bash / curl — ping com código de status visível

curl -s -o /dev/null -w "%{http_code}\n" \
  -d "hub.mode=publish&hub.url=https://example.com/feed.xml" \
  https://pubsubhubbub.appspot.com/

Um 204 ou 202 impresso de volta significa que o hub aceitou a notificação. Qualquer outra coisa (um 4xx/5xx, ou uma falha de conexão) significa que o ping não chegou — verifique a URL do hub e o valor de hub.url do seu feed antes de assumir que funcionou.

Python — mesmo ping, para integrar em um hook de publicação

import requests

HUB_URL = "https://pubsubhubbub.appspot.com/"
FEED_URL = "https://example.com/feed.xml"

response = requests.post(
    HUB_URL,
    data={"hub.mode": "publish", "hub.url": FEED_URL},
    timeout=10,
)

if response.status_code in (202, 204):
    print(f"WebSub ping accepted ({response.status_code})")
else:
    print(f"WebSub ping failed: {response.status_code} {response.text}")

Chame isso logo após seu CMS ou build de site estático publicar um novo post — no mesmo momento em que você regeneraria o feed em si. É seguro chamar em toda publicação; reenviar ping para um feed inalterado não causa dano, apenas diz ao hub para verificar novamente.

Prove que o WebSub realmente disparou

Verificações de aprovação/reprovação para depois de configurar o link do hub e o ping de publicação. Elas são propositalmente escalonadas: cada uma só prova sua própria etapa na cadeia publisher → hub → assinante, e o último salto — o hub realmente entregando a um assinante, e esse assinante agindo sobre isso — acontece completamente fora dos seus logs. Um publisher pode verificar as duas primeiras etapas diretamente e inferir a terceira a partir do novo fetch do próprio hub; nada aqui (ou em qualquer lugar no WebSub) permite que um publisher confirme que um assinante específico recebeu ou processou uma atualização.

Teste: o feed anuncia o hub e a si mesmo

• Teste a executar: Veja o código-fonte na URL do seu feed e procure por <link rel="hub" href="..."> e <link rel="self" href="..."> no nível do canal/feed.
• Resultado esperado: Ambas as tags presentes, com rel="self" correspondendo à URL exata em que você busca o feed.
• Interpretação de falha: rel="hub" ausente significa que não há hub para enviar ping em primeiro lugar; rel="self" ausente ou incompatível significa que o hub não consegue confirmar de forma confiável a qual tópico um ping se refere.
• Janela de monitoramento: Imediata — verifique logo após qualquer alteração no template do feed.
• Gatilho de rollback: Qualquer tag ausente ou rel="self" apontando para uma URL diferente daquela que os mecanismos de busca realmente buscam.

Teste: o ping de publicação retorna um status de sucesso

• Teste a executar: Envie um ping (veja a lente Scripts) e leia o código de status HTTP de volta.
• Resultado esperado: 204 No Content ou 202 Accepted.
• Interpretação de falha: Um 4xx geralmente significa uma solicitação malformada (valores hub.mode/hub.url ruins) ou um hub.url que o hub não reconhece como seu; um 5xx ou timeout significa que o próprio hub está inacessível — tente novamente antes de assumir uma falha permanente.
• Janela de monitoramento: Imediata — toda vez que seu fluxo de publicação dispara um ping.
• Gatilho de reversão: Respostas repetidas não-2xx em várias publicações — isso é uma integração quebrada, não um problema pontual.

Teste: o hub realmente buscou o feed novamente

• Teste a executar: Verifique os logs do seu servidor em busca de uma solicitação Feedfetcher-Google (ou do seu hub) contra a URL do feed logo após um ping bem-sucedido.
• Resultado esperado: Uma solicitação de busca contra a URL do feed dentro de aproximadamente alguns minutos após o ping.
• Interpretação de falha: Um ping 2xx sem uma busca de acompanhamento nos logs sugere que o hub aceitou a solicitação, mas não conseguiu resolver ou alcançar seu feed — vale a pena confirmar que a URL do feed está publicamente acessível e não bloqueada por robots.txt ou um firewall.
• Janela de monitoramento: Dentro de uma hora após uma publicação de teste; este é o mais lento desses checks, pois depende do próprio cronograma de busca do hub.
• Gatilho de reversão: Nenhuma busca aparece após vários pings de aparência bem-sucedida seguidos — trate o relacionamento com o hub como não verificado até que os logs confirmem isso.

Teste você mesmo: WebSub

Cinco perguntas rápidas sobre o que é WebSub, como funciona e onde estão seus limites. Escolha uma resposta para cada uma e depois confira.

Registro de alterações