Schema SoftwareApplication: il prezzo e la valutazione che decidono se appare

Lo schema SoftwareApplication è idoneo al risultato arricchito per le app di Google solo quando contiene tre elementi: name, offers.price e aggregateRating oppure review. Una pagina può dichiarare il nome e la categoria, omettere gli altri due e superare comunque qualsiasi validatore di sintassi. Valido non significa idoneo. La documentazione Google sulle app, letta il 2026-10-25, tratta un prezzo o una valutazione mancanti come una condizione non soddisfatta, non come un avviso.

Cosa richiede lo schema SoftwareApplication

Tre proprietà fanno il lavoro. Due sono facoltative in schema.org e obbligatorie per Google, ed è questa differenza che spiega perché tante pagine si fermano a un campo dal traguardo.

La valutazione è il punto in cui si fermano più team. Un aggregateRating richiede ratingValue e ratingCount; una review singola richiede autore e punteggio. Le linee guida Google sugli snippet di recensione sono esplicite: non aggregare recensioni o valutazioni prese da altri siti e non inserire recensioni false o incentivate senza dichiararlo. La valutazione deve riguardare il tuo prodotto e venire da persone che lo hanno usato.

applicationCategory accetta un valore dall'elenco supportato da Google. BusinessApplication, DeveloperApplication e DesignApplication sono nell'elenco; WebApplication è un tipo, non una categoria. Copia un valore dalla documentazione invece di inventare un'etichetta che suona bene.

Un risultato per le app è un nome con un prezzo e una valutazione. Se manca uno dei tre, Google non ha niente da mostrare.

Quale tipo usare: WebApplication, SoftwareApplication o Product

Un prodotto che gira nel browser è di solito una WebApplication; un'app desktop o mobile da installare è una SoftwareApplication; un articolo venduto da un catalogo è un Product. Google accetta tutti e tre, e l'errore è impilare due tipi sulla stessa pagina con prezzi diversi.

C'è un'eccezione documentata da conoscere prima di scegliere: Google non mostra il risultato arricchito per un'app che porta solo il tipo VideoGame. Serve un secondo tipo, per esempio MobileApplication. Il caso è ristretto, ma è proprio il genere di dettaglio che lascia un markup corretto senza alcun effetto visibile.

Se la pagina vende già un piano con prezzo e disponibilità, leggi prima come scrivere una landing page di prodotto e decidi quale tipo possiede il prezzo su quella pagina. Non marcare entrambi con cifre diverse.

Il deliverable: un blocco da incollare

Questo è il blocco minimo che può essere idoneo per un prodotto web con un piano gratuito. Sostituisci i quattro valori, mantieni la struttura.

{
  "@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"
  }
}

Il piano gratuito è la trappola classica: offers.price resta obbligatorio quando la risposta è zero, quindi scrivi "price": "0" invece di cancellare l'oggetto offer. Con un piano a pagamento usa il prezzo d'ingresso reale e conserva priceCurrency. Per un'app da scaricare cambia @type in SoftwareApplication e indica su quali piattaforme gira.

I valori devono venire dalla stessa scheda della tua descrizione prodotto per tutti i canali, così prezzo e nome non si separano tra una pagina e l'altra.

Aggiungi aggregateRating solo se la pagina mostra quella valutazione a chi la visita. Le regole generali sui dati strutturati chiedono che il markup descriva il contenuto visibile; una valutazione che vive solo dentro un tag script è una dichiarazione ingannevole. Le regole sulle recensioni aggiungono che le valutazioni aggregate devono venire da recensioni reali, non da un altro sito.

Il deliverable: il controllo in otto righe

Falle in ordine. Le prime quattro fermano un blocco che non può funzionare; le quattro successive fermano un blocco che funziona ma descrive la pagina sbagliata.

Il blocco va nel template della pagina, accanto a titolo e descrizione, così non si sposta quando qualcuno modifica il corpo. I valori devono venire da dove la pagina li rende; una valutazione scritta a mano è il primo campo che invecchia.

1. Incolla l'URL della pagina nel Rich Results Test e verifica che rilevi “Software app”.
2. Leggi gli errori prima degli avvisi. Una proprietà obbligatoria mancante è un errore; una consigliata mancante no.
3. Apri lo stesso URL nell'ispezione URL e controlla che l'HTML renderizzato contenga il blocco.
4. Segui il report sui dati strutturati in Search Console nei giorni successivi. Dice cosa ha trovato Google, non cosa volevi tu.

Perché un markup valido non appare comunque

I fallimenti prendono quattro forme e nessuna è un errore di sintassi. Il blocco viene analizzato, la pagina viene indicizzata, il risultato non esce mai.

La quarta riga è la più silenziosa. Spesso si marca l'annuncio di lancio perché è la pagina che il team modifica, mentre la pagina prodotto, quella che descrive davvero l'app, non porta nulla. Google valuta la pagina in cui si trova il blocco. Se il risultato deve apparire sulla pagina prodotto, il blocco deve stare lì.

C'è anche un fallimento precedente: il JSON è rotto, con una virgola in più o una virgoletta in meno. Il test mostra un errore di analisi e Search Console separa questi casi nel report sui dati strutturati illeggibili. Non serve indovinare.

Quello che non sappiamo e quando fermarsi

Non sappiamo con quale frequenza Google scelga di mostrare il risultato per le app quando una pagina è idonea. Google non pubblica un tasso di visualizzazione, non garantisce che una funzione basata sui dati strutturati appaia, e non l'abbiamo misurato abbastanza a lungo sulle nostre pagine per dare un numero. L'idoneità è nelle tue mani, la visualizzazione no.

C'è anche un caso in cui la risposta onesta è aspettare. Se il prodotto non ha ancora valutazioni reali, non inventare un numero e non copiarne uno da un sito di recensioni. Pubblica nome, categoria e prezzo, e aggiungi la valutazione quando utenti reali ne avranno lasciata una. Una valutazione assente costa il risultato arricchito; una fabbricata costa il markup, la pagina e la fiducia per cui era stata scritta.

Fermati quando il test elenca l'app senza errori e la pagina visibile corrisponde al blocco. Quello che resta è misurare se il risultato appare, e appartiene alla parte di analisi di ricerca e IA, non al codice sorgente.

Domande frequenti

A cosa serve lo schema SoftwareApplication?

È un markup schema.org che descrive un prodotto software su una pagina: nome, categoria, piattaforme, prezzo e valutazione. Google lo usa per decidere se la pagina può mostrare un risultato per le app con nome, prezzo e stelle.

Google supporta ancora questo markup?

Sì. La documentazione Google sulle app era ancora online e aggiornata al 2026-09-08 quando l'abbiamo letta il 2026-10-25, e il risultato per le app è ancora nell'elenco delle funzioni supportate. A differenza di FAQ e HowTo, non è stato ritirato.

Il markup per le app mostra le stelle?

Solo se porta una valutazione o una recensione. Con nome e prezzo ma senza valutazione, la pagina non soddisfa le proprietà obbligatorie. Con una valutazione inventata, il problema passa dalla visualizzazione alla conformità alle regole.

Devo scrivere SoftwareApplication e Product insieme?

No. Scegli il tipo che corrisponde a ciò che vende la pagina e lascia che uno possieda il prezzo. Due tipi con prezzi diversi sulla stessa pagina danno a Google due fatti contraddittori e a te nessun modo di sapere quale ha letto.

Perché il Rich Results Test non trova nulla?

Quasi sempre perché il JSON-LD viene aggiunto con JavaScript dopo l'HTML che il test vede per primo, o perché l'URL testato non è quello che porta il blocco. Renderizza il blocco lato server e testa l'URL esatto che deve posizionarsi, non la home.