Local Schema Markup: Strukturierte Daten für lokale Suche

Wer ein lokales Unternehmen in Österreich betreibt, wird fast ausschließlich über Google gefunden. Der Marktführer hält hier 81,87 % Marktanteil bei Suchmaschinen (Stand Mai 2026), gefolgt von Bing mit 9,01 % und DuckDuckGo mit 2,75 %. Bei 8,69 Millionen Internetnutzern und einer Penetration von 95,3 % entscheidet die organische und lokale Suche maßgeblich darüber, ob eine Praxis, ein Handwerksbetrieb oder ein Restaurant Kundschaft gewinnt.

Damit Google und zunehmend auch KI-Systeme die Eckdaten eines lokalen Betriebs zuverlässig erfassen, reicht reiner Fließtext nicht aus. Local Schema Markup liefert diese Daten maschinenlesbar. Trotz des hohen Nutzens ist die Verbreitung gering: Laut Web Almanac 2024 erscheint LocalBusiness-Markup nur auf 3,97 % der mobilen Seiten und ist damit zwar der dritthäufigste JSON-LD-Typ, aber weit von einer Standardpraxis entfernt. Genau darin liegt eine reale Differenzierungschance. Dieser Artikel zeigt, wie LocalBusiness Schema aufgebaut ist, wie du es für einen österreichischen Betrieb korrekt implementierst und welche Fehler die häufigsten Ursachen für fehlende Rich Results sind.

Warum Local Schema Markup für lokale Sichtbarkeit zählt

Strukturierte Daten sind Code-Annotationen, die den Inhalt einer Seite explizit beschreiben, statt ihn nur darzustellen. Google empfiehlt dafür das Format JSON-LD, ein in einem <script>-Tag eingebettetes Datenobjekt. Der Web Almanac 2024 bestätigt den Trend: JSON-LD ist von 34 % im Jahr 2022 auf 41 % aller Seiten im Jahr 2024 gestiegen und gilt als das von Google bevorzugte und am schnellsten wachsende Format.

Für lokale Unternehmen erfüllt LocalBusiness Schema drei Funktionen. Es macht Standort, Öffnungszeiten und Kontaktdaten eindeutig auswertbar, es kann die Darstellung des Betriebs in den Suchergebnissen erweitern, und es liefert KI-Systemen wie Google AI Overviews oder Perplexity strukturierte Fakten für ihre Antworten. Anders als ein Google-Business-Profil, das du auf einer Plattform pflegst, gehört das Markup zu deiner eigenen Website und stärkt deren Autorität als primäre Datenquelle.

Wichtig ist die Erwartungshaltung: Schema ist kein direkter Ranking-Faktor. Es verbessert nicht die Position, sondern die Verständlichkeit und die Darstellung. Der Wert entsteht indirekt über bessere Datenqualität, höhere Klickbereitschaft durch Rich Results und konsistente Signale an Such- und KI-Systeme.

LocalBusiness Schema im Verhältnis zu Organization und WebSite

Drei Schema-Typen werden häufig verwechselt. Organization: beschreibt das Unternehmen als juristische oder geschäftliche Entität, ohne zwingenden lokalen Bezug. Es eignet sich für Marken und überregionale Firmen. WebSite: beschreibt die Website selbst, etwa für den Website-Namen, den Google in den Suchergebnissen anzeigt. Die Sitelinks-Suchbox, für die WebSite-Markup früher genutzt wurde, zeigt Google seit dem 21. November 2024 nicht mehr an. LocalBusiness: ist eine Spezialisierung von Organization und Place und beschreibt einen Betrieb mit physischem Standort und lokalem Einzugsgebiet. Nur LocalBusiness transportiert Adresse, Geo-Koordinaten und Öffnungszeiten als zentrale Eigenschaften.

Entscheidend ist die Wahl des richtigen Sub-Typs. Google empfiehlt ausdrücklich, den spezifischsten LocalBusiness-Sub-Typ zu verwenden, etwa Restaurant, DaySpa oder HealthClub. Schema.org definiert eine umfangreiche Hierarchie: Dentist für eine Zahnarztpraxis, Plumber für einen Installateur, Restaurant für Gastronomie, LegalService für eine Kanzlei. Existiert kein passender Sub-Typ, nutzt du den allgemeinen Typ LocalBusiness. Ein falscher oder zu allgemeiner Typ verschenkt Kontext, den spezialisierte Sub-Typen über zusätzliche Eigenschaften wie servesCuisine oder menu bereitstellen.

Pflicht- und empfohlene Eigenschaften im Detail

Google nennt in seiner Dokumentation zwei Pflicht-Eigenschaften: name und address vom Typ PostalAddress. Ohne diese beiden Felder ist das Markup nicht gültig. Alle weiteren Eigenschaften sind empfohlen und steigern den Nutzen erheblich.

• name: der exakte Geschäftsname, identisch mit Google Business Profile und Citations.
• address (PostalAddress): strukturierte Adresse mit streetAddress, postalCode, addressLocality (Ort), addressRegion (Bundesland) und addressCountry (für Österreich AT).
• geo (GeoCoordinates): latitude und longitude als Dezimalgrad. Präzise Koordinaten verbessern die Zuordnung in Maps, besonders bei mehrdeutigen Adressen.
• telephone: die Telefonnummer im internationalen Format mit Ländervorwahl, für Österreich beginnend mit +43.
• openingHoursSpecification: maschinenlesbare Öffnungszeiten mit dayOfWeek, opens und closes im 24-Stunden-Format.
• priceRange: das Preisniveau, etwa als Symbol (€€) oder Spanne.
• areaServed: das bediente Gebiet, sinnvoll vor allem für Betriebe ohne Laufkundschaft, die zu Kunden fahren.
• url, image, sameAs: Website, Foto und Verknüpfungen zu Profilen wie Google Business Profile, Facebook oder Branchenverzeichnissen.

JSON-LD Schritt für Schritt: Beispiel für einen Wiener Betrieb

Das folgende Beispiel zeigt ein gültiges Markup für eine fiktive Zahnarztpraxis in Wien. Beachte die österreichspezifische Formatierung: addressCountry auf AT, die Telefonnummer im +43-Format und der Dezimalpunkt (nicht Komma) bei den Geo-Koordinaten.

```html
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Dentist",
"@id": "https://www.zahnarzt-beispiel.at/#praxis",
"name": "Zahnarztpraxis Dr. Beispiel",
"image": "https://www.zahnarzt-beispiel.at/praxis.jpg",
"url": "https://www.zahnarzt-beispiel.at",
"telephone": "+43 1 5550123",
"priceRange": "€€",
"address": {
"@type": "PostalAddress",
"streetAddress": "Mariahilfer Straße 100",
"postalCode": "1070",
"addressLocality": "Wien",
"addressRegion": "Wien",
"addressCountry": "AT"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 48.198765,
"longitude": 16.345678
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday"],
"opens": "08:00",
"closes": "17:00"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": "Friday",
"opens": "08:00",
"closes": "13:00"
}
],
"sameAs": [
"https://www.google.com/maps/place/?q=place_id:BEISPIEL",
"https://www.facebook.com/zahnarztbeispiel"
]
}
</script>
```

Platziere den Block im <head> oder <body> der jeweiligen Seite, idealerweise auf der Startseite oder der Kontaktseite mit den vollständigen Standortdaten. Das Attribut @id mit einer eindeutigen URL ist wichtig, sobald du mehrere Entitäten verknüpfst oder mehrere Standorte abbildest. Jede angegebene Information muss auch sichtbar auf der Seite stehen.

NAP-Konsistenz: Schema, Google Business Profile und Citations

NAP steht für Name, Address, Phone. Diese drei Datenpunkte müssen über alle Quellen hinweg identisch sein: im LocalBusiness Schema, im Google Business Profile und in lokalen Citations wie herold.at, firmenabc.at oder Branchenverzeichnissen. Inkonsistenzen, etwa "Str." gegen "Straße" oder unterschiedliche Telefonformate, schwächen das Vertrauen der Suchmaschine in die Daten und können die lokale Sichtbarkeit beeinträchtigen.

Das Schema ist dabei die maschinenlesbare Bestätigung dessen, was auf dem Google Business Profile und in Citations steht. Die Eigenschaft sameAs verknüpft deine Website explizit mit diesen externen Profilen und hilft Suchmaschinen, die Einträge als dieselbe Entität zu erkennen. Pflege deshalb eine einzige verbindliche NAP-Schreibweise und übernimm sie überall unverändert. Konsistenz über mehrere Plattformen ist relevant, weil Konsumenten ohnehin mehrere Quellen prüfen: Laut einer US-Erhebung von BrightLocal nutzen 77 % der Konsumenten mindestens zwei Bewertungsplattformen in ihrer Recherche und 41 % sogar drei oder mehr.

AggregateRating und Review-Markup für lokale Unternehmen

Bewertungen sind ein starker Hebel im lokalen Umfeld. Laut der US-Studie von BrightLocal lesen 81 % der Konsumenten Bewertungen lokaler Unternehmen über Google, und 75 % lesen Online-Bewertungen "immer" oder "regelmäßig". Mit AggregateRating-Markup lässt sich die durchschnittliche Bewertung samt Anzahl auszeichnen. Auf der eigenen Website eines lokalen Betriebs bringt das aber keine Sterne in den Suchergebnissen.

Der Grund ist Googles Regel zu self-serving Reviews. Kontrolliert das bewertete Unternehmen die Bewertungen über sich selbst, sind Seiten mit LocalBusiness- oder Organization-Markup nicht für Bewertungssterne berechtigt. Das gilt auch für echte Kundenbewertungen auf der eigenen Website, egal ob sie direkt im Markup stehen oder über ein eingebettetes Widget mit Google- oder Facebook-Bewertungen kommen. Google empfiehlt aggregateRating und review im LocalBusiness-Markup nur für Websites, die Bewertungen über andere lokale Unternehmen sammeln, also etwa für Bewertungsportale. Sterne für einen lokalen Betrieb erscheinen deshalb über sein Google Business Profile, etwa im Local Pack, oder auf solchen Portalen. Für jedes Bewertungs-Markup gilt außerdem: ratingValue, reviewCount und bestRating müssen exakt den sichtbar dargestellten Daten entsprechen. Erfundene oder aggregierte Werte ohne sichtbaren Beleg verstoßen gegen die Richtlinien und können zu manuellen Maßnahmen führen.

Multi-Location, Service-Area-Businesses und @id-Verknüpfung

Betriebe mit mehreren Standorten benötigen pro Filiale ein eigenes LocalBusiness-Objekt mit eigener Adresse, eigenen Geo-Koordinaten und eigener @id. Lege für jeden Standort eine dedizierte Landingpage an und platziere dort das jeweils passende Markup. Über die @id lassen sich die Standorte konsistent referenzieren und mit einem übergeordneten Organization-Objekt verknüpfen, das den Mutterbetrieb beschreibt.

• Mehrere Filialen: je Standort eine eigene URL, eigene @id und eigenes LocalBusiness-Objekt mit standortgenauen Daten.
• Service-Area-Business: Betriebe ohne öffentlichen Standort, etwa mobile Handwerker, lassen Straße und Hausnummer weg, geben in address aber Ort, Postleitzahl, Bundesland und Land an, weil Google address als Pflichtfeld führt. Zusätzlich definieren sie areaServed mit den bedienten Orten oder Regionen.
• @id als Anker: Eine eindeutige @id pro Entität verhindert, dass Suchmaschinen mehrere Standorte zu einer Einheit verschmelzen, und erlaubt saubere Verknüpfungen zwischen Organization und einzelnen Filialen.

Validierung und Fehlerbehebung

Veröffentlichtes Markup gehört geprüft. Drei Werkzeuge ergänzen sich.

• Rich Results Test: Googles Test zeigt, ob aus dem Markup ein Rich Result entstehen kann und welche Eigenschaften fehlen oder fehlerhaft sind. Er ist der erste Anlaufpunkt für LocalBusiness.
• Schema Markup Validator (schema.org): Dieser Validator prüft die syntaktische und strukturelle Korrektheit nach der Schema.org-Spezifikation, unabhängig von Google-Rich-Results.
• URL-Inspektion in der Search Console: Mit „Live-URL testen“ zeigt sie, wie Google die Seite aktuell rendert. LocalBusiness führt sie nicht als erkanntes Element auf. Im gerenderten HTML siehst du aber, ob der JSON-LD-Block im gecrawlten Zustand ankommt, etwa bei clientseitig gerendertem JavaScript.

Behandle Warnungen und Fehler getrennt. Fehler verhindern Rich Results und müssen behoben werden, Warnungen betreffen fehlende empfohlene Eigenschaften und sollten ergänzt werden, sind aber nicht blockierend.

Local Schema Markup im Kontext von AI-Search und AEO

Strukturierte Daten gewinnen mit dem Aufstieg von KI-gestützter Suche an Bedeutung. Google AI Overviews, ChatGPT und Perplexity ziehen Fakten bevorzugt aus klar strukturierten, eindeutig attribuierten Quellen. LocalBusiness Schema liefert genau das: maschinenlesbare Aussagen zu Standort, Öffnungszeiten und Leistungen, die ein KI-System direkt in eine Antwort übernehmen kann.

Für Answer Engine Optimization (AEO) bedeutet das: Konsistente, sichtbare und mit Schema bestätigte Daten erhöhen die Wahrscheinlichkeit, dass ein lokaler Betrieb in KI-Antworten korrekt genannt wird. Das Markup ersetzt keine guten Inhalte, aber es reduziert Mehrdeutigkeit. Wenn Adresse, Telefonnummer und Öffnungszeiten sowohl im sichtbaren Text als auch im JSON-LD übereinstimmen, sinkt das Risiko, dass ein KI-System veraltete oder falsche Daten aus Drittquellen verwendet. Angesichts der geringen Verbreitung von LocalBusiness-Markup ist die saubere Implementierung ein realistischer Vorsprung gegenüber dem Wettbewerb.

Häufige Fehler bei Local Schema Markup

• Falscher oder zu allgemeiner Sub-Typ: LocalBusiness statt Dentist oder Restaurant verschenkt spezifischen Kontext und zusätzliche Eigenschaften.
• Inkonsistente NAP-Daten: Abweichungen zwischen Schema, Google Business Profile und Citations schwächen das Vertrauen der Suchmaschine.
• Markup ohne sichtbaren Seiteninhalt: Daten im JSON-LD, die nicht auf der Seite stehen, verstoßen gegen Googles Richtlinien und können ignoriert oder abgestraft werden.
• Self-serving Review-Markup: Bewertungs-Markup über den eigenen Betrieb auf der eigenen Website bringt bei LocalBusiness keine Sterne, auch bei echten Kundenbewertungen nicht.
• Falsche Formate: Telefonnummern ohne +43, Öffnungszeiten nicht im 24-Stunden-Format oder Geo-Koordinaten mit Komma statt Punkt führen zu Fehlern.
• Mehrere Standorte in einem Objekt: Filialen ohne eigene @id und eigene Seite verschmelzen und verlieren ihre individuelle Sichtbarkeit.

Erfolg messen: Rich Results, Impressionen und CTR

Den Erfolg von Local Schema Markup misst du primär in der Google Search Console. Einen eigenen Verbesserungsbericht für LocalBusiness gibt es dort allerdings nicht: Rich-Result-Statusberichte bietet die Search Console nur für bestimmte Typen wie Navigationspfade, Produkt-Snippets oder Rezensions-Snippets. Ob Google das Markup lesen kann, prüfst du deshalb mit dem Rich Results Test. Er unterstützt LocalBusiness und rendert die Seite so, wie Google sie verarbeitet. Die Wirkung misst du im Leistungsbericht über Impressionen und CTR.

• Fehler beheben: Teste jede geänderte Seite mit dem Rich Results Test und behebe gemeldete Fehler zeitnah.
• Impressionen beobachten: Steigende Impressionen für lokale Queries nach der Implementierung deuten auf bessere Erfassung hin. Filtere dazu im Leistungsbericht nach Österreich und nach Ortsnamen.
• CTR vergleichen: Vergleiche die CTR betroffener Seiten vor und nach dem Markup für dieselben Queries.
• Indexierung prüfen: Kontrolliere über die URL-Inspektion, ob die Seite indexiert ist und der JSON-LD-Block im gerenderten HTML steht.

Beachte, dass Rich Results nicht garantiert sind. Google entscheidet je nach Query und Qualität, ob ein erweitertes Snippet ausgespielt wird. Bewerte den Erfolg deshalb über die Kombination aus fehlerfreiem Markup, Impressionen und CTR, nicht über eine einzelne Kennzahl.

Weiterführendes

Local Schema Markup ist eine technische Grundlage, die ihren Wert erst im Zusammenspiel mit konsistenten Daten entfaltet. Beginne mit dem spezifischsten LocalBusiness-Sub-Typ, fülle die Pflichtfelder name und address sowie die wichtigsten empfohlenen Eigenschaften, und halte NAP über Website, Google Business Profile und Citations identisch. Validiere das Ergebnis mit dem Rich Results Test und der URL-Inspektion und überwache die Wirkung in der Search Console. Da nur ein kleiner Teil der Seiten LocalBusiness-Markup nutzt, ist eine saubere Implementierung für österreichische Betriebe ein konkreter und erreichbarer Vorteil in klassischer und KI-gestützter Suche.