LocalBusiness-Schema

TL;DR — LocalBusiness schema ist code Sie hinzufügen zu ein Seite that tells Suche Engines the facts über ein physical business — its name, address, phone number, und hours. Google nur requires two things (name und address); everything else ist optional aber macht the Ergebnis richer. es ist nicht the gleich als setting up ein Google Business Profile, und adding es tut nicht guarantee Sie ein fancy Suche Ergebnis — es just macht Sie eligible für one.

war LocalBusiness schema ist

wenn ein Suchmaschine reads Ihre “Contact” Seite, es sees text. es kann nicht automatically mitteilen Ihre street address aus Ihre phone number aus Ihre opening hours the Weg Sie kann. LocalBusiness schema spells es out in code: dies ist the name, dies ist the address, dies ist the phone number, these sind the hours.

es uses the shared vocabulary aus schema.org — the gleich vocabulary behind alle schema markup — und Sie usually schreiben es als JSON-LD, ein small block von code that sits in the Seite ohne changing wie es looks. Evidence for this claim Schema.org LocalBusiness is a subtype of both Organization and Place for describing a physical business or branch. Scope: Schema.org vocabulary; Google applies separate local-business search requirements. Confidence: high · Verified: 2026-07-14 Schema.org: LocalBusiness

war Google tatsächlich benötigt

hier’s the surprising part. schema.org defines dozens von properties Sie could hinzufügen, aber Google nur requires two:

• name — the name von the business.
• address — the physical street address.

Everything else — phone number, hours, price range, map coordinates — ist recommended. Evidence for this claim Google's LocalBusiness feature documentation requires name and address and recommends additional applicable business details. Scope: Google Search LocalBusiness requirements; eligibility and display are not guaranteed. Confidence: high · Verified: 2026-07-14 Google: LocalBusiness structured data Sie don’t haben zu enthalten es, aber the mehr accurate detail Sie hinzufügen, the mehr vollständig Ihre listing kann look in Suche.

The two things beginners erhalten wrong

1. Schema ist nicht Ihre Google Business Profile. These sind two different Systeme. Ihre Google Business Profile (the free listing Sie claim bei business.google.com) ist war powers Ihre pin auf Google Maps und the “local pack” von three businesses under ein map. LocalBusiness schema ist separate code auf Ihre own Website. One tut nicht ersetzen the other — Sie generally wollen both, und Google reconciles them separately.

2. Don’t mark up Ihre own star rating. es ist tempting zu hinzufügen Ihre own five-star average mit aggregateRating, aber Google’s own guidelines say that property ist für Websites that prüfen other businesses (like ein directory reviewing restaurants), nicht für ein business rating itself. Marking up Ihre own testimonials als ein rating ist ein “self-serving prüfen” und breaks the rules.

One mehr: verwenden the specific type. wenn Sie ausführen ein restaurant, mark es up als Restaurant, nicht the generic LocalBusiness. Google explicitly asks für the meisten specific type that fits.

wollen the full version — the exact property table, subtype selection, geo-coordinate precision, multi-location patterns, und wie “NAP consistency” fits in? Switch zu the Fortgeschritten tab.

TL;DR — LocalBusiness ist ein subtype von Organization und Place, so the full schema.org spec inherits dozens von properties — aber Google requires nur name + address und consumes ~12 recommended ones. The wins: verwenden the meisten specific subtype (multiple types go in ein array; additionalType ist nicht supported), halten NAP consistent across Ihre markup, Google Business Profile, und citations, und erhalten the details right — geo benötigt ≥5 decimal places, priceRange must stay under 100 characters. Don’t mark up Ihre own aggregateRating/review (das ist für Websites reviewing other businesses; self-serving Bewertungen break the guidelines), und don’t treat schema als ein Google Business Profile substitute — sie sind separate, reconciled separately, und valid markup nur macht Sie eligible.

wo es sits: ein subtype von Organization und Place

The single meisten nützlich thing zu verstehen über LocalBusiness ist its position in the schema.org hierarchy. es ist ein subtype von both Organization und Place, welche ist exactly warum es kann carry general company properties (name, logo, sameAs) und location-specific ones (address, geo, openingHoursSpecification). That dual inheritance ist auch warum the full spec ist so large — es pulls properties aus two big parent types.

That matters für wie Sie think über the wider Entity & Identity schema picture. ein company-wide Organization entity (sitewide, auf the homepage) und ein per-location LocalBusiness entity sind related aber distinct: one describes the company, the other describes ein place Sie kann walk into. für the company-level entity, sehen Organization schema; für the Menschen behind es, Person schema.

The full spec vs. war Google tatsächlich consumes

dies ist the distinction meisten Leitfäden blur. schema.org/LocalBusiness inherits dozens von properties aus Organization und Place. Google consumes ein small subset. Don’t confuse “schema.org supports X” mit “Google will tun something mit X.”

erforderlich (nur two):

• address (PostalAddress) — the physical location. Google’s advice: enthalten als viele address sub-properties als possible; the mehr Sie bereitstellen, the higher the quality von the Ergebnis.
• name — the name von the business.

Recommended (the properties that tatsächlich enrich the Ergebnis): aggregateRating, department, geo (mit geo.latitude / geo.longitude), menu, openingHoursSpecification (mit .opens, .closes, .dayOfWeek, .validFrom, .validThrough), priceRange, review, servesCuisine, telephone, und url.

The takeaway für prioritizing dev effort: nail the erforderlich pair, then hinzufügen the recommended properties that machen Ihre listing mehr vollständig (hours und geo für ein storefront; servesCuisine und menu für ein restaurant). Filling in obscure inherited properties that Google ignores ist wasted effort.

Die passende Unterkategorie auswählen

Google ist explicit: verwenden the meisten specific LocalBusiness sub-type possible — für Beispiel Restaurant, DaySpa, HealthClub. Generic LocalBusiness funktioniert, aber ein specific subtype gives Engines mehr zu arbeiten mit.

ein few practical mappings:

• Restaurant / café → Restaurant, CafeOrCoffeeShop, BarOrPub (under FoodEstablishment)
• Law firm → LegalService (oder Attorney)
• Dentist / doctor → Dentist, Physician (under MedicalBusiness)
• Plumber / electrician / general contractor → HomeAndConstructionBusiness subtypes (Plumber, Electrician, GeneralContractor)
• Consultancy / agency mit kein better fit → ProfessionalService

wenn Ihre business genuinely spans two types, specify them als ein array — Google supports multiple @type Werte that Weg. Note that additionalType ist nicht supported für dies purpose, so don’t reach für es.

NAP consistency — schema, GBP, und citations

“NAP” (Name, Address, Phone) consistency ist longstanding local-SEO beste practice: the gleich name, address, und phone sollte erscheinen identically across Ihre auf-Seite schema, Ihre Google Business Profile, und directory citations (Yelp, BBB, industry directories). Mismatches — ein old suite number hier, ein tracking phone number dort — muddy the signals Engines verwenden zu identifizieren und trust ein location.

One honest caveat: “NAP” ist industry shorthand, nicht ein Google spec Begriff. Google’s LocalBusiness documentation tut nicht verwenden the word. Frame es als well-established local-SEO consensus, nicht ein quoted Google Ranking factor. es still matters — arguably mehr als any single individual property — weil es ist über the coherence von Ihre entity across the Web, nicht one field auf one Seite.

The implementation details that trip Menschen up

• Geo coordinates benötigen bei least 5 decimal places. Google states the precision must sein bei least 5 decimal places für both latitude und longitude. ein common slip ist ein CMS oder geocoding Tool rounding coordinates zu 2–3 places — genug zu put Ihre pin in the wrong block.
• priceRange hat ein 100-character ceiling. es must sein shorter than 100 characters; bei 100 oder mehr, Google wird nicht zeigen ein price range bei alle. halten es short ($$, oder $10–30), nicht ein paragraph.
• openingHoursSpecification syntax und edge cases. dayOfWeek accepts full schema.org URLs (https://schema.org/Monday) oder the short name (Monday). Google’s own Beispiele verwenden 24-hour opens/closes times ohne seconds (hh:mm); schema.org’s broader Time type auch accepts hh:mm:ss wenn Ihre generator adds es. Four patterns abdecken almost every case, straight aus Google’s documentation: ein normal day ("opens": "09:00", "closes": "17:00"), hours that cross midnight ("opens": "18:00", "closes": "03:00" für ein overnight Saturday), offen alle day ("opens": "00:00", "closes": "23:59"), und closed alle day ("opens": "00:00", "closes": "00:00"). für seasonal oder holiday closures, hinzufügen validFrom / validThrough in YYYY-MM-DD (Google’s own Beispiel uses "validFrom": "2015-12-23", "validThrough": "2016-01-05") — ein nuance meisten basic implementations skip entirely.
• Department naming convention. wenn Sie nest ein department, enthalten the Shop name mit the department name (e.g., “gMart” und “gMart Pharmacy”) — unless the department ist its own independent brand (e.g., “beste kaufen” und “Geek Squad”), in welche case name es standalone.

Bewertungen und ratings: the self-serving-rating trap

dies one wastes ein lot von implementation effort. Google’s docs sind klar that aggregateRating und review sind recommended nur für Websites that capture Bewertungen über other local businesses — ein directory oder prüfen Plattform, nicht the business rating itself. ein business marking up its own star average auf its own Seite ist doing ein “self-serving prüfen,” welche violates Google’s prüfen-snippet guidelines; Google stopped showing self-serving prüfen stars für LocalBusiness/Organization Jahre ago. Evidence for this claim Google's review snippet rules make self-serving reviews for LocalBusiness and Organization ineligible for the star review feature. Scope: Google Search review snippet eligibility policy; genuine third-party review contexts are treated differently. Confidence: high · Verified: 2026-07-14 Google: Review snippet structured data

So wenn Sie waren planning zu sprinkle Ihre homepage testimonials into ein aggregateRating: don’t. es wird nicht earn the stars Sie sind picturing, und es kann cross the line aus “kein benefit” into “guideline violation.”

Multi-location businesses: one Seite vs. viele

Competitors geben hand-wavy advice hier, so let me sein concrete. The correct pattern depends auf Ihre architecture:

• One LocalBusiness per location Seite. The cleanest approach für ein chain: jede location erhält its own Seite mit its own LocalBusiness markup describing that address. Sie kann tie them zu the parent mit parentOrganization / branchOf.
• Nesting under Organization. bei the company level, Sie kann express the brand als ein Organization mit locations als subOrganization.

war nicht zu tun: stack five unrelated LocalBusiness blocks flatly auf Ihre homepage. wenn ein Seite hat one address in the footer aber five different LocalBusiness addresses in the markup, Sie’ve made es ambiguous welche address the Seite ist tatsächlich über. Mark up the location the Seite represents.

LocalBusiness-Schema vs. Google Unternehmensprofil

Say dies plainly weil meisten Leitfäden bury es: schema markup ≠ Google Business Profile. They sind different Systeme that Google reconciles separately.

• Ihre Google Business Profile feeds Maps und the local pack directly durch Google’s own Systeme. es ist the primary driver von “near me” und local-pack visibility.
• auf-Seite LocalBusiness schema ist ein corroborating auf-Website signal Google may verwenden für Knowledge Panels und enriched Ergebnisse. es ist nicht ein substitute für ein Business Profile — und ein Business Profile ist nicht ein substitute für auf-Seite schema.

Sie wollen both, kept consistent (das ist the NAP point again). Neither one alone tut the other’s job.

war es tut — und tut nicht — guarantee

Valid, guideline-compliant markup macht ein Seite eligible für ein local Knowledge Panel oder ein business carousel — though “eligible” scopes differently per feature. Google’s restaurant carousel, beispielsweise, ist currently limited zu ein small festlegen von participating restaurant providers, so valid Restaurant markup alone tut nicht erhalten ein arbitrary Website into es. Beyond that scoping, eligibility still tut nicht guarantee display — Google says outright that es tut nicht guarantee that features consuming structured data will zeigen up in Ergebnisse. und ein note auf the stats floating rund competitor blogs: numbers like “30–50% mehr häufig in the local pack” oder “20–35% CTR lift” circulate widely mit kein primary Quelle. Treat them als unverified marketing claims, nicht Google-confirmed outcomes.

Validate vor Sie ship

1. hinzufügen the erforderlich properties (name, address), then the recommended ones that fit Ihre business.
2. Validate mit the Rich Results Test und the Schema Markup Validator.
3. Deploy, then prüfen mit URL Inspection in Search Console und Anfrage ein recrawl.
4. Monitor the structured-Daten Berichte in Search Console over time.

Validate, then deploy — nicht the reverse.

AI summary

ein condensed nehmen auf the Advanced version:

• war es ist: schema.org/LocalBusiness structured data (usually JSON-LD) describing ein physical business — name, address, phone, hours, geo, price range.
• Hierarchy: ein subtype von both Organization und Place, welche ist warum es inherits dozens von properties und warum the full spec ist large.
• Full spec vs. Google: Google requires nur name + address und consumes ~12 recommended properties (geo, openingHoursSpecification, priceRange, telephone, url, department, menu, servesCuisine, plus aggregateRating/review). Don’t assume “schema.org supports X” bedeutet “Google uses X.”
• Subtype: verwenden the meisten specific subtype (Restaurant, LegalService, Dentist), nicht generic LocalBusiness. Multiple types go in ein array; additionalType ist nicht supported.
• NAP consistency: halten name/address/phone identical across markup, Google Business Profile, und citations. “NAP” ist industry shorthand, nicht ein Google spec Begriff — aber coherence matters mehr als any single property.
• Detail traps: geo benötigt ≥5 decimal places; priceRange must sein under 100 characters oder Google drops es; opening hours verwenden hh:mm:ss und short oder full dayOfWeek, mit validFrom/validThrough für seasonal closures.
• Bewertungen: aggregateRating/review sind für Websites reviewing other businesses. Marking up Ihre own rating ist ein self-serving prüfen that violates Google’s guidelines (self-serving stars waren dropped rund 2019).
• Multi-location: one LocalBusiness per location Seite (tie mit parentOrganization/branchOf) oder nest under Organization via subOrganization. Don’t stack unrelated addresses flatly auf the homepage.
• Schema ≠ Google Business Profile: separate Systeme, reconciled separately. GBP feeds Maps/local pack; auf-Seite schema corroborates für Knowledge Panels. wollen both.
• kein guarantee: valid markup macht Sie eligible, nicht guaranteed. Ignore uncited “30–50% mehr local pack” / “20–35% CTR” stats — kein primary Quelle.
• Validate: Rich Results testen + Schema Markup Validator, then URL Inspection und Search Console Berichte. Validate, then deploy.

Offizielle Dokumentation

Primary-Quelle documentation aus the Suchmaschinen und schema.org.

Google

• Local business (LocalBusiness) structured data — the maßgebliche Quelle: required/recommended properties, subtype guidance, geo precision, priceRange limit, department naming, und the validation workflow.
• Organization structured data — the company-level entity, für the LocalBusiness-vs-Organization distinction.
• Review snippet structured data — the guidelines behind the self-serving-prüfen restriction auf aggregateRating/review.
• Rich Results Test — prüft rich-Ergebnis eligibility und erforderlich-property errors.
• Schema Markup Validator — validates any schema.org type, einschließlich LocalBusiness.

schema.org

• schema.org/LocalBusiness — the full vocabulary: every inherited property aus Organization und Place (the “full spec” side von the vergleichen-und-contrast).

Bing / Microsoft

• Marking Up Your Site with Structured Data — Bing Webmaster Tools — Bing’s general structured-Daten guidance und validator (Schema.org / Microdata / RDFa / OpenGraph).
• Bing Places for Business — Bing’s separate listing Produkt, the parallel zu Google Business Profile (gleich “listing Plattform ≠ auf-Seite schema” distinction).

Quotes aus the Quelle

auf-the-record statements aus Google’s LocalBusiness documentation. wo the Seite exposes the text, the Link ist ein deep Link that jumps zu the quoted passage.

Google docs — war es enables

• “wenn users Suche für businesses auf Google Suche oder Maps, Suchergebnisse may display ein prominent Google knowledge panel mit details über ein business that matched the Anfrage. wenn users Suche für ein type von business (zum Beispiel, ‘beste NYC restaurants’), they may sehen ein carousel von businesses related zu the Anfrage.” Local business structured data

Google-Dokumentation — Leitfaden für Unterkategorien

• “verwenden the meisten specific LocalBusiness sub-type possible; zum Beispiel, Restaurant, DaySpa, HealthClub, und so auf.” Jump to quote

Google-Dokumentation — Geopräzision

• “The precision must sein bei least 5 decimal places.” Jump to quote

Google docs — self-serving Bewertungen

• auf aggregateRating und review: “dies property ist nur recommended für Websites that capture Bewertungen über other local businesses.” Jump to quote

Eigenschaften-Spickzettel

erforderlich vs. recommended (war Google tatsächlich consumes)

Gängige LocalBusiness-Unterkategorien

Fast facts

• erforderlich = 2 (name, address); everything else ist recommended.
• verwenden the meisten specific subtype; multiple types go in ein array; additionalType ist nicht supported.
• Geo ≥ 5 decimal places; priceRange < 100 characters.
• aggregateRating/review = für Websites reviewing other businesses, nicht self-Bewertungen.
• Schema ≠ Google Business Profile — separate Systeme, reconciled separately.
• NAP consistency (industry Begriff, nicht ein Google spec word) across markup, GBP, und citations matters mehr als any single property.
• Valid markup = eligible, never guaranteed. Validate → deploy.

Anti-patterns: wie LocalBusiness markup goes wrong

The mistakes I sehen meisten, und war zu tun stattdessen.

1. NAP inconsistency. Ihre schema says “123 Main St, Suite 200,” Ihre Google Business Profile says “123 Main Street,” und Yelp still hat Ihre old phone number. These mismatches undermine the whole point — Engines verwenden the coherence von Ihre name/address/phone across the Web zu identifizieren und trust ein location. Fix: pick one canonical NAP und machen the markup, the Business Profile, und every citation match es exactly.

2. Verwendung the generic type wenn ein specific one exists. Marking ein restaurant als bare LocalBusiness wenn Restaurant exists throws away signal Google explicitly asks für. Fix: verwenden the meisten specific subtype that fits (Restaurant, LegalService, Dentist); verwenden multiple @type Werte in ein array wenn Sie genuinely span two — aber nicht additionalType.

3. Self-serving Bewertungen. Marking up Ihre own testimonials als aggregateRating/review zu try zu win star ratings. Google’s guidelines reserve diese properties für Websites reviewing other businesses; self-serving stars waren dropped Jahre ago und dies kann cross into ein guideline violation. Fix: don’t self-rate. Earn genuine Drittanbieter- Bewertungen (welche live auf the prüfen Plattformen, nicht Ihre markup).

4. Stacking multiple locations auf one Seite. Five different LocalBusiness blocks mit five different addresses auf one homepage, wenn the Seite really represents one entity (oder none). es ist ambiguous welche address the Seite ist über. Fix: one LocalBusiness per location Seite (tie zu the brand mit parentOrganization/branchOf), oder model the company als ein Organization mit subOrganization.

5. Confusing schema mit ein Google Business Profile. Assuming auf-Seite markup will erhalten Sie into Maps und the local pack, oder that having ein Business Profile bedeutet Sie don’t benötigen schema. sie sind separate Systeme that Google reconciles separately — GBP drives Maps/local pack, schema corroborates für Knowledge Panels. Fix: festlegen up both und halten them consistent.

Bonus trips: rounding geo coordinates below 5 decimal places (wrong-block pin), ein priceRange over 100 characters (Google silently drops es), und expecting ein guaranteed rich Ergebnis aus valid markup (eligibility ≠ display).

testen yourself: LocalBusiness Schema

Five quick questions auf LocalBusiness schema — erforderlich properties, subtypes, the prüfen trap, und wie es relates zu ein Google Business Profile. Pick ein Antwort für jede, then prüfen.

welche LocalBusiness subtype sollte I verwenden?

The article’s subtype guidance turns into ein straightforward branch: match Ihre business category zu the meisten specific LocalBusiness sub-type schema.org defines, und nur fall back zu the generic type wenn nothing fits.

One Seite per location, oder nest under Organization?

The other genuine fork in the article ist architectural: wie tun Sie markup ein business mit mehr als one physical location?

Worked Beispiele: LocalBusiness JSON-LD

Three annotated blocks, jede erstellt aus the erforderlich und recommended properties covered above.

Beispiel 1: minimum viable markup (erforderlich properties nur)

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Riverside Dental Care",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "412 Riverside Ave",
    "addressLocality": "Columbus",
    "addressRegion": "OH",
    "postalCode": "43215",
    "addressCountry": "US"
  }
}

• name und address sind the nur two properties Google requires — dies passes validation, aber es ist leaving the recommended properties (und ein specific subtype) auf the table.
• Even bei dies minimal level, Google’s advice ist zu enthalten als viele address sub-properties als Sie kann — das ist warum alle five sind filled in hier stattdessen von ein single streetAddress line.

Beispiel 2: ein specific subtype mit the recommended properties filled in

{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "name": "Riverside Dental Care",
  "telephone": "+1-614-555-0142",
  "url": "https://www.riversidedentalcare.example/",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "412 Riverside Ave",
    "addressLocality": "Columbus",
    "addressRegion": "OH",
    "postalCode": "43215",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 39.96199,
    "longitude": -83.00275
  },
  "priceRange": "$$",
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday"],
      "opens": "08:00:00",
      "closes": "17:00:00"
    }
  ]
}

• @type ist Dentist, nicht generic LocalBusiness — the specific subtype Google asks für.
• geo.latitude/geo.longitude both carry 5 decimal places, matching Google’s minimum-precision requirement.
• priceRange ist ein short $$, well under the 100-character ceiling.
• openingHoursSpecification uses hh:mm:ss times und short dayOfWeek names, grouped für the days that teilen the gleich hours.

Beispiel 3: ein restaurant mit ein seasonal-closure und department nesting note

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "gMart Pharmacy",
  "servesCuisine": "American",
  "menu": "https://www.example-diner.example/menu/",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "88 Harbor Rd",
    "addressLocality": "Portland",
    "addressRegion": "ME",
    "postalCode": "04101",
    "addressCountry": "US"
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "https://schema.org/Monday",
      "opens": "11:00:00",
      "closes": "21:00:00",
      "validFrom": "2026-01-01",
      "validThrough": "2026-12-24"
    }
  ]
}

• servesCuisine und menu sind the recommended properties that matter meisten für ein FoodEstablishment subtype like Restaurant.
• dayOfWeek hier uses the full schema.org URL form statt the short name — both sind valid, dies just zeigt the alternative.
• validFrom/validThrough mark ein seasonal window in YYYY-MM-DD — the detail meisten basic implementations skip.
• The name Wert follows the article’s department-naming convention: “gMart Pharmacy” keeps the Shop name mit the department name, the pattern zu verwenden unless the department ist its own independently branded entity (like “beste kaufen” und “Geek Squad”).

Three mental models für thinking über LocalBusiness schema

1. Full spec vs. war Google tatsächlich consumes. schema.org/LocalBusiness inherits dozens von properties aus both Organization und Place, aber Google requires nur name + address und meaningfully consumes über ein dozen recommended ones (geo, openingHoursSpecification, priceRange, telephone, url, department, menu, servesCuisine, aggregateRating/review). The framework: never assume “schema.org supports property X” bedeutet “Google will tun something mit property X.” Prioritize the erforderlich pair, then the recommended properties that fit Ihre business, und treat obscure inherited properties Google ignores als wasted implementation effort.

2. Schema ist nicht ein Google Business Profile. These sind two separate Systeme that Google reconciles independently. ein Google Business Profile feeds Maps und the local pack directly durch Google’s own Systeme — es ist the primary driver von “near me” und local-pack visibility. auf-Seite LocalBusiness schema ist ein corroborating auf-Website signal Google may verwenden für Knowledge Panels und enriched Ergebnisse. Neither substitutes für the other; the framework ist “festlegen up both, und don’t expect one zu tun the other’s job.”

3. NAP als coherence, nicht ein single field. Name/Address/Phone consistency across Ihre schema markup, Ihre Google Business Profile, und directory citations ist nicht über any one property being correct — es ist über the coherence von Ihre entity across the entire Web. ein mismatched suite number oder ein stale tracking phone number in one place muddies the signals Engines verwenden zu identifizieren und trust ein location, even wenn every individual field ist technically valid auf its own Seite. Treat “NAP” als well-established local-SEO consensus (the Begriff itself ist nicht in Google’s documentation), nicht ein single checkbox zu tick once.

Tools für validating LocalBusiness markup

• Rich-Result Eligibility Checker — my own free Tool. Paste Ihre LocalBusiness JSON-LD, ein HTML Seite, oder fetch ein live URL, und es zeigt exactly welche erforderlich fields sind missing und welche recommended ones Sie sind leaving out, specific zu the local-business rich Ergebnis. es läuft entirely in Ihre browser, so nothing Sie paste in leaves Ihre machine.
• Schema Markup Validator — auch mine. Validates the JSON-LD’s schema.org vocabulary directly (nicht just the Google-specific subset), prüft cross-block @id references wenn Sie sind linking LocalBusiness zu ein parent Organization, und gives Sie back ein corrected, copy-pasteable block.
• Rich Results Test — Google’s own Tool. verwenden es after the two above zu confirm Google’s live parser agrees the Seite ist eligible.
• URL Inspection (Search Console) — after deploying, prüfen wie Google tatsächlich crawled und rendered the Seite, und Anfrage ein recrawl.

Pitch: ausführen the Rich-Ergebnis Eligibility Checker oder the Schema Markup Validator vor Sie ship ein ändern, then confirm mit the Rich Results testen und URL Inspection after — das ist the gleich sequence the Validation Tests lens below walks durch in detail.

Proving Ihre LocalBusiness markup ändern worked

testen 1: erforderlich-property und syntax validation

testen zu ausführen: Paste the updated JSON-LD into my Rich-Result Eligibility Checker oder Schema Markup Validator. Expected Ergebnis: kein missing-erforderlich-field errors auf name oder address, und the Tool zeigt the local-business rich Ergebnis als eligible. Failure interpretation: ein flagged missing property bedeutet es genuinely ist nicht present in the markup Sie shipped — re-prüfen the JSON-LD Quelle rather than assuming ein caching issue. Monitoring window: Immediate — the Tool reads the markup directly, kein crawlen wait erforderlich. Rollback trigger: Validation still fails after ein direct fix zu the template — revert the ändern und re-diff against the last known-good JSON-LD.

testen 2: Google’s own Rich Results testen agrees

testen zu ausführen: ausführen the live URL durch Google’s Rich Results Test. Expected Ergebnis: The Seite ist detected als eligible für the local business Ergebnis, mit the erforderlich und recommended properties Google’s parser sees matching war Sie shipped. Failure interpretation: wenn Google’s Tool disagrees mit the two Tools above, the live Seite likely differs aus war Sie validated — prüfen für ein caching layer oder ein erstellen step serving stale markup. Monitoring window: Immediate. Rollback trigger: The eligible-Seite prüfen still zeigt missing erforderlich fields after ein deploy — the fix didn’t reach the live Seite.

testen 3: Search Console structured-Daten Berichte over time

testen zu ausführen: Search Console’s structured-Daten / Enhancement Berichte für the affected URLs, after requesting ein recrawl via URL Inspection. Expected Ergebnis: The URL count mit LocalBusiness errors drops zu zero, und previously flagged Seiten move into the valid bucket. Failure interpretation: Still flagged after ein recrawl bedeutet either the fix hasn’t propagated zu the version Google fetched, oder ein different erforderlich property ist auch missing — re-ausführen testen 1 against the exact URL Search Console Listen. Monitoring window: 2–4 weeks — structured-Daten Bericht Aktualisierungen lag behind ein single recrawl. Rollback trigger: Error counts climb statt falling after the ändern ships broadly — revert und re-validate vor rolling forward again.

Änderungsprotokoll