SoftwareApplication-Markup für SaaS-Angebote

Den Gegenstand der Seite vor dem Markup bestimmen

Prüfen Sie, ob die betreffende Seite wirklich eine Softwareanwendung beschreibt. Eine redaktionelle Anleitung, ein Beratungsangebot und die Produktseite einer webbasierten Anwendung erfüllen unterschiedliche Leseraufgaben. Das Markup sollte diesen Unterschied abbilden. Die bloße Erwähnung eines Tools in einem Blogartikel macht den Artikel nicht selbst zur Anwendung.

Legen Sie fest, welche konkrete Anwendung beschrieben wird und unter welcher stabilen Adresse die Produktinformation erreichbar ist. Name, Beschreibung und Anbieterbezug sollten zur sichtbaren Seite passen. Bei mehreren Produkten benötigen Sie eine nachvollziehbare Trennung; bei mehreren Preisvarianten dürfen Sie nicht versehentlich mehrere scheinbar verschiedene Anwendungen aus demselben Produkt machen.

Anwendung, Organisation und Angebot auseinanderhalten

Die Software ist der nutzbare Gegenstand. Die Organisation steht für den tatsächlichen Anbieter. Ein Angebot beschreibt kommerzielle Bedingungen, sofern diese wirklich öffentlich bestätigt sind. Diese Ebenen können in einem Datenmodell miteinander verbunden werden, sollten aber nicht durch beliebige Textfelder ineinander verschwimmen.

Eine kostenlose Vorbereitung, ein zeitlich begrenzter Test und ein dauerhaft kostenloser Tarif sind verschiedene Aussagen. Wenn nur eine davon zutrifft, darf die strukturierte Beschreibung nicht etwas anderes behaupten. Nutzen Sie für Tarifdetails dieselbe bestätigte Grundlage wie die sichtbare Preis- oder Produktseite. Änderungen an Preisen oder Verfügbarkeit müssen beide Ausgaben erreichen, nicht nur den Werbetext.

Eine passende ergänzende Entscheidungshilfe bietet Strukturierte Daten testen und Fehler beheben.

Ein Belegregister für Softwareangaben anlegen

Die folgende Zuordnung ist eine redaktionelle Vorbereitung für die technische Umsetzung. Sie ersetzt keine vollständige Prüfung sämtlicher Schema-Eigenschaften, macht aber die wichtigsten Herkunftsfragen sichtbar.

Lassen Sie unbelegte Angaben weg und dokumentieren Sie die offene Frage intern. Ein technisch vollständiger wirkender Datensatz ist fachlich schlechter, wenn er falsche Tatsachen enthält. Besonders Bewertungen dürfen nicht aus einer internen Wunschbewertung oder einem selbst entworfenen Beispiel übernommen werden.

Vereinfachtes Strukturbeispiel mit Platzhaltern

Dieses ausdrücklich schematische Beispiel zeigt nur die Zuordnung einer tatsächlichen Anwendung. Ersetzen Sie alle Platzhalter durch bestätigte sichtbare Angaben. Das Beispiel enthält absichtlich weder erfundene Bewertungen noch ein unbestätigtes Preisangebot und ist kein vollständiger Nachweis für eine besondere Google-Suchdarstellung.

{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "Platzhalter: bestätigter Anwendungsname",
  "url": "https://example.org/anwendung/",
  "description": "Platzhalter: tatsächlich bestätigte Beschreibung"
}

Prüfen Sie vor dem Einbau die aktuellen Anforderungen der tatsächlich gewünschten Suchfunktion und die fachliche Grundlage zusätzlicher Eigenschaften. Der kopierte Ausschnitt allein ist keine abgeschlossene Implementierung.

Schema-Gültigkeit und Google-Eignung getrennt prüfen

Schema.org beschreibt ein Vokabular zur strukturierten Beschreibung. Google dokumentiert zusätzlich, welche Angaben und Bedingungen es für seine jeweilige Suchfunktion berücksichtigt. Eine grundsätzlich verständliche Schema-Beschreibung ist deshalb nicht automatisch für jede besondere Suchdarstellung geeignet. Lesen Sie die aktuelle Google-Anleitung für Softwareanwendungen vor der Umsetzung.

Prüfen Sie erforderliche und empfohlene Angaben gegen Ihre reale Datenlage. Sind notwendige Nachweise nicht vorhanden, wird daraus eine offene Eignungsfrage und kein Auftrag zum Erfinden zusätzlicher Fakten. Auch eine technisch erfolgreiche Prüfung garantiert keine spätere Darstellung. Dokumentieren Sie deshalb Syntax, fachliche Deckung und mögliche Suchfunktion als getrennte Prüfergebnisse.

Die öffentliche Ausgabe mit dem sichtbaren Inhalt vergleichen

Kontrollieren Sie nach dem Einbau nicht nur die Vorlage im CMS. Rufen Sie die tatsächlich veröffentlichte Seite ab und untersuchen Sie alle ausgegebenen strukturierten Daten. Plugins, Themes und individuell ergänzte Blöcke können gleichzeitig Angaben erzeugen. Widersprüchliche Preise oder doppelte, unterschiedlich benannte Anwendungen sollten vor der Veröffentlichung geklärt werden.

Prüfen Sie außerdem Verbindungen zwischen den beschriebenen Objekten. Ein Anbieterbezug darf nicht versehentlich auf eine alte Testorganisation zeigen. Bildadressen, Produkt-URL und Angebot sollten öffentlich erreichbar und fachlich zugeordnet sein. Wiederholen Sie den Vergleich nach einem Tarifwechsel oder einer größeren Produktänderung. Ein einmal bestandener Test schützt nicht vor späteren Widersprüchen.

Fiktives Beispiel: eine Webanwendung mit Testphase

Ein Anbieter betreibt eine browserbasierte Fachanwendung und bietet einen befristeten Test an. Die Produktseite erklärt den tatsächlichen Testumfang und verweist auf aktuelle Konditionen. Das Team beschreibt zunächst nur bestätigte Anwendungseigenschaften und den richtigen Anbieter. Es übernimmt keine frei erfundenen Bewertungen, um einen Prüfhinweis verschwinden zu lassen.

Vor der Freigabe wird der Testablauf noch einmal mit dem öffentlichen Angebot verglichen. Stellt sich heraus, dass ein Tarif gewählt werden muss, wird dieser Umstand verständlich erklärt. Das Beispiel ist ein Modell für die Abstimmung von Inhalt und Daten; es verspricht keinen sicher erreichbaren Suchvorteil.

Die Pflege an fachliche Änderungen koppeln

Benennen Sie eine Zuständigkeit für Produktbeschreibung und Konditionen. Die technische Pflege kann bei der Entwicklung liegen, die fachliche Bestätigung muss aber von der Stelle kommen, die das tatsächliche Angebot verantwortet. Halten Sie fest, welche Änderung eine erneute Prüfung auslöst: neue Nutzungsbedingungen, anderer Preis, geänderter Name oder eingestellte Funktion.

Speichern Sie eine freigegebene Sollfassung mit dem zugehörigen Seitenstand. Vergleichen Sie bei Problemen zunächst diese Fassung mit der öffentlichen Ausgabe. Das verhindert, dass ein Templatefehler als neues inhaltliches Problem behandelt wird. Der Nutzen liegt in einer konsistenten Produktbeschreibung und einer überprüfbaren Datenpflege, nicht in einem versprochenen Ranking.

Die übergreifenden Grundlagen vertieft der Leitfaden Strukturierte Daten: Geeignete Typen auswählen.

Eine passende Vertiefung für die nächste konkrete Aufgabe bietet AI Visibility für SaaS mit ehrlichen Einrichtungs- und Integrationsangaben.

Häufige Fragen.