LocalBusiness Schema for Multiple Locations: How I Implemented It Using GTM

TL;DR:
Implementing LocalBusiness schema across dozens of physical locations can become difficult to maintain manually. For Mole Valley Farmers, I used Google Tag Manager to identify which of 50+ store pages was being viewed, retrieve the corresponding location data and dynamically populate a single LocalBusiness schema template. This case study explains how I built the setup and scaled location-specific structured data across the entire store network.

Why I needed a scalable LocalBusiness schema setup

Implementing LocalBusiness schema for one location is relatively straightforward. Doing it across 50+ stores, each with its own address, telephone number, opening hours, coordinates and location page, is a different problem.

This was the situation I had with Mole Valley Farmers, a national retailer with more than 50 physical stores.

Rather than manually creating and maintaining separate LocalBusiness schema for every store, I used Google Tag Manager to identify the location being viewed, retrieve the appropriate store information and dynamically populate the LocalBusiness schema for that location.

This case study explains how I did it.

If you’re looking for the basic implementation rather than a multi-location setup, I’ve covered that separately in how to implement LocalBusiness schema using Google Tag Manager.

The Multi-Location LocalBusiness Schema Problem

Following a website migration and relaunch, I worked with Mole Valley Farmers to improve organic visibility and drive more relevant traffic to the site.

The work covered a range of technical and on-page improvements, including site speed, Core Web Vitals, category page optimisation and dynamic product page optimisation.

Alongside its ecommerce website, Mole Valley Farmers had more than 50 physical country stores across the UK, each with its own store page and Google Business Profile.

That created a sizeable local SEO opportunity, particularly for location-specific and “near me” searches, but also a scalability problem.

Optimising and maintaining more than 50 individual store pages, Google Business Profiles and sets of LocalBusiness structured data manually would be extremely time-consuming.

The challenge was therefore to find a way to manage the location data centrally and use it to dynamically generate the correct LocalBusiness schema for each individual store.

That’s where Google Tag Manager came in.

Managing Google Business Profiles Across Multiple Locations

Before getting into the schema implementation, there was also the wider challenge of managing Google Business Profiles across more than 50 locations.

Fortunately, Mole Valley Farmers was already using Uberall, which allowed store information to be managed in bulk and exported rather than having to work through every profile individually. More importantly for this implementation, it gave us a structured source of location data that we could work with.

For each Google Business Profile, I also made sure the core business information was accurate and consistent with the corresponding store page.

The website URLs used within the profiles included UTM parameters:

?utm_source=googlemaps&utm_medium=organic

For example:

https://www.moleonline.com/storelocator/index/store/0/alnwick/?utm_source=googlemaps&utm_medium=organic

This meant traffic arriving through the website link on a Google Business Profile could be identified separately in analytics.

I’ve covered that process in more detail in my guide to tracking Google Business Profile traffic.

The important part for this case study was that we now had a central source containing the information for all 50+ locations. The next step was turning that into a dataset we could use for the LocalBusiness schema implementation.

Step 1: Create a Master Dataset for Every Business Location

Once the store data had been exported, the next step was to bring everything together into a single spreadsheet.

This became the master dataset for the implementation, with one row for each location and columns containing the information needed for both the individual store and its LocalBusiness schema.

For each location, I included:

• Store ID / location name
• Website URL
• Google Maps listing URL
• Business name
• Street address
• City
• County
• Postcode
• Country
• Telephone number
• Email address
• Latitude
• Longitude
• Opening and closing times for each day

Opening hours were split into separate opening and closing columns for each day. This was important because those values would eventually be used to populate the OpeningHoursSpecification within the schema.

The finished spreadsheet looked something like this:

At this point we had all the location-specific information in one place. The next problem was telling Google Tag Manager which location’s data it needed to use on each store page.

That meant finding a reliable way to identify the store being viewed.

Step 2: Identify Which Location Page the User Is Viewing

With the store data ready, Google Tag Manager needed a way to identify which location page was being viewed so it could retrieve the correct information.

In this case, every store page included the location name within the H1, so I used that as the identifier.

Using the browser’s inspector, I first identified the CSS selector for the H1 containing the store name.

I then created a Google Tag Manager variable called H1 Store Name, using the DOM Element variable type and CSS Selector as the selection method.

When visiting an individual store page, I could then use Tag Assistant to confirm that the variable was returning the correct location name.

So, if somebody was viewing the Alnwick store page, the H1 Store Name variable returned Alnwick.

That gave me the value I needed to connect the page being viewed with the corresponding row of location data.

The next step was getting that data into Google Tag Manager.

Step 3: Import the Location Data Into Google Tag Manager

With Google Tag Manager now able to identify the location, the next step was to connect that location name with the corresponding store data.

For this, I used Lookup Table variables.

In simple terms, a Lookup Table takes an input and returns a corresponding output. In this case, the input was the H1 Store Name variable created in the previous step.

For each property in the master spreadsheet, I created a Lookup Table that associated the store name with the appropriate value.

For example, the website URL Lookup Table looked something like this:

The input variable was:

{{H1 Store Name}}

So, when Alnwick was returned by the H1 variable, {{Store - URL}} returned the website URL associated with the Alnwick store.

The same principle could then be used for the address, postcode, telephone number, latitude, longitude, opening hours and every other location-specific value needed for the schema.

Creating Lookup Tables for 50+ stores across 28 different properties would, however, be a real pain in the arse if you had to build them all manually.

Fortunately, you don’t.

If you don’t know already Simo Ahava is the Godfather of all things tag manager, so it should come as no surprise that he’s come up with a relatively quick and easy way to create large look up tables.

Follow this link to find out how to do it

When you’ve got to grips with that, you will find yourself using Google Sheets as follows to create and populate your tables:

Once that process had been repeated for each required property, I effectively had the location dataset available within Google Tag Manager.

Visiting a store page would populate the variables with the values associated with that location:

At this point, Google Tag Manager knew which store was being viewed and had access to all the data associated with that store.

The next step was to use those variables to dynamically populate a single LocalBusiness schema template.

Step 4: Create the LocalBusiness Schema Template

With all the location-specific information now available as Google Tag Manager variables, I could use those variables to create a single LocalBusiness schema template.

Rather than creating different schema for every store, the same template could be used across all 50+ locations. The values within it would change dynamically depending on the store being viewed.

For example:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "{{Store - Name}}",
  "url": "{{Store - URL}}",
  "logo": "https://moleonline.com/media/wysiwyg/mole_valley_logo.png",
  "image": "https://lh5.googleusercontent.com/p/AF1QipNg3sC47D2PVbLuFqJysbvyG5P21U2ccR2SiShT=w426-h240-k-no",
  "hasMap": "{{Store - hasMap}}",
  "telephone": "{{Store - Telephone}}",
  "email": "{{Store - Email}}",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "{{Store - Street Address}}",
    "addressLocality": "{{Store - Locality}}",
    "addressRegion": "{{Store - Region}}",
    "postalCode": "{{Store - Postcode}}",
    "addressCountry": "UK"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": "{{Store - Latitude}}",
    "longitude": "{{Store - Longitude}}"
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday"],
      "opens": "{{Store - Mon Open}}",
      "closes": "{{Store - Mon Close}}"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Tuesday"],
      "opens": "{{Store - Tue Open}}",
      "closes": "{{Store - Tue Close}}"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Wednesday"],
      "opens": "{{Store - Wed Open}}",
      "closes": "{{Store - Wed Close}}"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Thursday"],
      "opens": "{{Store - Thu Open}}",
      "closes": "{{Store - Thu Close}}"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Friday"],
      "opens": "{{Store - Fri Open}}",
      "closes": "{{Store - Fri Close}}"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Saturday"],
      "opens": "{{Store - Sat Open}}",
      "closes": "{{Store - Sat Close}}"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Sunday"],
      "opens": "{{Store - Sun Open}}",
      "closes": "{{Store - Sun Close}}"
    }
  ],
  "sameAs": [
    "https://www.facebook.com/molevalleyfarmers/",
    "https://twitter.com/molevalley",
    "https://www.youtube.com/channel/UCMiUx9-x5oTJ2FlTpO_iB6Q"
  ]
}
</script>

The important part here is that properties such as the business name, URL, telephone number, address, coordinates and opening hours aren’t hard-coded. They use the Lookup Table variables created in the previous step.

Step 5: Add the Correct Schema to Each Location Page

With the schema template created, the final step was to make sure it only fired on the relevant store pages.

I added the schema as a Custom HTML tag in Google Tag Manager and created a trigger covering the store page section of the website.

There were a few ways I could have handled the trigger. For example, I could have checked whether the H1 Store Name variable contained a valid value.

In this case, though, all the store pages followed the same URL structure, so I simply used the URL path to determine when the tag should fire.

When the trigger conditions were met, the tag fired and the schema template was added to the page. Because the Lookup Table variables had already been populated using the store name, the resulting LocalBusiness schema contained the information for that specific location.

The final step was to validate the output and make sure the expected values were appearing correctly.

I used the Schema.org Markup Validator to check the generated structured data and confirm that the LocalBusiness schema was being output correctly.

At this point, the complete process was working:

store page → identify location → retrieve location data → populate schema template → output location-specific LocalBusiness schema

The same GTM tag could therefore handle the LocalBusiness schema across all 50+ store pages without creating and maintaining a separate tag for each location.

How Do You Structure LocalBusiness Schema for Multiple Locations?

For a business with multiple physical locations, each location should have structured data that describes that specific store rather than using the same LocalBusiness information across every location page.

That means the schema for each location can contain its own:

• Business or store name
• Location page URL
• Address
• Telephone number
• Latitude and longitude
• Opening hours
• Other location-specific information

That’s effectively what the implementation above achieves.

I only created one LocalBusiness schema template, but the values used within that template changed depending on which store page was being viewed.

So, when somebody visited the Alnwick store page, Google Tag Manager populated the template with the Alnwick address, telephone number, coordinates and opening hours. Visit another location and the same template was populated with the data for that store.

The important distinction is between reusing the schema template and reusing the location data.

The template can be reused across every location. The LocalBusiness structured data it generates should still describe the individual location represented by that page.

For Mole Valley Farmers, that meant one scalable implementation could generate location-specific LocalBusiness schema across more than 50 store pages.

What Happened After Implementation?

After putting all of this in place, the next question was whether we could see any improvement in organic visibility and traffic to the individual store pages.

And we could.

The Search Console data showed a significant increase in impressions and clicks to the store pages following the wider local SEO implementation.

See if you can spot when the work was carried out:

Comparing the periods before and after implementation showed a clear increase in visibility and clicks:

We also saw an improvement in click-through rate for relevant “near me” searches:

I can’t share the underlying Google Analytics or commercial data, but organic traffic, transactions, conversion rate and revenue associated with the store pages also increased.

It’s important not to attribute all of that improvement to LocalBusiness schema alone. This was part of wider local SEO work that included optimisation of the individual store pages and Google Business Profiles.

What this particular implementation gave us was a scalable way to provide structured, location-specific business information across more than 50 store pages without having to manage the schema for every location individually.

In Summary

If you manage a business with multiple physical locations, creating and maintaining separate LocalBusiness schema manually for every store can quickly become difficult to manage.

The approach I used here allowed me to:

• Maintain the location information in a central dataset
• Identify the store being viewed automatically
• Pull the relevant location data into Google Tag Manager
• Populate a single LocalBusiness schema template
• Output location-specific structured data across more than 50 store pages

The same principle can be applied to other multi-location businesses where each branch, store or office has its own location page and business information.

The key is that the implementation is shared, but the LocalBusiness data generated for each location is unique to that location.

For Mole Valley Farmers, it meant we could manage the implementation at scale rather than creating and maintaining 50+ separate versions of essentially the same schema.

This all led to a happy client:

LocalBusiness Schema for Multiple Locations FAQs

Should each business location have its own LocalBusiness schema?

Each location page should contain structured data that describes the specific business location represented on that page.

That means details such as the address, telephone number, coordinates and opening hours should relate to that individual store rather than simply repeating the same business information across every location page.

Can I use the same LocalBusiness schema template for multiple locations?

Yes. That’s exactly what I did in this implementation.

The same template can be reused, provided the location-specific properties are dynamically populated with the correct information for each location.

This makes it possible to manage LocalBusiness schema across tens or even hundreds of locations without maintaining a separate template for every store.

Can I add LocalBusiness schema for multiple locations using Google Tag Manager?

Yes. Google Tag Manager can be used to identify the location page being viewed and populate a schema template with the corresponding business information.

In this case, I used the store name from the H1 as the identifier and Lookup Table variables to retrieve the relevant data.

Do I need a separate page for every business location?

If individual locations have genuinely useful information for customers, dedicated location pages provide somewhere to publish details such as the address, contact information, opening hours, directions and services available at that location.

They also give you a logical page on which to include structured data describing that particular location.

How do I manage LocalBusiness schema for lots of locations?

The key is to avoid maintaining every location manually.

For this implementation, I kept the location information in a central dataset, used Google Tag Manager to associate each page with the appropriate data and then populated a single LocalBusiness schema template dynamically.

That meant the same implementation could be scaled across more than 50 locations while still generating structured data specific to each store.

---