Warum die KI-Suche für jeden Standort eine eigene Seite braucht

Einträge zeigen, dass es einen Standort gibt. Standortseiten zeigen, was dort gilt.

In einem ergänzenden Beitrag sind wir der Frage nachgegangen, warum KI-Assistenten reale Standorte falsch darstellen: Sie geben wieder, was ihre Quellen sagen, und viele dieser Quellen sind veraltet. Dort haben wir auch beschrieben, was wir bei Kunden beobachten, deren Standortnetze einen strukturierten Store Locator, eigene Local Landing Pages und gepflegte unternehmenseigene Standortdaten kombinieren. In unserer internen Kundenanalyse lag die Genauigkeit von Standortdaten in KI-Antworten bei Standortnetzen mit dieser Kombination aus eigener Standortinfrastruktur beim 3,2-Fachen der vergleichbaren Branchen-Benchmarks zur Datengenauigkeit, die wir ausgewertet haben. Das Ergebnis beruht auf Beobachtungen und belegt nicht, dass diese Kombination oder eine einzelne ihrer Komponenten den Unterschied bewirkt. Dieser Beitrag beschreibt die Architektur, die diesen Netzen gemeinsam ist, und warum es auf sie ankommt.

Store Locator und Local Landing Pages werden meist als SEO-Bausteine bewertet. Das greift zu kurz. Gemeinsam gehören sie zur markeneigenen Standortdaten-Infrastruktur. Nur hier hält die Marke auf ihrer Domain und in eigener Regie fest, was für jeden ihrer Standorte gilt.

Die Profile bei Google, Apple und Bing bleiben das Fundament. Ein Profil liegt jedoch auf der Plattform eines Dritten, folgt dessen Datenmodell und kann durch dessen Prozesse verändert werden. Bei Marken mit vielen Standorten ist häufig ausgerechnet die Website die Lücke: eine Seite mit Adressen, ein Karten-Widget, eine zentrale Telefonnummer.

Eine Kartenplattform mag wissen, dass es einen Ort gibt. Eine gut gebaute Standortseite hilft Maschinen zu verstehen, was für genau diesen Ort gilt.

Zwei Fragen, zwei Bausteine

Store Locator und Local Landing Page werden meist gemeinsam beauftragt, gebaut und bewertet. Sie beantworten aber unterschiedliche Fragen.

Ein Store Locator ohne Standortseiten ist ein Verzeichnis, hinter dessen Treffern nichts steht. Standortseiten ohne Store Locator sind Datensätze, zu denen niemand navigieren kann; Crawler finden sie, wenn überhaupt, durch Zufall. Die Infrastruktur entsteht erst aus beiden zusammen.

Eine eigene Standortdatenschicht

Tausend automatisch erzeugte, nahezu identische Seiten sind nicht das Ziel. Gebraucht wird für jeden realen Standort eine stabile, crawlbare, für Menschen wie für Maschinen lesbare Darstellung, veröffentlicht von der Marke und erzeugt aus denselben kontrollierten Standortdaten wie ihre Profile.

Zusammen bilden Store Locator und Local Landing Pages das, was wir eine eigene Standortdatenschicht nennen. Sie beantwortet jedem System, das die Website ausliest, fünf Fragen zum Standortnetz:

Unverzichtbar bleiben die Einträge auf Plattformen trotzdem. Standortseiten ersetzen weder Google, Apple und Bing noch Kartenanbieter, Verzeichnisse oder die Datendistribution. Sie ergänzen diese Kanäle um eine maßgebliche Darstellung jedes Standorts aus der Hand der Marke: eine, die bestätigen kann, was die Plattformen zeigen, und die kein Plattformprozess überschreiben kann.

Warum es für KI-Systeme auf die Website der Marke ankommt

Die Belege ergeben ein einheitliches Bild, und keiner davon beruht auf Spekulationen darüber, wie ein bestimmtes Modell seine Quellen gewichtet.

Am Anfang stehen Googles Richtlinien für Unternehmensprofile. Sie sehen eine Website vor, die den einzelnen Standort des Unternehmens repräsentiert, und, wo möglich, eine Telefonnummer, die zu diesem Standort führt statt zu einer zentralen Hotline^[1]. In einem Standortnetz repräsentiert weder die Startseite noch ein Suchergebnis im Store Locator einen einzelnen Standort. Eine Local Landing Page leistet genau das.

Hinzu kommt Googles Leitfaden zu KI-Funktionen in der Suche. Er stellt keine zusätzlichen Anforderungen und verlangt kein spezielles Markup. Eine Seite muss indexiert sein und für die Anzeige mit Snippet infrage kommen, ihre strukturierten Daten sollten dem sichtbaren Text entsprechen, und die Angaben im Google Unternehmensprofil sollten aktuell sein^[2]. Der Leitfaden beschreibt damit eine gute Standortseite, kein besonderes KI-Format, und schließt jede Abkürzung aus: Weder eine Datei noch ein Schema ersetzt eine indexierbare Seite mit korrekten Angaben.

Der dritte Beleg kommt aus der Forschung. Im ergänzenden Beitrag haben wir eine Prüfung von KI-Empfehlungen auf Basis einer vollständigen Markterhebung besprochen. Den größten Effekt darauf, ob ein Betrieb überhaupt empfohlen wurde, fand die Studie bei einer eigenen Website (Odds Ratio 1,92); die Präsenz in einem offenen Ortsdatenbestand zeigte dagegen keinen positiven Effekt^[3]. Die Studie betrachtet Restaurants, Cafés und Bars in zwei Gebieten auf Bali und belegt einen Zusammenhang, keine Ursache. Bemerkenswert bleibt das Ergebnis dennoch: Eine eigene Website ging stärker mit Empfehlungen einher als die Präsenz in einem offenen Ortsdatenbestand.

Schließlich nennt ein Branchenindex vier Quellentypen, auf die Assistenten bei lokalen Fragen zurückgreifen: Kartenplattformen, Unternehmenswebsites, Bewertungsportale und Social-Media-Profile^[4]. Eine Marke kontrolliert ihre Profile nur zum Teil, ihre Website dagegen vollständig.

Die Profile liefern die Kernfakten; auf der Website nennt die Marke sie selbst. Ein Assistent, der in beiden denselben aktuellen Stand findet, hat weniger Anlass, eine ältere Version aus einer anderen Quelle zu wiederholen.

Eine Local Landing Page ist in erster Linie ein Datensatz

Diese Felder legen wir in Standortseiten-Projekten fest. Die Tabelle zeigt, warum jedes davon wichtig ist und wie es im schema.org-Markup abgebildet wird:

Zwei Regeln sorgen dafür, dass das Markup verlässlich bleibt. Strukturierte Daten beschreiben, was die Seite zeigt, und ergänzen nie Fakten, die dort nicht stehen. Außerdem entstehen sie aus demselben Datensatz wie die sichtbare Seite und die Profile, sodass alle drei auf denselben Fakten beruhen. Googles Dokumentation schreibt für LocalBusiness-Markup nur Name und Adresse vor und empfiehlt weitere Angaben wie Koordinaten, Telefonnummer, URL und Öffnungszeiten^[5]. Wir zeichnen aus, was die Seite tatsächlich zeigt, und lassen alles andere weg.

Datensatz statt Brückenseite

Standortseiten haben nicht ohne Grund einen schlechten Ruf. Viele Netze haben Hunderte nahezu identischer Seiten veröffentlicht, deren einziger individueller Inhalt ein Stadtname ist. Gebaut wurden sie, um für eine Leistung in einer Stadt zu ranken, und nicht, um einen Ort zu beschreiben. Googles Spam-Richtlinien beschreiben dieses Muster unter dem Begriff „Brückenseiten“ (Doorway Pages): Seiten, die auf bestimmte Regionen oder Städte ausgerichtet sind und Nutzer auf eine einzige Seite leiten, sowie weitgehend ähnliche Seiten, die eher Suchergebnissen gleichen als einer klar definierten, navigierbaren Hierarchie^[6].

Die Prüffrage ist einfach. Eine Standortseite hat ihre Berechtigung, wenn ein realer Standort dahintersteht, dessen Fakten sich von allen anderen unterscheiden: Adresse, Öffnungszeiten, Ausnahmen, Telefon, Leistungen und Zugang. Unterscheidet sie sich nur im Keyword, ist sie eine Brückenseite. Tausend Seiten sind in Ordnung, wenn sie tausend reale Orte beschreiben. Tausend Seiten, die nur eine Vorlage abbilden, sind es nicht.

Vorlagen sind dabei nicht das Problem. Jedes große Netz braucht eine, und Einheitlichkeit über alle Seiten hinweg hilft Menschen wie Maschinen. Problematisch wird eine Vorlage, in der nichts Standortspezifisches steckt.

Eine Struktur, die auch tausend Standorte trägt

Jede Ebene ist für sich eine nützliche Seite, etwa eine Länderliste oder eine Stadtübersicht mit allen Standorten der Stadt, und jede verlinkt auf die nächsttiefere Ebene. Eine Ebene, die nichts beiträgt, kann entfallen: Ein Land mit zwölf Standorten braucht keine regionale Zwischenebene. Wichtiger als das URL-Muster sind diese Entscheidungen:

• Eine URL pro realem Standort, für seine gesamte Lebensdauer. Ein umbenannter Standort behält seine URL, ebenso einer, der innerhalb seines Einzugsgebiets umzieht. Profile, Verzeichnisse und alte Links zeigen auf diese URL. Wählen Sie URL-Slugs, die Veränderungen überstehen: Ein Straßenname liest sich gut, macht aber jeden Umzug zu einer Weiterleitung; ein Bezirksname oder eine kurze Standortkennung tut das nicht.
• Serverseitig gerenderte Links zu jedem Standort. Viele Store Locator bestehen aus einer JavaScript-Karte, deren Ergebnisse erst bei Bedarf nachgeladen werden. Menschen können sie bedienen; ein Crawler sieht womöglich nur eine leere Hülle. Jede Standortseite braucht mindestens einen einfachen HTML-Link, aus einer Liste oder von einer Stadtseite.
• Eine kanonische URL pro Standort. Gefilterte Ansichten und Suchergebnisse im Store Locator, etwa nach Leistung oder Umkreis, sollten keine indexierbaren Kopien derselben Standorte erzeugen.
• Jedes Profil verweist auf seine Standortseite. Das Website-Feld im Google-, Apple- und Bing-Eintrag jedes Standorts verlinkt auf diese Seite statt auf die Startseite.
• Schließungen werden abgewickelt, nicht gelöscht. Ein dauerhaft geschlossener Standort behält seine Seite für eine Übergangszeit, klar als geschlossen gekennzeichnet und mit Links zu den nächstgelegenen Alternativen, bevor sie auf die Stadtseite oder den Store Locator weitergeleitet wird. Bei einem kommentarlosen 404-Fehler laufen alle Verweise aus Profilen und Verzeichnissen, die auf die Seite zeigten, ins Leere.
• Sprachversionen pro Seite. In mehrsprachigen Märkten gibt es jede Standortseite in mehreren Sprachversionen, verknüpft über hreflang-Angaben, damit die deutsche und die englische Seite derselben Filiale als ein Standort verstanden werden.
• Eine Sitemap, die den Daten folgt. Das Änderungsdatum einer Seite sollte sich ändern, wenn sich die Fakten des Standorts ändern, und nicht bei jedem Deployment.

Store Locator und Filialfinder gehören auch zu den Projekten rund um Karten- und Standorttechnologie, die wir umsetzen, wenn ein Store Locator eine eigene Karte, Suche oder Routenplanung braucht.

Ein Datensatz, viele Ausgabekanäle

Ein Fehler, den wir in Standortseiten-Projekten immer wieder sehen, hat weder mit Design noch mit Markup zu tun. Die Ursache ist eine zweite Kopie der Daten. Das Website-Team baut die Seiten aus einer Tabelle oder dem CMS, das Operations-Team pflegt die Profile aus dem führenden Datensatz, und innerhalb einer Saison stimmen beide nicht mehr überein. Die Seite, die als maßgebliche Quelle gedacht war, wird zu einer weiteren veralteten.

Der Grundsatz, nach dem wir solche Projekte aufsetzen: Die Standortseite ist eine Ausgabe desselben Datensatzes wie die Profile, veröffentlicht im selben Prozess und zur selben Zeit. Eine einmal freigegebene Feiertagsänderung erreicht Google, Apple, Bing, die Standortseite, den Store Locator und die strukturierten Daten gleichzeitig. Anschließend gleicht das Monitoring den Live-Stand auf jedem Kanal mit dem Datensatz ab, die Seiten der Marke eingeschlossen.

Einträge, Website, Store Locator, Standortseiten: was jede Stufe beiträgt

Die Ausgangslagen, die wir in Projekten antreffen, lassen sich als aufeinander aufbauende Stufen lesen. Das ist ein qualitatives Raster aus unserer Projektarbeit, keine gemessene Rangfolge.

Die letzte Zeile entspricht der Ausbaustufe, in der unsere Kundenanalyse eine höhere Genauigkeit von Standortdaten in KI-Antworten als die vergleichbaren Branchen-Benchmarks zur Datengenauigkeit beobachtet hat, wie im ergänzenden Beitrag dargelegt. Die Logik der Tabelle gilt aber auch unabhängig davon: Jede Zeile nimmt einer Maschine einen Grund, die Fakten eines Standorts anderswo zu suchen.

Was Einträge leisten können und was nicht

Über Plattformeinträge kommen die meisten Kunden mit einem Standort in Berührung. Auf Standortseiten hält die Marke unter ihrem Namen und auf ihrer Domain fest, was für ihn gilt. Beides lesen inzwischen auch Maschinen.

Was der Betrieb verlangt

Ein Standortseiten-Projekt lässt sich leicht als Website-Projekt planen und als Betriebsaufgabe unterschätzen. Der Aufbau ist irgendwann abgeschlossen, die Daten ändern sich weiter. Ob die Seiten korrekt bleiben, entscheiden vier Punkte:

• Zuständigkeit: wer welches Feld ändern darf und wer die Änderung freigibt. Öffnungszeiten verantwortet oft das Operations-Team, Leistungen das Marketing, die Firmierung die Rechtsabteilung.
• Vorlaufzeiten: Sonderöffnungszeiten und geplante Schließungen werden veröffentlicht, bevor sie gelten, und zwar auf allen Kanälen gleichzeitig.
• Lebenszyklus: Ein neuer Standort bekommt seine Seite vor der Eröffnung, bei einem Umzug wird die bestehende Seite aktualisiert, und Schließungen folgen dem vereinbarten Übergang. Die zeitliche Abfolge beschreibt unsere Seite zu Standortänderungen.
• Abgleich: Die Live-Seite, ihre strukturierten Daten und jedes Profil werden Feld für Feld mit dem Datensatz verglichen, und über jede Abweichung wird entschieden.

Wer welchen Teil übernimmt, ist eine Frage des Betriebsmodells: Ihr Team auf unserer Plattform, MapsExperts im Managed Service oder eine Aufteilung zwischen beiden. Den Aufbau selbst, vom Store Locator über die Seitenvorlage bis zur Datenanbindung, deckt unser Angebot Local Pages & Store Locator ab.