Web Stories no Google: ainda vale a pena produzir?

Um Web Story é um formato de página web feito de telas verticais em sequência, navegável por toque, construído sobre a especificação AMP. Ele ainda é suportado pelo Google, ainda pode aparecer no Discover e, com menos regularidade, na busca e no Google Imagens — mas o alcance deixou de ser tão previsível quanto era quando o formato foi lançado, e isso muda a conta de quando vale a pena investir tempo de produção nele.

Este texto foca no que decide essa conta: os requisitos técnicos que o formato realmente exige, onde ele aparece hoje e por que isso varia, e, mais importante, que tipo de conteúdo tem retorno sobre o custo de produzir uma imagem ou vídeo único para cada página da história. Não é um tutorial de como abrir um editor e arrastar elementos; é o raciocínio para decidir se vale a pena antes de gastar esse tempo.

O que é um Web Story, tecnicamente

Visualmente, um Web Story se parece com um story do Instagram ou do Snapchat: tela cheia, formato vertical, poucas palavras sobrepostas a uma imagem ou vídeo, avanço por toque na lateral da tela. A diferença que importa para SEO é estrutural: um Web Story vive em uma URL própria, no seu próprio domínio, é rastreável e indexável pelo Google como qualquer outra página — não fica preso dentro de um aplicativo fechado nem desaparece depois de 24 horas.

Por trás da experiência de deslizar instantaneamente de uma página para a próxima está o componente amp-story, parte do projeto AMP (Accelerated Mobile Pages). Cada "página" do story é, na prática, uma seção de HTML dentro de um único documento AMP, com camadas de imagem, texto e animação organizadas por tags específicas da especificação. É esse pré-carregamento agressivo entre páginas, e não uma ilusão de vídeo, que faz a navegação parecer instantânea mesmo em conexões mobile lentas.

Por que o formato ainda depende do AMP

Em 2021, o Google deixou de exigir que uma página fosse construída em AMP para aparecer no carrossel de Notícias em Destaque da busca, uma mudança que levou boa parte do ecossistema a tratar o AMP como assunto encerrado. O Web Story é a exceção que sobrou: o formato continua sendo especificamente uma implementação AMP, porque é a arquitetura do AMP, com pré-renderização e componentes restritos, que sustenta a promessa central do formato, que é a transição instantânea entre páginas.

Na prática, isso significa que um Web Story não é apenas uma página comum com aparência de story: ele precisa validar contra o AMP Validator, usar apenas as tags que a especificação amp-story libera (amp-story-page, amp-story-grid-layer, amp-img, amp-video, entre outras) e não pode carregar scripts customizados fora do que o AMP permite. Um erro de validação não gera um aviso discreto — pode simplesmente impedir que o Google trate o conteúdo como um Web Story elegível para as superfícies do formato.

Onde os Web Stories aparecem na prática

O Discover é a superfície mais consistente para o formato. Como o feed do Discover já é otimizado para consumo visual e rápido no celular, um Web Story compete de forma natural ali, ao lado de artigos e vídeos, para o mesmo público que consome aquele feed pelo hábito de rolar a tela.

Na busca propriamente dita, a presença é mais pontual. Um Web Story pode aparecer destacado no Google Imagens, ou ocasionalmente em um carrossel de histórias visuais dentro da página de resultados — mas esse posicionamento varia por mercado, por tipo de consulta e por período, e não é algo sobre o qual você tem controle direto ao publicar. Tratar a busca como o motivo principal para produzir Web Stories é apostar em um posicionamento que você não escolhe e não pode garantir.

Existe uma terceira superfície que é, na prática, a única totalmente sob seu controle: incorporar o próprio story dentro de uma página comum do seu site, usando o componente amp-story-player. Isso transforma o story em um elemento de uma página que você já controla e já rankeia — útil, por exemplo, para abrir um artigo com um resumo visual navegável antes do texto completo.

• Discover: a superfície mais estável para o formato
• Busca ou Google Imagens: posicionamento variável, fora do seu controle
• Incorporação via amp-story-player: a única superfície onde você decide se aparece

Metadados e imagens de capa exigidos pela validação

A especificação exige, no mínimo, uma imagem de capa vertical (poster-portrait-src), em proporção próxima de 3:4, além do logotipo do publisher (publisher-logo-src) em formato quadrado — é esse logotipo que aparece na atribuição ao lado do nome do site quando o story circula no Discover. Sem essas duas imagens no tamanho e na proporção corretos, o story simplesmente não chega a ser elegível para exibição, mesmo que o conteúdo em si esteja tecnicamente válido.

Duas variantes adicionais de capa, quadrada (poster-square-src) e horizontal (poster-landscape-src), são opcionais na especificação, mas sua ausência pode custar posicionamento em superfícies que preferem outra proporção de tela. Título, nome do publisher e data de publicação também fazem parte dos metadados que o Google lê para decidir como, e se, exibir o story fora do seu domínio.

• poster-portrait-src, obrigatório: proporção vertical, aproximadamente 3:4
• publisher-logo-src, obrigatório: formato quadrado, usado na atribuição
• poster-square-src e poster-landscape-src, recomendados: cobrem superfícies com outra proporção de tela
• Título, nome do publisher e data de publicação: lidos como metadados da própria história

Que tipo de conteúdo funciona no formato, e qual não funciona

O formato recompensa conteúdo que já é sequencial por natureza: um passo a passo visual, uma lista ordenada, um antes-e-depois, uma linha do tempo de um evento, uma vitrine de produtos. Cada página do story cabe pouquíssimo texto, poucas frases no máximo, então o conteúdo precisa se sustentar em uma sequência de imagens ou clipes curtos que contam a história por si só, com o texto funcionando como legenda, não como corpo do argumento.

É por isso que conteúdo analítico, argumentativo, ou que depende de qualificações e ressalvas, geralmente perde na tradução para o formato. Forçar um argumento com nuances em oito telas de poucas frases cada tende a produzir uma versão rasa do argumento original, não uma versão visual dele. O formato não é um resumo de um artigo; é um gênero diferente, com suas próprias regras de composição.

Um exemplo prático ajuda a ver a diferença: uma receita de cozinha se presta naturalmente ao formato, porque cada etapa do preparo já é uma unidade visual discreta e sequencial. Já uma comparação de preços entre concorrentes, ou uma explicação de como funciona um algoritmo de ranqueamento, não se presta bem — a informação relevante está nas relações entre as partes, não em uma sequência de imagens isoladas que possam ser lidas fora de ordem.

O custo real de produzir um Web Story

O custo que a maioria subestima não é o código AMP — hoje existem editores visuais que geram o markup automaticamente — é o custo de imagem. Um artigo de blog precisa, tipicamente, de uma imagem de destaque reaproveitada ao longo do texto. Um Web Story de oito a doze páginas precisa de oito a doze ativos visuais distintos, um por página, porque reaproveitar a mesma imagem em várias telas quebra a sensação de progressão que sustenta o formato e aumenta a chance de o leitor sair antes do fim.

Esse custo por página multiplica rápido quando o conteúdo não nasce de um processo que já produz esses ativos. Uma loja que já fotografa cada produto para o catálogo, ou uma redação que já cria cards para redes sociais a cada matéria publicada, reaproveita esse material com custo marginal baixo. Quem não tem esse fluxo precisa produzir de oito a doze imagens ou clipes de vídeo só para um único story, e é aí que o cálculo de retorno costuma virar negativo.

Há também um custo menos óbvio: manutenção. A especificação AMP evolui, e um template que valida hoje pode passar a acusar erros depois de uma atualização da especificação ou do próprio validador. Diferente de um artigo escrito uma vez que continua rankeando por anos, um Web Story tende a depender de frescor para aparecer no Discover, o que empurra para uma cadência de produção contínua, não um projeto pontual e isolado.

Quando vale a pena produzir

Vale a pena quando pelo menos duas condições se encontram: os ativos visuais já existem ou custam pouco para gerar dentro do fluxo de trabalho atual, e uma fração real do tráfego mobile do site já vem do Discover — o que indica que existe, de fato, um público naquele feed disposto a consumir esse tipo de conteúdo vindo do seu domínio. Sem o segundo sinal, você está produzindo para uma superfície onde ainda não tem histórico de leitores.

Também vale a pena quando o assunto em si é naturalmente visual e sequencial, o tipo de conteúdo descrito na seção anterior. Nesse caso, mesmo sem histórico forte de tráfego por Discover, o custo de produção tende a ser mais baixo, porque o material já "quer" ser contado em imagens em sequência.

Não vale a pena quando a produção parte do zero só na aposta de aparecer no Discover, quando o conteúdo é abstrato ou depende de nuance para fazer sentido, ou quando o site nunca teve tráfego relevante por aquela superfície. Nesses casos, o mesmo tempo investido em aprofundar um artigo já publicado tende a ter retorno mais previsível do que o tempo investido em um story novo.

• Ativos visuais já fazem parte do fluxo de produção, como fotos de produto ou cards de redes sociais
• Há tráfego mensurável vindo do Discover para o domínio
• O assunto é sequencial ou visual por natureza: passo a passo, lista, linha do tempo
• Existe capacidade de manter uma cadência de publicação, não apenas um story isolado

Erros que reduzem o alcance de um Web Story

A maioria dos problemas que limitam o alcance de um Web Story não está na estratégia, está na execução técnica, e por isso é relativamente fácil corrigir depois de identificada. Nenhum desses erros invalida o formato: eles só deslocam o retorno do investimento de um Web Story bem produzido, com metadados completos, ativos visuais originais por página e uma cadência de publicação sustentável.

• Transcrever o texto de um artigo página a página, sem adaptar para o ritmo visual do formato — texto em excesso por tela é o erro mais comum
• Publicar sem as variantes quadrada e horizontal da imagem de capa, o que pode custar exibição em superfícies que preferem outra proporção
• Colocar links de saída em praticamente todas as páginas, quando a orientação é reservar chamadas para ação a um número limitado de telas
• Não validar contra o AMP Validator antes de publicar, gerando falhas silenciosas na indexação do story
• Tratar o story como conteúdo publicado uma única vez, sem manter cadência, o que reduz a chance de reaparecer no Discover ao longo do tempo
• Reaproveitar a mesma imagem em páginas consecutivas para economizar tempo de produção, o que quebra a sensação de progressão que sustenta o formato