Custom website development: a dozen store locations on the site—is a third-party embedded map enough? Ops says yes, the boss wants city filtering. Who's right?

For a website that needs to list a dozen store locations, the common 2026 approach is a lightweight one: embed a third-party map directly rather than build your own map system. The reason is that before visiting a store, visitors usually do only two things: confirm the store location and tap to navigate to a mobile map app. As long as the number of locations is within about a dozen and addresses are relatively stable, an embedded map plus a set of address cards is usually enough. Only when there are many locations, city filtering is required, or a later integration with a store system is needed does a heavier solution become worth considering. In practice, map module delays are often not because the map itself is hard, but because address coordinates, business hours, phone numbers, and mobile app handoff are not aligned.

What do visitors really need before going to a store?

Many clients assume a map on the website is for looks. In reality, before visiting a store, visitors mainly do three things: confirm which location is closest to them, check business hours and phone number, and tap navigation to jump to a map app. If the map is just a static image with no clickable navigation, the visit step is broken.

So to judge whether a solution is good, don't look at how much space the map takes up. Look at whether these three things form a closed loop.

• Find the nearest location by city or area;
• Copy the address, phone number, and business hours, and tap to call;
• Tap navigation to open a map app on mobile, rather than only showing an image.

Why a store map is often part of the conversion path, not decoration

For chains, dealers, and service locations, a website map is often one of the entry points for store visit conversion. In 2026, mobile traffic share is usually not low across many corporate websites. If the map module loads slowly or navigation handoff fails, the loss is store visit opportunities.

Another reality is maintenance cost. Stores open and close, relocate, and adjust business hours. If addresses are hand-written across pages, one change later means editing many places—similar to maintaining product prices in multiple locations.

• Store data should have a single source: maintain once, use in many places;
• Store information changes should be editable in the admin, not scattered across multiple pages;
• Coordinates should be saved together with address, phone, and business hours, rather than storing only a text address.

To decide between third-party embedding and a heavier solution, look at three things first

We break the decision into three steps: scenario first, then visitors, then maintenance capability. If any one of the three is unclear, rework is likely later.

First, the number of locations and how often they change

The number of locations directly determines the solution shape. If the number is small and changes are slow, the key is not to overbuild a simple thing. If the number is large and changes are frequent, the focus shifts to the admin and filtering.

• 1 to 5 locations with rare changes: a static map plus address cards and navigation links is usually enough;
• 6 to 30 locations: embedding a third-party map with list filtering is common;
• More than 30 locations or province/city sub-sites: consider map aggregation, back-end store management, and even integration with the store system.

Second, where most visitors are

If mobile dominates, navigation handoff, one-tap calling, and address copying take priority over map visuals. If desktop dominates, a zoomable map that shows nearby traffic is more important. The trade-offs differ; don't force the same layout on both.

Third, who can maintain it

If the operations person has no technical background, the admin should allow direct edits to addresses and coordinates. If every store change requires a developer to edit code and schedule a release, you save on admin development in the short term but pay with maintenance waiting in the long term.

Comparison of three common approaches

The three below are common choices in 2026 projects. They are not mutually exclusive and can be combined. Time and cost are experience ranges and vary with the number of locations and the completeness of materials.

1. Third-party map embedding: Call the web API of Baidu Maps or Amap (Gaode Maps) open platform for store markers and navigation handoff. Launch typically takes 1 to 3 days, with relatively low maintenance cost. Pay attention to API keys, quotas, mobile handoff compatibility, and script loading performance. Suitable for most corporate websites.
2. Static map plus address cards and navigation links: Use a static image or store photo with copyable addresses and navigation links. Launch typically takes half a day to 1 day. Lightweight, suitable when there are few locations and no map interaction is needed. Downside: the surrounding area isn't visible, and coordinates changes require replacing the image.
3. Build your own map module or connect to your own data: Store store data in the back end, and the front end filters by city and renders the map. Development typically takes 1 to 3 weeks or longer. Suitable when there are many locations, filtering is needed, or later integration with a store system is required. The cost is higher maintenance and higher map service usage; a website with modest traffic usually doesn't need to go this far.

Before choosing, ask one question: do visitors truly need to find a store by distance, or do they just need a store address they can navigate to? That answer usually determines cost more than comparing feature lists.

Delivery scene: the rework when one store move required edits in many places

One type of project has a very typical set of constraints: the client has more than twenty stores, only one operations person, stores relocate as malls adjust, and originally addresses were hand-written across multiple pages. Our approach was not to build a custom map directly. Instead, we created a separate table for store data, made address, phone, and business hours editable in the admin, shipped address cards and city filtering on the front end first, and lazy-loaded the map through a third-party API. As a result, the operations person usually updates one store in a few minutes. The trade-off was that the first version didn't include distance sorting or store system integration. If later sorting by visitor location is needed, additional development is required, typically 1 to 3 weeks as an experience range. In typical ranges, centralized store data maintenance often affects later cost more than the map visuals themselves.

Common pitfalls and acceptance criteria

Most delivery pitfalls are not in the map API itself but in misaligned content and details. The following come up repeatedly in projects; check them one by one before acceptance.

• Coordinate offset: If the coordinate system used when converting addresses to coordinates is inconsistent, map markers may land on the next street. Pick coordinates by actual clicking and confirm the front end and back end use the same coordinate system.
• Keys and quotas: Map API keys should be separated for test and production environments, with domain whitelisting. Otherwise, errors may occur after launch, or the map may fail to display due to exceeding the quota.
• Mobile handoff failure: Some in-app browsers cannot directly open a map app. Provide a fallback entry to copy the address or open the web version of the map.
• Map slows down the first screen: Map scripts are not small. Lazy-load them: show address cards first, and load the map when the page scrolls to the map position.
• Address without business hours: Visitors arriving to a closed store is a source of bad reviews. Verify phone and business hours for each store before delivery.

Acceptance criteria can be written like this: store addresses, phone numbers, and business hours match the admin; tapping navigation on mobile opens a map app or web map; map loading does not block first-screen text; key whitelisting works. If these are done, it is basically qualified.

Where it fits and where it doesn't

Fits: chains, dealer outlets, after-sales service points, multiple office addresses in the same city, and websites where visitors need to find the nearest store by location.

Doesn't fit or isn't urgent: only 1 to 2 addresses that rarely change—a text address plus navigation link is enough; visitors almost never come from mobile and are not coming to a store; store information changes often but no one on operations maintains it—putting up a map may instead leave old addresses displayed long term.

The value of a map module depends on whether visitors have store visit intent. For a website that closes deals purely online, putting budget into product pages and inquiry paths usually brings more direct returns.

Frequently asked questions

For a website map, should I use Baidu or Amap?

It depends on visitor devices and region. Most users in mainland China can use either. In delivery, a common approach is to choose one as the primary option, avoiding two map scripts on the same page that slow loading.

Can the map show real-time store open/closed status?

Third-party maps usually do not guarantee syncing real-time store status to you. A common approach is to maintain business hours as text in the admin and update manually on holidays, rather than making it a real-time status.

Does embedding a map cost extra?

Common third-party map open platforms have free quotas and charge by usage beyond that. As an experience range, a small website's annual usage usually falls within the free quota; projects with high usage should check quotas and commercial terms in advance.

If a store closes, how do I remove it from the map?

First delete the store data in the admin and the site marker, then sync the merchant information on the third-party map platform. If you only update the website and not the platform listing, visitors may still see the old store in search.

Does the map help with search indexing?

The map itself has limited impact on indexing, but store pages with address, phone, and business hours are content that can be used by local search. A common approach is to give each store its own page rather than cramming all of them onto one map.

If a website has more than 3 stores and visitors are mostly on mobile, start with a lightweight version: address cards plus a lazy-loaded third-party map. After launch, look at navigation clicks and store visit inquiries, then decide whether to add filtering and an admin. Following enterprise project delivery habits, Xiyue Company usually creates a separate table for store data and makes it editable in the admin when building multi-location websites, avoiding site-wide code hunts during later relocations. If stores rarely change and visitors are not coming to a store, this part can be postponed.