Google Business Profile & NAP — Konsistenz für Local & KI

NAP (Name, Address, Phone) klingt trivial — ist es selten. Eine Praxis zeigt „Musterstraße 1“, das Google Business Profile „Musterstr. 1“, das Schema eine Postfachadresse und im Footer noch die alte Mobilnummer. Menschen rufen die falsche Nummer an; Algorithmen und generative Engines zweifeln, welche Entity gemeint ist. Bei Modernisierung gleichen wir sichtbare NAP-Daten, LocalBusiness/Organization und GBP-Vorgaben in einem Durchgang ab — Branchenbeispiele: Handwerk (Einsatzgebiet), Physio (Praxis-NAP), Steuerberater (Kanzleisitz). Lokale Märkte wie Bruchsal, Kraichgau oder Landkreis Karlsruhe ändern die Regel nicht: eine Schreibweise, viele Touchpoints.

Was bedeutet NAP in der Praxis?

Antwort zuerst: NAP ist die eine verbindliche Schreibweise von Firmenname, Straßenadresse und Telefon — überall gleich, wo der Betrieb öffentlich erreichbar ist.

Dazu gehören: Kontaktseite, Footer, Impressum, E-Mail-Signatur (optional), GBP, wichtige Verzeichnisse und strukturierte Daten. Nicht gemeint: keyword-lastige Firmennamen („Steuerberater Müller Bad Schönborn GmbH & Co. SEO“) oder fiktive Zweigstellen ohne physische Präsenz. GEO & AI-Sichtbarkeit braucht extrahierbare, widerspruchsfreie Fakten — Census: 6.675 Audits, Agent-Ready Ø 25/100, Sitemap-Benchmark 73,5 % (AI-Readiness-Studie).

Praktische Master-Regel: Eine Zeile, die du ausdrucken und an die Wand hängen könntest — Name wie auf dem Briefbogen, Straße mit voller Schreibweise (Straße nicht Str., sofern du dich dafür entscheidest), PLZ, Ort, Telefon in E.164 für Maschinen und lesbarer Display-Form für Menschen. Die Display-Form darf optisch abweichen (+49 152 … vs. +49152…), aber Ziffernfolge und Ländercode müssen identisch sein. Domain und Webseiten-URL im GBP müssen zur kanonischen Origin passen (bei Modern Stack: Apex modern-stack.de, nicht www als zweite Wahrheit).

Zusätzlich zur Triplett-Regel zählen in der Praxis oft Nebenfelder, die NAP „mitziehen“: rechtlicher Name vs. Markenanzeigename, Suite-/Etagenangabe, Ortsteil vs. Gemeinde, internationale Rufnummer vs. lokale Vorwahl. Entscheide einmal, dokumentiere die Entscheidung, und spiegle sie. Halbe Umstellungen („nur GBP geändert, Footer später“) sind der häufigste Dauerzustand unklarer Entities.

Warum Inkonsistenz Local Pack und KI-Antworten schwächt

Antwort zuerst: Systeme kreuzen Webseite, GBP und Verzeichnisse — Widersprüche senken Vertrauen in die Entity; das ist kein Versprechen auf bessere Rankings.

Lokale Suche und generative Antworten kombinieren mehrere Quellen: Maps/GBP-Felder, sichtbares HTML, Schema, Nutzerfeedback und Drittverzeichnisse. Wenn Telefon A im Footer und Telefon B im Profil stehen, „gewinnt“ oft die Quelle, die zuletzt gecrawlt oder stärker bestätigt wirkt — nicht deine bevorzugte NAP. Für Local Pack bedeutet das: unklare Zuordnung, doppelte Listings, falsche Öffnungszeiten-Synopsen. Für KI-Antworten (ChatGPT-Sichtbarkeit, Grounding in Answer Engines) bedeutet es: Halluzinationsrisiko steigt, weil Retrieval widersprüchliche Fakten sieht.

Wichtig und ehrlich: Sauberes NAP garantiert keine Position im Local Pack und keine Citation-Quote in ChatGPT & Co. Es entfernt eine Klasse vermeidbarer Fehler. Relevanz, Reviews, Proximität, Inhaltsqualität und Wettbewerb bleiben dominante Faktoren. Princeton GEO (Aggarwal et al., arXiv:2311.09735) betont zitierfähige Fakten und Quellen — widersprüchliche Kontaktdaten sabotieren genau diese Zitierfähigkeit.

Signalmatrix: wo NAP hingehört

Warum Schema allein NAP nicht rettet

Antwort zuerst: JSON-LD mit falscher Telefonnummer ist schlimmer als kein Schema — es bestätigt einen Fehler maschinell.

Google und andere Systeme erwarten, dass strukturierte Daten mit dem übereinstimmen, was Nutzer sehen (Structured data intro, Local Business). Im Census haben 41,9 % JSON-LD — technische Hülle ohne inhaltliche Konsistenz nützt wenig. Regel: zuerst sichtbare NAP auf der Webseite fixieren, dann Schema spiegeln, dann GBP. Abweichungen zwischen Öffnungszeiten auf Webseite und Profil sind ein klassischer Physio-/Handwerksfehler.

Minimaler LocalBusiness-Kern (Prinzip — Werte müssen Footer/Impressum/GBP spiegeln):

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Modern Stack",
  "url": "https://modern-stack.de",
  "telephone": "+4915225317285",
  "email": "info@modern-stack.de",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Glöckelsberg 13/2",
    "postalCode": "76669",
    "addressLocality": "Bad Schönborn",
    "addressRegion": "Baden-Württemberg",
    "addressCountry": "DE"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 49.22167,
    "longitude": 8.65734
  }
}

Wenn Markup und sichtbarer Text auseinanderlaufen, ist Schema schädlicher als kein Schema: Crawler und generative Engines sehen Widersprüche. Nach Modernisierung gehört Validierung (Rich-Results-Test / Schema-Stichprobe) in dieselbe Abnahme wie Canonicals — siehe Technical SEO Basis.

Organization vs. LocalBusiness: Organization beschreibt die Marke/Rechtseinheit; LocalBusiness (oder ein spezifischerer Typ) betont physischen Standort und lokale Angebote. Beide dürfen dieselbe NAP tragen. Widerspruch Name in Organization vs. GBP-Anzeigename ist ein häufiger Cutover-Fail nach Rebranding.

Welche typischen NAP-Fehler entstehen nach Migration?

Antwort zuerst: Cutover ist der Moment, in dem alte NAP-Fragmente am häufigsten sichtbar werden — PDF, Bilder, Plugin-Schema, zweites GBP.

Checkliste nach WordPress-Migration oder Baukasten-Cutover:

• Alte Telefonnummer noch in PDF-Fußzeilen, Visitenkarten-Downloads oder Hero-Bildern mit eingebranntem Text
• Zwei GBP-Einträge für dieselbe Adresse (alte GmbH + neuer Markenname)
• areaServed in Schema ohne echtes Einsatzgebiet (Handwerk)
• Postfach im Impressum, Straßenadresse nur im GBP
• www vs. Apex in Kontakt-URLs und GBP-Webseiten-Feld
• Yoast-/Rank-Math-Schema mit anderer Firma als Footer
• WhatsApp-Link mit alter Ziffernfolge, tel: mit neuer
• Öffnungszeiten nur im GBP, auf der Kontaktseite „nach Vereinbarung“ ohne Abgleich

Nach Migration prüfen wir Footer, Kontakt-MDX und Schema in einem Durchgang — nicht „später SEO“. Soft-Fails: HTML-Entities in Firmennamen (& im Titel), Trailing Spaces in Schema-Strings, unterschiedliche Hausnummernformatierung (13/2 vs. 13-2).

Smoke-Muster für den Abgleich (Prinzip):

# Sichtbare NAP-Stichprobe vs. JSON-LD (vereinfacht)
curl -s "https://example.de/" | rg -o 'Glöckelsberg[^<]+|\+49[0-9 ]{8,}' | head
curl -s "https://example.de/" | rg -o '"@type"\s*:\s*"(LocalBusiness|Organization)"' -n
# Manuell: GBP-Felder Name, Adresse, Telefon, Webseiten-URL, Öffnungszeiten
# gegen denselben Master-String halten — nicht aus dem Gedächtnis tippen

Ein zweiter Cutover-Klassiker: Redirects und Canonicals sind sauber, aber die Kontaktseite zeigt noch die alte Domain in Fließtext und Schema. sameAs-Links auf LinkedIn oder Maps dürfen bleiben — sie ersetzen nicht die kanonische url. Wenn du den Markennamen änderst, plane GBP-Namensänderung und Impressum gemeinsam; zeitversetzte Rebrands erzeugen wochenlang doppelte Entities.

Wie Modern Stack NAP bei der Migration setzt

Antwort zuerst: Eine Master-NAP-Datei im Projekt speist Footer, Kontaktseite und Schema — nicht drei manuelle Pflegeorte; GBP pflegst du in Google gegen dieselbe Quelle.

Workflow:

1. Master-NAP definieren — Name, Straße, PLZ, Ort, E.164-Telefon, Display-Telefon, kanonische URL, E-Mail.
2. HTML sichtbar machen — Footer, Kontakt, Impressum; keine versteckten NAP-Blöcke nur für Crawler.
3. LocalBusiness/Organization JSON-LD — aus demselben Datensatz, Code statt Plugin-Zufall.
4. GBP-Abgleich — Name, Kategorie, Adresse, Telefon, Webseite, Öffnungszeiten, Attribute; Duplikate melden/zusammenführen.
5. Regionsseiten — Place-Kontext verlinken (Bad Schönborn, Mingolsheim, Langenbrücken), ohne eine zweite Straße zu erfinden.

Referenzbeispiel Modern Stack: Glöckelsberg 13/2, 76669 Bad Schönborn, +4915225317285, https://modern-stack.de — Webseite, Schema und GBP müssen identisch sein. GBP-Pflege bleibt in Googles Oberfläche; wir liefern die konsistente Webseiten-Quelle und das Schema. Brand-Entity: Modern Stack.

Technisch speichern wir NAP idealerweise als eine Konstante/Config (Name, Adresse, Geo, Telefon E.164, Display, E-Mail, kanonische URL). Footer-Komponente, Kontakt-MDX und JSON-LD importieren denselben Datensatz. So verhindert der Stack Drift, den Plugin-SEO und manuelle Textbausteine sonst jede Woche erzeugen. Wenn Redaktion Texte ändert, bleibt die Kontaktzeile geschützt — editierbar nur über den Master.

Wie Regionsseiten und NAP zusammenspielen

Antwort zuerst: Regions- und Ortsteilseiten vertiefen Intent und Place-Kontext — sie ersetzen keine Master-NAP und dürfen keine Zweitadresse erfinden.

Local SEO & Regionen und lokale Landings (z. B. Bad Schönborn inkl. Ortsteile) helfen Menschen und Maschinen, Leistungsgebiet und Sitz zu verstehen. Typischer Fehler: Auf der Mingolsheim-Seite eine „Filiale Mingolsheim“ zu behaupten, obwohl nur ein Sitz in Bad Schönborn existiert. Korrekt: Sitz-NAP einmal klar, Service-Gebiet und Place-Links (areaServed, interne Verlinkung zu Place-Entities) ohne Fake-Standort.

Dasselbe Muster gilt für Bruchsal, Kraichgau und Landkreis Karlsruhe: Ort im H1/Intent, NAP aus dem Master. Keyword-Stuffing von Ortsnamen im Firmennamen im GBP verstößt gegen Profilrichtlinien und erzeugt oft Duplikat-/Ablehnungsrisiken — sag den Ort in Leistungs- und Regionscopy, nicht im legalen Namen.

GBP, Local Pack und generative Antworten — was du erwarten darfst

Antwort zuerst: Konsistente NAP erhöht die Chance auf korrekte Entity-Zuordnung; sie verspricht keine Local-Pack-Position und keine AI-Citation.

Lokale Antworten kombinieren GBP-Signale, Webseiteninhalt und Nutzerfeedback. Konsistente NAP erhöht die Chance, dass „Telefon Praxis XY“ oder „Steuerberater in Bruchsal“ die richtige Entity trifft — ohne Garantie auf Rankings. Inhaltlich: answer-first Kontaktblöcke, klare CTAs, keine NAP nur in Bildern. Performance (Core Web Vitals) erleichtert das Abrufen mobiler Kontaktseiten; langsame Origins erschweren Crawl und Nutzerkonversion gleichermaßen.

Für generative Engines zählt Extrahierbarkeit: flaches HTML, klare Fakten, externe Bestätigung. Reviews und Maps-Signale bleiben GBP-seitig; die Webseite muss sie nicht nachbauen, aber auch nicht widersprechen (andere Adresse, andere Marke). Vertiefung: GEO & AI-Sichtbarkeit, ChatGPT-Sichtbarkeit.

Was du nicht erwarten solltest: dass ein NAP-Cleanup allein eine schlechte Leistungsseite, fehlende Bewertungen oder irrelevante Kategorien ausgleicht. Local Pack gewichtet Nähe, Relevanz und Bekanntheit; NAP ist Hygiene. AI-Antworten gewichten zitierfähige Passagen und Bestätigung — NAP ist eine der Faktenquellen, nicht die gesamte GEO-Strategie. Wer „wir machen NAP und sind dann #1“ verspricht, verkauft Sicherheit, die das System nicht hergibt.

Wann NAP-Arbeit dringend ist — und wann sie allein nicht reicht

Antwort zuerst: Dringend bei Rufnummernwechsel, Umzug, Rebranding, doppelten GBP-Einträgen oder Schema/HTML-Drift — allein zu wenig, wenn Angebot, Conversion und Inhalte unklar sind.

Jetzt angehen, wenn: Kunden melden falsche Nummern, Maps zeigt eine Alt-Adresse, Impressum und Footer divergieren, nach Migration noch Plugin-Schema mit Alt-Daten läuft, oder zwei Profile um denselben Pin konkurrieren.

Zusätzlich brauchen, wenn: Die Webseite keine klaren Leistungen und Anfragewege hat, Core Web Vitals mobil Kontaktpfade abwürgen, oder Regionscopy Fake-Standorte andeutet. Dann NAP plus Modernisierung, ggf. Redesign und Conversion — nicht nur ein Profil-Update in Google.

Mehrstandort-Betriebe: jedes physische Büro braucht klare NAP und idealerweise eigene LocalBusiness-Knoten bzw. GBP-Einträge — ohne „virtuelle“ Adressen. Franchise: lokale Office-Mails und lokale NAP, keine Konzern-Zentrale als Ersatz für den Standort, an dem Kunden erscheinen.

NAP und Branchen-Intent

Antwort zuerst: Dieselbe NAP-Regel gilt überall — aber sichtbarer Kontext unterscheidet Handwerk, Physio und Steuerberater.

Handwerk: Einsatzgebiet-Texte ergänzen NAP, ersetzen sie nicht (Handwerk, Handwerk-Studie). Physio: Öffnungszeiten und Terminweg müssen zu GBP passen (Physio). Steuerberater: Kanzleisitz sachlich, ohne irreführende Zweigstellen (Steuerberater). Agenturen vor Ort: Webdesign Bad Schönborn — NAP und Leistungsgebiet trennen. Generative Antworten mischen diese Signale — Widersprüche verwässern lokale Autorität, ersetzen aber keine inhaltliche Qualität.

Wie du NAP selbst prüfst und misst

Antwort zuerst: Quartals-Abgleich GBP vs. Footer vs. Impressum vs. Schema — Anruf testen, Maps-Pin vs. Adresse, keine Ranking-Fantasie als KPI.

Konkrete Stichprobe:

1. Suche Markenname + Ort — stimmen Telefon und Adresse in der Knowledge-Panel-/Maps-Karte?
2. Öffne die Webseite — Footer und Kontakt identisch?
3. Rich-Results-/Schema-Stichprobe — telephone und streetAddress deckungsgleich?
4. Anruf und WhatsApp-Link testen (richtige Ziffernfolge).
5. Bei Umzug: zuerst Webseite + Redirects + Schema, dann GBP — nicht umgekehrt, sonst lebt die alte Adresse länger im HTML.

Search Console Impressionen für „Leistung + Ort“ sind nützlich — ohne sauberes NAP steigen Impressionen selten in Anrufe. Census-Reminder: Agent-Ready 25/100 — technische Basis first. Misserfolge dokumentieren (Screenshot GBP vs. Footer), nicht „wir machen mehr Ortsseiten“ als Ersatztherapie.

Was kostet NAP-Arbeit im Modernisierungsrahmen?

Antwort zuerst: Basis ab 500 € für bis zu 10 Seiten — NAP-Abgleich gehört in denselben technischen Durchgang wie Schema und Cutover; kein separates „Local-SEO-Wunderpaket“.

Im Rahmen der Webseite-Modernisierung setzen wir Master-NAP, sichtbare Kontaktblöcke und LocalBusiness/Organization. GBP-Login und Verifizierung bleiben beim Betreiber; wir liefern die konsistente Quelle und die Checkliste. Module: Redesign ab 1.000 €, Knowledge Graph 500 €, Conversion ab 500 € — siehe Preise & Pakete. Sonderumfänge (viele Standorte, Franchise, Shop-Standorte) werden vorab getrennt ausgewiesen.

Checkliste vor Go-Live und nach Quartal

Master-NAP schriftlich, Footer = Kontakt = Impressum, Schema-Spiegel, GBP-Felder abgeglichen, keine Duplikat-Profile, Regionsseiten ohne Fake-Filialen, Öffnungszeiten synchron, Webseiten-URL = Kanonik, E.164 und Display-Telefon konsistent, Alt-PDFs bereinigt oder entfernt, Anruf-/WhatsApp-Test bestanden. Nach Cutover: 48-Stunden-Stichprobe Maps + Startseite + Kontakt. Quartalsweise: denselben Abgleich — besonders nach Rufnummernwechsel, Umzug oder Rebranding.

Kurz: Google Business Profile & NAP ist Entity-Hygiene — eine Schreibweise, viele Spiegel, keine Ranking-Garantie. Anfrage stellen