LocalBusiness-Schema: Was es wirklich bewirkt

LocalBusiness-Schema ist strukturierte Daten, meist als JSON-LD im Seitenkopf eingebunden, die einer Suchmaschine exakt mitteilen, wer ein Unternehmen ist, wo es sich befindet, wie man es erreicht und wann es geöffnet hat. Der Punkt ist nicht, zusätzliche Informationen hinzuzufügen, die auf der Seite gar nicht stehen. Der Punkt ist, Informationen, die ohnehin sichtbar sind, in eine Form zu bringen, die eine Maschine ohne Interpretation lesen kann.

Ohne Markup muss eine Suchmaschine aus Fließtext, Fußzeile und Kontaktseite ableiten, was die tatsächliche Adresse ist und was nur eine beiläufige Erwähnung im Blogtext. Mit einem korrekt ausgezeichneten LocalBusiness-Objekt entfällt dieses Raten. Genau darum geht es in diesem Artikel: was das Markup tatsächlich leistet, welche Eigenschaften wirklich zählen, warum Konsistenz wichtiger ist als Vollständigkeit, und wo die Grenzen dessen liegen, was Schema-Markup überhaupt bewirken kann.

Die Eigenschaften, die den Unterschied machen

Ein LocalBusiness-Objekt kann Dutzende Eigenschaften enthalten, aber nur eine Handvoll trägt tatsächlich zur Sache bei. name muss exakt so lauten wie der eingetragene Geschäftsname – nicht der Markenname, falls beide voneinander abweichen, und ohne Zusätze wie einen Slogan oder eine Standortbezeichnung, die so nirgendwo sonst auftaucht. address gehört als eigenes PostalAddress-Objekt mit getrennten Feldern für Straße, Ort, Postleitzahl und Land eingebunden, nicht als eine einzelne zusammengeworfene Textzeile. telephone braucht ein Format, das ohne Umwege wählbar ist, inklusive Landesvorwahl, damit auch ein internationaler Suchender direkt anrufen kann.

geo, als GeoCoordinates mit Breiten- und Längengrad, verankert das Unternehmen an einem exakten Punkt auf der Karte und ist besonders bei Adressen hilfreich, die sich schwer eindeutig auflösen lassen – Gewerbeparks, große Einkaufszentren, Adressen mit mehreren Eingängen oder Hinterhöfen. openingHoursSpecification beschreibt die Öffnungszeiten strukturiert, mit einzelnen Wochentagen und Uhrzeiten, statt als Fließtext irgendwo im Footer. priceRange gibt eine grobe Preisorientierung, meist als Dollarzeichen-Skala, und ist vor allem für Suchende relevant, die schon vor der ersten Anfrage wissen wollen, in welcher Preisklasse sie landen. url verlinkt zurück auf die kanonische Seite genau dieses einen Standorts. sameAs verweist auf die offiziellen Profile desselben Unternehmens – Google Business Profile, Facebook-Seite, ein einschlägiges Branchenverzeichnis – und hilft einer Suchmaschine, verschiedene Erwähnungen im Web als dieselbe Entität zu erkennen, statt als mehrere ähnliche.

• name – der eingetragene Name, exakt, ohne Werbezusatz
• address – als PostalAddress mit einzelnen Feldern, nicht als ein Textblock
• telephone – im wählbaren internationalen Format
• geo – Koordinaten, besonders wichtig bei mehrdeutigen Adressen
• openingHoursSpecification – strukturierte Zeiten statt Fließtext
• priceRange – grobe Preisklasse, kein exakter Einzelpreis
• url – die kanonische Seite genau dieses einen Standorts
• sameAs – Links zu den offiziellen Profilen desselben Unternehmens

Den spezifischsten Typ wählen statt des allgemeinen

schema.org bietet unterhalb von LocalBusiness eine tiefe Hierarchie an Subtypen: Restaurant, Dentist, HairSalon, ClothingStore, AutoRepair, LegalService und noch etliche weitere, jeweils mit eigenen zusätzlichen Eigenschaften, die zur jeweiligen Branche passen. Wer stattdessen den generischen Typ LocalBusiness verwendet, obwohl ein passenderer Subtyp existiert, verschenkt Informationen, die eine Suchmaschine bei der spezifischeren Bezeichnung automatisch mitversteht. Ein als Restaurant ausgezeichnetes Unternehmen kann zum Beispiel servesCuisine oder ein menu tragen, ein als Dentist ausgezeichnetes kann fachliche Zusatzangaben machen, für die generisches LocalBusiness gar keinen Platz vorsieht.

Die Faustregel ist einfach: zuerst prüfen, ob ein Subtyp existiert, der die eigene Branche eindeutig beschreibt, und erst dann auf die generische Bezeichnung zurückfallen, wenn wirklich keiner passt oder das Geschäft mehrere Kategorien gleichzeitig bedient, etwa ein Restaurant mit angeschlossenem Feinkostladen. Der generische Typ ist an sich kein Fehler – aber er ist die am wenigsten aussagekräftige Wahl von allen, und aussagekräftig ist an dieser Stelle genau das Ziel der ganzen Übung.

Der Punkt, der über allem steht: Konsistenz

Alles in diesem Artikel läuft auf ein einziges Prinzip hinaus, und es ist wichtiger als jede einzelne Eigenschaft für sich: Das Markup muss mit drei Dingen übereinstimmen – mit dem sichtbaren Inhalt der Seite selbst, mit dem Business-Profil des Unternehmens und mit den Einträgen in anderen Verzeichnissen. Wenn die Telefonnummer im Markup eine andere ist als die im Footer derselben Seite, oder wenn die Öffnungszeiten im Markup von denen im Google Business Profile abweichen, hat man kein unvollständiges Profil – man hat ein Glaubwürdigkeitsproblem.

Der Grund dafür ist simpel: Eine Suchmaschine, die zwei widersprüchliche Fakten über dasselbe Unternehmen findet, hat keinen Weg zu wissen, welcher der beiden stimmt. Sie kann nur folgern, dass die Quelle insgesamt unzuverlässig ist. Das trifft dann nicht nur die eine widersprüchliche Angabe, es färbt auf den Rest des Profils ab. Ein Unternehmen, das schon bei der eigenen Telefonnummer uneins mit sich selbst ist, wirkt auch bei allem anderen weniger vertrauenswürdig. Genau deshalb ist eine fehlende Eigenschaft im Markup fast immer harmloser als eine falsche. Fehlt priceRange, fehlt eine nette Zusatzinformation. Sagt priceRange im Markup "$$$" und die Speisekarte auf derselben Seite zeigt eindeutig andere Preise, ist das ein Widerspruch, den eine Maschine registriert und dem Rest der Angaben anlastet.

In der Praxis bedeutet das: Nach jeder Änderung an Adresse, Telefonnummer, Öffnungszeiten oder Namen müssen mindestens drei Stellen im selben Arbeitsgang aktualisiert werden – die Seite selbst, das strukturierte Markup auf der Seite, und das Google Business Profile beziehungsweise die entsprechenden Einträge in anderen Verzeichnissen. Ein Umzug, eine neue Vorwahl bei der Telefonnummer, eine Namensänderung nach einer Übernahme – jedes dieser Ereignisse ist ein Anlass, alle drei Quellen gemeinsam zu prüfen, nicht nacheinander über Wochen verteilt, während in der Zwischenzeit widersprüchliche Angaben online stehen.

Mehrere Standorte: eine Seite, eine Filiale, ein Markup

Unternehmen mit mehreren Filialen machen hier häufig denselben Fehler: Eine einzige Standorte-Übersichtsseite, auf der alle Filialen mit ihren Adressen aufgelistet sind, bekommt ein einziges LocalBusiness-Markup, das irgendwie versucht, alle Filialen gleichzeitig abzubilden. Das funktioniert nicht sauber. Ein LocalBusiness-Objekt beschreibt einen Standort, nicht ein Unternehmen mit mehreren Standorten gleichzeitig.

Die korrekte Struktur ist eine eigene Seite pro Filiale, jede mit ihrem eigenen LocalBusiness-Markup, das die exakte Adresse, Telefonnummer, Öffnungszeiten und Geokoordinaten genau dieser einen Filiale trägt. Die übergeordnete Marke kann zusätzlich als Organization ausgezeichnet werden, mit den einzelnen Filialen als verknüpfte Einträge, aber jede Filiale braucht ihre eigene, in sich konsistente Beschreibung. Eine Sammelseite mit mehreren Adressen im selben Markup-Block erzeugt genau die Art von Mehrdeutigkeit, die das ganze Format eigentlich verhindern soll: Welche Telefonnummer gehört zu welcher Adresse, wenn beide im selben Objekt stehen?

• Pro Filiale eine eigene Seite mit eigener URL
• Pro Seite ein eigenes LocalBusiness-Objekt mit den Daten genau dieser Filiale
• Die Marke als Ganzes optional zusätzlich als Organization, nicht als Ersatz für die einzelnen Filialen
• Keine Sammelseite, die mehrere Adressen in einem einzigen Markup-Block bündelt

Öffnungszeiten: die Sonderfälle, die fast immer falsch sind

Reguläre Öffnungszeiten – montags bis freitags von neun bis achtzehn Uhr – sind der leichte Teil. openingHoursSpecification bildet das mit dayOfWeek, opens und closes sauber ab. Die Fehler passieren bei den Sonderfällen, die in der Praxis fast jedes Unternehmen irgendwann hat: geteilte Öffnungszeiten mit Mittagspause, abweichende Wochenendzeiten, und vor allem Feiertage.

Geteilte Zeiten – etwa neun bis dreizehn Uhr und dann wieder fünfzehn bis achtzehn Uhr – brauchen zwei separate openingHoursSpecification-Einträge für denselben Wochentag, nicht einen einzigen Eintrag mit einer künstlich verlängerten Zeitspanne, die die Mittagspause einfach verschweigt. Feiertage und Sonderöffnungszeiten gehören als eigene Einträge mit validFrom und validThrough eingetragen, damit sie ausschließlich an den betroffenen Tagen gelten und danach automatisch wieder zur regulären Regel zurückfallen. Wer das Markup einmal einrichtet und danach nie wieder anfasst, hat spätestens am nächsten Feiertag ein Markup, das Kunden falsch informiert – geöffnet zeigt, obwohl geschlossen ist, oder umgekehrt geschlossen, obwohl geöffnet ist.

Das ist keine akademische Feinheit. Öffnungszeiten sind die Angabe, die sich am häufigsten ändert, und gleichzeitig diejenige, die am seltensten aktualisiert wird, weil sie nach der Ersteinrichtung stillschweigend als erledigt gilt. Eine feste Routine, das Markup vor bekannten Feiertagen zu prüfen, ist am Ende wirksamer als jede rein technische Lösung.

Was das Markup bewirkt – und was es nicht bewirkt

Hier lohnt sich Ehrlichkeit, weil die Erwartung an dieses eine Feature oft zu hoch ist. LocalBusiness-Schema hilft einer Suchmaschine, ein Unternehmen korrekt zu verstehen und einzuordnen, und es ist eine Voraussetzung für bestimmte erweiterte Darstellungen in den Suchergebnissen – etwa Angaben wie die Öffnungszeiten, sofern die übrigen Voraussetzungen dafür ebenfalls erfüllt sind. Es unterstützt also Eligibility, die grundsätzliche Möglichkeit, für ein Feature überhaupt in Frage zu kommen.

Was es nicht tut: Es verschafft keinen Platz im lokalen Kartenausschnitt, dem sogenannten Map Pack, und es ist kein direkter Rankingfaktor in dem Sinne, dass mehr Markup automatisch zu einer besseren Position führt. Die Position im Map Pack hängt von einer ganz anderen Gruppe an Faktoren ab – Nähe zum Suchenden, Relevanz der Kategorie, und die Signalstärke des Google Business Profile selbst, nicht in erster Linie die der Website. Jeder Beitrag, der behauptet, LocalBusiness-Schema allein bringe eine bessere Kartenplatzierung, verwechselt Verständnis mit Ranking. Das Markup macht ein Unternehmen für die Maschine lesbar. Es macht es nicht automatisch sichtbarer.

Validieren und aktuell halten

Vor der Veröffentlichung gehört jedes LocalBusiness-Markup durch einen Validator, der die Syntax prüft und anzeigt, welche Eigenschaften erkannt wurden und welche mit Fehlern oder Warnungen markiert sind. Eine Warnung bedeutet meist, dass eine empfohlene, aber nicht zwingende Eigenschaft fehlt; ein Fehler bedeutet, dass die Syntax selbst kaputt ist und das ganze Objekt im schlimmsten Fall komplett ignoriert wird.

Validierung ist aber kein einmaliger Schritt, der nach dem Launch erledigt ist. Jede Änderung an Adresse, Öffnungszeiten, Telefonnummer oder Namen sollte denselben Weg noch einmal durchlaufen, und zwar im selben Arbeitsgang wie die Aktualisierung der Seite selbst und des Business-Profils – aus genau dem Konsistenzgrund von weiter oben. Ein LocalBusiness-Markup, das bei der Einrichtung korrekt war und seither nicht mehr angefasst wurde, ist nach dem nächsten Umzug oder der nächsten Preisänderung wahrscheinlich schon wieder veraltet, ohne dass es irgendjemandem auffällt – bis ein Kunde vor einer verschlossenen Tür steht, weil die Öffnungszeiten auf der Seite etwas anderes versprochen haben.