Sub-grade spoke
Operating Signals — can agents confirm your business is open right now?
Local businesses, restaurants, dental offices, salons, and service-pros all share one agent-readability bottleneck: are you open when the user wants to come in? The signal stack is OpeningHoursSpecification schema, holiday-hours markup, and business-status indicators that survive JS-only rendering. Sites that ship structured hours get booked; sites with hours in a JS widget or stale on a Google Business Profile get skipped. The 62% of consumers who avoid businesses with wrong info is the demand-side anchor; agents apply the same filter without exception.
By Chris Mühlnickel · 2026-05-16
What is Operating Signals?
Operating Signals is whether your site publishes OpeningHoursSpecification structured data with accurate weekly hours, holiday-hours overrides, and current business-status — making your operational availability machine-readable for agents.
By the numbers
- 62% — of consumers would avoid a business if they found it had incorrect information listed. (BrightLocal — Consumer Search Behavior)
- 85% — of consumers view contact information presence as an important factor — higher than price or proximity. (BrightLocal — Consumer Search Behavior)
- 30% — improvement in local search visibility for businesses using local schema markup with hours. (LocalMighty — Local Business Schema Implementation Guide)
Why it matters
Operating hours are the most-checked piece of information about a local business — by humans and increasingly by agents acting on a user's behalf. The 85% of consumers BrightLocal reports as treating contact information as important runs ahead of price and proximity for a reason: the user can't transact, can't visit, can't even make a phone call if the operating data is wrong. Agents apply the same logic deterministically. The agent searching for a dentist who can see the user tomorrow at 2pm filters first by OpeningHoursSpecification — sites without the schema either drop out or get scored against fallback signals (Google Business Profile, Yelp listing) that the site doesn't control as cleanly.
Stale or wrong hours is worse than missing hours. The 62% consumer-avoidance figure BrightLocal measures is the cost of bad data, not absent data. When a site publishes hours that don't match reality — Monday 9-5 in the schema but actually closed Mondays — the agent confidently recommends the business, the customer shows up, the bad experience routes through reviews and reputation channels back to the merchant. Agents trust structured signals; the cost of betraying that trust is reputational, sustained, and routes through vendor reputation for months. Better to ship no schema than to ship schema that's six months stale.
Holiday hours and business-status are where most operating data fails. Weekly hours are usually correct — they were entered once and rarely change. Holiday closures, seasonal variations, temporary relocations: these are where the divergence between schema and reality opens up. Sites that publish weekly hours and forget holiday overrides have agents confidently booking appointments on Christmas Eve at offices that close at noon. The schema supports the override pattern cleanly; the work is editorial discipline.
JS-only hour widgets are functionally invisible. A common pattern in service-local sites is a JavaScript widget that fetches hours from a CMS or third-party booking system. The visible result is correct; the schema is absent. Agents fetching initial HTML see no hours data. The LocalMighty figure of 30% local-search visibility improvement for structured-hours markup is the human-search-side payoff; the agent-search-side payoff is binary — citation eligible or not. Server-rendered OpeningHoursSpecification on the LocalBusiness block is the fix.
Where it's heading
Real-time business status replaces static schedules. Within 12-24 months expect agents to consult real-time business-status APIs — slot availability, current wait time, walk-in capacity — in addition to baseline operating hours. Sites with strong baseline OpeningHoursSpecification markup adopt the real-time extensions cheaply; sites still hand-rolling weekly schedules in 2027 lag. Service-local businesses with real-time availability win the agent-routed walk-in market.
Agent-initiated bookings filter by hours pre-recommendation. As direct-booking flows scale through agent platforms, the agent confirms operating hours plus slot availability before suggesting the business to the user. Sites without machine-readable hours drop out of the recommendation set; sites with both layers earn the booking share. The market for agent-routed local bookings is small today and large by 2027 — the schema is the access ticket.
Multi-channel hour synchronization becomes the maturity layer. Today most service-local businesses maintain hours in three places: website schema, Google Business Profile, and a booking platform (Calendly, Acuity, OpenTable). The drift between these sources is the failure mode that compounds across surfaces. Expect tooling that synchronizes from a single source-of-truth out to all consumed surfaces — agents read whichever signal is freshest, and sites that maintain consistency win the consistency premium.
Common mistakes
- Weekly hours present, holiday hours missing. Agents confidently book appointments on closed days. Override blocks per holiday range fix it.
- Hours in a JS-rendered widget, no schema. Visible to humans, invisible to agents fetching initial HTML. Server-rendered OpeningHoursSpecification is the fix.
- Schema published once, never updated. Hours change, schema doesn't. Six months later it lies to every agent that fetches the page.
- Google Business Profile correct, on-site schema absent. Agents that fetch the site directly (Perplexity, Claude) see no hours; the GBP signal doesn't reach them.
- Permanently closed but still listed as open. Business-status markup supersedes hours; missing the closure signal keeps the location in agent recommendation pools.
Frequently asked
What's the minimum operating-hours markup my site needs?
An OpeningHoursSpecification block on LocalBusiness schema with dayOfWeek, opens, and closes for each weekday. Optionally validFrom / validThrough for seasonal variations and a separate block array for holiday hours. The schema was designed for the case of 'open M-F 9-5, Sat 10-2' and handles complex cases — multiple shifts per day, multi-location, seasonal — without extension. A Spekto audit reports the gaps.
Does Google Business Profile data substitute for on-site hours markup?
Partially. GBP feeds Google's local panel and Maps; agents that consult Google's APIs read it. But not every agent surface routes through Google — Perplexity, Claude, and direct-fetch flows consult the site itself. Sites that publish OpeningHoursSpecification on-site plus maintain accurate GBP cover both paths; sites that rely on GBP alone are invisible to agents that fetch the site directly. The dual signal is the safer pattern.
How do I markup holiday hours and unusual closures?
Use a separate OpeningHoursSpecification block with validFrom and validThrough for the specific date range, plus modified opens/closes (or opens: '00:00' / closes: '00:00' for closures). The 'closed Christmas Day' pattern ships as a single override block; recurring annual closures ship the same way. The common failure is publishing weekly hours and forgetting holiday overrides — agents fall back to the weekly schedule, customers show up to a closed door.
What if my hours change frequently — seasonal, weather-dependent, by appointment?
Three patterns. Seasonal: array of OpeningHoursSpecification blocks each with validFrom / validThrough. Weather-dependent: pair the schedule with a real-time business-status signal (a small endpoint or business-status flag the site updates). By appointment: signal byAppointment: true and link to a direct booking flow. Sites that publish 'open by appointment' machine-readably get correctly routed; sites that publish '9-5' but actually require appointments waste agent and user time.
Should I publish operating hours when my business is fully online — no physical location?
Yes, for service availability. The same schema covers 'customer support available 9-5 ET' and 'live chat staffed M-F.' Agents using your support endpoints need to know when responses are expected. The schema applies to any Organization that has availability windows, not just LocalBusiness types.
How does business-status interact with operating hours?
Operating hours describe the schedule; business-status describes whether the business is currently operational at all. Permanently closed, temporarily closed, relocating — the status signal supersedes the hours. Sites that fail to publish closed/relocated status keep showing up in agent recommendations as 'open' — and customers complain to the agent platform, not the site, when they arrive at a shuttered location.
How frequently should operating-hours data be reviewed?
Per-deploy at minimum, weekly during seasonal transitions, and ad-hoc whenever hours change. The failure mode the audit catches is silent drift — site updated hours on the website but not in the schema, or vice versa. CI validation via Google's Rich Results Test catches the structural cases; the editorial discipline catches the content cases.