Seven local business schema mistakes

1. Using LocalBusiness when something specific exists

This is the most common and the easiest to fix. Schema.org has specific subtypes that inherit everything LocalBusiness has and add meaning: AutoRepair, CafeOrCoffeeShop, Restaurant, LodgingBusiness, HairSalon, Dentist, Plumber, SecurityService.

{ "@type": "AutoRepair", "@id": "https://example.com/#business" }

Use the narrowest type that is still true.

2. Claiming service areas you do not serve

areaServed listing every county within fifty miles is a common piece of optimism. It does not help you rank in those places, and claiming coverage you cannot deliver is how listings get reported.

Mark up what you actually cover, typed properly:

"areaServed": [
  { "@type": "City", "name": "Watford" },
  { "@type": "AdministrativeArea", "name": "Hertfordshire" }
]

3. Unlinked copies of the same entity on every page

If every page declares a fresh LocalBusiness with no @id, you have told search engines you have as many businesses as you have pages.

Declare the entity once with a stable @id, then reference it everywhere else:

{ "@type": "WebPage", "@id": "https://example.com/services/#page",
  "about": { "@id": "https://example.com/#business" } }

One graph per page, one @id per real-world thing, references instead of repeats.

4. Inventing AggregateRating

This is the one that can actually hurt you. Marking up ratings that do not exist, or that you gathered yourself and presented as independent, violates Google’s structured data spam policies and earns a manual action.

If you have genuine reviews on your own site, mark them up. If you do not, leave the field out. An absent rating costs you a star in a search result; a fabricated one can cost you the rich result entirely, across the whole domain.

5. Opening hours as prose

"openingHours": "Mon-Fri 9-5" is a string. Use the structured form so it can be parsed, and include the edge cases:

"openingHoursSpecification": [
  { "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
    "opens": "09:00", "closes": "17:30" },
  { "@type": "OpeningHoursSpecification",
    "dayOfWeek": "Saturday", "opens": "09:00", "closes": "13:00" }
]

Times are 24-hour. A business closed on Sunday simply omits it.

6. NAP that disagrees with itself

Name, address and phone number should be byte-identical across your markup, your Google Business Profile, your footer and every directory listing. “Street” in one place and “St” in another is a reconciliation problem you are handing to a machine that will not always get it right.

7. Services as a list instead of entities

A paragraph listing six services is not six things. Each service a business wants to be found for deserves its own Service node, and usually its own page:

{ "@type": "Service", "@id": "https://example.com/services/cctv/#service",
  "serviceType": "CCTV installation",
  "provider": { "@id": "https://example.com/#business" } }

Delta Surveillance does this per offering; E R Alloy Wheels does it per job type.

Validate both ways

Run every page through the Schema.org validator and Google’s Rich Results Test. The first tells you whether the vocabulary is right; the second tells you whether Google will do anything with it. Passing one is not passing the other.