Store locator on any website.

Schema.org LocalBusiness is the structured-data type that powers Google's Local Pack (the three-pack of map results above the blue links), the Knowledge Panel on the right rail, and the Place card in Google Maps. Without it, Google has to guess that your URL is the canonical web presence for a given branch; with it, you tell Google explicitly. The required properties are name, address (PostalAddress with streetAddress, addressLocality, addressRegion, postalCode, and addressCountry), geo (GeoCoordinates with latitude and longitude), telephone, and openingHoursSpecification. Optional but highly recommended: image, priceRange, paymentAccepted, currenciesAccepted, areaServed, and sameAs (linking to your Google Business Profile, Yelp, Facebook). Poper auto-emits a complete LocalBusiness JSON-LD block per location on every plan including Free. Pair the widget with claimed Google Business Profile listings for each branch and you become individually rankable in Google Local SERP for every city you operate in. Validate after embedding using Google's Rich Results Test; one detection per pin should appear.

Since Google's June 2018 pricing change, Google Maps Platform charges per Map Load: Dynamic Maps cost roughly $7 per 1,000 loads after the first 28,000 free per month, and the free tier requires a credit card on file. For high-traffic sites or multi-property brands, this can quickly translate to four-figure monthly bills. The two practical alternatives in 2026: Mapbox offers 50,000 free loads/month before pricing kicks in at $5 per 1,000 loads, with cleaner default styling and richer customization (Mapbox Studio lets you design custom map skins). OpenStreetMap is fully free and open-source, requires no API key or credit card, and renders via the Leaflet.js library; the trade-off is no Street View, no satellite imagery without a third-party tile provider, and OSM data quality varies by region (excellent in Europe and North America, patchier in parts of Asia and Africa). Poper supports all three providers in a single config flag, so you can prototype on OpenStreetMap, A/B-test against Mapbox, and graduate to Google Maps once you have proven ROI. Switching providers does not require re-importing locations or re-embedding the script.

Two technologies underpin ‘find my nearest store’: IP geolocation and HTML5 Geolocation. IP geolocation reads the visitor's IP address and looks it up in a database (MaxMind, IP2Location, ipapi); accuracy is city-level (typically within 25-50 km), no permission prompt is required, and it works on first paint. HTML5 Geolocation uses the browser's navigator.geolocation API and asks the visitor for explicit permission; on a phone with GPS the precision is street-level (within 5-10 m), but the prompt is a UX speed bump that 30-60% of visitors will deny depending on the page context and how it is asked. The right pattern: render IP-detected results immediately on page load (no friction), then offer a discreet ‘Use my exact location’ button that triggers HTML5 Geolocation only when the visitor opts in. Poper implements this two-stage pattern by default and stays GDPR-clean: IP geolocation is treated as a legitimate-interest data point with no cookie set, and HTML5 Geolocation only activates after explicit user gesture, which satisfies the consent requirement under GDPR Article 6.

Multi-location retailers, franchise networks, and large medical groups often need to manage thousands of branches with hours, contact info, services, and photos. Three import pathways matter: CSV (one-off bulk uploads, ideal for initial seed and occasional refreshes), Google Sheets sync (the locations source-of-truth lives in a Sheet that Poper polls every 15 minutes), and REST API (POS or ERP pushes location updates in real time). The page-performance trick at scale is data partitioning: rather than shipping all 10,000 locations to the browser on first paint, the widget renders the visible map viewport, then lazy-loads pin clusters as the user pans or zooms. Poper handles this transparently and clusters pins above 50 visible markers so the map remains scannable. For SEO, every individual location should also have a unique, indexable detail page (e.g. /stores/seattle-broadway/) with its own LocalBusiness JSON-LD; the locator widget links to these pages on click. Avoid the antipattern of cramming all 10,000 location names into the homepage HTML for ‘SEO’; Google rewards a clean information architecture, not keyword stuffing.

A store locator widget is one half of a multi-location SEO strategy. The other half is Google Business Profile (GBP), formerly Google My Business. For every physical branch you operate, you should claim and verify a GBP listing with the same name, address, and phone number (NAP) that appears in your locator's LocalBusiness JSON-LD. Consistency is non-negotiable: if your widget shows ‘123 Main St, Suite 4’ but your GBP listing shows ‘123 Main Street’, Google's entity-resolution may treat them as separate businesses and dilute your local authority signals. Best practice in 2026: maintain a single source of truth for location data (the same CSV or Sheet that feeds Poper also feeds your GBP API integration), generate a unique landing page per branch with embedded LocalBusiness schema, link back to the locator from each branch page (creates a hub-and-spoke internal-link pattern Google rewards), and link out to the corresponding GBP listing via the sameAs property in your JSON-LD. Brands that get this stack right typically capture 40-70% of mobile ‘near me’ queries in their categories within 6-9 months.