LocalBusiness schema has incomplete or invalid location data

This issue reports the location block of a LocalBusiness schema your page declares: the properties that place the business on a map and in the local pack — where it is, how to reach it, and when it is open.

A LocalBusiness — or any of its schema.org subtypes, such as Dentist, Hotel, Restaurant, Plumber, Attorney, ProfessionalService, Bakery or ClothingStore — is checked for:

• address.addressCountry — the country that decides which market Google places the business in, and the property a hand-written PostalAddress most often omits
• geo — a GeoCoordinates node with a latitude and longitude that are numbers in decimal degrees and inside the range the earth has
• telephone — a value that contains an actual number
• openingHoursSpecification — entries that name a dayOfWeek and give opens and closes as 24-hour times (09:00, not 9am), or the legacy openingHours string in its schema.org form (Mo-Fr 09:00-17:00)

What this issue is not:

• It does not guess. A page with no LocalBusiness schema is never reported, however much address, phone or opening-hours text sits in its body. Whether a page is meant to be a location page is an editorial decision the markup cannot settle, and the old heuristic that guessed it produced findings on pages that were correct as written.
• It does not repeat issue #89 (Organization/LocalBusiness schema). The identity fields of the same schema — name, url, logo, and whether address is a well-formed PostalAddress with a street, locality and postcode — belong there. Each fact is reported under one issue only.
• It does not demand the recommended-but-optional properties. Google requires name and address; a business that publishes those and omits geo, telephone, hours or priceRange has published nothing wrong, so those absences are recorded as recommendations on the page record rather than raised as a defect.

LocalBusiness schema is critical for local SEO and user experience:

• Local search visibility: Businesses with LocalBusiness schema are 2.7x more likely to be in the local 3-pack
• Voice search optimization: Voice assistants rely on structured data to answer "near me" queries
• Rich results: Enables business hours, contact info, and location in search results
• AI search readiness: AI engines use LocalBusiness schema to provide accurate business information
• Competitive advantage: Many businesses still don't implement this schema correctly

Resolving this issue improves your local SEO health score by ensuring search engines can properly identify and display your business information.

If the issue was raised, your page already declares a LocalBusiness — go to the finding, which names the properties at fault, and correct them in the block below. Steps 1 and 2 are for adding the schema to a page that has none: worthwhile for a location page, and never reported as a defect.

1. Identify pages with physical location information (Contact page, About page, Store locator)

2. Choose the correct LocalBusiness subtype from Schema.org:

   • Restaurant, Store, MedicalClinic, Hotel, HairSalon, etc.
   • Use the most specific type that matches your business

3. Add JSON-LD structured data to your Contact or About page:

   {
     "@context": "https://schema.org",
     "@type": "Restaurant",
     "name": "Your Business Name",
     "address": {
       "@type": "PostalAddress",
       "streetAddress": "123 Main St",
       "addressLocality": "City",
       "addressRegion": "State",
       "postalCode": "12345",
       "addressCountry": "US"
     },
     "telephone": "+1-555-123-4567",
     "openingHoursSpecification": [
       {
         "@type": "OpeningHoursSpecification",
         "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
         "opens": "09:00",
         "closes": "17:00"
       }
     ],
     "geo": {
       "@type": "GeoCoordinates",
       "latitude": "40.7128",
       "longitude": "-74.0060"
     }
   }

4. Validate with Google's Local Business Structured Data Testing Tool

Notes

• Use the most specific LocalBusiness subtype (e.g., Restaurant instead of generic LocalBusiness)
• Ensure geo coordinates are accurate for your business location
• Keep openingHoursSpecification updated with holiday hours
• Link to your Organization schema via @id for entity consistency

Example 1: Complete Location Data

Scenario: A restaurant declares the schema and fills in its location block.

Correct state (passes):

<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "Restaurant",
    "name": "Joe's Pizza",
    "url": "https://joespizza.example.com",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "123 Main St",
      "addressLocality": "New York",
      "addressRegion": "NY",
      "postalCode": "10001",
      "addressCountry": "US"
    },
    "telephone": "+1-212-555-1234",
    "geo": {
      "@type": "GeoCoordinates",
      "latitude": "40.7128",
      "longitude": "-74.0060"
    },
    "openingHoursSpecification": [
      {
        "@type": "OpeningHoursSpecification",
        "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"],
        "opens": "11:00",
        "closes": "22:00"
      },
      {
        "@type": "OpeningHoursSpecification",
        "dayOfWeek": ["Sunday"],
        "opens": "12:00",
        "closes": "21:00"
      }
    ]
  }
</script>

Example 2: Address With No Country

Problematic state (fails):

{
  "@context": "https://schema.org",
  "@type": "Store",
  "name": "Tech Startup",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "789 Innovation Blvd",
    "addressLocality": "San Francisco",
    "postalCode": "94105"
  }
}

Reported: address.addressCountry missing.

Why it fails: without a country the address is ambiguous across markets, and Google cannot place the business.

Corrected state (passes): add "addressCountry": "US" to the PostalAddress.

Example 3: Coordinates That Are Not Coordinates

Problematic state (fails):

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Riverside Cafe",
  "address": { "@type": "PostalAddress", "streetAddress": "1 Quay St", "addressLocality": "Bristol", "postalCode": "BS1 4DA", "addressCountry": "GB" },
  "geo": { "@type": "GeoCoordinates", "latitude": "near the river", "longitude": "by the bridge" }
}

Reported: geo.latitude "near the river" is not a number in decimal degrees.

Corrected state (passes):

"geo": { "@type": "GeoCoordinates", "latitude": 51.4499, "longitude": -2.5975 }

Strings are accepted — "51.4499" is fine — as long as they are numbers in decimal degrees and inside ±90 / ±180.

Example 4: Opening Hours a Machine Cannot Read

Problematic state (fails):

"openingHoursSpecification": {
  "@type": "OpeningHoursSpecification",
  "dayOfWeek": "Monday",
  "opens": "9am",
  "closes": "5pm"
}

Reported: openingHoursSpecification.opens "9am" is not a 24-hour time (expected HH:MM, e.g. 09:00).

Corrected state (passes):

"openingHoursSpecification": {
  "@type": "OpeningHoursSpecification",
  "dayOfWeek": "Monday",
  "opens": "09:00",
  "closes": "17:00"
}

The legacy string form is also accepted when it follows schema.org: "openingHours": "Mo-Fr 09:00-17:00".

Example 5: A Contact Page With No Schema — Not This Issue

<h1>Contact Us</h1>
<p><strong>Address:</strong> 123 Main St, New York, NY 10001</p>
<p><strong>Phone:</strong> +1-212-555-1234</p>
<p><strong>Hours:</strong> Mon-Sat 11am-10pm</p>

Nothing is reported. Whether this page was meant to carry LocalBusiness schema is an editorial decision the markup cannot settle — adding the schema is worthwhile (see How to fix it), but its absence is not raised as a defect.

Example 6: Missing Recommended Properties — Not a Finding

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Corner Bookshop",
  "url": "https://corner.example.com",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "4 Market Row",
    "addressLocality": "Leeds",
    "postalCode": "LS1 6DG",
    "addressCountry": "GB"
  }
}

Google requires name and address, and both are here. The absent geo, telephone, opening hours and priceRange are recorded as recommendations on the page record, not reported as an issue.

1. Read the structured data the page publishes: every JSON-LD block is parsed, and @graph wrappers are flattened, so a LocalBusiness emitted by Yoast, RankMath or stock WordPress is seen as the entity it is.

2. Select the declared LocalBusiness entities: any schema whose @type is LocalBusiness or any of its schema.org subtypes — Dentist, Hotel, Plumber, Attorney, ProfessionalService, Bakery, ClothingStore, VeterinaryCare and the rest of the roughly seventy the vocabulary defines, including a @type array that contains one of them, and including types written as a full IRI (https://schema.org/Restaurant) or a schema: prefix. Nothing else on the page is examined, and a page with no such schema is not examined at all.

   The recognised set used to be four names — LocalBusiness, Restaurant, Store, MedicalClinic — which is why this issue reported almost nothing in practice. A real site picks the specific subtype: a dentist publishes Dentist, a hotel Hotel. Those four names are what generic templates emit, so the short list matched the sites that had put the least thought into their markup and missed the ones that had put in the most.

3. Validate the location properties:

   • address — addressCountry must be present. A node that is only an @id pointer to an address defined elsewhere is followed, not flagged. addressRegion is a recommendation.
   • geo — must be a GeoCoordinates object carrying latitude and longitude. Values may be written as numbers or as strings ("40.7128" is how most templates emit them); they are rejected only when they are not numeric at all or fall outside ±90 / ±180.
   • telephone — reported when it is declared but empty or contains no digits.
   • openingHoursSpecification — each entry must name a dayOfWeek and state opens and closes in HH:MM (or HH:MM:SS) form. A day written as closed (00:00 to 00:00) is valid. A legacy openingHours string is checked against the schema.org form, e.g. Mo-Fr 09:00-17:00.

4. Keep the finding separate from #89: the location errors are never added to the schema's own validation errors, so a LocalBusiness missing both its url and its country produces one #89 finding about the url and one #96 finding about the country — never the same fact under two headings.

5. Report once per page: a store-locator page carrying twenty branches from one template produces one finding, naming the first businesses at fault and counting the rest. Every failing business is carried whole in the finding's details.

6. Record the recommendations: absent geo, telephone, opening hours or priceRange are stored as schema warnings on the page record and never become a finding.

Storage Level

Page Level — This issue is evaluated for each individual URL that contains structured data.

Database Table / Prisma Model

PageStructuredData

Stored Fields

Detection Dependencies

• The following data sources are required to evaluate this issue:
• HTML Document — The crawler parses the HTML to find structured data (JSON-LD, Microdata, RDFa)
• Structured Data Validation — The extracted schema is validated against Schema.org definitions
• Schema Parser — JSON-LD scripts, Microdata attributes, and RDFa markup are parsed