Eine Kanzlei-Website kann inhaltlich tadellos sein und trotzdem für Suchmaschinen und KI-Systeme unscharf bleiben, weil im Hintergrund die strukturierten Daten fehlen, die der Maschine sagen, wer hier eigentlich auftritt. Genau dafür gibt es Schema.org. Dieser Artikel zeigt dir, welche Typen eine Anwaltskanzlei wirklich braucht, mit kopierfertigem JSON-LD und den Fehlern, die wir in der Praxis am häufigsten sehen.
Er knüpft an die allgemeine Einführung Schema.org & Structured Data für Einsteiger an und übersetzt sie auf den konkreten Fall der Kanzlei. Wer zuerst wissen will, was Schema überhaupt leistet, liest dort. Wer es konkret umsetzen will, ist hier richtig.
Warum Schema.org für Kanzleien überhaupt zählt
Strukturierte Daten sind die Schicht, mit der du einer Maschine unmissverständlich mitteilst, was auf deiner Seite steht: Das hier ist eine Kanzlei, sie sitzt in dieser Stadt, sie deckt diese Rechtsgebiete ab, und diese Personen arbeiten dort. Ohne diese Schicht muss Google sich alles aus dem Fließtext zusammenreimen. Mit ihr liest es die Fakten direkt aus.
Für Kanzleien ist das besonders relevant, weil Mandanten zunehmend über lokale Suchen und über KI-Assistenten wie ChatGPT, Perplexity oder Googles AI Overviews recherchieren. Diese Systeme arbeiten mit Entitäten: Sie wollen wissen, ob „Kanzlei Mustermann" eine eindeutige, konsistent beschriebene Einheit ist. Saubere strukturierte Daten sind die Grundlage dafür, korrekt erkannt und zitiert zu werden. Eine ehrliche Einordnung gehört aber dazu: Schema ist Hygiene, kein Ranking-Wunder. Warum das so ist, erklärt der Artikel Schema-Mythos: Was wirklich zählt.
Der richtige Basistyp: LegalService, Attorney oder LocalBusiness?
Die häufigste Weichenstellung, und die häufigste Fehlentscheidung, ist der Basistyp. Hier die Lage, Stand 2026:
| Typ | Wofür | Status / Hinweis |
|---|---|---|
| LegalService | Die Kanzlei als Betrieb | Empfohlener Haupttyp. Subtyp von LocalBusiness, erbt Adresse, Telefon, Öffnungszeiten, areaServed |
| Person | Die einzelnen Anwälte | Je ein Objekt, verknüpft über employee / worksFor |
| Attorney | (früher: einzelne Anwälte) | Deprecated: „LegalService is more inclusive and less ambiguous". Meiden. Ist zudem kein Person-Typ |
| ProfessionalService | (früher: generischer Betrieb) | Deprecated wegen Verwechslung mit dem Typ Service. Meiden |
| LocalBusiness | Generischer Fallback | Nur, wenn nichts Spezifischeres passt. Für Kanzleien tut es das aber |
Die Empfehlung ist deshalb klar: LegalService als Haupttyp deiner Kanzlei-Seite, je ein Person-Objekt für jede Anwältin und jeden Anwalt. Ein spezifischer Typ schlägt einen generischen, und beide veralteten Typen, Attorney wie ProfessionalService, sind bei Schema.org ausdrücklich abgekündigt. Wer sie heute noch einbaut, signalisiert Maschinen einen überholten Stand.
Die Pflicht-Properties: Was rein muss
So sieht ein vollständiges, valides JSON-LD für die Kanzlei selbst aus. Es gehört als eigener <script>-Block in den Seitenkopf. Das Beispiel nutzt eine fiktive Bremer Kanzlei. Werte natürlich durch deine ersetzen:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "LegalService",
"@id": "https://www.musterkanzlei.de/#kanzlei",
"name": "Kanzlei Mustermann & Partner",
"legalName": "Mustermann & Partner Rechtsanwälte PartG mbB",
"url": "https://www.musterkanzlei.de",
"logo": "https://www.musterkanzlei.de/logo.png",
"image": "https://www.musterkanzlei.de/kanzlei.jpg",
"telephone": "+49 421 1234567",
"email": "kanzlei@musterkanzlei.de",
"address": {
"@type": "PostalAddress",
"streetAddress": "Musterstraße 1",
"addressLocality": "Bremen",
"postalCode": "28195",
"addressRegion": "Bremen",
"addressCountry": "DE"
},
"areaServed": [
{ "@type": "City", "name": "Bremen" },
{ "@type": "AdministrativeArea", "name": "Niedersachsen" }
],
"openingHoursSpecification": [{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
"opens": "09:00",
"closes": "17:00"
}],
"knowsAbout": ["Arbeitsrecht", "Familienrecht", "Mietrecht"],
"sameAs": [
"https://www.linkedin.com/company/musterkanzlei",
"https://www.anwalt.de/musterkanzlei"
],
"employee": [
{ "@id": "https://www.musterkanzlei.de/#ra-mustermann" }
]
}
</script>Die wichtigsten Bausteine im Klartext:
- @id: eine stabile, eindeutige Kennung der Kanzlei, auf die du aus anderen Objekten verweisen kannst. So entsteht ein verknüpfter Graph statt loser Einzelteile.
- address als
PostalAddress: Straße, Ort, PLZ, Region, Land getrennt ausgezeichnet, nicht als ein Textklumpen. - areaServed: dein Einzugsgebiet. Für lokale Auffindbarkeit der stärkste Hebel im Markup.
- knowsAbout: deine Rechtsgebiete als Liste. Das ist das thematische Signal, an dem KI-Systeme deine Spezialisierung festmachen.
- employee: verweist per @id auf die Person-Objekte der Berufsträger (siehe nächster Abschnitt).
Bewusst nicht im Beispiel: priceRange. Bei Anwaltshonoraren ist eine pauschale Preisspanne selten aussagekräftig und berufsrechtlich heikel. Lass das Feld weg, statt eine irreführende Angabe zu machen.
Berufsträger korrekt auszeichnen: Person mit @id-Referenz
Die einzelnen Berufsträger modellierst du als Person, jeweils mit eigener @id und zurückverknüpft zur Kanzlei:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Person",
"@id": "https://www.musterkanzlei.de/#ra-mustermann",
"name": "Dr. Erika Mustermann",
"jobTitle": "Rechtsanwältin, Fachanwältin für Arbeitsrecht",
"worksFor": { "@id": "https://www.musterkanzlei.de/#kanzlei" },
"knowsAbout": ["Arbeitsrecht", "Kündigungsschutz"],
"alumniOf": { "@type": "CollegeOrUniversity", "name": "Universität Bremen" },
"memberOf": {
"@type": "Organization",
"name": "Rechtsanwaltskammer Bremen",
"url": "https://www.rak-bremen.de"
},
"sameAs": ["https://www.linkedin.com/in/erika-mustermann"]
}
</script>Zwei Details, die in der Praxis oft schiefgehen: Erstens gehört der legalName ausschließlich zur Organisation, nicht zur Person. Eine Anwältin hat im Schema keinen „legalName". Zweitens muss ein im jobTitle geführter Fachanwaltstitel real geführt werden dürfen. Schema-Angabe und tatsächliche Berechtigung müssen übereinstimmen, sonst entsteht aus einer Marketing-Nachlässigkeit schnell ein berufs- oder wettbewerbsrechtliches Problem. Was eine Kanzlei werblich überhaupt sagen darf, behandelt der Spoke BORA-Novelle und Kanzlei-Website.
Die Mitgliedschaft in der zuständigen Rechtsanwaltskammer über memberOf als eigenes Organization-Objekt ist ein starkes Vertrauenssignal. Es belegt die Zulassung maschinenlesbar.
Jeder Berufsträger ist damit eine eigene Entität mit stabiler @id. Ob eine solche Person dafür auch eine eigene Seite als kanonisches Zuhause braucht oder nicht, erklärt der Spoke Grounding Pages und Entitäten.
Ergänzende Typen, die sich lohnen
Über das Fundament hinaus gibt es eine Handvoll Typen, die je nach Seite sinnvoll sind:
- BreadcrumbList: der Navigationspfad. Fast immer sinnvoll und unkompliziert.
- FAQPage: auf Ratgeber- und Rechtsgebiets-Seiten, aber nur für echte, sichtbare Fragen. Wichtig: FAQ-Markup bringt seit 2026 keine Rich Results mehr in Google (dazu gleich mehr). Für die maschinelle Auslesbarkeit durch KI-Systeme bleibt es trotzdem nützlich.
- Service mit
hasOfferCatalog: einzelne Rechtsgebiete als Leistungen modelliert. Achte auf die korrekte Schreibweise: Die Property heißthasOfferCatalog, nicht „hasOfferingCatalog". Letzteres existiert bei Schema.org nicht. - WebSite mit SearchAction, nur, wenn es eine echte interne Suche gibt.
Und ein Typ, von dem wir ausdrücklich abraten: AggregateRating bzw. Review in Eigenregie. Bewertungssterne, die eine Kanzlei über sich selbst auf der eigenen Seite einbettet, wertet Google als Richtlinienverstoß. Die Seite verliert dadurch die Berechtigung für das Sterne-Snippet. Echte Bewertungen gehören auf unabhängige Plattformen, nicht ins selbst gepflegte Markup.
Die fünf häufigsten Schema-Fehler auf Kanzlei-Seiten
- Falscher Basistyp. Attorney oder ProfessionalService statt LegalService, beide sind deprecated. Oder nur ein nacktes Organization ohne lokale Eigenschaften.
- Schema ≠ sichtbarer Inhalt. Angaben im Markup, die auf der Seite gar nicht stehen. Google wertet das als Verstoß und kann Rich Results komplett entziehen.
- Erfundene Bewertungssterne. Selbst eingebettete AggregateRating-Werte ohne echte, unabhängige Grundlage.
- Mehrere widersprüchliche Blöcke. Doppelte Kanzlei-Entitäten in verschiedenen Skripten, ohne sie über eine gemeinsame @id zu verknüpfen.
- Titel ohne Deckung. Ein Fachanwaltstitel im jobTitle, der real nicht oder nicht mehr geführt werden darf.
So prüfst du dein Markup
Bevor das JSON-LD live geht, gehört es durch zwei Werkzeuge, und danach unter Beobachtung:
- Google Rich Results Test: zeigt, ob und welche Rich-Results-Typen Google aus deinem Markup erkennt.
- Schema.org Validator (validator.schema.org): prüft Syntax und Struktur unabhängig von Google.
- Search Console: nach dem Live-Gang die Berichte zu Verbesserungen und strukturierten Daten beobachten.
Die Reihenfolge ist simpel: erst validieren, dann veröffentlichen, dann in der Search Console nachhalten. Wer das überspringt, merkt Fehler erst, wenn die Darstellung in der Suche kippt.
Was dieser Artikel nicht beantwortet
Keine allgemeine Schema-Einführung. Was Schema.org und JSON-LD grundsätzlich sind, steht in Schema.org & Structured Data für Einsteiger.
Kein Ranking-Versprechen. Warum Schema allein keine Plätze nach oben schiebt, erklärt Schema-Mythos: Was wirklich zählt.
Kein Werberecht im Einzelfall. Was eine Kanzlei sagen darf, regelt die BORA, dazu BORA-Novelle und Kanzlei-Website. Für konkrete Fragen ist die Kammer oder eine Fachanwältin zuständig, nicht dieser Artikel.
Keine anderen freien Berufe. Vieles davon gilt sinngemäß auch für verwandte Berufe mit eigenen Stolperfallen. Wie eine Steuerberater-Website aufgebaut sein sollte, behandeln wir gesondert.
Häufige Fragen
Welcher Schema.org-Typ ist für eine Anwaltskanzlei richtig?
LegalService für die Kanzlei als Ganzes, ein Subtyp von LocalBusiness, der Adresse, Telefon, Öffnungszeiten und areaServed erbt. Für einzelne Anwältinnen und Anwälte je ein Person-Objekt, verknüpft über employee bzw. worksFor. Die früher gängigen Typen Attorney und ProfessionalService sind bei Schema.org beide deprecated.
Sind Attorney und ProfessionalService noch gültige Schema-Typen?
Nein. Schema.org markiert Attorney als deprecated mit dem Hinweis, LegalService sei umfassender und eindeutiger. ProfessionalService gilt ebenfalls als deprecated, weil es regelmäßig mit dem Typ Service verwechselt wurde. Nutze stattdessen LegalService plus Person.
Bringt Schema.org meiner Kanzlei bessere Google-Rankings?
Nicht direkt. Schema ist kein klassischer Ranking-Faktor. Strukturierte Daten machen deine Seite maschinenlesbar und ermöglichen eine saubere Entitäts-Erkennung in Suche und KI-Antworten, die Grundlage für korrekte Darstellung, aber kein Garant für eine bessere Platzierung.
Darf ich Bewertungssterne selbst auf meiner Kanzlei-Seite einbinden?
Nein. Wenn die bewertete Einheit die Bewertungen über sich selbst kontrolliert, ist die Seite laut Google nicht für das Sterne-Snippet berechtigt. Das gilt auch für eingebettete Bewertungs-Widgets. Im Zweifel weglassen.
Wie viele Schema-Typen braucht eine Kanzlei-Website?
In der Regel vier bis fünf: LegalService, je ein Person-Objekt, BreadcrumbList und auf passenden Seiten FAQPage, optional Service mit hasOfferCatalog. Entscheidend ist die korrekte Verschachtelung, nicht die Menge.
Bringt FAQPage-Markup noch Rich Results?
Nein. Google hat FAQ-Rich-Results 2023 stark eingeschränkt und 2026 vollständig eingestellt. FAQPage blendet keine aufklappbaren Fragen mehr in der Suche ein. Sinnvoll bleibt es, weil es Inhalte für KI- und Antwortsysteme strukturiert auslesbar macht.
Hinweis: Dieser Artikel ist eine technische Anleitung zu strukturierten Daten, keine Rechtsberatung. Berufsrechtliche Fragen rund um Titelführung, Werbung und Außendarstellung klärst du mit deiner Rechtsanwaltskammer oder einer fachkundigen Kollegin. Schema.org-Typen und Google-Richtlinien ändern sich. Maßgeblich ist der Stand vom 31. Mai 2026.
Quellen
- Schema.org: LegalService (Typdefinition & Vererbung)
- Schema.org: Attorney (deprecated)
- Schema.org: ProfessionalService (deprecated)
- Google Search Central: Review-Snippet-Richtlinie (self-serve)
- Google: Änderungen an FAQ- und HowTo-Rich-Results (08/2023)
- Google Search Central: FAQPage structured data
Ist deine Kanzlei-Website maschinenlesbar?
Der kostenlose KI- und Compliance-Check zeigt in wenigen Minuten, wie sauber deine Website strukturiert ist: Schema-Coverage, Performance und Barrierefreiheit auf einen Blick. Ohne Anmeldung. Wenn du danach mit uns sprechen willst, gibt es Festpreis-Umsetzung, und der Code gehört dir.
Check starten