Service Schema beschreibt eine konkrete Dienstleistung auf einer Leistungsseite und verbindet die Leistung maschinenlesbar mit dem Anbieter. Ein sauberes Service JSON-LD hilft Suchmaschinen und anderen Systemen, Leistung, Anbieter und Einzugsgebiet einzuordnen – ohne bessere Rankings oder eine besondere Darstellung in den Suchergebnissen zu garantieren.
In meiner Arbeit mit KMU sehe ich häufig dasselbe Problem: Die Website ist visuell schlüssig, beantwortet aber zentrale Fragen nicht eindeutig. Was wird konkret angeboten? Wer erbringt die Leistung? Für welche Zielgruppe ist die Leistung gedacht? In welchem Gebiet ist das Angebot verfügbar? Strukturierte Daten können vorhandene Informationen eindeutig auszeichnen, dürfen einen unklaren sichtbaren Seiteninhalt aber nicht kaschieren.
Service Schema ist die Auszeichnung einer real angebotenen und auf der Seite sichtbaren Dienstleistung mit schema.org/Service. JSON-LD ist das technische Format; die Leistungsseite bildet die verständliche und überprüfbare Grundlage.
Service Schema übersetzt eine klar beschriebene Leistung in eine maschinenlesbare Struktur. Fehlende oder widersprüchliche Inhalte kann das Markup nicht korrigieren.
Service Schema für Leistungsseiten: Wann ist es sinnvoll?
Service Schema ist sinnvoll, wenn eine Seite eine konkrete Dienstleistung oder eine klar abgegrenzte Leistungsgruppe beschreibt. Eine belastbare Leistungsseite beantwortet mindestens diese Fragen:
- Was wird angeboten? Zum Beispiel Markenstrategie, Webentwicklung, Beratung, Fotografie oder Prozessautomatisierung.
- Wer bietet die Leistung an? Etwa ein Unternehmen, ein lokaler Betrieb, eine Praxis oder ein selbstständiger Experte.
- Für wen ist die Leistung gedacht? Beispielsweise für inhabergeführte Betriebe, Hotels, Kanzleien oder kleine B2B-Teams.
- Wo wird die Leistung erbracht? An einem bestimmten Standort, in einer Region, in mehreren Ländern oder online.
- Was umfasst die Leistung? Die wesentlichen Bestandteile müssen auf der Seite verständlich beschrieben sein.
Eine geeignete Grundlage ist beispielsweise unsere Leistungsseite für strategisches Webdesign und Webentwicklung. Die Seite beschreibt Website-Strategie, Gestaltung, technische Umsetzung, Inhalte und Automatisierung als zusammenhängende Leistung. Damit enthält sie ausreichend sichtbare Informationen für ein passendes Service-Markup.
Weniger sinnvoll ist Service Schema auf dünnen Sammelseiten oder Seiten, die lediglich Fachbegriffe aufzählen. Eine Zeile mit „Branding, SEO, KI, Social Media, Webdesign und Beratung“ ist noch keine verständliche Leistungsbeschreibung. Das Markup würde in diesem Fall nur eine unklare Seite strukturiert wiedergeben.
Was schema.org/Service beschreibt
schema.org/Service ist ein Typ aus dem Vokabular von Schema.org. Der Typ beschreibt eine Dienstleistung, nicht das gesamte Unternehmen. Eigenschaften wie provider, areaServed, serviceType, url und gegebenenfalls offers ordnen die Dienstleistung fachlich und räumlich ein.
Für KMU unterscheide ich drei Ebenen:
- Organization beschreibt die übergeordnete Organisation und ihre Identität, etwa Name, Website, Logo und offizielle Profile.
- LocalBusiness ist eine spezifischere Form für einen lokalen Betrieb und kann unter anderem Standort, Adresse und Öffnungszeiten abbilden.
- Service beschreibt eine einzelne Dienstleistung oder eine klar zusammengehörende Leistungsgruppe.
Ein Betrieb sollte daher nicht das gesamte Unternehmen als Service modellieren. Stattdessen verweist die Dienstleistung über provider auf die bestehende Organization oder das passende LocalBusiness. Dadurch bleibt erkennbar: Das Unternehmen ist der Anbieter, die Leistung ist das Angebot.
Die wichtigsten Eigenschaften eines Leistungsseiten-Schemas
Ein gutes Leistungsseiten-Schema muss nicht möglichst umfangreich sein. In der Praxis ist ein schlankes, korrektes Modell besser als ein überladener Datenblock mit unklaren oder unbelegten Angaben.
- @type: Kennzeichnet den Knoten als Service.
- @id: Gibt der konkreten Dienstleistung eine stabile und eindeutige Kennung, üblicherweise als URL mit Fragment.
- name: Nennt die Leistung verständlich und ohne Aneinanderreihung von Suchbegriffen.
- description: Fasst die Leistung kurz zusammen. Die Aussage muss im sichtbaren Seiteninhalt nachvollziehbar sein.
- serviceType: Bezeichnet die Art der Dienstleistung, beispielsweise „Webdesign und Website-Entwicklung“.
- url: Verweist auf die konkrete Leistungsseite.
- provider: Verbindet die Dienstleistung über eine stabile @id mit der Organization oder dem LocalBusiness.
- areaServed: Beschreibt das tatsächliche Einzugsgebiet der Leistung.
- offers: Kann reale Angebotsinformationen abbilden, sofern diese mit dem sichtbaren Angebot übereinstimmen.
areaServed realistisch einsetzen
Bei areaServed zählt das tatsächliche Tätigkeitsgebiet. Ein Betrieb in Bozen sollte nicht automatisch „weltweit“ eintragen, nur weil Videogespräche möglich sind. Wenn Du in Südtirol vor Ort arbeitest und bestimmte Leistungen zusätzlich in Italien oder im DACH-Raum anbietest, sollte diese Unterscheidung aus der Leistungsseite hervorgehen.
offers auch ohne festen Preis verwenden
Ein Offer setzt nicht zwingend einen festen Preis voraus. Du kannst damit auch ein reales Angebot beschreiben, dessen Preis individuell kalkuliert wird. Die ausgezeichneten Angebotsinformationen müssen jedoch existieren und auf der Leistungsseite nachvollziehbar sein.
Wenn Du einen festen Paketpreis oder einen belastbaren Einstiegspreis veröffentlichst, kann das Markup den sichtbaren Preis abbilden. Wenn jedes Projekt individuell kalkuliert wird, darfst Du keine scheinbar genaue Zahl ergänzen, nur um das Schema vollständiger wirken zu lassen.
Service JSON-LD mit @graph und stabilen @id-Werten
Bei kleinen Websites kann ein einzelner JSON-LD-Block ausreichen. Sobald mehrere Seiten und Entitäten zusammenkommen, ist ein @graph häufig übersichtlicher. Organization, LocalBusiness, WebSite, WebPage und Service lassen sich darin als getrennte Knoten modellieren und über stabile @id-Werte verbinden.
Das folgende Beispiel zeigt eine Leistungsseite, deren Service-Knoten auf einen bestehenden Anbieter verweist:
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "LocalBusiness",
"@id": "https://www.beispielbetrieb.tld/#localbusiness",
"name": "Beispielbetrieb GmbH",
"url": "https://www.beispielbetrieb.tld/"
},
{
"@type": "Service",
"@id": "https://www.beispielbetrieb.tld/leistungen/webdesign/#service",
"name": "Strategisches Webdesign für KMU",
"description": "Planung, Gestaltung und technische Umsetzung von Unternehmenswebsites für kleine und mittlere Unternehmen.",
"serviceType": "Webdesign und Website-Entwicklung",
"url": "https://www.beispielbetrieb.tld/leistungen/webdesign/",
"provider": {
"@id": "https://www.beispielbetrieb.tld/#localbusiness"
},
"areaServed": [
{
"@type": "AdministrativeArea",
"name": "Südtirol"
},
{
"@type": "Country",
"name": "Italien"
}
]
}
]
}Entscheidend ist die gemeinsame @id des Anbieters. Wenn dieselbe Organization oder dasselbe LocalBusiness auf verschiedenen Seiten mit abweichenden Kennungen oder Unternehmensdaten angelegt wird, entstehen unnötige Doppelungen und Widersprüche.
Lege deshalb zuerst die zentrale Unternehmensentität fest. Der Beitrag zum Aufbau eines eindeutigen Entity Home zeigt, wie Du eine verlässliche Referenzseite für Dein Unternehmen schaffst. Die einzelnen Services können anschließend konsistent auf diese Entität verweisen.
Sichtbarer Seiteninhalt und JSON-LD müssen übereinstimmen
Der sichtbare Seiteninhalt ist die inhaltliche Referenz, das JSON-LD die strukturierte Beschreibung. Google verlangt, dass ausgezeichnete Inhalte für Nutzer sichtbar und für den Hauptinhalt der Seite relevant sind. Technisch korrektes Markup kann ungeeignet sein, wenn es fehlende oder irreführende Inhalte beschreibt. Das erläutert Google in den allgemeinen Richtlinien für strukturierte Daten.
Prüfe deshalb jede wichtige Aussage im Markup gegen die Seite:
- Wird die ausgezeichnete Dienstleistung tatsächlich erklärt?
- Ist der genannte Anbieter auf der Seite eindeutig erkennbar?
- Entspricht areaServed dem realen Tätigkeitsgebiet?
- Ist die Beschreibung sachlich korrekt und sichtbar nachvollziehbar?
- Stimmen Angebote und Preise mit den veröffentlichten Informationen überein?
- Sind ausgezeichnete Bewertungen echt, relevant und auf der Seite sichtbar?
Typische Fehler sind künstlich vervielfachte Services, überladene Namen, erfundene Bewertungen und unzutreffende Preisangaben. Unterleistungen sollten nicht allein deshalb als eigenständige Service-Knoten angelegt werden, um zusätzliche Suchbegriffe unterzubringen.
Schema-Validierung richtig durchführen
Eine belastbare Schema-Validierung besteht aus einer allgemeinen technischen, einer Google-spezifischen und einer inhaltlichen Prüfung. Die Werkzeuge beantworten unterschiedliche Fragen.
1. Schema Markup Validator
Der Schema Markup Validator prüft allgemeines schema.org-Markup. Der Validator erkennt verwendete Typen und Eigenschaften, ohne die Prüfung auf von Google unterstützte Suchfunktionen zu beschränken.
2. Rich Results Test
Der Rich Results Test prüft, welche von Google unterstützten Rich Results aus den strukturierten Daten einer Seite entstehen könnten. Google grenzt beide Werkzeuge in der Dokumentation zu den Testwerkzeugen für strukturierte Daten voneinander ab.
Service ist kein eigenständiger, von Google dokumentierter Rich-Result-Typ. Ein valides Service JSON-LD kann daher im Schema Markup Validator korrekt erkannt werden, während der Rich Results Test keine unterstützte Suchfunktion für den Service anzeigt. Das bedeutet nicht, dass das Service-Markup fehlerhaft ist.
3. Manuelle Inhaltsprüfung
Kein Validator kann beurteilen, ob eine Positionierung fachlich stimmt oder ein Leistungsversprechen im betrieblichen Alltag eingehalten wird. Vergleiche deshalb jede relevante Eigenschaft mit dem sichtbaren Seiteninhalt und den tatsächlichen Unternehmensdaten.
4. Kontrolle in der Google Search Console
Für generisches Service-Markup ist in der Google Search Console kein eigener Verbesserungsbericht zu erwarten. Nutze stattdessen die URL-Prüfung, um Indexierung, Abrufbarkeit und die von Google verarbeitete Seite zu kontrollieren. Eigene Berichte zu strukturierten Daten erscheinen nur für unterstützte Suchfunktionen und geeignete Datentypen.
Selbst korrekt implementierte strukturierte Daten garantieren keine besondere Darstellung. Strukturierte Daten schaffen bei unterstützten Typen eine technische Berechtigung, erzwingen aber weder ein Rich Result noch eine bessere Platzierung.
FAQ Rich Results: Was aktuell belegt ist
FAQ-Markup und FAQ Rich Results sind zwei verschiedene Dinge. FAQPage kann sichtbare Fragen und Antworten semantisch beschreiben. Ein FAQ Rich Result ist dagegen eine konkrete Darstellung in den Google-Suchergebnissen.
Eine vollständige Einstellung der FAQ Rich Results zum 7. Mai 2026 ist nicht belastbar belegt. Die offizielle Mitteilung von Google aus dem August 2023 besagt, dass FAQ Rich Results nur noch regelmäßig für bekannte, maßgebliche Behörden- und Gesundheitswebsites angezeigt werden. Für die meisten KMU ist daher praktisch nicht mit FAQ Rich Results zu rechnen. Die dokumentierte Einschränkung findest Du bei Google Search Central.
FAQ-Markup kann weiterhin verwendet werden, wenn die Fragen und Antworten sichtbar auf der Seite stehen und inhaltlich relevant sind. Du solltest FAQPage jedoch nicht mit der Erwartung einbauen, dadurch eine erweiterte Darstellung oder bessere Rankings zu erhalten.
Mein Prüfablauf für KMU
Bei kleinen Teams beginne ich mit der Leistungsseite, nicht mit dem Code. Dieser Ablauf verhindert, dass technische Details ein inhaltliches Problem verdecken:
- Leistung abgrenzen: Definiere, welche konkrete Dienstleistung die Seite beschreibt.
- Seite prüfen: Kontrolliere, ob Zielgruppe, Umfang, Anbieter und Einzugsgebiet sichtbar beantwortet werden.
- Anbieter identifizieren: Lege fest, ob der provider auf eine Organization oder ein LocalBusiness verweist.
- @id-Werte festlegen: Verwende stabile Kennungen für Anbieter und Service.
- JSON-LD modellieren: Zeichne nur reale, relevante und sichtbare Informationen aus.
- Allgemein validieren: Prüfe das Markup im Schema Markup Validator.
- Google-Funktionen prüfen: Nutze den Rich Results Test mit der richtigen Erwartung.
- Indexierung kontrollieren: Prüfe die URL nach der Veröffentlichung in der Google Search Console.
Bei mehreren Leistungsseiten priorisiere ich die wirtschaftlich und strategisch wichtigsten Angebote. Eine klar positionierte Hauptleistung ist ein besserer Ausgangspunkt als zahlreiche oberflächlich ausgezeichnete Unterleistungen. Eine ergänzende Reihenfolge für weitere Datentypen findest Du in unserem Leitfaden zu den Prioritäten strukturierter Daten für KMU.
Wann Du das Markup erneut prüfen solltest
Eine feste Prüfroutine kann sinnvoll sein. Wichtiger ist jedoch die Kontrolle nach konkreten Änderungen. Prüfe das Leistungsseiten-Schema insbesondere nach:
- einem Relaunch oder einem Wechsel des Website-Systems,
- einer Änderung der URL oder Seitenstruktur,
- einer wesentlichen Änderung der Dienstleistung,
- einer Änderung des Anbieters oder der Unternehmensform,
- einer Erweiterung oder Einschränkung von areaServed,
- neuen Paketen, Preisen oder Angebotsbedingungen,
- größeren Änderungen am sichtbaren Seiteninhalt.
Prüfe außerdem, ob bestehende @id-Werte weiterhin konsistent verwendet werden. Eine stabile Kennung sollte nicht bei jeder kleinen Textänderung ersetzt werden.
Was Service Schema nicht leisten kann
- Service Schema garantiert keine besseren Rankings.
- Service Schema garantiert keine Rich Results.
- Service Schema garantiert keine Erwähnung in KI-Antworten.
- Service Schema ersetzt keine klare Positionierung.
- Service Schema ersetzt keine vollständige Leistungsbeschreibung.
- Service Schema korrigiert keine widersprüchlichen Unternehmensdaten.
- Service Schema macht aus einer Sammelseite keine gute Leistungsseite.
Strukturierte Daten sind ein technischer Baustein innerhalb eines Systems aus Branding, Website, Inhalt und verlässlichen Unternehmensinformationen. Der Nutzen liegt in der konsistenten Beschreibung realer Leistungen, nicht in unbelegten Sichtbarkeitsversprechen.
Meine praktische Empfehlung
Beginne mit Service Schema, wenn Deine wichtigsten Leistungsseiten klar aufgebaut sind oder im Zuge eines Website-Projekts überarbeitet werden. Arbeite in dieser Reihenfolge:
- Positionierung klären: Wofür soll Dein Betrieb wahrgenommen werden?
- Leistungsseite schärfen: Welche konkrete Leistung wird für welche Zielgruppe angeboten?
- Anbieter konsolidieren: Stimmen Name, Standort, Website und Unternehmensidentität überein?
- Service JSON-LD erstellen: Übertrage nur sichtbare und belastbare Angaben.
- Entitäten verbinden: Verknüpfe Service und provider über stabile @id-Werte.
- Markup validieren: Nutze die Werkzeuge entsprechend ihrem Zweck.
- Änderungen pflegen: Aktualisiere Markup und sichtbaren Inhalt gemeinsam.
Wenn Du diese Reihenfolge einhältst, wird das Leistungsseiten-Schema zu einem sinnvollen Teil Deiner Website. Der konkrete Nutzen besteht in einer eindeutigen Beschreibung dessen, was Dein Unternehmen anbietet.
FAQ: Service Schema für Leistungsseiten
Bringt Service Schema bessere Rankings?
Nein, Service Schema garantiert keine besseren Rankings. Das Markup kann die Bedeutung einer Leistung klarer ausdrücken, ersetzt aber weder relevante Inhalte noch technische Qualität, Vertrauen und eine passende Suchintention.
Warum zeigt der Rich Results Test keinen Service-Typ an?
Service ist kein eigenständiger, von Google dokumentierter Rich-Result-Typ. Prüfe das Service JSON-LD deshalb mit dem Schema Markup Validator; der Rich Results Test zeigt nur von Google unterstützte Suchfunktionen an.
Braucht jede Unterleistung ein eigenes Service-Markup?
Nein. Eine Unterleistung braucht nur dann einen eigenen Service-Knoten, wenn sie klar abgegrenzt und auf der Seite ausreichend beschrieben ist. Kurze Aufzählungen oder einzelne Arbeitsschritte rechtfertigen nicht automatisch zusätzliche Services.
Soll jede Hauptleistung eine eigene Leistungsseite bekommen?
Für wirtschaftlich wichtige und deutlich unterschiedliche Leistungen ist eine eigene Seite häufig sinnvoll. Jede Seite muss jedoch einen eigenständigen Nutzen haben und darf nicht nur eine leicht veränderte Kopie derselben Beschreibung sein.
Kann ich mehrere Services auf einer Seite auszeichnen?
Ja, wenn die Seite mehrere eigenständige Dienstleistungen sichtbar und ausführlich beschreibt. Bei unterschiedlichen Angeboten erleichtern getrennte Leistungsseiten meistens die Zuordnung für Menschen und Maschinen.
Soll Service als eigener JSON-LD-Block oder in einem @graph stehen?
Beide Varianten können technisch funktionieren. Ein @graph ist besonders hilfreich, wenn Du mehrere Entitäten wie Organization, LocalBusiness, WebPage und Service über gemeinsame @id-Werte verbinden möchtest.
Wie verbinde ich Service mit Organization oder LocalBusiness?
Verweise im Feld provider auf die stabile @id Deiner Organization oder Deines LocalBusiness. Nutze auf der gesamten Website dieselbe Anbieterkennung, damit keine widersprüchlichen Unternehmensobjekte entstehen.
Muss ein Offer einen festen Preis enthalten?
Nein, ein Offer kann auch ohne festen Preis modelliert werden. Verwende offers aber nur für ein tatsächlich vorhandenes Angebot und bilde veröffentlichte Preise oder Bedingungen korrekt ab.
Kann ich FAQ-Markup weiterhin einsetzen?
Ja, wenn die Fragen und Antworten sichtbar auf der Seite stehen und für den Inhalt relevant sind. Für gewöhnliche KMU-Websites solltest Du daraus jedoch keine Erwartung auf FAQ Rich Results oder bessere Rankings ableiten.
Gibt es in der Google Search Console einen Service-Bericht?
Für generisches Service-Markup ist kein eigener Verbesserungsbericht zu erwarten. Nutze die URL-Prüfung für Indexierung und Abrufbarkeit; spezielle Berichte erscheinen nur für unterstützte strukturierte Datentypen und Suchfunktionen.
Wann muss ich Service Schema aktualisieren?
Prüfe das Markup nach Änderungen an Leistung, URL, Anbieter, Einzugsgebiet, Preisen oder sichtbarem Seiteninhalt. Auch nach einem Relaunch solltest Du alle @id-Verknüpfungen und JSON-LD-Blöcke erneut validieren.
