Product- und Service-Markup nicht miteinander verwechseln

Wann ist Product-Markup richtig und wann muss eine Leistung als Service modelliert werden?

Product beschreibt ein angebotenes Gut oder eine klar als Produkt geführte Leistungseinheit mit passenden Produkteigenschaften. Service bildet eine erbrachte Tätigkeit und ihr Leistungsgebiet ab; entscheidend sind reale Angebotsform, sichtbarer Inhalt und die vom Vokabular vorgesehene Bedeutung.

Realer Angebotsgegenstand

• Realer Angebotsgegenstand – Die Seite macht eindeutig, ob Kunden ein standardisiertes Gut erwerben oder eine Tätigkeit durch einen Anbieter erhalten.

• Passende Eigenschaften – Preis, Anbieter, Gebiet, Modell und weitere Werte werden nur verwendet, wenn sie für den gewählten Typ fachlich zutreffen.

• Sichtbare Entsprechung – Name, Beschreibung, Angebot und Konditionen im Markup stimmen mit den für Nutzer sichtbaren Angaben überein.

Rich-Result-Typwahl

• Rich-Result-Typwahl – Ein Typ wird allein wegen einer erhofften Suchdarstellung gewählt und macht aus einer Dienstleistung ein fiktives Handelsprodukt.

• Unpassende Produktfelder – SKU, Lagerzustand oder Bewertung werden ergänzt, obwohl das reale Leistungsangebot diese Eigenschaften nicht besitzt.

• Gemischte Hauptentität – Eine Seite beschreibt Anbieter, Leistung und Paket, ohne klar zu benennen, welcher Gegenstand ihr Hauptinhalt ist.

Praxisbeispiel: „Rich-Result-Typwahl“

Eine Agentur verkauft ein fest benanntes Audit mit Umfang und Preis, erbringt dabei aber weiterhin eine fachliche Tätigkeit. Die Seite modelliert die Leistung und ihren Anbieter, statt Lagerbestand und Produktkennung zu erfinden; ein tatsächlich versendetes Handbuch bleibt dagegen ein Product.

Passende Eigenschaften

1. Angebotsform, Vertragseinheit und sichtbare Aussagen fachlich beschreiben, bevor ein Schema-Typ ausgewählt wird.

2. Nur passende Eigenschaften aus derselben kontrollierten Datenquelle in die jeweilige Entität übernehmen.

3. Gerenderte Ausgabe gegen Vokabular, Suchrichtlinien und Seiteninhalt prüfen und unzutreffende Felder entfernen.

Sichtbare Entsprechung

• Anteil ausgezeichneten Angebote mit fachlich begründeter Typwahl und vollständiger sichtbarer Entsprechung aller Kernwerte.

• Zahl validierter Felder, die zwar syntaktisch zulässig sind, aber den realen Angebotsgegenstand nicht korrekt beschreiben.

Verwandte Fragen und nächste Schritte

Von „Product- und Service-Markup trennen“ trennt Strukturierte Daten nur für tatsächlich sichtbare Inhalte verwenden eine wichtige Anschlussfrage ab: Warum müssen strukturierte Daten mit dem sichtbaren Seiteninhalt übereinstimmen?

Wer „Product- und Service-Markup trennen“ aus Sicht des Clusters „Lokales SEO & Entitätsmanagement“ vertiefen möchte, findet in Schema.org für LocalBusiness sauber und vollständig einsetzen die passende Einordnung.

Wenn du „Product- und Service-Markup trennen“ praktisch umsetzen möchtest, kannst du auf robuste Website-Systeme zurückgreifen. Dort stehen „Kommerzielle Typen und Bewertungsmarkups“ und „Realer Angebotsgegenstand“ im Mittelpunkt.

Fazit: Product- und Service-Markup trennen

Strukturierte Daten sollen Realität präzisieren, nicht das Angebot für Suchfunktionen umdeuten. Die fachliche Typbedeutung steht deshalb vor gewünschter Darstellung und verfügbaren Feldern.

Quellen und weiterführende Hinweise

Für Plattformverhalten, Begriffe und Prüfgrenzen bei „Product- und Service-Markup trennen“ sind diese Primärquellen maßgeblich.

• Review snippet structured data – Google Search Central: Offizielle Regeln für zulässige Bewertungsobjekte, erforderliche Properties und selbstbezogene Reviews.

• Product snippet structured data – Google Search Central: Offizielle Typ-, Property- und Inhaltsanforderungen für Produkt-Snippets in der Google Suche.

• Local Business structured data – Google Search Central: Offizielle Anleitung zur Auswahl passender LocalBusiness-Untertypen und zu Standort-, Öffnungs- und Unternehmensdaten.