LocalBusiness JSON-LD for Dallas Multi-Location Brands

What Schema.org LocalBusiness Actually Does

Schema.org is a vocabulary of types that describe entities on the web. LocalBusiness is the type for physical businesses with a location clients can visit. When you mark up a page with LocalBusiness JSON-LD, you’re telling Google:

• This page represents a real business at a specific physical address.
• Here are the verifiable facts: name, phone, hours, geo-coordinates.
• Here’s the relationship to a parent brand (if any).
• Here are the services offered and the geographic area served.

Google uses supported structured data to understand details such as opening hours and departments. Eligibility for a rich result depends on the page and the search. The markup itself carries no guaranteed placement. Read Google’s LocalBusiness documentation.

Map the details from a real Dallas office

Aurum Title publishes one Dallas office with a suite number and a main phone. Begin with those details and match the visible page when filling in the JSON-LD.

Before adding opening hours or coordinates, verify them with the office and add the relevant information to the page. Keep the same suite number and primary phone everywhere customers use them.

Which LocalBusiness fields does Google require?

Google lists name and address as required properties for LocalBusiness rich result eligibility. Use the most specific business subtype that applies. Add other supported properties when the details are accurate and relevant.

Keep the node’s @id stable and distinct for each location. Schema.org properties such as parentOrganization can describe the brand relationship. For review markup, follow Google’s review snippet rules.

A Complete Single-Location JSON-LD Example

This fictional Plano dentist example shows the shape of a single location. Put the JSON-LD on a page with the relevant public business details, then substitute your verified values.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "@id": "https://example.com/#business",
  "name": "Plano Family Dental",
  "image": "https://example.com/storefront.jpg",
  "url": "https://example.com",
  "telephone": "+19725550100",
  "priceRange": "$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "1234 Park Blvd",
    "addressLocality": "Plano",
    "addressRegion": "TX",
    "postalCode": "75093",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 33.01984,
    "longitude": -96.69892
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "08:00:00",
      "closes": "17:00:00"
    }
  ],
  "sameAs": [
    "https://www.facebook.com/planofamilydental",
    "https://www.instagram.com/planofamilydental"
  ]
}
</script>

The @type deserves special attention. Choose the most specific subtype that applies to your business:

• Restaurant, Cafe, Bakery — food and beverage
• Dentist, MedicalClinic, Physician — healthcare
• AutoRepair, Plumber, Electrician — home services
• AttorneyLaw, AccountingService, FinancialService — professional services
• Store, ClothingStore, FurnitureStore — retail
• HealthClub, SportsActivityLocation — fitness
• Otherwise, default to LocalBusiness

Multi-Location Pattern 1: One Page Per Location (Recommended)

For brands with several customer-facing offices, a practical pattern is one dedicated URL per location, each with its own LocalBusiness schema. URL structure looks like:

example.com/locations/plano/
example.com/locations/frisco/
example.com/locations/mckinney/

Each location page contains a full LocalBusiness schema as shown above, PLUS a reference to a parent Organization. The parent Organization is declared once (on the homepage or an “about” page) and referenced from each location.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Smile Dental Group",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "sameAs": ["https://facebook.com/smiledentalgroup"]
}
</script>

On each location page, use its own business entity and link it back to the parent.

{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "@id": "https://example.com/locations/plano/#business",
  "name": "Smile Dental Group",
  "parentOrganization": { "@id": "https://example.com/#organization" },
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "1234 Example Street",
    "addressLocality": "Plano",
    "addressRegion": "TX",
    "postalCode": "75075",
    "addressCountry": "US"
  },
  "telephone": "+1-972-555-0100"
}

Multi-Location Pattern 2: Single Page with Array of Branches

If the site has a shared locations directory, it can list the offices and link to their pages. The schema below illustrates how subOrganization relates each branch to the parent brand. Use separate IDs and complete public address fields for the offices you describe.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Quick Wash Car Care",
  "url": "https://example.com",
  "subOrganization": [
    {
      "@type": "LocalBusiness",
      "@id": "https://example.com/locations/plano-park/#business",
      "name": "Quick Wash — Plano Park",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "100 Example Street",
        "addressLocality": "Plano",
        "addressRegion": "TX",
        "postalCode": "75075",
        "addressCountry": "US"
      },
      "telephone": "+19725550101"
    },
    {
      "@type": "LocalBusiness",
      "@id": "https://example.com/locations/frisco-main/#business",
      "name": "Quick Wash — Frisco Main",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "200 Example Street",
        "addressLocality": "Frisco",
        "addressRegion": "TX",
        "postalCode": "75034",
        "addressCountry": "US"
      },
      "telephone": "+19725550102"
    }
  ]
}

A dedicated page gives customers one place to find the office’s address, hours and services. A directory can help visitors find those pages.

Service-Area Businesses (Mobile Plumbers, Roofers, etc.)

If you serve clients at their location rather than yours (think: mobile car detailing, roof repair, locksmith), you’re a “service-area business” in Google’s terminology. Use areaServed instead of relying solely on address:

{
  "@type": "Plumber",
  "name": "DFW Emergency Plumbing",
  "telephone": "+19725550199",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Dallas",
    "addressRegion": "TX",
    "addressCountry": "US"
  },
  "areaServed": [
    {
      "@type": "City",
      "name": "Plano"
    },
    {
      "@type": "City",
      "name": "Frisco"
    },
    {
      "@type": "City",
      "name": "McKinney"
    }
  ]
}

Use areaServed to describe the service territory. Google lists a physical address for its LocalBusiness rich result feature. Businesses that visit customers should follow Google’s service-area guidance and keep private dispatch addresses private.

Six checks before publishing LocalBusiness markup

1. Match the name, physical address and phone to the location page.
2. Check that the primary phone includes a country code and reaches the right branch.
3. Use a business subtype that describes the actual location.
4. Keep each location’s @id distinct and consistent across pages.
5. Compare any coordinates and opening hours to verified office details.
6. Check review fields against Google’s policy, which excludes self-serving LocalBusiness reviews from review snippets.

Worked Example: Structuring a 14-Location Dental Group

Consider a 14-location dental group with offices across DFW. Its existing schema: a single LocalBusiness block on the homepage covering only the original Dallas location. The other 13 locations need their own verified details and entity IDs.

What to build:

• One Organization schema on the homepage (parent entity).
• 14 dedicated location pages (/locations/plano/, /locations/frisco/, etc.) following Pattern 1.
• Each location page: full LocalBusiness schema with Dentist subtype, complete NAP, geo coordinates, hours, parent reference, sameAs (links to per-location GBP profiles).
• Synchronized NAP across schema, GBP profiles, and on-page content for every location.
• Internal links from the main “Locations” index page to each location page using descriptive anchor text.

Special Case: Franchises with Independent Owners

Franchise businesses have a unique schema challenge: each location is independently owned and operated, but clients perceive them as a single brand. Use this pattern:

• Describe the actual local operator and publish the address, phone and hours customers use for that location.
• Use Organization to identify the corporate brand on its main site.
• Give each local operator a distinct identifier and describe its relationship to the brand accurately.

For deep franchise SEO strategy (which extends well beyond schema), see our service breakdown of franchise and multi-location SEO services.

The 3-Step Validation Workflow Before Every Deploy

1. Validate the vocabulary. Use the Schema Markup Validator to check the properties and types.
2. Check Google eligibility. Run the Rich Results Test and address errors before publishing.
3. Confirm the deployed page. Test the public URL and use URL Inspection in Search Console to check that Google can access the page and its markup.

When to Update Your LocalBusiness Schema

Schema is not “set and forget.” Update it whenever:

• Hours change (holidays, seasonal, permanent)
• You open or close a location
• NAP changes (phone, address)
• You add a new service worth marking up
• You start accepting new payment types
• Your reviews/ratings change visibly on the page

For multi-location brands changing addresses or consolidating locations, also implement proper 301 redirects from old location URLs to new ones. The 301 redirect playbook applies to location migrations too.

Frequently Asked Questions