LocalBusiness (Schema)

LocalBusiness ist der schema.org-Typ, mit dem eine Website ein Unternehmen mit physischem Bezug maschinenlesbar beschreibt: Name, Adresse, Telefonnummer, Öffnungszeiten, Geo-Koordinaten. Ausgeliefert wird er in der Regel als JSON-LD-Block im Quellcode. Google nutzt diese Angaben, um ein Unternehmen als Entität zu verstehen — die Dokumentation nennt ausdrücklich das hervorgehobene Knowledge Panel in Suche und Maps sowie Karussells zu kommerziellen Suchanfragen als mögliche Darstellungen.

LocalBusiness ist damit das Gegenstück zum Unternehmensprofil auf der eigenen Domain. Das Google Business Profile liefert die Daten aus Googles eigenem System; das Markup liefert sie aus der Quelle, die das Unternehmen selbst kontrolliert. Stimmen beide überein, verstärken sie sich. Widersprechen sie sich, hat man ein Konsistenzproblem — siehe NAP-Konsistenz.

Wo LocalBusiness im schema.org-Vokabular sitzt

LocalBusiness ist ein Untertyp von Organization und gleichzeitig von Place. Diese doppelte Herkunft erklärt, warum der Typ sowohl Organisations-Properties (legalName, sameAs, vatID) als auch Ortseigenschaften (geo, hasMap, openingHoursSpecification) trägt. Die vollständige Definition steht bei schema.org/LocalBusiness.

So spezifisch wie möglich auszeichnen

Google empfiehlt, statt des generischen LocalBusiness den passenden Untertyp zu verwenden. Das Vokabular kennt Dutzende davon, und die Liste ist überraschend feingliedrig:

• Gesundheit: Dentist, Physician, Pharmacy, MedicalBusiness, Optician, VeterinaryCare
• Recht und Beratung: LegalService, Attorney, AccountingService, InsuranceAgency, FinancialService
• Handwerk und Bau: Plumber, Electrician, RoofingContractor, HVACBusiness, Locksmith, HousePainter
• Gastronomie und Handel: Restaurant, CafeOrCoffeeShop, Bakery, Store, AutoRepair
• Dienstleistung: DaySpa, HealthClub, HairSalon, ProfessionalService, RealEstateAgent

Da LocalBusiness von Organization erbt, empfiehlt Google zusätzlich, die Organisationsfelder zu füllen — Logo, sameAs-Verweise auf offizielle Profile, Gründungsdaten, wo sie vorliegen. Bietet ein Betrieb mehrere Gewerke an, lassen sich mehrere Typen als Array angeben; additionalType unterstützt Google an dieser Stelle nicht:

{
  "@context": "https://schema.org",
  "@type": ["Electrician", "Plumber", "Locksmith"],
  "name": "Beispiel Haustechnik GmbH"
}

Pflicht- und empfohlene Properties

Googles Anforderungen sind minimal, die Wirkung der empfohlenen Felder ist es nicht. Erforderlich sind lediglich zwei Angaben; alles andere entscheidet darüber, wie vollständig die Entität wird.

Öffnungszeiten richtig auszeichnen

openingHoursSpecification ist das Feld, an dem die meisten Implementierungen scheitern, weil Sonderfälle nicht sauber abgebildet werden. Reguläre Zeiten kommen ohne validFrom und validThrough aus und gelten dann ganzjährig. Für Wochentage akzeptiert Google sowohl die kanonischen schema.org-URLs (https://schema.org/Monday) als auch die Kurzform (Monday). Öffnungszeiten über Mitternacht hinaus werden in einer einzigen OpeningHoursSpecification abgebildet, nicht in zwei. Saisonale Schließungen werden über validFrom und validThrough im Format JJJJ-MM-TT datiert.

"openingHoursSpecification": [
  {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
    "opens": "09:00",
    "closes": "18:00"
  },
  {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": "Saturday",
    "opens": "10:00",
    "closes": "14:00"
  }
]

Beispiel aus Googles Dokumentation

Das Referenzbeispiel der Google-Search-Central-Dokumentation zu strukturierten Daten für lokale Unternehmen zeichnet ein Restaurant als Restaurant aus — also über den Untertyp, nicht über LocalBusiness — und kombiniert image in drei Seitenverhältnissen, vollständige PostalAddress, geo, telephone im E.164-Format, servesCuisine, priceRange, eine menu-URL sowie vier OpeningHoursSpecification-Blöcke für unterschiedliche Wochentage. Das Muster ist übertragbar: erst den spezifischsten Typ wählen, dann die branchentypischen Zusatzfelder ergänzen, die dieser Typ mitbringt.

Mehrere Standorte und Abteilungen

Bei mehreren Niederlassungen gilt: pro Standort eine eigene Seite, pro Seite ein eigener LocalBusiness-Block mit der jeweiligen Adresse und der kanonischen URL dieser Seite. Eine Sammelseite, die alle Filialen in einem Markup-Block auflistet, erzeugt keine saubere Entität je Standort und rankt entsprechend schlecht. Eine stabile @id pro Standort — üblicherweise die Standort-URL mit Fragment — hilft, die Entität über Seitenumbauten hinweg wiedererkennbar zu halten.

Für Abteilungen innerhalb eines Standorts, die eigene Öffnungszeiten oder Rufnummern haben, ist department vorgesehen. Google gibt dafür eine Namenskonvention vor: {Unternehmensname} {Abteilungsname} — im Dokumentationsbeispiel „Dave's Department Store" mit der verschachtelten Abteilung „Dave's Pharmacy" vom Typ Pharmacy. Trägt die Abteilung eine eigene Marke, wird sie separat geführt.

Was LocalBusiness-Markup nicht leistet

Zwei Missverständnisse halten sich hartnäckig.

Selbstbewertungen sind nicht zulässig

aggregateRating und review sind laut Googles Dokumentation nur für Seiten empfohlen, die Rezensionen über andere lokale Unternehmen erfassen. Die eigene Durchschnittsnote als Sterne-Snippet in die Suchergebnisse zu bringen, funktioniert über diesen Weg also nicht — Google behandelt solche Angaben als unzulässige Selbstbewertung. Wer mit Bewertungen arbeiten will, arbeitet an den Google-Rezensionen im Unternehmensprofil, nicht am Markup. Und wer eine Durchschnittsnote auf der Website ausspielt, prüft vorher die wettbewerbsrechtlichen Anforderungen, sonst droht eine Abmahnung.

Markup ersetzt keine Inhalte und kein Ranking

Strukturierte Daten sind eine Beschreibung, kein Ranking-Faktor im engeren Sinn. Sie erhöhen die Chance, korrekt verstanden und in besonderen Darstellungsformen ausgespielt zu werden. Eine dünne Standortseite wird durch ein perfektes LocalBusiness-Objekt nicht zu einer guten Seite. Umgekehrt verschenkt eine starke Standortseite ohne Markup Eindeutigkeit — genau die Eindeutigkeit, auf die Antwortmaschinen angewiesen sind, wenn sie Adresse und Öffnungszeiten aus einer Seite ziehen sollen. Für die Sichtbarkeit im Local Pack bleibt das Unternehmensprofil der stärkere Hebel; das Markup stützt die Datenlage dahinter.

Validierung und Monitoring

Vor dem Live-Gang gehört jeder Block durch ein Prüfwerkzeug. Zwei sind etabliert: Googles Test für Rich-Suchergebnisse zeigt, welche Google-Funktionen mit dem Markup erreichbar sind, und der Schema Markup Validator prüft gegen das schema.org-Vokabular selbst, unabhängig von Googles Funktionsliste. Kritische Fehler müssen weg; nicht kritische Hinweise verbessern die Qualität, blockieren aber keine Darstellung.

• Nach dem Deployment das URL-Prüftool der Search Console nutzen, um zu sehen, wie Google die Seite gerendert sieht — besonders wichtig, wenn das Markup per JavaScript erzeugt wird.
• Zugänglichkeit prüfen: robots.txt, noindex und Login-Hürden verhindern, dass der Block überhaupt gelesen wird.
• Dauerhaft beobachten: Der Bericht zu strukturierten Daten in der Search Console meldet Fehler, die nach einem Template-Update auftreten — der häufigste Weg, auf dem korrektes Markup wieder kaputtgeht.
• Änderungen anmelden: Eine aktuelle Sitemap beschleunigt das erneute Crawling nach größeren Umbauten.

Wie das Markup in KI-Antworten hineinwirkt

Antwortmaschinen lesen Seiten nicht wie ein Kunde, sondern wie eine Datenquelle. Wenn ein Modell die Frage „Bis wann hat die Praxis am Samstag offen?" beantworten soll, sind zwei Wege möglich: Es leitet die Antwort aus Prosa ab und rät bei Unklarheiten, oder es liest ein eindeutiges Feld. Genau deshalb hat LocalBusiness-Markup über die klassischen Rich Results hinaus an Gewicht gewonnen. Die Angabe kostet einmal Aufwand und reduziert dauerhaft die Wahrscheinlichkeit, dass eine Maschine veraltete oder fremde Daten über den Betrieb ausspielt.

Das ersetzt keine Pflege an anderer Stelle. Ein Unternehmensprofil mit falschen Öffnungszeiten bleibt falsch, auch wenn das Markup stimmt — und Google gewichtet bei lokalen Fragen sein eigenes Profil stark. Sinnvoll ist deshalb die einfache Regel: Ein Datensatz, drei Orte. Die Öffnungszeiten stehen im Unternehmensprofil, im sichtbaren Seitentext und im Markup, und sie werden an allen drei Stellen im selben Arbeitsschritt geändert. Wer das trennt, produziert innerhalb eines Jahres zuverlässig Widersprüche.

Ein praktischer Nebeneffekt: Weil sameAs auf die offiziellen Profile eines Unternehmens verweist, verknüpft ein vollständiger Block die eigene Domain mit Branchenverzeichnissen, Bewertungsportalen und Social-Profilen. Das ist keine Ranking-Mechanik, sondern Entitätsarbeit — es macht nachvollziehbar, dass es sich bei „Kanzlei Musterfrau" auf fünf Plattformen um dieselbe Organisation handelt.

Abgrenzung: LocalBusiness, Organization, Service, Place

Vier Typen werden regelmäßig verwechselt, obwohl sie unterschiedliche Fragen beantworten. Die Entscheidung fällt nicht nach Geschmack, sondern danach, was die jeweilige Seite tatsächlich beschreibt.

• Organization beschreibt das Unternehmen als Rechts- und Markeneinheit: Dachmarke, Logo, Rechtsform, offizielle Profile über sameAs. Der richtige Typ für Start- und Über-uns-Seiten von Unternehmen ohne Publikumsverkehr.
• LocalBusiness beschreibt einen Betrieb an einem Ort. Er erbt von Organization und ergänzt alles, was mit Aufsuchbarkeit zu tun hat.
• Service beschreibt eine einzeln vermarktete Leistung — „Heizungswartung", „Arbeitsrechtsberatung" — mit eigener Beschreibung, Anbieter und bedientem Gebiet. Der passende Typ für Leistungsseiten.
• Place beschreibt einen Ort ohne Geschäftsbezug, etwa ein Gebäude oder einen Parkplatz. Für Unternehmensseiten praktisch nie die richtige Wahl.

Ein Dienstleister mit einem Standort und fünf Leistungen fährt in der Regel gut mit einem LocalBusiness-Untertyp auf Startseite und Standortseite plus je einem Service-Objekt auf den Leistungsseiten, das über provider auf die Unternehmensentität zurückverweist.

Typische Implementierungsfehler

• Markup und sichtbarer Inhalt weichen voneinander ab. Öffnungszeiten im JSON-LD, die nicht im Seitentext stehen, verstoßen gegen Googles allgemeine Richtlinien für strukturierte Daten.
• Generisches LocalBusiness statt Untertyp. Funktioniert, verschenkt aber die branchenspezifischen Felder und die klarere Zuordnung.
• Telefonnummer im nationalen Format. 0211 123456 ist mehrdeutig, +49211123456 nicht.
• Ein Markup-Block für alle Standorte. Führt zu einer unscharfen Entität statt zu mehreren klaren.
• Koordinaten aus dem Kartenausschnitt geschätzt. Google verlangt mindestens fünf Nachkommastellen; grobe Werte setzen den Betrieb auf die falsche Straßenseite.
• Markup nur im Consent-abhängigen Skript. Wird das JSON-LD erst nach einer Zustimmung ausgeliefert, sieht der Crawler es nie.

Häufige Fragen zu LocalBusiness-Schema

JSON-LD, Microdata oder RDFa?

JSON-LD, in einem script type="application/ld+json"-Block. Es ist von den sichtbaren HTML-Inhalten getrennt, übersteht Template-Änderungen besser und ist das von Google bevorzugte Format.

Gehört der Block in den head oder in den body?

Beides funktioniert. Der head ist üblich und macht die Pflege einfacher, weil das Markup dann nicht in Layout-Komponenten wandert.

Reichen Name und Adresse?

Formal ja, praktisch nein. Erst Telefonnummer, Geo-Koordinaten, Öffnungszeiten, Bilder und die standortspezifische URL machen aus dem Minimaleintrag eine belastbare Entitätsbeschreibung.

Muss ich LocalBusiness auf jeder Seite ausgeben?

Nein. Startseite und Standortseiten genügen; auf Standortseiten mit der jeweiligen Adresse. Auf Blog- oder Leistungsseiten ist stattdessen Organization oder Service der passendere Typ.

Wie schnell wirkt das Markup?

Google muss die Seite neu crawlen und indexieren; das dauert nach der Veröffentlichung typischerweise einige Tage. Eine Garantie für eine bestimmte Darstellung in den Suchergebnissen gibt es nicht, auch nicht bei fehlerfreiem Markup.