Monitoramos 2.000 Manifests UCP Todos os Dias por um Mês. Veja o Que Quebra

No nosso último post, realizamos 180 sessões de compras com agentes de IA e mostramos o que acontece quando os modelos realmente tentam comprar coisas. Esses dados nos disseram quais modelos chegam ao checkout e quais caem no funil.

Mas isso deixou uma pergunta maior sem resposta: e quanto às lojas em si?

Uma sessão falhando porque Claude adivinhou um ID de variante errado é um problema do modelo. Uma sessão falhando porque o manifesto da loja desapareceu da noite para o dia é um problema de infraestrutura. E você não consegue distinguir a diferença a partir de uma única verificação.

Então, dez dias após o lançamento do UCP em 11 de janeiro, começamos a monitorar. Não uma verificação única — uma verificação contínua e automatizada de cada domínio em nosso pool, a cada 24 horas. Um mês depois, nosso rastreador realizou mais de 24.000 verificações em 2.008 domínios.

Veja o que os dados mostram.

O pool de monitoramento

Nosso rastreador acompanha 2.008 domínios, descobertos através de quatro canais:

• Extensão do navegador: 1.480 domínios — nossa extensão do Chrome investiga /.well-known/ucp em cada loja visitada e alimenta novos domínios no pool automaticamente. Taxa de verificação de 98,4% — as lojas que encontra são, em sua maioria, comerciantes reais com manifestos ativos.
• Rastreador: 407 domínios — um motor proprietário que descobre continuamente novas lojas habilitadas para UCP.
• Web: 120 domínios — verificações manuais enviadas através do ucpchecker.com por desenvolvedores e proprietários de lojas testando suas implementações.
• Verificação em massa: 1 domínio único — envios em lote, principalmente domínios que já estamos rastreando.

Nenhuma fonte única cobre o quadro completo. O rastreador encontra lojas conhecidas de forma sistemática. A extensão captura lojas que não aparecem em nenhum diretório — marcas de nicho, varejistas regionais, pontos finais de desenvolvimento. Juntas, elas oferecem uma cobertura mais ampla do que qualquer uma das abordagens isoladamente.

A partir de 27 de fevereiro:

83% dos domínios têm um manifesto UCP funcionando. Essa é uma base sólida — mas a história interessante está nos outros 17%, e no que acontece com os manifestos que foram verificados ontem.

Os manifestos quebram. Mais frequentemente do que você imagina.

Durante o período de monitoramento, detectamos 457 mudanças de status em todo o pool. 95 dessas foram quebras: um domínio que foi verificado em uma verificação voltou inválido, inacessível ou bloqueado na próxima.
A divisão:

• 68 verificados → inválidos — o manifesto ainda existe, mas falha na validação. O modo de falha mais comum. Uma implantação envia um JSON ruim, um campo desaparece ou uma string de versão fica malformada.
• 14 verificados → inacessíveis — o ponto final expira completamente. Problema de infraestrutura, mudança de DNS ou má configuração de CDN.
• 7 verificados → bloqueados — o domínio começa a rejeitar o rastreador. Normalmente uma mudança de regra do WAF.
• 6 verificados → não detectados — o manifesto desaparece. O ponto final retorna 404 ou redireciona.

88 domínios únicos experimentaram pelo menos uma quebra durante o mês. Isso representa aproximadamente 5% das lojas verificadas que ficaram fora do ar em algum momento — e, em muitos casos, voltando.

O ciclo de recuperação

A boa notícia: a maioria das quebras é temporária.

Observamos 96 recuperações — domínios que estavam quebrados ou ausentes e depois voltaram:

• 69 inválidos → verificados (implantação ruim revertida)
• 13 inacessíveis → verificados (infraestrutura se recupera)
• 10 não detectados → verificados (novo manifesto publicado)
• 4 bloqueados → verificados (regras de bot relaxadas)

Isso cria um padrão que estamos chamando de "ciclo de recuperação do manifesto." O ponto final UCP de uma loja quebra — geralmente devido a um manifesto inválido — e tipicamente se recupera dentro de 24–48 horas.

Uma ressalva: estamos executando um ciclo de rastreamento de 24 horas, então o tempo real de recuperação pode ser mais curto. Uma loja que quebra e se corrige dentro de algumas horas entre as verificações não apareceria como uma transição — significando que a verdadeira taxa de quebra é provavelmente maior do que o que estamos relatando.

A implicação para desenvolvedores de agentes: só porque uma loja funcionou ontem não significa que funcione hoje. E só porque está quebrada agora não significa que desapareceu.

Os flappers

32 domínios mostraram sinais de instabilidade persistente — oscilando entre estados de funcionamento e quebrados várias vezes ao longo do mês. Estamos chamando esses de "flappers."

O ponto final mais instável mudou de status 22 vezes em um mês. Outros no top 10 incluem grandes varejistas e empresas de tecnologia conhecidas — nomes que você esperaria ter infraestrutura estável. Alguns estão executando implementações personalizadas de UCP fora do Shopify, o que pode explicar a instabilidade. Outros parecem estar testando ou iterando em produção.

Flapping é um sinal. Isso indica que o ponto final existe e alguém está trabalhando ativamente nele — mas ainda não é confiável o suficiente para um agente depender.

Para desenvolvedores de agentes construindo fluxos de produção contra lojas específicas, domínios flappers precisam de uma estratégia diferente: lógica de repetição, tratamento de fallback ou simplesmente esperar até que a implementação se estabilize.

Quem está bloqueando agentes — e o paradoxo

95 domínios estão bloqueando ativamente nosso rastreador:

• Bloqueios de firewall (1.179 instâncias de verificação) — o WAF do domínio rejeita a solicitação antes que ela chegue ao ponto final UCP. Isso inclui grandes varejistas como Kohl's, Macy's, Sears, REI, Neiman Marcus e Tiffany.
• Bloqueios de robots.txt (108 instâncias) — desautorização explícita do rastreador.

Aqui está o paradoxo que sinalizamos em nossa primeira auditoria e persiste: alguns desses domínios bloqueados têm manifestos UCP totalmente implantados. Eles construíram a infraestrutura para comércio agente e então trancaram a porta da frente.

Isso é quase certamente uma lacuna operacional — a equipe de segurança atualizando regras de firewall sem coordenar com a equipe de produto que lançou o UCP. Mas para os agentes, o resultado é um retorno difícil.

Robots.txt: a imagem de acesso

Entre os domínios verificados, verificamos robots.txt para seis maj