Business Search Local: Firmendaten maschinenlesbar bereitstellen und prüfen
Wie Betriebe ihre Firmendaten mit LocalBusiness JSON-LD, Google Business Profile und konsistenten NAP-Angaben bereitstellen und prüfen, ob Google sie ausliest.
Bei einer lokalen Unternehmenssuche verarbeitet Google Informationen aus einer Vielzahl unterschiedlicher Quellen. Dazu gehören die eigene Unternehmenswebsite, strukturierte Daten im Quellcode, das Google Business Profile, öffentliche Register und vertrauenswürdige Branchenverzeichnisse. Nur wenn Firmenname, Anschrift, Telefonnummer und Öffnungszeiten über diese Kanäle hinweg übereinstimmen, kann die Suchmaschine die Angaben zuverlässig demselben Betrieb zuordnen.
Business Search Local beginnt daher auf der technischen Datenebene. Ein Unternehmen muss seine Kerndaten eindeutig veröffentlichen, diese mittels LocalBusiness Structured Data auszeichnen und anschließend verifizieren, ob die Suchmaschine diese Informationen technisch korrekt ausliest und interpretiert.
Welche Datenquellen nutzt die lokale Unternehmenssuche?
Es gibt keine einzelne Datenbank, aus der Google sämtliche Informationen bezieht. Die Suchmaschine betreibt einen kontinuierlichen Abgleich verschiedener Quellen:
- Die öffentlich erreichbaren Seiten der Unternehmenswebsite.
- LocalBusiness Structured Data (Schema Markup) im HTML-Quellcode.
- Das verifizierte Google Business Profile (GBP).
- Deutsche Registerquellen und amtliche Bekanntmachungen.
- Etablierte Branchenverzeichnisse, Karten- und Nachbarschaftsportale (z. B. Nextdoor).
- Nutzergesteuerte Änderungen und andere öffentlich zugängliche Datenpunkte.
Diese Quellen erfüllen unterschiedliche Funktionen. Während die Website oft die detailliertesten Kontaktdaten bietet, dient das Google Business Profile als primäre Quelle für die Google Suche und Google Maps. Das Unternehmensregister hingegen dokumentiert die rechtlich verbindlichen Daten.
Widersprüche zwischen diesen Quellen erschweren die Zuordnung. Verwendet eine Website beispielsweise einen verkürzten Markennamen, während im Register ausschließlich die vollständige Gesellschaftsbezeichnung steht, muss der Zusammenhang durch konsistente Zusatzdaten (wie die Adresse) technisch klar erkennbar sein.
NAP-Daten als gemeinsame Grundlage
NAP steht für Name, Address und Phone. Diese drei Kerndaten bilden das Fundament der lokalen Identität. Sie sollten auf allen kontrollierbaren Quellen konsistent sein.
Konsistenz bedeutet nicht zwingend zeichengenaue Identität, da Suchmaschinen Variationen wie “Musterstraße 12” und “Musterstr. 12” in der Regel als identisch erkennen. Kritisch sind jedoch sachliche Abweichungen:
- Unterschiedliche Hausnummern oder Postleitzahlen.
- Veraltete Telefonnummern.
- Abweichende Orts- oder Stadtteilangaben.
- Ehemalige Firmennamen ohne erkennbare Verbindung zum neuen Namen.
- Widersprüchliche Angaben zu dauerhaft geschlossenen Standorten.
- Unterschiedliche Öffnungszeiten auf der Website und im Profil.
Für die Telefonnummer empfiehlt sich ein einheitliches internationales Format, zum Beispiel +49 511 1234567. Während die sichtbare Darstellung für den Nutzer lesefreundlich gestaltet sein kann, sollte sie im strukturierten Datensatz stabil und eindeutig bleiben.
Da keine belastbaren Statistiken zur Häufigkeit inkonsistenter NAP-Daten in deutschen Verzeichnissen vorliegen, ist die individuelle Prüfung des eigenen Datenbestands für jeden Betrieb die wichtigste Maßnahme.
LocalBusiness Structured Data mit JSON-LD
Google unterstützt LocalBusiness als spezifischen Typ für strukturierte Daten. Damit lassen sich Anschrift, Telefonnummer, Öffnungszeiten, einzelne Abteilungen und Bewertungen maschinenlesbar übergeben.
Als Format empfiehlt Google JSON-LD. Dieser Datenblock wird im HTML-Dokument eingebunden, bleibt jedoch vom sichtbaren Seiteninhalt getrennt, was die technische Pflege vereinfacht.
Ein beispielhafter Datensatz sieht wie folgt aus:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"@id": "https://www.beispiel.de/#unternehmen",
"name": "Beispiel Werkstatt GmbH",
"url": "https://www.beispiel.de/",
"telephone": "+49 511 1234567",
"image": "https://www.beispiel.de/bilder/werkstatt.jpg",
"address": {
"@type": "PostalAddress",
"streetAddress": "Musterstraße 12",
"postalCode": "30159",
"addressLocality": "Hannover",
"addressCountry": "DE"
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": [
"Monday",
"Tuesday",
"Wednesday",
"Thursday",
"Friday"
],
"opens": "08:00",
"closes": "17:00"
}
]
}
</script>
Der Typ sollte so spezifisch wie möglich gewählt werden. Anstatt des allgemeinen Typs LocalBusiness bieten sich je nach Branche Typen wie Restaurant, AutoRepair, Dentist oder Store an. Entscheidend ist, dass die Auszeichnung die tatsächliche Geschäftstätigkeit präzise beschreibt.
Die Eigenschaft @id dient als stabile Kennung. Sie sollte dauerhaft auf dieselbe Unternehmenseinheit verweisen. Bei mehreren Standorten benötigt jeder Standort einen eigenen Datensatz mit separater Adresse und eindeutiger Kennung.
Übereinstimmung von Markup und sichtbaren Inhalten
Strukturierte Daten sind kein unsichtbarer Zusatz, sondern müssen die sichtbaren Angaben der Website spiegeln. Wenn im JSON-LD-Markup Öffnungszeiten von 08:00 bis 17:00 Uhr hinterlegt sind, die Website im Text aber 09:00 bis 18:00 Uhr angibt, entsteht ein Widerspruch, der die Datenqualität mindert.
Dies gilt insbesondere für:
- Unternehmensnamen und offizielle Geschäftsbezeichnungen.
- Die vollständige Standortadresse.
- Zentrale oder standortspezifische Telefonnummern.
- Reguläre sowie abweichende Öffnungszeiten (Feiertage).
- Den aktuellen Status des Standorts.
Technische Gültigkeit bedeutet lediglich, dass ein Parser die Daten lesen kann. Ob Google diese Informationen tatsächlich in der Suche anzeigt, liegt im Ermessen des Algorithmus. So ist beispielsweise das Restaurant-Karussell auf Basis von LocalBusiness-Markup laut Dokumentation nur mit eingeschränktem Zugang verfügbar. Zudem müssen alle Daten die allgemeinen Google-Richtlinien für strukturierte Daten erfüllen. Irreführende oder versteckte Angaben können dazu führen, dass die Auszeichnung ignoriert wird.
Das Google Business Profile verifizieren
Das Google Business Profile ist ein kostenloses Werkzeug zur Verwaltung der lokalen Präsenz. Damit ein Unternehmen die Hoheit über seine Daten behält, muss das Profil beansprucht und verifiziert werden.
Der Zugang zum eigenen Profil erfolgt laut Google entweder über die Suche nach Firmenname und Ort oder über den Suchbegriff “my business” in der Google Suche bzw. in Google Maps.
Die Verifizierung bestätigt die Identität des Betreibers. Je nach Fall bietet Google unterschiedliche Methoden an, wie zum Beispiel per Video, Telefon, E-Mail oder Postversand. Die Methode ist oft vorgegeben und kann nicht frei gewählt werden.
Nach der Verifizierung ist ein Abgleich der NAP-Daten zwischen Profil und Website zwingend erforderlich. Für Unternehmen, deren Profile gesperrt wurden, stellt Google einen spezifischen Prozess zur Wiederherstellung bereit.
Deutsche Registerquellen als Validierung
Das Unternehmensregister ist die zentrale Plattform für Unternehmensdaten in Deutschland. Es bietet Zugang zu Einträgen aus dem Handels-, Genossenschafts-, Gesellschafts- und Partnerschaftsregister.
Diese Daten sind für die rechtliche Identifikation essenziell. Relevant sind hier:
- Die vollständige Firma inklusive Rechtsform.
- Der offizielle Sitz des Unternehmens.
- Das zuständige Registergericht und die Registernummer.
- Die vertretungsberechtigten Personen.
Es ist wichtig zu verstehen, dass der eingetragene Unternehmenssitz nicht zwingend mit jeder Betriebsstätte übereinstimmen muss. Auch eine Marke kann vom Registernamen abweichen. Solange die Website transparent macht, welche Marke zu welcher Gesellschaft gehört, liegt kein Fehler vor. Weitere Signale liefern Branchenverzeichnisse oder lokale Plattformen wie Nextdoor.
Prüfen, ob Google die Daten tatsächlich ausliest
Die technische Kontrolle der Datenbereitstellung erfolgt in vier Schritten:
1. Markup validieren
Mit dem “Rich Results Test” von Google lässt sich prüfen, ob das Markup erkannt wird und ob Fehler vorliegen. Der “Schema Markup Validator” ergänzt dies durch eine Prüfung der allgemeinen Schema.org-Struktur.
2. Gerenderten HTML-Code kontrollieren
Der JSON-LD-Block muss im finalen, gerenderten HTML vorhanden sein. Dies ist besonders kritisch, wenn Plugins oder JavaScript die Daten dynamisch generieren. Eine Prüfung im Editor ist nicht ausreichend, da der Crawler die gerenderte Version sieht.
3. URL-Prüfung in der Search Console
Die URL-Prüfung der Google Search Console zeigt, ob die Seite indexiert ist. Der Live-Test gibt Aufschluss darüber, ob Google die Seite aktuell erreichen kann und welche Seitenelemente erkannt werden. Hier sollten blockierte Ressourcen oder Unterschiede zwischen Live-Version und Index-Version analysiert werden.
4. Vergleich der Suchdarstellung mit den Quelldaten
Zuletzt werden die in der Suche angezeigten Daten mit der Website, dem Markup und dem Business Profile verglichen. Abweichungen können auf veraltete Einträge in Drittverzeichnissen oder verzögerte Crawls zurückzuführen sein.
Technische Checkliste für Business Search Local
Ein optimierter Datenbestand erfüllt folgende Kriterien:
- Website nennt eindeutige und aktuelle Unternehmensdaten.
- NAP-Daten sind über alle Quellen hinweg konsistent.
- Jeder Standort hat eine eigene maschinenlesbare Beschreibung.
- LocalBusiness oder ein spezifischer Untertyp ist via JSON-LD eingebunden.
- Sichtbare Inhalte und Markup sind identisch.
- Google Business Profile ist verifiziert und aktuell.
- Bezug zwischen Registername und Geschäftsbezeichnung ist nachvollziehbar.
- Rich Results Test meldet keine kritischen Fehler.
- Search Console kann die URL korrekt rendern.
- Änderungen wurden nach einem erneuten Crawl verifiziert.
