Esquema SoftwareApplication: o preço e a nota que decidem se ele aparece

O esquema SoftwareApplication só é elegível para o resultado enriquecido de aplicativo do Google quando traz três coisas: name, offers.price e aggregateRating ou review. Uma página pode declarar o nome e a categoria, deixar os outros dois de fora e ainda passar em qualquer validador de sintaxe. Válido não é elegível. A documentação do Google sobre aplicativos, lida em 2026-10-25, trata preço ou avaliação ausente como condição não cumprida, não como aviso.

O que o esquema SoftwareApplication exige

Três propriedades fazem o trabalho. Duas são opcionais no schema.org e obrigatórias para o Google, e é essa diferença que explica por que tantas páginas param a um campo do objetivo.

A avaliação é o que trava a maioria. Um aggregateRating precisa de ratingValue e ratingCount; uma review individual precisa de autor e nota. As diretrizes do Google para trechos de avaliação são explícitas: não agrupe avaliações ou notas de outros sites, e não inclua avaliações falsas nem incentivadas sem divulgar. A nota precisa ser do seu produto e vir de pessoas que o usaram.

applicationCategory recebe um valor da lista aceita pelo Google. BusinessApplication, DeveloperApplication e DesignApplication estão nela; WebApplication é um tipo, não uma categoria. Copie um valor da documentação em vez de inventar um rótulo que soe bem.

Um resultado de aplicativo é um nome com preço e nota. Se faltar um dos três, o Google não tem o que mostrar.

Qual tipo usar: WebApplication, SoftwareApplication ou Product

Um produto que roda no navegador costuma ser uma WebApplication; um aplicativo de desktop ou celular que precisa ser instalado é uma SoftwareApplication; um item vendido a partir de um catálogo é um Product. O Google aceita os três, e o erro é empilhar dois tipos na mesma página com preços diferentes.

Há uma exceção documentada que vale conhecer antes da escolha: o Google não mostra resultado enriquecido para um aplicativo que carrega apenas o tipo VideoGame. É preciso adicionar um segundo tipo, como MobileApplication. O caso é estreito, mas é exatamente o tipo de detalhe que deixa uma marcação correta sem efeito visível.

Se a sua página já vende um plano com preço e disponibilidade, leia antes como criar uma landing page de produto e decida qual tipo é dono do preço nessa página. Não marque os dois com números diferentes.

O entregável: um bloco para colar

Este é o menor bloco que pode ser elegível para um produto web com plano gratuito. Troque os quatro valores e mantenha a estrutura.

{
  "@context": "https://schema.org",
  "@type": "WebApplication",
  "name": "Example",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web",
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "USD"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "ratingCount": "128"
  }
}

O plano gratuito é a armadilha clássica: offers.price continua obrigatório quando a resposta é zero, então escreva "price": "0" em vez de apagar o objeto offer. Com plano pago, use o preço de entrada real e mantenha priceCurrency. Para um aplicativo que se baixa, troque @type por SoftwareApplication e diga em quais plataformas ele roda.

Os valores devem sair da mesma ficha da sua descrição de produto para todos os canais, para que preço e nome não se separem entre páginas.

Inclua aggregateRating só se a página mostra essa nota para quem visita. As regras gerais de dados estruturados pedem que a marcação descreva o conteúdo visível; uma nota que existe apenas dentro de uma tag script é uma declaração enganosa. As regras de avaliação acrescentam que notas agrupadas precisam vir de avaliações reais, não de outro site.

O entregável: a checagem em oito linhas

Faça na ordem. As quatro primeiras barram um bloco que não pode funcionar; as quatro seguintes barram um bloco que funciona mas descreve a página errada.

O bloco pertence ao template da página, ao lado do título e da descrição, para não sair do lugar quando alguém editar o corpo. Os valores devem vir de onde a página renderiza; uma nota escrita à mão é o primeiro campo a envelhecer.

1. Cole a URL da página no Rich Results Test e confirme que ele detecta “Software app”.
2. Leia os erros antes dos avisos. Propriedade obrigatória ausente é erro; recomendada ausente não é.
3. Abra a mesma URL na inspeção de URLs e verifique se o HTML renderizado contém o bloco.
4. Acompanhe o relatório de dados estruturados no Search Console nos dias seguintes. Ele diz o que o Google encontrou, não o que você queria.

Por que uma marcação válida ainda não aparece

As falhas costumam ter quatro formas, e nenhuma é erro de sintaxe. O bloco é analisado, a página é indexada e o resultado nunca sai.

A quarta linha é a mais silenciosa. Muitas equipes marcam o anúncio de lançamento porque é a página que editam, enquanto a página do produto, que de fato descreve o aplicativo, não leva nada. O Google avalia a página onde o bloco está. Se o resultado deve aparecer na página do produto, o bloco precisa estar lá.

Existe uma falha anterior: o JSON está quebrado, com uma vírgula a mais ou uma aspa a menos. O teste mostra um erro de análise e o Search Console separa esses casos no relatório de dados estruturados ilegíveis. Não é preciso adivinhar.

O que não sabemos e quando parar

Não sabemos com que frequência o Google escolhe mostrar o resultado de aplicativo quando uma página é elegível. O Google não publica taxa de exibição, não garante que um recurso com dados estruturados apareça, e não medimos por tempo suficiente nas nossas páginas para dar um número. A elegibilidade está no seu controle; a exibição não.

Há também um caso em que a resposta honesta é esperar. Se o produto ainda não tem avaliações reais, não invente um número nem copie um de um site de avaliações. Publique o nome, a categoria e o preço, e adicione a nota quando usuários reais tiverem deixado uma. Uma nota ausente custa o resultado enriquecido; uma fabricada custa a marcação, a página e a confiança para a qual ela foi escrita.

Pare quando o teste listar o aplicativo sem erros e a página visível corresponder ao bloco. O que sobra é medir se o resultado aparece, e isso pertence à parte de análise de busca e IA, não ao código-fonte.

Perguntas frequentes

Para que serve o esquema SoftwareApplication?

É uma marcação schema.org que descreve um produto de software em uma página: nome, categoria, plataformas, preço e nota. O Google usa isso para decidir se a página pode mostrar um resultado de aplicativo com nome, preço e estrelas.

O Google ainda aceita essa marcação?

Sim. A documentação de aplicativos do Google continuava no ar e com atualização de 2026-09-08 quando lemos em 2026-10-25, e o resultado de aplicativo segue na lista de recursos aceitos. Diferente de FAQ e HowTo, ele não foi retirado.

A marcação de aplicativo mostra estrelas?

Só se levar uma nota ou uma avaliação. Com nome e preço mas sem nota, a página não cumpre as propriedades obrigatórias. Com uma nota inventada, o problema deixa de ser exibição e passa a ser cumprimento de política.

Preciso escrever SoftwareApplication e Product juntos?

Não. Escolha o tipo que corresponde ao que a página vende e deixe um deles ser dono do preço. Dois tipos com preços diferentes na mesma página dão ao Google dois fatos contraditórios e a você nenhuma forma de saber qual foi lido.

Por que o Rich Results Test não encontra nada?

Quase sempre porque o JSON-LD é adicionado por JavaScript depois do HTML que o teste vê primeiro, ou porque a URL testada não é a que carrega o bloco. Renderize o bloco no servidor e teste a URL exata que deve ranquear, não a home.