How a dental group builds an office finder page

This guide is for a marketing lead at a dental group of about 3 to 50 or more offices. Some groups call the same page a location finder. The job is the same: a person, and a crawler, can reach every open office from one list. The samples use placeholder offices named Oak Park, Pine Hill, and Elm Street. Ask your own counsel about privacy rules for location data. For the other jobs a group website has to do, see marketing a multi-location practice or DSO.

The crawlable list

Google's page on crawlable links says that, generally, Google can only crawl your link if it is an <a> element with an href attribute. The same page puts an <a onclick> without an href, and a <span href>, in the not-recommended column. An a element that has both an href and an onclick is in the recommended column, because the href is still there. Anchor text is the visible text of the link. The office name is the anchor. "Click here" is not.

So the HTML the server sends already contains the full open list: office name, town, and a directions link. The map and the search box can hide rows after the page loads. They do not invent the links. JavaScript SEO basics says Google processes JavaScript web apps in three phases: crawling, rendering, and indexing. Parsing the HTML response works well when that response already contains the content. The same page says server-side rendering or pre-rendering is still worth doing because it makes the site faster for users and crawlers, and not all bots can run JavaScript. Our practice: the office list is in that first HTML.

Each office page also needs a plain link from somewhere a person already looks. The footer or the menu is the usual second path. If the group publishes a state or region page, that page links to the offices in that area. One path is enough for a person who already has the finder. More than one path is how a missed menu edit does not hide a door.

Sitemaps says a sitemap tells search engines which pages and files you think are important, and that if pages are properly linked, Google can usually discover most of a site. The same page says a sitemap can help on a larger or more complex site, and that a sitemap does not guarantee every URL in it will be crawled and indexed. Our practice: every office page is in the XML sitemap, and it is also an ordinary link on the finder. The sitemap is a list you submit. It is not a substitute for the href.

The map and long lists

The map is decoration on top of the list. A person who cannot use the map, or who does not want to, still reaches Oak Park from the link. Pins that are not links do not count as the office list.

Pause motion

Fixing lazy-loaded content describes infinite scroll as a technique that loads more content, more distinct pages, as a person scrolls. To keep that indexable, the page says to give each chunk its own persistent, unique URL, to keep the content at that URL the same each time it loads, to avoid relative values such as a date of "yesterday" in those URLs, and to link the URLs in sequence so they can be discovered. When a new chunk becomes the main thing on screen, the page says to update the displayed URL with the History API so a person can refresh, share, and link to it. The glossary has a short entry for office finder page.

Our practice: for up to a few hundred offices, one page with the full list grouped by state is simpler than paging. That count is our rule of thumb, not a limit from Google. If the group does split the list, each set gets the URL treatment above. A scroll that only appends cards, with no URL change and no links between sets, is the pattern to skip.

Use my location

The Geolocation API lets a person provide their location to a web page if they want to. For privacy reasons, the user is asked for permission to report location information. Calling navigator.geolocation is what causes the browser to ask. If the person accepts, the page can read the position. The API is available only in secure contexts. MDN describes a secure context as a window or worker that meets a defined standard of authentication and confidentiality, and it says many features are accessible only there. A top-level document is a secure context when its URL is potentially trustworthy. An https URL is in that set. An http URL on a public host is not.

Our practice, from those two facts:

• •Do not call the API when the page loads. The only call is from a button the person presses, with a visible name such as "Use my location."
• •Serve the finder over HTTPS. On plain HTTP the API is not available, and the button should not pretend that it is.
• •Always offer a ZIP or town box. If the person says no, or the device has no location, the list still shows.
• •Do not store the coordinates. Do not send them to an ad tool or an analytics tool.

The button is optional for the person. The list is not optional for the site. A finder that works only after a permission prompt is a finder that fails closed for anyone who says no.

Directions links

Maps URLs says you can build a cross-platform URL that launches Google Maps for a search, for directions, or for a map view, and that you do not need an API key for these URLs. The parameter api=1 is required. If it is missing, the other parameters are ignored and the default Maps app opens. Directions use https://www.google.com/maps/dir/?api=1 plus parameters. The destination is the endpoint. It can be a place name, an address, or comma-separated coordinates, and the string has to be URL-encoded. The document's own example turns a comma into %2C and uses a plus sign for a space. destination_place_id is optional. If you include it, you must also include a destination. A place id is a textual identifier for a place.

Use the same office name and the same address as the office page and the Business Profile. Who may edit that profile, and how the website field is set, is in Google Business Profile governance. The directions link does not replace the link to the office page. A person who wants hours, the phone, or booking still needs the office URL.

Origin can be omitted. The Maps URLs page says origin defaults to the most relevant starting point, such as the device location if one is available, and that without one the map may show a blank form. Leaving origin off means the finder is not putting the person's coordinates into your URL. That matches the rule above: the site does not keep the location.

Example Dental Oak Park | 100 Example Street | Oak Park | CA | 95820 | https://example.com/locations/oak-park | open
Example Dental Pine Hill | 200 Example Avenue | Pine Hill | CA | 95821 | https://example.com/locations/pine-hill | open
Example Dental Elm Street | | Elm Street | NV | 89501 | https://example.com/locations/Elm_Street | open
Example Dental Cedar Park | 400 Example Road | Cedar Park | NV | 89502 | https://example.com/locations/cedar-park | closed
Example Dental Birch Lane | 500 Example Way | Birch Lane | NV | 8950 | https://example.com/locations/birch-lane | open
Example Dental Maple Court | 600 Example Drive | Maple Court | CA | 95822 | http://example.com/locations/pine-hill | open

<label for="zip">ZIP code or town</label>
<input id="zip" name="zip" type="text" />
<button type="button">Use my location</button>
<p role="status">Showing 4 open offices, grouped by state.</p>

<h2>Offices</h2>
<h3>CA</h3>
<ul>
  <li>
    <a href="http://example.com/locations/pine-hill">Example Dental Maple Court</a>, Maple Court
    <a href="https://www.google.com/maps/dir/?api=1&amp;destination=Example+Dental+Maple+Court%2C+600+Example+Drive%2C+Maple+Court%2C+CA+95822">Directions</a>
  </li>
  <li>
    <a href="https://example.com/locations/oak-park">Example Dental Oak Park</a>, Oak Park
    <a href="https://www.google.com/maps/dir/?api=1&amp;destination=Example+Dental+Oak+Park%2C+100+Example+Street%2C+Oak+Park%2C+CA+95820">Directions</a>
  </li>
  <li>
    <a href="https://example.com/locations/pine-hill">Example Dental Pine Hill</a>, Pine Hill
    <a href="https://www.google.com/maps/dir/?api=1&amp;destination=Example+Dental+Pine+Hill%2C+200+Example+Avenue%2C+Pine+Hill%2C+CA+95821">Directions</a>
  </li>
</ul>
<h3>NV</h3>
<ul>
  <li>
    <a href="https://example.com/locations/Elm_Street">Example Dental Elm Street</a>, Elm Street
    <a href="https://www.google.com/maps/dir/?api=1&amp;destination=Example+Dental+Elm+Street%2C+Elm+Street%2C+NV+89501">Directions</a>
  </li>
</ul>

Search results and labels

When a ZIP or town search updates the list, tell the person how many offices matched. WCAG 2.2 success criterion 4.1.3, Status Messages, says that in markup, status messages can be programmatically determined through role or properties so assistive technologies can present them without the message receiving focus.

The understanding document defines a status message as information about the success or results of an action, a waiting state, the progress of a process, or an error, when that message is not delivered by a change of context. It also says the list of search results is not itself a status message, while a short text about the search, such as that results came back or that none came back, is a status message when it does not take focus. Our practice: put that sentence in an element with role="status", next to the list, and do not move keyboard focus to it. The glossary has a short definition of a status message.

Success criterion 3.3.2, Labels or Instructions, says labels or instructions are provided when content requires user input. The intent is that people know what to enter. A visible label does that for everyone. An accessible name that only assistive technology receives is a different criterion, and a placeholder that disappears is not the label. The ZIP or town box gets a visible label, such as "ZIP code or town." Filters are native controls a keyboard can reach and operate. Do not build the only filter as a control that works only with a pointer.

Our practice for order: the default list is grouped by state, then by town. Distance is a sort you apply after the person asks, by typing a ZIP or a town, or by using the location button. A finder that opens already sorted by a guessed distance has already asked for a location the person did not offer.

When the map library loads

The finder is often a high-traffic page. People tap the list, the search box, and the directions links before they ever open the map. Interaction to Next Paint is a Core Web Vital that assesses responsiveness. It observes the latency of click, tap, and keyboard interactions during a visit, and it reports a single value which all, or nearly all, of those interactions were beneath. A low value means the page was able to respond quickly. The page says the intent is to measure the time until the next paint is blocked, not every later effect of the interaction, such as a network fetch that finishes afterward.

Our practice: do not load the map library in the first response. Load it after the person asks for the map, or when the map area scrolls into view. The list, the labels, and the links are already in the HTML, so the first taps do not wait on that library.

Structured data

Local business structured data says that with this markup you can tell Google about business hours, different departments within a business, and more. The same page says to define each local business location as a LocalBusiness type, and to use the most specific LocalBusiness subtype possible. It also says you can add LocalBusiness structured data to any page, though it may make more sense on a page that contains information about your business. Address is a required property. Departments, on that page, are parts of one business that have their own hours or phone, marked with a department property. That is a different shape from a group of offices at different addresses.

Our practice: markup for an office goes on that office's page, and it describes that office. The finder lists offices and links to them. It does not mark up every door as one business, and it does not use the department pattern to stand in for separate offices. Do not claim that the markup produces a rich result or a ranking change. Swap in your own office details in the sample below.

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Example Dental Oak Park",
  "url": "https://example.com/locations/oak-park",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "100 Example Street",
    "addressLocality": "Oak Park",
    "addressRegion": "CA",
    "addressCountry": "US"
  }
}

URLs, closures, and doorway pages

URL structure recommends a simple structure that people can understand, and readable words rather than long ID numbers. The recommended column on that page is simple, descriptive words. Our practice: one stable URL per office, such as /locations/oak-park, used in the finder, in the menu, in the sitemap, and in the profile's website field. What else belongs on that office page is in location pages for a multi-office site.

A closed office does not stay in the open list. How a move edits the existing profile, how a merge marks the other profile Permanently closed, and how a closure points the old page at open offices, is in moving, merging, or closing an office. Take the name off the finder in the same pass. Leaving it up tells a person the door is still open.

If the finder filters by treatment, the filter reads the service-by-office sheet. An office marked no for that treatment does not appear in the filtered list. How that sheet feeds the treatment page, the office page, the profile, and the ads is in which office offers which treatment.

Spam policies describe doorway abuse as sites or pages created to rank for specific, similar search queries. They lead users to intermediate pages that are not as useful as the final destination. The examples include pages targeted at specific regions or cities that funnel users to one page, and substantially similar pages that sit closer to search results than a hierarchy a person can browse. So do not publish a near-copy "dentist near this town" page for a town where the group has no office. The finder and the real office pages are the pages. A town with no door does not get its own page.

Who owns which edit

Accounts stay with the group. A vendor can have a seat. The vendor is not the owner of record. Finder events belong with the same office slug the group already uses. How calls, forms, and bookings are recorded without patient details is in GA4 calls, forms, and bookings. Profile edits stay with the governance guide linked above.

Questions for an agency

Ask these in a proposal or a handoff. A scorecard for hiring is in how to choose a DSO dental marketing company.

Red flags

Watch for these in any office finder plan.

1. 1. Office links exist only inside a map or a JavaScript widget.

   Google's crawlable links page says Google can generally only crawl a link that is an a element with an href. A span with an href, or an a element that has only an onclick, is in the not-recommended list. The office pages need ordinary links in the HTML the server sends.

2. 2. The finder asks for location as soon as the page loads.

   The Geolocation API asks the person for permission, and it is available only in a secure context. A prompt on load is not a request the person chose. Call it from a button. Keep the ZIP or town box on the page.

3. 3. There is no ZIP or town box.

   If the person says no, or the browser has no location, the finder still has to work. A ZIP or town box is the fallback. The full list remains the default.

4. 4. The list grows as you scroll, and those sets have no URLs.

   Google's lazy-loading page says infinite scroll should give each chunk its own persistent URL, keep that content stable, and link the URLs so they can be discovered. A list with no URL per set does not do that.

5. 5. Office pages are missing from the XML sitemap.

   A sitemap tells search engines which URLs you think are important. It does not replace links, and it does not guarantee indexing. Our practice is both: a plain link on the finder, and the office URL in the sitemap.

6. 6. The name or address on the finder differs from the Business Profile.

   The directions destination and the visible address should be the same office name and the same address as the office page and the profile. A mismatch sends the person to a different door than the one the profile describes.

7. 7. The map library loads before anyone uses the page.

   Interaction to Next Paint assesses whether the page responds to clicks, taps, and keyboard input. Our practice is to load the map library after a request or when the map area scrolls into view, so the first taps on the list and the search box are not waiting on that library.

8. 8. A closed office is still in the open list.

   The finder is a list of open doors. A move, a merge, or a closure is handled in the office change guide, including the profile status and the old URL. Leaving the closed name on the finder tells people that door is still open.

Samples

The samples use three placeholder offices, Oak Park, Pine Hill, and Elm Street, on https://example.com, with a placeholder street. Replace every placeholder with your own office names, URLs, and addresses before you use the pattern.

<!-- Replace example.com and the office names with your own. -->

<label for="zip">ZIP code or town</label>
<input id="zip" name="zip" type="text" />
<button type="button">Use my location</button>
<p role="status">Showing every open office, grouped by state.</p>

<h2>Offices</h2>
<h3>Example State</h3>
<ul>
  <li>
    <a href="https://example.com/locations/oak-park">Oak Park</a>
    <a href="https://www.google.com/maps/dir/?api=1&destination=Example+Dental+Oak+Park">Directions</a>
  </li>
  <li>
    <a href="https://example.com/locations/pine-hill">Pine Hill</a>
    <a href="https://www.google.com/maps/dir/?api=1&destination=Example+Dental+Pine+Hill">Directions</a>
  </li>
  <li>
    <a href="https://example.com/locations/elm-street">Elm Street</a>
    <a href="https://www.google.com/maps/dir/?api=1&destination=Example+Dental+Elm+Street">Directions</a>
  </li>
</ul>

https://www.google.com/maps/dir/?api=1&destination=Example+Dental+Oak+Park%2C+100+Example+Street

A place id is optional. If you add one, keep destination in the same URL.
Replace PLACE_ID_HERE. It is not a real place id.

https://www.google.com/maps/dir/?api=1&destination=Example+Dental+Oak+Park&destination_place_id=PLACE_ID_HERE

Checklist

Twelve checks before you treat the finder as the path to every open office. Ticks stay in this browser only.

What DDS Web Solutions builds

DDS Web Solutions builds practice websites. Our team has been building websites since 2014, and we have served 100+ practices. Our offices are in Sacramento and San Mateo. Our products are Smyly, SmileTrak, and ToothRank. We build office finders with a plain link to every open office, a ZIP or town box, and directions links. We do not promise search results. For planning, see DSO and multi-location marketing. For a hiring scorecard, see how to choose a DSO dental marketing company.

Sources

• •Google Search Central: Links crawlable
• •Google Search Central: Understand JavaScript SEO basics
• •Google Search Central: Fix lazy-loaded content
• •Google Search Central: Learn about sitemaps
• •Google Search Central: URL structure
• •Google Search Central: Local business structured data
• •Google Search Central: Spam policies for Google web search
• •MDN: Geolocation API
• •MDN: Secure contexts
• •W3C: Understanding SC 4.1.3 Status Messages
• •W3C: Understanding SC 3.3.2 Labels or Instructions
• •Google Maps Platform: Maps URLs
• •web.dev: Interaction to Next Paint