SoftwareApplication-Schema: Apps in der Suche auszeichnen

Mit dem SoftwareApplication-Schema beschreibst du eine App oder Software in strukturierten Daten, sodass Google sie als eigenständiges Objekt mit Name, Preis, Kategorie und Bewertung versteht. Im besten Fall erscheint daraus ein erweitertes Suchergebnis mit Sternen, Bewertungszahl und Preisangabe. Garantiert ist das nie: Das Markup ist die Voraussetzung, nicht das Versprechen.

Der Teufel steckt in den Properties. Wer nur name und description einträgt, erzeugt zwar gültiges Schema.org-Markup, aber kein Rich Result. Google verlangt für die Darstellung bestimmte Felder, und zwei davon, offers und eine Bewertung, stolpern in der Praxis fast alle. Dieser Beitrag geht die Felder der Reihe nach durch, zeigt ein vollständiges JSON-LD-Beispiel und klärt, wann sich der Aufwand lohnt und wann nicht. Produktstrategie und Positionierung von Software-Seiten sind hier bewusst kein Thema, es geht ausschließlich um das Markup.

Was der Typ SoftwareApplication abdeckt

SoftwareApplication ist ein Typ aus dem Vokabular von Schema.org. Er beschreibt Programme jeder Art: Desktop-Software, Apps für Smartphones, Browser-Erweiterungen und Webanwendungen. Davon leiten sich zwei speziellere Typen ab, die Google in seiner Dokumentation ausdrücklich nennt: MobileApplication für Apps auf Smartphones und Tablets sowie WebApplication für Anwendungen, die im Browser laufen. Wer einen dieser Untertypen verwendet, erbt alle Properties von SoftwareApplication.

Die Wahl des Typs ist keine Formalie. Eine iOS-App als MobileApplication auszuzeichnen, sagt Suchmaschinen präziser, womit sie es zu tun haben, als der allgemeine Oberbegriff. Bei einem SaaS-Produkt, das nur im Browser läuft, ist WebApplication die naheliegende Wahl. Für klassische Programme zum Herunterladen bleibt es bei SoftwareApplication. Ein Sonderfall sind Spiele: Dafür gibt es den Typ VideoGame, der anderen Regeln folgt und hier nicht behandelt wird.

Wichtig ist außerdem, was der Typ nicht ist. Er beschreibt genau ein Produkt auf genau einer Seite. Eine Übersichtsseite, die zehn Tools auflistet, ist kein guter Kandidat für zehn SoftwareApplication-Objekte mit Sternen. Die Auszeichnung gehört auf die Detailseite, die das Produkt tatsächlich im Hauptinhalt behandelt.

Pflichtfelder laut Google: name, offers und Bewertung

Schema.org kennt für SoftwareApplication Dutzende Properties, aber Google verlangt für das erweiterte Ergebnis nur eine kleine Menge. Laut der Dokumentation zu Software-App-Markup sind das der Name der Anwendung, ein offers-Objekt mit einem Preis sowie eine Bewertung, entweder als aggregateRating oder als einzelnes review. Fehlt eines davon, markiert das Rich-Results-Test-Tool den Eintrag als ungültig für das erweiterte Ergebnis, auch wenn das Schema formal korrekt ist.

Bei der aggregateRating-Property braucht es den ratingValue, also den Durchschnittswert, und die Anzahl der Bewertungen, entweder als ratingCount oder als reviewCount. Wer stattdessen ein einzelnes review verwendet, muss einen Autor und eine reviewRating mit ratingValue mitliefern. Der Unterschied ist wichtig: aggregateRating fasst viele Stimmen zusammen, review steht für eine einzelne Kritik. Eine einzelne Redaktionsbewertung als aggregateRating zu tarnen, ist die falsche Abkürzung.

• name: der Produktname, so wie er auf der Seite und im Store steht.
• offers mit price: zwingend, auch wenn die Software kostenlos ist. Dann lautet der Preis 0.
• aggregateRating mit ratingValue und ratingCount oder reviewCount, alternativ ein review mit Autor und reviewRating.
• Empfohlen, aber nicht verpflichtend: applicationCategory, operatingSystem und priceCurrency im offers-Objekt.

offers: Preis, Währung und der Fall kostenloser Software

Das offers-Objekt ist die häufigste Fehlerquelle. Viele Teams tragen es nicht ein, weil ihr Produkt keinen festen Preis hat: SaaS mit Staffelpreisen, Freemium-Modelle, Angebote auf Anfrage. Google braucht aber einen konkreten Wert im Feld price. Bei kostenloser Software ist das die 0, und zwar als Zahl oder Zeichenkette ohne Währungssymbol. Die Währung gehört in ein eigenes Feld, priceCurrency, als dreistelliger Code nach ISO 4217, etwa EUR oder USD.

Bei Freemium-Produkten stellt sich die Frage, welcher Preis gemeint ist. Die ehrliche Antwort lautet: der Preis, den ein Besucher auf der Seite sieht und zu dem er das Produkt tatsächlich nutzen kann. Bietet die Seite eine kostenlose Stufe und mehrere bezahlte, ist der Einstiegspreis 0 vertretbar, sofern die kostenlose Stufe wirklich nutzbar ist und nicht nur eine befristete Testversion. Eine 14-tägige Probephase ist kein kostenloses Produkt. Hier gilt die Grundregel für alle strukturierten Daten: Das Markup muss dem entsprechen, was Nutzer auf der Seite lesen.

Für Staffelpreise lässt sich alternativ ein AggregateOffer verwenden, mit lowPrice und highPrice. Ob Google daraus die gleiche Darstellung ableitet wie aus einem einfachen Offer, ist nicht verbindlich zugesichert. Wer auf Nummer sicher gehen will, nennt den günstigsten tatsächlich buchbaren Preis und vermerkt auf der Seite, wofür er gilt.

aggregateRating: woher die Bewertungen kommen dürfen

Das Bewertungsfeld ist heikel, weil es am leichtesten zu missbrauchen ist. Google verlangt, dass Bewertungen, die im Markup stehen, auch für Nutzer auf der Seite sichtbar sind und dass sie sich auf das ausgezeichnete Produkt beziehen. Werte aus dem Nichts, erfundene Durchschnittswerte oder eine Bewertung, die auf der Seite nirgends nachvollziehbar ist, verstoßen gegen die Richtlinien für strukturierte Daten. Die Folge kann eine manuelle Maßnahme sein, bei der Google die Rich-Result-Berechtigung der Seite entzieht.

Legitime Quellen sind Bewertungen, die tatsächlich auf deiner Domain gesammelt und angezeigt werden, etwa Kundenstimmen auf der Produktseite, oder Store-Bewertungen, die du dort transparent ausweist, mit Quelle und Anzahl. Wichtig ist die Konsistenz: Steht im Markup 4,6 bei 312 Bewertungen, muss dieselbe Zahl sichtbar sein. Wenn sich der Durchschnitt ändert, muss das Markup mitziehen. Das gelingt zuverlässig nur, wenn beide Werte aus derselben Datenquelle gerendert werden, nicht aus zwei getrennt gepflegten Stellen.

Zwei weitere Details fallen oft durch. Erstens der Wertebereich: Standardmäßig geht Google von einer Skala von 1 bis 5 aus. Nutzt dein System eine andere Skala, gibst du bestRating und worstRating an. Zweitens die Mindestmenge: Es gibt keinen offiziellen Schwellenwert, aber ein Durchschnitt aus drei Bewertungen wirkt weder glaubwürdig noch stabil. Ob Google ihn anzeigt, entscheiden Algorithmen, die nicht offenliegen.

operatingSystem und applicationCategory

Diese beiden Felder sind laut Google empfohlen, nicht erforderlich. Sie liefern dennoch den Teil der Darstellung, der Nutzern bei der Auswahl hilft. Mit applicationCategory gibst du die Kategorie an, zum Beispiel GameApplication, BusinessApplication, MultimediaApplication oder SocialNetworkingApplication. Google nennt in seiner Dokumentation eine Liste zulässiger Werte, und es lohnt sich, daraus zu wählen statt eine eigene Bezeichnung zu erfinden.

Beim Betriebssystem ist die Schreibweise frei, sollte aber lesbar sein: zum Beispiel ANDROID, iOS oder Windows 11. Mehrere Systeme trennst du mit Komma oder führst sie als Liste auf. Bei reinen Webanwendungen wird das Feld oft vergessen, weil es scheinbar keinen Sinn ergibt. Sinnvoll ist dann ein Wert wie Web oder ein Hinweis auf unterstützte Browser. Wichtig ist, dass du nur Systeme nennst, die das Produkt tatsächlich unterstützt. Eine App, die es nur für iOS gibt, mit ANDROID auszuzeichnen, führt Nutzer in die Irre und ist ein Verstoß gegen die Richtlinien.

Weitere Properties sind optional, aber nützlich für das Verständnis: softwareVersion, downloadUrl, fileSize, screenshot oder featureList. Sie lösen meist keine eigene Darstellung im Suchergebnis aus. Sie helfen der Suchmaschine, die Seite thematisch einzuordnen, und sie machen das Markup für andere Maschinen lesbar, etwa Verzeichnisse oder Assistenten.

Ein vollständiges JSON-LD-Beispiel

Google empfiehlt JSON-LD als Format, weil es getrennt vom sichtbaren HTML im Head oder Body der Seite steht und sich leicht pflegen lässt. Das folgende Beispiel beschreibt eine fiktive Notiz-App für Android mit allen Pflicht- und Empfehlungsfeldern. Die Werte sind erfunden und dienen nur der Veranschaulichung: Der Typ ist MobileApplication, der Name lautet Notizblitz, die Kategorie ist BusinessApplication, das Betriebssystem ANDROID. Im offers-Objekt stehen price 0 und priceCurrency EUR. Die Bewertung lautet im aggregateRating-Objekt ratingValue 4.6 und ratingCount 312.

Alle diese Angaben gehören in ein einziges JSON-Objekt innerhalb eines script-Elements mit dem Typ application/ld+json. Die Angaben im Markup müssen mit der sichtbaren Seite übereinstimmen: Name, Preis und Bewertung stehen dort im Text. Nach der Veröffentlichung prüfst du die Seite mit dem Rich-Results-Test von Google und später in der Search Console, wo unter den Verbesserungen ein eigener Bericht für Software-Apps erscheint, sobald Google gültige Elemente findet. Dort siehst du Fehler, die den Test bestehen, aber im Live-Betrieb auffallen, etwa fehlende Felder auf einzelnen Seiten einer Vorlage.

Wann das Rich Result erscheint und wann nicht

Gültiges Markup ist eine Eintrittskarte, kein Anspruch. Google entscheidet pro Suchanfrage, ob ein erweitertes Ergebnis angezeigt wird. Erscheint es nicht, liegt das nicht zwingend an einem Fehler. Typische Gründe sind, dass die Seite für die Suchanfrage nicht gut genug rankt, dass die Bewertungsdaten als unzuverlässig gelten oder dass die Suchanfrage kein Interesse an einer Produktdarstellung zeigt. Wer nach einer Anleitung sucht, bekommt selten Sterne.

Außerdem verändert Google die Darstellung von Rich Results immer wieder, und einzelne Formate werden eingeschränkt oder abgeschaltet. Verlass dich deshalb nicht darauf, dass die Sterne dauerhaft sichtbar sind, und miss den Effekt: Vergleiche in der Search Console die Klickrate der betroffenen Seiten vor und nach der Einführung, am besten über einen Zeitraum mit vergleichbarer Nachfrage. Ein Anstieg der Klicks ist plausibel, aber nicht gesetzt, und eine pauschale Zahl dafür gibt es nicht.

Ein letzter Punkt betrifft Seiten, die ihre App selbst bewerten. Wer als Anbieter Sterne für das eigene Produkt einträgt, bewegt sich in einer Grauzone, die Google an anderer Stelle für Organisationen und lokale Unternehmen ausdrücklich eingeschränkt hat. Für Software-Apps gilt diese konkrete Einschränkung laut Dokumentation nicht in gleicher Weise, aber der Grundsatz bleibt: Bewertungen müssen echt, nachprüfbar und sichtbar sein.

Typische Fehler und wie du sie vermeidest

Die meisten Probleme entstehen nicht beim ersten Einbau, sondern im Betrieb. Eine Vorlage wird erweitert, ein Preis ändert sich, ein Plug-in schreibt zusätzliches Markup, und plötzlich widersprechen sich die Daten. Die folgende Liste deckt die Fehler ab, die in der Praxis am häufigsten auftreten.

• Doppeltes Markup: Ein Plug-in und ein handgeschriebenes Script erzeugen zwei SoftwareApplication-Objekte mit abweichenden Werten. Entscheide dich für eine Quelle.
• Veralteter Preis: Der Preis wurde auf der Seite geändert, aber nicht im Markup. Generiere beide aus demselben Feld.
• Fehlende Bewertung: Ohne aggregateRating oder review gibt es kein erweitertes Ergebnis, egal wie sauber der Rest ist.
• Falsche Währung oder Preisformat: 9,99 € im Feld price statt 9.99 mit priceCurrency EUR. Der Punkt ist das Dezimaltrennzeichen, Symbole gehören nicht hinein.
• Kategorielisten statt Detailseite: Markup auf Übersichtsseiten, die mehrere Produkte zeigen, ohne dass eines im Fokus steht.
• Mehrere Plattformen vermischt: Eine Seite für iOS, Android und Web mit einem einzigen Bewertungswert, der nur für eine Plattform gilt. Trenne die Seiten oder nenne die Quelle offen.
• Bewertung ohne Sichtbarkeit: Die Zahl steht nur im JSON-LD, nirgends im Text. Das ist der Klassiker für manuelle Maßnahmen.

Umsetzung im Alltag: Vorlage, Test und Monitoring

Bei einer einzelnen App genügt ein handgeschriebenes JSON-LD-Script. Sobald du mehrere Produkte oder Sprachversionen hast, lohnt sich eine Vorlage, die das Markup aus den Produktdaten erzeugt. Das verhindert, dass Seite und Markup auseinanderlaufen. Bei mehrsprachigen Seiten übersetzt du name und description pro Sprache, lässt aber Preis, Währung und Bewertung konsistent zur jeweiligen Sprachversion, weil Preise je nach Markt abweichen können.

Teste jede Vorlage vor dem Livegang mit dem Rich-Results-Test und zusätzlich mit dem Schema-Markup-Validator, der auch Properties prüft, die Google nicht auswertet. Beachte den Unterschied: Der Schema-Markup-Validator sagt dir, ob das Markup syntaktisch zu Schema.org passt. Der Rich-Results-Test sagt dir, ob es für eine Google-Darstellung ausreicht. Beide Antworten sind unabhängig voneinander.

Nach dem Livegang beobachtest du den Bericht in der Search Console. Gehen gültige Elemente plötzlich zurück oder tauchen neue Fehler auf, ist meist eine Vorlagenänderung die Ursache. Plane deshalb bei jedem Relaunch einen Stichprobentest der Produktseiten ein. Das kostet wenige Minuten und erspart dir wochenlanges Rätselraten, warum die Sterne aus den Suchergebnissen verschwunden sind.