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.

Wo „Product- und Service-Markup trennen“ an Nachbarthemen grenzt

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.

Für die praktische Umsetzung von „Product- und Service-Markup trennen“ verweist VELUNO auf robuste Website-Systeme. Der Schwerpunkt „Kommerzielle Typen und Bewertungsmarkups“ wird dort anhand von „Realer Angebotsgegenstand“ als plan- und prüfbares Vorhaben konkret.

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.