LocalBusiness (schema)

Google uses this information to understand a business as an entity; the documentation expressly names the prominent knowledge panel in Search and Maps and carousels for commercial search queries as possible displays.

LocalBusiness is thus the counterpart to the business profile on your own domain. The Google Business Profile supplies the data from Google's own system; the markup supplies it from the source that the business itself controls. If the two match, they reinforce each other. If they contradict each other, you have a consistency problem; see NAP consistency.

Where LocalBusiness sits in the schema.org vocabulary

LocalBusiness is a subtype of Organization and at the same time of Place. This dual origin explains why the type carries both organisation properties (legalName, sameAs, vatID) and place properties (geo, hasMap, openingHoursSpecification). The full definition is at schema.org/LocalBusiness.

Mark up as specifically as possible

Google recommends using the appropriate subtype instead of the generic LocalBusiness. The vocabulary knows dozens of them, and the list is surprisingly fine-grained:

• Health: Dentist, Physician, Pharmacy, MedicalBusiness, Optician, VeterinaryCare
• Law and advice: LegalService, Attorney, AccountingService, InsuranceAgency, FinancialService
• Trades and construction: Plumber, Electrician, RoofingContractor, HVACBusiness, Locksmith, HousePainter
• Hospitality and retail: Restaurant, CafeOrCoffeeShop, Bakery, Store, AutoRepair
• Services: DaySpa, HealthClub, HairSalon, ProfessionalService, RealEstateAgent

Since LocalBusiness inherits from Organization, Google also recommends filling in the organisation fields: logo, sameAs references to official profiles and founding data where available. If a business offers several trades, several types can be specified as an array; Google does not support additionalType at this point:

{
  "@context": "https://schema.org",
  "@type": ["Electrician", "Plumber", "Locksmith"],
  "name": "Example Building Services Ltd"
}

Required and recommended properties

Google's requirements are minimal; the effect of the recommended fields is not. Only two details are required; everything else decides how complete the entity becomes.

Marking up opening hours correctly

openingHoursSpecification is the field where most implementations fail, because special cases are not represented cleanly. Regular hours do without validFrom and validThrough and then apply all year round. For days of the week, Google accepts both the canonical schema.org URLs (https://schema.org/Monday) and the short form (Monday). Opening hours past midnight are represented in a single OpeningHoursSpecification, not in two. Seasonal closures are dated via validFrom and validThrough in the format YYYY-MM-DD.

"openingHoursSpecification": [
  {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
    "opens": "09:00",
    "closes": "18:00"
  },
  {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": "Saturday",
    "opens": "10:00",
    "closes": "14:00"
  }
]

An example from Google's documentation

The reference example in the Google Search Central documentation on structured data for local businesses marks up a restaurant as Restaurant, i.e. via the subtype rather than LocalBusiness, and combines image in three aspect ratios, a complete PostalAddress, geo, telephone in E.164 format, servesCuisine, priceRange, a menu URL and four OpeningHoursSpecification blocks for different days of the week. The pattern is transferable: first choose the most specific type, then add the industry-specific additional fields that this type brings with it.

Multiple locations and departments

With several branches, the rule is: one separate page per location, one separate LocalBusiness block per page with the respective address and the canonical URL of that page. A collective page that lists all branches in one markup block does not create a clean entity per location and ranks correspondingly badly. A stable @id per location, usually the location URL with a fragment, helps to keep the entity recognisable across page restructurings.

department is intended for departments within a location that have their own opening hours or telephone numbers. Google specifies a naming convention for this: {business name} {department name}; in the documentation example, "Dave's Department Store" with the nested department "Dave's Pharmacy" of type Pharmacy. If the department carries its own brand, it is listed separately.

What LocalBusiness markup does not do

Two misconceptions are persistent.

Self-ratings are not permitted

According to Google's documentation, aggregateRating and review are only recommended for pages that collect reviews about other local businesses. Getting your own average rating into the search results as a star snippet therefore does not work via this route; Google treats such information as an impermissible self-rating. Anyone who wants to work with reviews works on the Google reviews in the business profile, not on the markup. And anyone who displays an average rating on their website should first check the requirements of competition law, otherwise they risk a warning letter.

Markup replaces neither content nor ranking

Structured data is a description, not a ranking factor in the narrower sense. It increases the chance of being understood correctly and shown in special display formats. A thin location page does not become a good page because of a perfect LocalBusiness object. Conversely, a strong location page without markup gives away unambiguity, precisely the unambiguity on which answer engines depend when they are supposed to pull address and opening hours from a page. For visibility in the local pack, the business profile remains the stronger lever; the markup supports the data behind it.

Validation and monitoring

Before going live, every block should go through a testing tool. Two are established: Google's Rich Results Test shows which Google features can be reached with the markup, and the Schema Markup Validator checks against the schema.org vocabulary itself, independently of Google's list of features. Critical errors must be removed; non-critical warnings improve quality but do not block any display.

• After deployment, use the URL inspection tool in Search Console to see how Google sees the rendered page, which is particularly important if the markup is generated by JavaScript.
• Check accessibility: robots.txt, noindex and log-in hurdles prevent the block from being read at all.
• Monitor continuously: the structured data report in Search Console reports errors that occur after a template update, the most common way in which correct markup breaks again.
• Announce changes: an up-to-date sitemap speeds up recrawling after major restructurings.

How the markup feeds into AI answers

Answer engines do not read pages like a customer but like a data source. If a model is to answer the question "Until what time is the practice open on Saturday?", there are two possible routes: it derives the answer from prose and guesses when things are unclear, or it reads an unambiguous field. That is exactly why LocalBusiness markup has gained in importance beyond the classic rich results. The information costs effort once and permanently reduces the likelihood of a machine displaying outdated or someone else's data about the business.

This does not replace maintenance elsewhere. A business profile with incorrect opening hours remains incorrect even if the markup is right, and Google gives its own profile heavy weight for local questions. The simple rule therefore makes sense: one data set, three places. The opening hours are in the business profile, in the visible page text and in the markup, and they are changed in all three places in the same step. Anyone who separates these reliably produces contradictions within a year.

A practical side effect: because sameAs refers to a business's official profiles, a complete block links your own domain with industry directories, review portals and social profiles. This is not a ranking mechanism but entity work: it makes it traceable that "Musterfrau law firm" on five platforms is the same organisation.

Distinction: LocalBusiness, Organization, Service, Place

Four types are regularly confused, even though they answer different questions. The decision is not a matter of taste but of what the respective page actually describes.

• Organization describes the business as a legal and brand entity: umbrella brand, logo, legal form, official profiles via sameAs. The right type for the home and about us pages of businesses without walk-in customers.
• LocalBusiness describes a business at a location. It inherits from Organization and adds everything to do with being able to visit it.
• Service describes an individually marketed service ("heating maintenance", "employment law advice") with its own description, provider and area served. The right type for service pages.
• Place describes a place without a business connection, such as a building or a car park. Practically never the right choice for business pages.

A service provider with one location and five services usually does well with a LocalBusiness subtype on the home page and location page plus one Service object on each service page that refers back to the business entity via provider.

Typical implementation mistakes

• Markup and visible content differ. Opening hours in the JSON-LD that do not appear in the page text violate Google's general guidelines for structured data.
• Generic LocalBusiness instead of a subtype. Works, but gives away the industry-specific fields and the clearer assignment.
• Telephone number in national format. 0211 123456 is ambiguous; +49211123456 is not.
• One markup block for all locations. Leads to one blurred entity instead of several clear ones.
• Coordinates estimated from the map excerpt. Google requires at least five decimal places; rough values put the business on the wrong side of the street.
• Markup only in the consent-dependent script. If the JSON-LD is only delivered after consent, the crawler never sees it.

Frequently asked questions about LocalBusiness schema

JSON-LD, Microdata or RDFa?

JSON-LD, in a script type="application/ld+json" block. It is separate from the visible HTML content, survives template changes better and is the format preferred by Google.

Does the block belong in the head or the body?

Both work. The head is usual and makes maintenance easier, because the markup then does not wander into layout components.

Are name and address enough?

Formally yes, practically no. Only the telephone number, geo-coordinates, opening hours, images and the location-specific URL turn the minimal entry into a robust description of the entity.

Do I have to output LocalBusiness on every page?

No. The home page and location pages are sufficient; on location pages with the respective address. On blog or service pages, Organization or Service is the more appropriate type instead.

How quickly does the markup take effect?

Google has to recrawl and reindex the page; after publication, this typically takes a few days. There is no guarantee of a particular display in the search results, not even with error-free markup.