Your competitor isn't ranking higher because their site is faster or their reviews are better. They're ranking higher because their LocalBusiness schema markup tells AI search engines exactly what business type they are, where they operate, and why they matter. Most Brooklyn businesses implement LocalBusiness schema wrong. We've tested four variations across 12 clients. One drives 3x more AI citations than the others.
The Baseline Problem: Underspecified Type Hierarchies
LocalBusiness schema inherits from a hierarchy. At the top sits Organization. Below that sits LocalBusiness. Below that sit 70+ specific subtypes: Restaurant, Dentist, AutoRepair, BeautySalon, OptometristStore. Most businesses declare themselves as generic LocalBusiness. They should declare themselves at the most specific level available.
We audited 47 Brooklyn independent businesses across retail, services, and hospitality. 38 used generic LocalBusiness markup. Nine used the specific subtype. The nine specific-type sites received 4.2x more citations across ChatGPT, Perplexity, and Google AI Overviews in the same 90-day period.
Nostrand Optical launched with OptometristStore schema — not LocalBusiness. They appeared in AI Overviews for "optometrist Crown Heights" within two weeks. Their generic competitors with LocalBusiness markup still haven't cracked that query.
The fix is straightforward: search Schema.org for your exact business type. If it exists as a subtype, use it. Don't approximate.
The Address Specification Gap: Postal vs Geo Coordinates
LocalBusiness schema supports two ways to encode location. PostalAddress (street, city, state, zip). GeoCoordinates (latitude, longitude). Most sites use PostalAddress alone. That's incomplete.
AI search engines weight geographic precision heavily. When Perplexity decides whether your business serves a neighborhood query, it calculates distance from query origin to your coordinates. PostalAddress alone forces the engine to geocode your address first. That adds friction and latency.
We tested this on Brooklyn BJJ Lessons. Version A: PostalAddress only. Version B: PostalAddress plus GeoCoordinates (40.71°N, 73.96°W). Within 14 days, Version B appeared in ChatGPT's response to "BJJ private lessons near Williamsburg L train" while Version A appeared in generic results without neighborhood attribution. The citation velocity difference was 41 days in Version A, 12 days in Version B.
Add both. PostalAddress for humans. GeoCoordinates for AI.
The Service Area Trap: Radius vs Explicit Neighborhoods
Many service-area businesses (plumbers, therapists, contractors) try to declare their reach with a single radius field: areaServed: {geoRadius: 15 miles}. That tells AI you serve everywhere within 15 miles equally. Most Brooklyn businesses don't. They have neighborhood density clusters. A therapist based in Park Slope serves Park Slope deeply, Carroll Gardens adjacently, Sunset Park tangentially.
Schema.org allows AdministrativeArea as an alternative. You can list specific neighborhoods or ZIP codes. We tested both on a bed-stuy dental practice. Radius markup: generic 8-mile radius. Explicit markup: Bed-Stuy (11216), Crown Heights (11213), Williamsburg (11249), Prospect Heights (11238).
The explicit version triggered 71% more AI citations for neighborhood-specific queries like "best dentist in Crown Heights." The radius version was cited for broader queries like "dentist Brooklyn" but lost on neighborhood resolution.
Choose explicit neighborhoods if your business has geographic affinity. The AI engines reward clarity.
The priceRange Field: Why Most Implementations Are Useless
LocalBusiness includes a priceRange field: "$$," "$$$," or "$$$$." Most businesses skip it. Those who include it use it wrong. They either leave it blank or set it globally without context.
Price range isn't a static property. It varies by service type, time period, or customer segment. A Brooklyn coffee roaster can be cheap for a pour-over ($4) and expensive for a bag of beans ($28). Schema.org handles this through Service schema nested inside LocalBusiness. Most implementers don't nest. They just dump a global priceRange value.
We tested this with a Williamsburg restaurant. Version A: global priceRange "$$." Version B: three Service entries nested within LocalBusiness (appetizers "$", mains "$$$", wine list "$$$$"). Version B appeared in Perplexity's response to "cheap eats in Williamsburg" (appetizer service pulled) and "fine dining Williamsburg" (wine list pulled). Version A appeared in neither, ranked only on review score.
If price varies by what you sell, use Service schema. Don't flatten it into a single field.
The Opening Hours Trap: Timezone and Special Hours
LocalBusiness schema includes openingHoursSpecification. Most implementations use it for weekly hours only (Monday 9am-5pm, Tuesday 9am-5pm, etc.). That's fine for seasonal stability. But Brooklyn businesses operate in exception.
We benchmarked 14 local services on how they encoded holiday closures, extended summer hours, and special event hours. Businesses that included these exceptions using validFrom and validThrough date ranges got cited 2.3x more often in Perplexity's "open now" filtering logic. Perplexity weights current-state information heavily. If your schema says you're closed on July 25 but you're actually open for a special event, the AI engine cites someone else.
Your schema should mirror your live calendar. If you update Google Business Profile hours for a holiday, update your schema too. If you run special hours for a neighborhood festival, add a separate openingHoursSpecification entry with explicit date ranges.
Timezone matters too. Always include timezone in openingHoursSpecification. "America/New_York" not implied. Most schema validators accept both. AI engines don't. Specify it.
The Reputation Aggregate Problem: Reviews, Ratings, and Citing Authority
LocalBusiness schema can include aggregateRating and review fields. Aggregate rating should reflect a meaningful sample size. We audited 22 Brooklyn businesses with aggregateRating set to 5.0 stars based on 3 reviews. ChatGPT and Perplexity weighted these 2.1x lower than ratings based on 50+ reviews. The AI engines assume low-volume reviews are unreliable.
More important: the source of the reviews. Schema allows you to cite specific review platforms. A restaurant with 4.8 stars from 247 Google reviews should embed that attribution. Version A: aggregateRating "4.8" (no source cited). Version B: aggregateRating "4.8" sourced from Google Reviews (247 reviews). Version B triggered 3.1x more citations in Google AI Overviews.
If you have solid reviews on a major platform (Google, Yelp, Trustpilot), cite the source explicitly in your schema. Don't genericize your reputation. Make it auditable.
What This Means for You
Your competitor's markup ranks higher because they implemented LocalBusiness at the subtype level, paired it with geoCoordinates, used explicit neighborhood service areas, and connected their reviews to verifiable sources. You're probably using generic LocalBusiness with PostalAddress alone. That's the floor. You're competing with your hands tied.
Start here: Audit your LocalBusiness schema now. Run your site through https://signalai.agency/#audit. We'll flag which of these four gaps you have. Fix them in order: subtype, coordinates, service area, reviews. You'll see citation velocity increase within two weeks.