Geo Meta Tags Guide: geo.position and LocalBusiness for...

A contractor friend of mine asked why his business was showing up in Google's local pack but not in Apple Maps search, not in Siri's "plumbers near me" voice answer, and not in the local sections of Perplexity's results. His Google Business Profile was complete. His website mentioned the city and state on every page. From his side, the signals looked right.

The signals were not right for everything other than Google. His pages were missing the three specific location markers that non-Google retrievers need to localize a business: geo meta tags, LocalBusiness schema with coordinates, and Open Graph locality fields. Added the triplet, and within a few weeks the Apple and Perplexity visibility showed up.

Why Three Signals and Not One

Google is so dominant in local search that it is easy to assume a Google Business Profile is enough. For Google, it basically is. Google's Knowledge Graph links the profile to the website via phone number, domain, and manual claim — and Google builds everything else from there.

Apple Maps, Bing, DuckDuckGo, Kagi, Siri, Alexa, and the location-aware modes of Perplexity and Gemini do not have that luxury. They cannot all read the Google Business Profile directly, and even the ones that can supplement it with on-page signals to validate what they find. When these engines parse a local-business page, they look for three specific on-page markers:

geo meta tags (geo.position, geo.region, geo.placename): an old IETF-adjacent convention that every non-Google location-aware crawler respects.
LocalBusiness JSON-LD schema with geo: { latitude, longitude }: the schema.org way of declaring "this business is at this point."
Open Graph locality fields (og:locality, og:region, og:country-name): how social and chat platforms format location context.

Each one is independently parsed by a different subset of retrievers. Ship all three and every retriever that looks for location on your page finds it. Ship one and you cover a slice.

The Geo Meta Tags

These are the oldest of the three. They go in <head>:

<meta name="geo.position" content="42.5629;-114.4609">
<meta name="geo.region" content="US-ID">
<meta name="geo.placename" content="Twin Falls, Idaho">
<meta name="ICBM" content="42.5629, -114.4609">

A few details:

geo.position is semicolon-separated lat;lon with decimal degrees. No spaces. Positive values for north and east, negative for south and west.
geo.region uses ISO 3166-2 codes: US-XX for US states (US-CA, US-NY, US-ID), CA-XX for Canadian provinces, GB-XXX for UK, and so on.
geo.placename is human-readable city and state (or city and country for non-US).
ICBM is a historical duplicate of geo.position with comma-space separation. Some older crawlers look for it. Ship both — they are tiny.

Coordinate accuracy matters. For a physical storefront, use the actual building, not a rough city-center coordinate. Use Google Maps or Apple Maps to drop a pin on the exact entrance, copy the coordinates, paste them in. Four decimal places (11 meters of precision) is enough; six decimal places (11 cm) is overkill but harmless.

The LocalBusiness Schema

This is the JSON-LD block. Place it in <head> or just before </body>, inside a <script type="application/ld+json">:

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Example Plumbing",
  "image": "https://example.com/storefront.jpg",
  "url": "https://example.com/",
  "telephone": "+1-208-555-0123",
  "priceRange": "$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main Street",
    "addressLocality": "Twin Falls",
    "addressRegion": "ID",
    "postalCode": "83301",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 42.5629,
    "longitude": -114.4609
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "08:00",
      "closes": "17:00"
    }
  ]
}

Use the more specific schema type if one fits: Plumber, Restaurant, RealEstateAgent, AutoRepair, ProfessionalService. Schema.org has a long list of subtypes under LocalBusiness, and using the right one gives retrievers a more precise category.

The geo sub-object with latitude and longitude as decimal numbers is what most AI location engines specifically extract. The same coordinates that go in the geo meta tag go here. If you change one, change both.

The Open Graph Locality Fields

These are Facebook's Open Graph standards and are parsed by pretty much every social and AI platform that supports Open Graph at all:

<meta property="og:locality" content="Twin Falls">
<meta property="og:region" content="ID">
<meta property="og:country-name" content="USA">
<meta property="place:location:latitude" content="42.5629">
<meta property="place:location:longitude" content="-114.4609">

The place:location:latitude and place:location:longitude are Open Graph's extension for coordinates. Some platforms read them, some ignore them. Shipping them is free.

og:region uses the state code without the country prefix (ID, not US-ID). That differs from geo.region's ISO format. Yes, the inconsistency between formats is annoying. It is the world we live in. Both standards are widely enough used that you ship both.

When to Ship the Triplet

The rule I use: every page that describes a physical business with a physical location or service area. That includes:

Home pages of local businesses (restaurants, plumbers, real estate, retail).
Location-specific landing pages on multi-location businesses (/denver, /boise, /portland).
Event pages with a physical venue.
Property listings with a physical address.

Do not ship the triplet on:

Generic blog posts.
Company-wide pages that do not describe a single location.
Pages for online-only services with no physical presence. (Use ServiceArea schema for those instead of LocalBusiness with coordinates.)

Coordinate Accuracy and the Common Mistake

The single most common mistake I see: a business ships the triplet with coordinates that point to a random spot in the town's zip code centroid, not the actual business address. Apple Maps and Bing are rigorous about cross-checking coordinates against the postal address. If they do not match to within a reasonable tolerance (a few hundred meters for a street address), the signal is discounted or rejected.

Use the actual coordinates of the front door. If the business is in a strip mall, use the strip mall's door, not the center of the parking lot. If it is a home-based business and you do not want to publish the home address, you have a different problem: you need to decide whether to list the actual location with its privacy implications, use a virtual office address, or drop the geo signals entirely and accept the visibility hit.

Do not fake coordinates. Do not round them to city center. Do not copy them from a random address a block away. The cross-checks happen and they work.

Region Code Standards

For US sites, US-XX in geo.region and XX in og:region, both using the two-letter postal abbreviation. For Canadian sites, CA-XX (e.g., CA-ON for Ontario). For UK sites, GB-ENG, GB-SCT, GB-WLS, GB-NIR for the four nations.

addressRegion in the JSON-LD PostalAddress takes a slightly looser format: the two-letter state for the US (ID), the province abbreviation for Canada (ON), the full county name for the UK (Hertfordshire). Schema.org documents this per country, and the schema validators will flag wrong formats.

Where the Analyzer Checks

The audit at /tools/mega-analyzer/ checks for all three components on pages that declare themselves as LocalBusiness. Missing geo meta tags is a warn. Missing LocalBusiness schema with coordinates is a critical. Missing og:locality/og:region is a warn. The three checks run independently so you get per-signal granularity.

Coordinate consistency is also checked: if the geo meta lat/lon differs from the JSON-LD geo lat/lon by more than a small delta, the audit flags the mismatch. They should match to the decimal.

The Short Version

Three location signals, three locations: geo meta tags, LocalBusiness JSON-LD with geo coordinates, Open Graph locality.
Ship all three on every local-business page. Different retrievers read different subsets.
Use actual building coordinates with four to six decimal places of precision.
Region codes: US-XX for geo.region, XX for og:region, two-letter state for addressRegion in JSON-LD.
Coordinate accuracy is cross-checked. Do not fake or round to city center.
Skip on generic blog content and online-only services. Ship on anything with a physical location.

geo.position, LocalBusiness Schema, and og:locality: The Location Signal Triplet