Use one row per public location with a stable location ID, display name, physical address, reviewed coordinates, hours, contact details, category and active status. Keep internal notes separate and verify every new, moved or reopened location before publishing.
Treat the spreadsheet as a publishing database
| Field | Rule |
|---|---|
| Location ID | Permanent and never reused |
| Public name | Consistent brand and branch naming |
| Physical address | No internal directions or mailing-only address |
| Latitude / longitude | Reviewed numeric point |
| Status | Active, temporarily closed, planned or permanently closed |
| Hours and timezone | Structured for the destination platform |
| Phone and URL | Public, tested and location-specific where possible |
| Updated at | Date the record was last verified |
Geocode the customer-facing physical location
A corporate mailing address or finance office may not be where customers visit. Use the branch's actual physical address and check multi-tenant buildings, shopping centers, airports and campuses manually. Preserve the provider-formatted address in a review column rather than silently replacing approved public copy.
Run publishing QA beyond coordinate validity
- Every active record has a unique ID and public name.
- Coordinates fall in the expected country or market.
- The marker is near the customer entrance when that matters.
- Phone numbers and URLs work.
- Hours include timezone and holiday-handling rules.
- Internal notes and employee data are absent.
- Closed and future locations are handled intentionally.
Use change-based refreshes
Track address, status and coordinate review dates. Geocode only new or changed physical addresses. When a store moves, close the old record and create or update the new location under a documented identity rule; do not let a row silently change historical meaning.
Sources and methodology
Technical claims were checked against the sources below on August 18, 2026. Product limits and third-party pricing can change; verify the live documentation before designing a production workflow.
Common questions
What columns does a store locator need?
At minimum: stable ID, public name, physical address, latitude, longitude and active status. Most locators also need phone, hours, category, URL and accessibility or service attributes.
Can several stores share one address?
Yes, especially malls and campuses. Use unique IDs and confirm whether the provider returns a building point or a store-specific entrance.
Should closed locations remain in the file?
Keep them in the system of record with an inactive status and closure date, but normally exclude them from the public export.
How often should coordinates be refreshed?
Do not re-geocode unchanged stores automatically. Recheck new, moved or corrected locations and periodically audit a representative sample.