If a potential customer asks ChatGPT or Perplexity "Is [your business] open on Sundays?", what happens? If you haven't told AI search engines your hours in a format they can actually read, the answer will either be wrong or simply absent. That is lost business, and it is entirely avoidable.
OpeningHoursSpecification is a schema type from schema.org that lets you express, in precise machine-readable terms, exactly when your business is open. It goes well beyond a simple text string. You can specify hours for each day of the week, define holiday exceptions, and even handle multiple opening periods within a single day. For AI search engines that are trying to give users accurate, real-time-adjacent answers, this kind of structured signal matters a great deal.
This guide walks through how to implement it properly, what mistakes to avoid, and why getting it right is increasingly important as AI becomes a primary discovery channel.
Why Opening Hours Matter More in AI Search Than in Traditional SEO
In classical Google search, your opening hours might appear in a Knowledge Panel pulled from your Google Business Profile. The schema on your own website was always helpful, but Google had other sources to cross-reference. AI search engines like ChatGPT, Perplexity, and Gemini don't have the same fallback infrastructure. They read the web and parse structured data. If your website's schema says you're open Monday to Friday, 9am to 5pm, that is what the AI will tell people.
This creates a real accountability shift. Your website's structured data becomes the primary source of truth. Inaccurate or missing OpeningHoursSpecification schema doesn't just mean a missed rich result. It means AI assistants actively misleading your potential customers about when they can reach you.
The good news is that this also creates an opportunity. Businesses that implement this schema correctly gain a meaningful advantage in AI-generated answers about local services, trading hours, and appointment availability.
The Structure of OpeningHoursSpecification
OpeningHoursSpecification lives inside a broader entity, typically a LocalBusiness, Store, or Organization schema type. It uses a handful of specific properties you need to know:
- dayOfWeek: One or more days, expressed as schema.org URLs (e.g.
https://schema.org/Monday) - opens: The opening time in HH:MM format using 24-hour notation
- closes: The closing time, also in HH:MM format
- validFrom: Optional. The date from which this specification applies (ISO 8601 format: YYYY-MM-DD)
- validThrough: Optional. The date until which this specification applies
The validFrom and validThrough properties are what make OpeningHoursSpecification genuinely powerful. They allow you to define seasonal hours, holiday schedules, and temporary closures alongside your standard trading hours.
A Working JSON-LD Example
Here is a complete, production-ready JSON-LD implementation for a retail shop with standard weekday hours, reduced Saturday hours, and a Sunday closure:
{
"@context": "https://schema.org",
"@type": "Store",
"name": "Finch & Co. Home Goods",
"url": "https://finchandco.co.uk",
"telephone": "+44 1234 567890",
"address": {
"@type": "PostalAddress",
"streetAddress": "14 Market Street",
"addressLocality": "Bristol",
"postalCode": "BS1 3AA",
"addressCountry": "GB"
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": [
"https://schema.org/Monday",
"https://schema.org/Tuesday",
"https://schema.org/Wednesday",
"https://schema.org/Thursday",
"https://schema.org/Friday"
],
"opens": "09:00",
"closes": "18:00"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": "https://schema.org/Saturday",
"opens": "10:00",
"closes": "16:00"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": "https://schema.org/Sunday",
"opens": "00:00",
"closes": "00:00"
}
]
}A couple of details worth noting here. First, you can group multiple days into a single OpeningHoursSpecification object if they share the same hours. This keeps your JSON-LD tidy. Second, for days when you are closed, the recommended approach is to either omit that day entirely or use "opens": "00:00" and "closes": "00:00". The latter is often preferable because it explicitly tells the AI the business is closed on that day, rather than leaving it ambiguous.
Handling Special Hours and Holiday Closures
This is where most implementations fall short. Standard opening hours are the easy part. What trips businesses up is holiday periods, bank holidays, and seasonal changes. Those are exactly the moments when customers most need accurate information, and when AI search engines are most likely to get it wrong without explicit schema.
Seasonal Hours
If your business runs extended hours in summer (say, May through August), you can define a second set of OpeningHoursSpecification objects with validFrom and validThrough dates. Here is how that looks:
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": [
"https://schema.org/Monday",
"https://schema.org/Tuesday",
"https://schema.org/Wednesday",
"https://schema.org/Thursday",
"https://schema.org/Friday"
],
"opens": "08:00",
"closes": "20:00",
"validFrom": "2025-05-01",
"validThrough": "2025-08-31"
}Stack this alongside your standard hours specification and AI parsers will pick up the correct hours based on the date context of the query.
Holiday Closures
For specific dates when you are fully closed (Christmas Day, Easter Sunday, bank holidays), define a separate OpeningHoursSpecification with the specific date range and "opens": "00:00", "closes": "00:00":
{
"@type": "OpeningHoursSpecification",
"opens": "00:00",
"closes": "00:00",
"validFrom": "2025-12-25",
"validThrough": "2025-12-26"
}This is clear, unambiguous, and exactly the kind of signal that AI search engines can act on with confidence.
Common Implementation Mistakes
Having reviewed dozens of e-commerce and local business sites, the same errors appear again and again. Here are the ones that cause the most damage to AI visibility:
Using 12-Hour Time Format
Schema.org requires 24-hour time notation. Writing "opens": "9:00am" is not valid and will cause parsing failures. Always use "opens": "09:00" with a leading zero.
Forgetting to Update After Hours Change
This is probably the single most common issue. A business changes its hours, updates the website text, but the JSON-LD in the page's <head> quietly stays the same. AI search engines read the structured data, not the human-readable text. The result is that ChatGPT tells someone you're open until 6pm when you've actually been closing at 5pm for six months. A regular schema audit prevents this. At FlinnSchema, structured data health checks are a core part of our free AI visibility audit, and stale opening hours come up more often than you'd think.
Placing the Schema Only on the Contact Page
OpeningHoursSpecification should live on every page where it makes sense for AI to surface the information, at minimum your homepage and any location-specific pages. Don't restrict it to a single contact page that might not be crawled as frequently.
Mixing Schema Types Incorrectly
OpeningHoursSpecification must be nested inside an appropriate parent entity. Floating it without a parent LocalBusiness, Store, or similar type means it has no context and AI parsers may discard it entirely.
Multiple Locations: Scaling OpeningHoursSpecification
If you operate more than one physical location, each location should have its own complete schema block with its own OpeningHoursSpecification. Don't try to define one global set of hours for a multi-location business. A customer asking "Is [brand] in Manchester open on Saturdays?" needs location-specific information, and so does the AI answering that question.
Each location page on your website should carry a distinct JSON-LD block tied to that location's address, phone number, and opening hours. This approach also ties in neatly with how AI search engines handle local queries. The more precisely you define each location as a distinct entity, the more confidently an AI can cite you for location-specific questions.
If you run a franchise or multi-site operation, this intersects with how you might use other schema types to express your brand structure. Our post on using Franchise schema to win AI search across locations covers the broader entity structure that OpeningHoursSpecification slots into for those kinds of businesses.
Testing and Validating Your Implementation
Once you've added OpeningHoursSpecification to your site, test it. Google's Rich Results Test will flag structural errors in your JSON-LD. Schema.org's validator at validator.schema.org is also useful for catching issues that the Rich Results Test might not surface.
Beyond validation tools, do a manual check: ask ChatGPT or Perplexity directly about your business's opening hours. If the AI gives a confident, correct answer, your schema is working. If it hedges or gives outdated information, there's more work to do.
It's worth understanding that schema validation and AI citation aren't the same thing. A schema that validates perfectly can still fail to influence AI answers if the broader page context isn't clear, if your domain lacks authority, or if your entity signals are weak. That's the wider AI visibility picture that goes well beyond any single schema type. If you want a fuller view of where your site stands, a free AI visibility audit is a practical starting point.
For a broader view of how schema markup works across different content types, our guide on common schema markup mistakes that hurt AI visibility covers the patterns that come up most often across client sites.
The Relationship Between OpeningHoursSpecification and AI Trust
AI search engines are fundamentally in the business of making confident, helpful recommendations. They don't cite sources they don't trust, and they don't surface information they can't verify. When you provide clean, specific, consistently formatted structured data about your opening hours, you're giving AI systems exactly what they need to cite you with confidence.
Think of it this way: an AI assistant is like a very thorough researcher who wants to be right before they say anything. Vague or missing data means they'll either skip you or caveat their answer heavily. Precise, machine-readable schema means they can say "Yes, Finch & Co. is open on Saturdays from 10am to 4pm" without hesitation. That directness is what drives foot traffic and enquiries.
This is one of the core principles behind how FlinnSchema approaches structured data. It's not just about ticking a technical box. It's about making your business the obvious, trustworthy answer to a specific question. Opening hours might seem like a small detail, but they are one of the highest-intent queries a local customer can make. Getting that answer right, every time, is not trivial.
Frequently Asked Questions
Does OpeningHoursSpecification affect Google search as well as AI search?
Yes. Google uses OpeningHoursSpecification to populate Knowledge Panels and local search results. Implementing it correctly benefits both traditional search visibility and AI search citation. They're not mutually exclusive, and the effort pays off in both channels simultaneously.
What's the difference between openingHours and openingHoursSpecification?
The openingHours property (note: no "Specification") is a simpler, older format that takes a text string like "Mo-Fr 09:00-18:00". It works but offers less precision. openingHoursSpecification is the more structured approach that supports date ranges, holiday exceptions, and multiple time periods per day. For AI visibility purposes, the full Specification format is strongly preferable.
How often should I update my OpeningHoursSpecification schema?
Every time your hours change, full stop. That includes permanent changes, seasonal adjustments, and holiday closures. It's good practice to review your schema at the start of each quarter and before any major holiday period. Stale opening hours are one of the most common and most damaging schema errors we see. Our guide on how often you should update your schema markup covers a sensible review cadence for all your structured data, not just opening hours.
Can I use OpeningHoursSpecification for an online-only business?
It depends. If your online business has customer service hours, live chat availability, or phone support hours that vary by day, there's an argument for using it to express those. However, OpeningHoursSpecification is primarily designed for physical locations. For purely digital businesses, it's less relevant and may confuse AI parsers if used without a corresponding address or place entity. In those cases, it's better to leave it out than to implement it poorly.