What the Schema Was Actually Saying

The client here is a small, family-run shop - the kind of place where the person who answers the phone is also the person who unlocks the door. During a routine technical review of their site, the JSON-LD block turned up something nobody had actually read since the day it went live.

It was declaring a full street address, latitude and longitude out to six decimal places, and an openingHoursSpecification claiming the shop was open 24 hours a day, every day of the week.

None of it was current. The address pointed at a location the business hadn't operated out of in years. The hours were lifted straight from whatever schema generator had produced the original template, never touched again. Nobody had decided to publish any of this - it arrived pre-filled, and nobody had gone back to delete it.

This is the kind of error that doesn't announce itself. The page looked fine. The listing rendered normally wherever it showed up in search. The only place any of it actually lived was in a block of markup nobody reads unless they go looking for it.

Before and After

Field Before After
Street address Full address published in schema, several years out of date Removed entirely
Geo coordinates Precise lat/long to six decimal places, tied to the old address Removed entirely
Opening hours "Open 00:00-23:59, every day of the week" Removed entirely
Where hours/location live now Only in the site's own schema, silently wrong A listing channel the owner actually updates, and a contact page a person reads before making the trip

Decision Log

Why the address was removed instead of corrected

The obvious first move once a stale address gets flagged is to just update it. That got overridden here. This is a small, appointment-heavy operation - walk-in traffic isn't really the model - and the owner was uneasy about a precise public address sitting in structured data that gets scraped, cached, and republished by anyone running a script, long after the site itself changes again. Removing it took that exposure off the table entirely, instead of just handing the same problem a new address to eventually go stale on.

Why the coordinates went too

Coordinates tied to a wrong address are worse than no coordinates at all - they send someone to a real place that isn't the right one, with more confidence than a vague listing would. Once the address itself was gone, coordinates pointing at nothing had no reason to stay either.

Why "open 24 hours" had to go, not just get corrected

This one mattered more than it looks. The real hours shift by season, and some weeks by the owner's own calendar - a small, owner-run shop doesn't operate on a fixed schedule the way a franchise does. Hand-entering "correct" hours today just means they're wrong again in a few months. And a wrong hours field is worse than a missing one: a customer who drives out because the schema said open, finds the door locked, doesn't just distrust the hours. They stop trusting anything else the structured data told them about the business.

Where the real information lives now

Instead of trying to keep a static field in sync with something that changes on its own schedule, the accurate version now lives where the owner actually updates it when things change - a listing they control directly, and a contact page a visitor reads before deciding to make the trip. Schema doesn't need to carry information nobody's maintaining.

Frequently asked questions

Why not just fix the hours instead of removing them?

Because a hand-entered value in a file nobody revisits will drift again the moment the real hours change. Removing the field avoids re-creating the exact problem that got found in the first place.

Doesn't removing structured data hurt local search visibility?

Less than leaving it wrong does. Schema is one signal among several, and search systems that catch one field being false tend to trust the rest of a site's structured data less too - not just that one field.

How did an audit even catch this if the page looked fine?

Because none of it is visible on the page. Reading schema means opening the markup directly and reading it line by line - not judging it by whether the rendered page looks right, since the two have nothing to do with each other.

Is this a common problem?

More common than it should be, especially on sites that started from a template or an automated generator. A lot of local-business schema in the wild was accepted as a default, not actually written by anyone.

If nobody's checked your schema since launch, it's probably still saying whatever the template said

Structured data doesn't fail loudly. It just sits there, quietly telling search engines and anyone else reading it something that stopped being true a while ago.