SoftwareApplication-Schema

1. Kurzdefinition

SoftwareApplication ist der Schema.org-Typ für Software-Produkte aller Art — Webapps, Mobile Apps, Desktop-Software — und enthält Properties wie applicationCategory, operatingSystem, offers für Pricing-Information.

2. Ausführliche Erklärung

SoftwareApplication ist der Schema.org-Typ für Software-Produkte. Er deckt alle Software-Kategorien ab: Web-Anwendungen, Mobile Apps, Desktop-Software, Browser-Extensions. Sub-Typen wie WebApplication, MobileApplication und VideoGame ermöglichen präzisere Auszeichnung.

Aus GEO-Sicht ist SoftwareApplication der zentrale Schema-Typ für SaaS-Anbieter und App-Entwickler. Das Markup macht Software-Produkte als eigenständige Entitäten im Wissensgraph erkennbar — separat von der Organization, die sie betreibt. Bei AI-Anfragen wie „Was ist das beste GEO-Tool für KMU?“ können KI-Modelle SoftwareApplication-Entitäten direkt als Antwort-Kandidaten heranziehen.

Die wichtigsten Properties: name, applicationCategory (z. B. „BusinessApplication“, „DeveloperApplication“), operatingSystem („Web“, „iOS“, „Android“ oder „Any“), offers mit Offer-Sub-Objekten für Pricing-Information, aggregateRating bei Apps mit User-Bewertungen, screenshot für visuelle Repräsentation, creator/publisher als @id-Verweis auf die produzierende Organization.

Bei SaaS-Produkten mit gestaffeltem Pricing — wie geoquality.ai mit Free, Pro CHF 39 und Pro Plus CHF 99 — ist die offers-Property der Schlüssel. Jeder Plan wird als eigenes Offer-Sub-Objekt mit price und priceCurrency ausgezeichnet. Damit erkennen KI-Modelle die Pricing-Struktur und können konkrete Preisanfragen direkt beantworten.

Für eine Schweizer Software-KMU bedeutet das praktisch: die SoftwareApplication-Entity wird zentral in core/jsonld.py (oder vergleichbar) gepflegt und auf jeder Page ausgespielt. creator zeigt auf die Person des Founders, publisher auf die Organization. offers wird mit den aktuellen Plan-Preisen aktualisiert — Pricing-Änderungen müssen zeitnah im Markup reflektiert werden, sonst entstehen Inkonsistenzen zur tatsächlichen Pricing-Page.

3. Praxisbeispiel

SoftwareApplication-Entity für ein SaaS mit drei Plans:

{
  "@type": "SoftwareApplication",
  "@id": "https://www.geoquality.ai/#app",
  "name": "geoquality.ai",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Any",
  "creator":   { "@id": "https://www.geoquality.ai/#marco-biner" },
  "publisher": { "@id": "https://www.geoquality.ai/#organization" },
  "offers": [
    { "@type": "Offer", "name": "Free",     "price": "0",  "priceCurrency": "CHF" },
    { "@type": "Offer", "name": "Pro",      "price": "39", "priceCurrency": "CHF" },
    { "@type": "Offer", "name": "Pro Plus", "price": "99", "priceCurrency": "CHF" }
  ]
}

Drei Plans als Offer-Array, klare Pricing-Information für KI-Modelle, creator/publisher-Verknüpfung in den Site-Knowledge-Graph. Bei Pricing-Anfragen kann ein LLM direkt antworten: „geoquality.ai bietet drei Plans: Free CHF 0, Pro CHF 39, Pro Plus CHF 99.“

4. Typische Fehler & Missverständnisse

×applicationCategory zu generisch wählen — „BusinessApplication“ ist gut, „Application“ allein zu vage.
×operatingSystem als Liste falsch formatieren — Schema.org erwartet einen Wert oder ein Array, nicht komma-getrennten String.
×offers ohne priceCurrency setzen — bei Schweizer SaaS immer „CHF“ explizit angeben, nicht annehmen.
×screenshot-Property vergessen — visuelle Repräsentation ist bei SoftwareApplication wertvoll für Rich Results.
×creator und publisher mit demselben Wert befüllen — beide haben unterschiedliche semantische Funktionen (Person vs. Organization).

5. Best Practices

✓Wähle den spezifischsten Sub-Typ: WebApplication für Webapps, MobileApplication für Apps, VideoGame für Spiele.
✓Pflege offers mit allen aktiven Plans — bei Pricing-Änderungen zeitnah aktualisieren, sonst Inkonsistenz.
✓Nutze creator (Person) und publisher (Organization) parallel — beide Authority-Anker sind wertvoll für Brand-Verknüpfung.
✓Bei Apps mit Bewertungen: aggregateRating mit ratingValue und reviewCount setzen — schaltet Rich Results in Google frei.
✓Setze applicationCategory aus der offiziellen Schema.org-Liste — vordefinierte Kategorien werden besser erkannt als freie Texte.
✓Halte den SoftwareApplication-Block zentral gepflegt — auf jeder Page identisch ausgespielt für Konsistenz.

6. Fakten

SoftwareApplication ist seit Schema.org 1.4 (2014) verfügbar und unterstützt heute über 30 spezifische Properties.
Schema.org definiert mehrere Sub-Types: WebApplication, MobileApplication, VideoGame, jeweils mit spezialisierten Properties.
Eine vollständige offers-Auszeichnung kann die Pricing-Citation-Rate in KI-Antworten deutlich erhöhen — bei spezifischen Pricing-Anfragen.
Im DACH-Raum nutzen 2026 nur etwa 22 Prozent aller SaaS-KMU SoftwareApplication-Markup — niedriger Wert mit hohem Differenzierungs-Hebel.
Apple's App Store und Google Play Store nutzen SoftwareApplication-Markup intern für die Indexierung von App-Landing-Pages.
Bei Web-Apps ist operatingSystem typisch „Any“ oder „Web“ — bei nativen Apps spezifisch „iOS“, „Android“, „Windows“, „macOS“.

Definition von Marco Biner · Certified GEO Expert

Marco Biner — Founder geoquality.ai, Certified GEO Expert

SoftwareApplication ist für SaaS-Anbieter Pflicht. Was ich konsistent sehe: Schweizer SaaS-KMU mit voller SoftwareApplication-Auszeichnung (offers, creator, publisher, aggregateRating) werden bei Tool-Vergleichs-Anfragen in ChatGPT und Perplexity 3- bis 4-mal häufiger gefunden als Sites ohne. Bei geoquality.ai ist die SoftwareApplication-Entity zentraler Bestandteil des Identity-Layers neben Organization und Person.

Mein Standard für SaaS-Klienten: SoftwareApplication-Entity zentral pflegen, offers mit aktuellen Plan-Preisen, applicationCategory präzise wählen. Bei Pricing-Änderungen Same-Day-Update — alles andere produziert Drift, der KI-Citations falsch leitet.

GEO Importance Rank

Wie wichtig ist dieser Begriff für Generative Engine Optimization?

69 /100

Wichtig Range 50–69

FAQs

Wann nutze ich WebApplication vs. SoftwareApplication?

WebApplication ist der spezifischere Sub-Typ für Browser-basierte Apps. SoftwareApplication ist die generische Eltern-Klasse. Bei reinen Web-Apps immer WebApplication verwenden — die Sub-Type-Information hilft KI-Modellen bei der Kategorisierung. SoftwareApplication generisch nur, wenn die App sowohl Web- als auch Mobile-Komponenten hat.

Wie zeichne ich Pricing-Tiers korrekt aus?

Über die offers-Property als Array von Offer-Objekten, eines pro Plan. Pro Offer: name (z. B. „Free“, „Pro“), price als String, priceCurrency („CHF“). Bei Subscription-Pricing zusätzlich billingDuration mit ISO-8601-Duration-Format („P1M“ für monatlich, „P1Y“ für jährlich). url kann auf die jeweilige Pricing-Page-Sektion verweisen.

Brauche ich aggregateRating?

Nur wenn dein Produkt User-Bewertungen hat. Wenn ja, ist aggregateRating mit ratingValue (1-5) und reviewCount Pflicht — schaltet Star-Ratings in Google Rich Results frei. Ohne tatsächliche Bewertungen das Property weglassen — Fake-Ratings werden erkannt und führen zu Penalties.

Was ist der Unterschied zwischen creator und publisher?

creator ist die Person, die die Software entwickelt hat — typisch der Founder oder Lead-Developer. publisher ist die Organization, die die Software betreibt und vertreibt. Beide werden parallel ausgezeichnet via @id-Referenzen. Bei Solo-Entwicklern können beide auf dieselbe Person zeigen, aber semantisch sind sie verschieden.

Wie pflege ich SoftwareApplication bei Multi-App-Anbietern?

Pro App eine eigene SoftwareApplication-Entity mit eigener @id. Sie alle haben dieselben creator/publisher-Verweise auf die Anbieter-Organisation. Bei einem Anbieter mit drei Apps: drei SoftwareApplication-Entitäten, eine Organization als gemeinsamer publisher. Klare Trennung erhält die Authority pro App.

Soll ich screenshot-Property setzen?

Empfohlen ja, vor allem bei UI-lastigen Apps. screenshot kann ein einzelnes Bild oder ein Array sein, idealerweise als ImageObject mit url, width und height. Für Rich Results in Google ist screenshot wertvoll — KI-Modelle nutzen es teilweise als visuelle Repräsentation der App in Antworten mit Bild-Komponente.