Store locators and maps AI agents can use

"Is there a Northwind shop near me that's open on Sunday?" is the kind of question people ask AI assistants. Whether one can answer depends on your store locator. Here's how to turn a map that only works with JavaScript into locations agents can find, read and recommend: a list in the HTML, a page per location, and data that says where and when you're open.

What agents need from a locator

Location questions are short and practical, and an assistant needs specific facts to answer them:

• "Where's the nearest one?" needs every location's address, in text.
• "Is it open now?" or "Is it open on the 26th?" needs regular hours for each location, plus holiday hours.
• "Can I pick up my order there?" or "Do they do repairs?" needs the services each location offers.
• "What's their number?" needs each location's own phone number, not just head office.

A person can squint at a map and click a pin. An assistant such as ChatGPT, Claude or Perplexity, fetching your pages to answer the question, needs those facts written down. If they aren't, it will answer from somewhere else (a directory listing, a map service, an old review) or tell the person it couldn't find out.

What each location needs to say, in text

• Address Street, town, postcode
• Hours Regular and holiday
• Phone This location's own number
• Services Click and collect, repairs, parking

Map-only locators hide all of it. Many store locators are a single page with a map, a search box and nothing else in the HTML. When someone types a postcode, a script asks an API for nearby locations and draws pins and a results list. Before that, the page is empty.

That fails agents in two ways. Agents that read the HTML without running JavaScript see a search box and no locations at all. Browser agents can run the page, but then they have to find the search field, type a place, press search, read the results out of a map panel and click pins one by one to get the hours. Every step is a chance to get stuck, and none of it is needed if the locations are already written down.

Map-only locator

• Empty page until a postcode is entered
• Locations come from an API, drawn by script
• Hours only in a pin's pop-up
• No URL for any single location

Agent-friendly locator

• Every location listed in the HTML, grouped by area
• Address and hours as text in the list
• A link to each location's own page
• The map is extra, not the only way in

This is a JavaScript problem first. See why AI agents can't see your JavaScript-only content for how to check what's in your served HTML.

A crawlable list of locations

Start with a locations index: one page, in the server-sent HTML, that lists every location. For a handful of shops, put them all on one page. For hundreds, group them by region or city, with a page for each group, so no page becomes a wall of text.

Each entry should carry the name, the address and today's or this week's hours as text, and a real link to the location's own page. Use headings for regions and a list for the locations, so an agent can scan the structure.

<h2>Portland</h2>
<ul>
  <li>
    <a href="/stores/portland-pearl-district/">Northwind Coffee, Pearl District</a>
    <p>1200 NW Glisan St, Portland, OR 97209</p>
    <p>Mon to Fri 7am to 6pm, Sat and Sun 8am to 5pm</p>
  </li>
  …
</ul>

Link the locations index from your main navigation or footer, so agents can reach it from any page, and list the location pages in your XML sitemap.

One page per location

A page for each location gives agents a stable URL to read, quote and send people to. It's also the natural home for everything specific to that place:

• The full address, a phone number and an email address or contact form for that location.
• Opening hours as text, including upcoming holiday changes. Never only as an image.
• Services and facilities: click and collect, returns accepted, repairs, accessibility, parking, payment methods. If people can collect online orders there, say how; see delivery slots and click and collect for AI agents.
• A plain link for directions, alongside any embedded map.
• A breadcrumb back to the region and the locations index. See breadcrumbs and site structure.

Use readable URLs such as /stores/portland-pearl-district/. When a location closes, don't let its page vanish into an error: say it has closed and link to the nearest alternatives. See status codes, redirects and soft 404s.

northwind.example/stores/portland-pearl-district/

Northwind Coffee, Pearl District

1200 NW Glisan St, Portland, OR 97209 Address as text

Mon to Fri 7am to 6pm, Sat and Sun 8am to 5pm Hours as text

Click and collect, bean grinding, step-free access Services listed

Get directions A real link

LocalBusiness data for each location

Each location page should also describe itself as structured data. Schema.org defines LocalBusiness as "a particular physical business or branch of an organization", which is exactly what each shop is. Use LocalBusiness, or a more specific type such as Store, with the location's own name, address, phone, coordinates and opening hours, and point back to your company with parentOrganization.

{
  "@context": "https://schema.org",
  "@type": "Store",
  "name": "Northwind Coffee, Pearl District",
  "url": "https://northwind.example/stores/portland-pearl-district/",
  "telephone": "+1-503-555-0142",
  "address": { "@type": "PostalAddress", "streetAddress": "1200 NW Glisan St",
    "addressLocality": "Portland", "addressRegion": "OR",
    "postalCode": "97209", "addressCountry": "US" },
  "parentOrganization": { "@type": "Organization", "name": "Northwind Coffee",
    "url": "https://northwind.example/" }
}

Add openingHoursSpecification and geo as well. We cover the whole pattern, including holiday hours and how to keep the company's own Organization data on the home page, in business and store details AI agents can trust, so we won't repeat it here. Two points specific to locators:

• One block per location, on that location's page. Don't put hundreds of LocalBusiness entries on the locator page and none on the location pages.
• Generate it from the same location data as the page. When a shop changes its hours, the page, the list and the markup should all change together. Google's local business documentation also shows how to describe departments with their own hours, such as a pharmacy inside a store.

"Near me" search agents can use

A search box is still useful, especially for browser agents acting for someone who's given them a postcode. Make it one they can operate:

• Label the field. A visible <label> such as "Postcode or town", not only placeholder text that disappears as you type.
• Name the buttons. "Search" and "Use my location" in words, not a magnifying glass and a crosshair icon. An agent may not be able to share the person's location, so the typed search must work on its own.
• Give results a URL. A search for 97209 should land on something like /stores/?near=97209, so an agent can open it directly and share it. See site search and filters AI agents can use.
• Show results as a list with links, the same entries as the locations index, with the map beside them.

For field labels and button names in general, see buttons, links and forms agents can use.

What AgentScore can and can't tell you

AgentScore doesn't test store locators. It never opens your locator page, so a good score says nothing about whether agents can find your shops.

Two of its checks touch the same habits, but only on your home page. "Form fields are labelled" looks at the fields on the rendered home page, so it only sees a "find a store" box if one sits there. "Content loads without JavaScript" compares the text in your home page's HTML with what a browser shows after scripts run. Neither looks at the locator itself.

To see whether an agent can find your nearest shop and its hours, describe that journey in your own words as a Ghost Agent test in the app, and watch the replay.

Where to start

Store locator checklist

• Locations index in the HTML, linked from the footer or menu
• A page per location with its own URL
• Address, hours, phone and services as text on each page
• LocalBusiness or Store data on each location page
• Labeled search with named buttons and results at their own URL
• Hours only in a map pop-up or an image