---
title: SoftwareApplication-Schema
slug: software-application-schema
canonical_url: https://www.geoquality.ai/glossar/software-application-schema
md_url: https://www.geoquality.ai/glossar/software-application-schema.md
language: de
last_modified: 2026-05-03T00:00:00+00:00
related_terms: [article-schema, json-ld, organization-schema, person-schema, schema-org, structured-data]
content_hash: ac676f9787eec725
license: CC BY 4.0
author: Marco Biner (geoquality.ai)
schema_type: DefinedTerm
---

# SoftwareApplication-Schema

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.

## Erläuterung

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.

## 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.“

## Häufige Fehler

- 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).

## 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.

## 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“.

## FAQ

### 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.

## Experten-Definition

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.

## Verwandte Begriffe

- [Article-Schema](https://www.geoquality.ai/glossar/article-schema.md) — Article ist der Schema.org-Typ für redaktionelle Inhalte — Blog-Posts, News-Artikel, Reportagen, Fachbeiträge — und der wichtigste Schema-Typ für Content-Marketing in der GEO-Praxis.
- [JSON-LD](https://www.geoquality.ai/glossar/json-ld.md) — JSON-LD ist ein W3C-standardisiertes Format zur Einbettung strukturierter Daten in Webseiten — typischerweise nach Schema.org-Vokabular — und der von Google sowie allen grossen KI-Crawlern bevorzugte Weg, Entitäten und Beziehungen maschinenlesbar zu beschreiben.
- [Organization-Schema](https://www.geoquality.ai/glossar/organization-schema.md) — Organization ist der Schema.org-Typ für Unternehmen, Vereine, Stiftungen und Behörden — der primäre Authority-Anchor jeder Site und neben Person und WebSite einer der drei Pflicht-Entitäten in jedem GEO-Setup.
- [Person-Schema](https://www.geoquality.ai/glossar/person-schema.md) — Person ist der Schema.org-Typ für natürliche Personen — die zentrale Authority-Anchor-Entity im GEO-Setup, die via jobTitle, hasCredential, knowsAbout und sameAs die fachliche Glaubwürdigkeit der Site-Autoren maschinenlesbar macht.
- [Schema.org](https://www.geoquality.ai/glossar/schema-org.md) — Schema.org ist das von Google, Microsoft, Yahoo und Yandex gemeinsam entwickelte Vokabular zur strukturierten Beschreibung von Web-Inhalten — der De-facto-Standard für maschinenlesbare Auszeichnung und das technische Fundament jeder GEO-Strategie.
- [Strukturierte Daten](https://www.geoquality.ai/glossar/structured-data.md) — Strukturierte Daten sind maschinenlesbare Auszeichnungen von Web-Inhalten — typischerweise als JSON-LD im HTML-Head — die Entitäten, Beziehungen und Metadaten explizit benennen statt sie nur implizit im Fliesstext zu hinterlassen.

## Quelle und Zitation

- HTML-Original: https://www.geoquality.ai/glossar/software-application-schema
- Lizenz: CC BY 4.0
- Zitiervorschlag: "SoftwareApplication-Schema (geoquality.ai Glossar, Biner 2026)"
