Hours and Contact Blocks: Opening Times, Exceptions, and Routes

An hours and contact block answers a practical question before a visit or enquiry fails: when can I reach this specific business, and which route should I use? It brings the weekly schedule, dated exceptions, phone, and email into one visible and machine-readable unit.

Why this element matters

Hours and contact details sit close to a real-world commitment. A reader may be deciding whether to travel, call during a short break, arrange an urgent repair, or ask about an accessibility need. Ambiguous hours transfer the cost of uncertainty to that person. A complete block names the branch, timezone, regular schedule, relevant exception, and route suited to the task.

The psychology is about confidence and recovery. “Open now” helps only when the closing time is also visible. A phone number helps only when it reaches the right team or explains a different answering schedule. Dated exceptions reassure readers that the date they care about was considered; an alternative route prevents a dead end.

Search engines, map products, voice assistants, AI agents, and directory feeds must connect each time and route to the correct location. A footer with one number, a map card with another, and JSON-LD with stale hours creates several plausible answers. Typed fields preserve the relationships among location, day, times, timezone, exceptions, contact purpose, and verification time.

The visible block remains the reader-facing source of truth. Structured data must not introduce longer hours, another phone number, or a hidden exception. Generate both outputs from the same operational record whenever possible.

When to use it

Use this element wherever hours or direct contact determine whether someone can complete the intended action. It is standard for staffed shops, clinics, offices, restaurants, service depots, attractions, and branches. It also fits a service page with a distinct enquiry route or operating window, and a company or branch profile containing operational contact.

Use one block per independently operated location. Identical schedules still need separate identities because exceptions, timezones, and phone routing can diverge. A directory may show compact blocks, but every schedule must remain attached to one location.

Common near misses need a different model:

• A booking calendar describes available appointments, not the hours when the business is generally open. The business may be open while no appointment remains.
• Customer-support coverage is not automatically the same as branch opening hours. Label it as support availability and associate it with that contact route.
• Product availability states whether an item can be obtained. “Open now” does not prove that the selected item is in stock.
• A delivery window states when an order may arrive, not when a customer can call the warehouse.
• A one-off event schedule belongs to the event. Do not overwrite the permanent location schedule to represent it.
• An unstaffed service area, mailbox, registered office, or virtual location must not be presented as a place readers can visit.

The element writing rules take precedence: choose this element because the passage’s purpose is to state operational hours and contact routes, not because the current design happens to resemble a card, table, or footer.

Ready to Monitor Your AI Visibility?

Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.

Get Started Contact

Where to place it

On a location or branch page, place the full block after the location identity and address and before directions, parking, booking, or visit-planning detail. Readers should not pass reviews or promotions before learning whether the location is open. A compact hero state should link to the full schedule and derive from the same data.

On a service page, place the block beside the enquiry action only when its route and hours apply to that service. For several locations, require a location selection before showing a schedule. A footer may repeat a brand route but cannot replace the page-specific block.

The block may sit beside an address, map, directions, or booking action for the same location. It may not sit beside a conflicting state, another branch’s number, a calendar that appears to share its hours, or an unrelated expiry. Keep qualifiers such as “emergency calls only” with their route.

On mobile, preserve the order: location name, current status with closing time, weekly schedule, dated exceptions, task-labelled contact routes, then actions. Sticky Call or Directions actions must use the same location record and must not conceal route limitations.

Anatomy

1. Location identity: names the branch or service point and carries a stable internal identifier.
2. Current state: says Open, Closed, Open 24 hours, or By appointment, followed by the next material change when it can be calculated reliably.
3. Regular weekly schedule: records every day, including explicitly closed days, in local wall-clock time.
4. Timezone: identifies the IANA timezone used to interpret the schedule and daylight-saving changes.
5. Exceptions: gives absolute dates for closures, shortened days, extended hours, or seasonal periods.
6. Contact routes: provides normalized phone and email values with human-readable labels.
7. Purpose and availability: explains which task each route handles and when that route is monitored if it differs from business hours.
8. Actions: offers accessible Call, Email, Book, or Directions actions without replacing the visible values.
9. Verification: records when the operational source last confirmed the details.

Stay Updated on AI Visibility Trends

Get the latest insights on AI mentions, brand monitoring, and optimization strategies.

Email address

Subscribe

Design examples

Every variant needs a location name, text states rather than color alone, and the same data contract.

Full weekly schedule. The location-page default shows all seven days, combining adjacent days only when their hours match and the grouping remains scannable.

Compact current-day summary. In a hero, directory row, or mobile panel, include the current state, next transition, nearest exception, and a control revealing the full week.

Holiday and one-off exceptions. List dated overrides beside the regular schedule while relevant. Say “Closed” rather than displaying an empty time range.

Seasonal hours. Name the season and its start and end dates. Show when the next schedule takes effect rather than silently swapping tables.

Multiple contact routes. Label the purpose of every bookings, service, accessibility, or emergency route; avoid unexplained numbers.

By appointment or split service. Keep reception hours, appointment availability, and emergency coverage separate because they represent different promises.

Parameters

“Source” describes where the component obtains the field, not the operational system that owns the fact.

Use variant=full, compact, or contact-first. An overnight period such as 22:00–02:00 starts on the named day and closes the next calendar day. Multiple periods on one day are separate regular-hours items, which preserves a lunch closure without inventing a continuous opening period.

Syntax and code examples

All three forms encode the same location, timezone, schedule, exception, and labelled routes. The publishing platform must register the adapter before production use.

Portable Markdown directive

:::hours-contact{location-id="riverside-repair" timezone="America/New_York" verified="2026-08-27" variant=full}
## Riverside Repair — hours and contact

::item{type=hours days="Monday-Friday" status=open opens="09:00" closes="17:30"}
Regular workshop and reception hours.
::
::item{type=hours days=Saturday status=open opens="09:00" closes="13:00"}
::
::item{type=hours days=Sunday status=closed}
::
::item{type=exception date="2026-12-25" status=closed}
Christmas Day closure.
::
::item{type=phone value="+12125550146" purpose="Repairs and bookings"}
Calls are answered during regular hours.
::
::item{type=email value="service@example.com" purpose="Service enquiries"}
Replies are handled during regular hours.
::
:::

Hugo shortcode

{{< hours_contact location_id="riverside-repair" timezone="America/New_York" verified="2026-08-27" variant="full" >}}
  {{< hours_item type="hours" days="Monday-Friday" status="open" opens="09:00" closes="17:30" >}}Regular workshop and reception hours.{{< /hours_item >}}
  {{< hours_item type="hours" days="Saturday" status="open" opens="09:00" closes="13:00" >}}{{< /hours_item >}}
  {{< hours_item type="hours" days="Sunday" status="closed" >}}{{< /hours_item >}}
  {{< hours_item type="exception" date="2026-12-25" status="closed" >}}Christmas Day closure.{{< /hours_item >}}
  {{< contact_item type="phone" value="+12125550146" purpose="Repairs and bookings" >}}Calls are answered during regular hours.{{< /contact_item >}}
  {{< contact_item type="email" value="service@example.com" purpose="Service enquiries" >}}Replies are handled during regular hours.{{< /contact_item >}}
{{< /hours_contact >}}

Every parameter is named; positional and named shortcode parameters are never mixed.

WordPress

<!-- wp:amicited/hours-contact {"locationId":"riverside-repair","timezone":"America/New_York","verified":"2026-08-27","variant":"full"} -->
<!-- wp:amicited/hours-item {"days":["Monday","Tuesday","Wednesday","Thursday","Friday"],"status":"open","opens":"09:00","closes":"17:30"} /-->
<!-- wp:amicited/hours-item {"days":["Saturday"],"status":"open","opens":"09:00","closes":"13:00"} /-->
<!-- wp:amicited/hours-item {"days":["Sunday"],"status":"closed"} /-->
<!-- wp:amicited/hours-exception {"date":"2026-12-25","status":"closed","label":"Christmas Day closure"} /-->
<!-- wp:amicited/contact-route {"type":"phone","value":"+12125550146","purpose":"Repairs and bookings","note":"Calls are answered during regular hours."} /-->
<!-- wp:amicited/contact-route {"type":"email","value":"service@example.com","purpose":"Service enquiries","note":"Replies are handled during regular hours."} /-->
<!-- /wp:amicited/hours-contact -->

A native WordPress block should keep schedules and routes as typed child records, not one rich-text field. The visible block and JSON-LD should read from those records.

Good and bad examples

Good

Riverside Repair — Thursday hours: Open 09:00–17:30. Saturday 09:00–13:00; Sunday closed. Closed 25 December 2026. For repairs and bookings call +1 212 555 0146 during opening hours, or email service@example.com . Times are local to America/New_York. Verified 27 August 2026.

This works because the branch, date interpretation, schedule, exception, route purpose, availability, and freshness are explicit. Readers can act while machines preserve each relationship.

Bad

We’re open late! Call us: 555-0146. Holiday hours may vary. Message the team anytime.

This fails because “late” is not a time, the number lacks a country code and purpose, no location or timezone is identified, and the holiday warning gives no dates. “Anytime” makes an undefined promise; structured data would have to guess.

Schema markup and accessibility

For a genuine physical business, the block can feed the most specific applicable LocalBusiness subtype. Regular periods map to openingHoursSpecification, with dayOfWeek, opens, and closes; dated or seasonal overrides map to specialOpeningHoursSpecification, using validFrom and validThrough as required by the range. The visible location and structured entity should share one stable @id so the hours do not become attached to a different branch.

Telephone and email can populate the business entity when they are the primary public routes. Purpose-specific routes may populate contactPoint with contactType, telephone or email, areaServed, availableLanguage, and hoursAvailable when known and visible. Exclude internal departments, personal extensions, tracking numbers, and unmonitored mailboxes.

Exceptions override the regular schedule only for their valid dates. A closure needs an explicit content state and an adapter mapping that follows the selected consumer’s documented representation. Empty strings or omitted dates resemble missing data. Test overnight periods, split shifts, seasonal schedules, and daylight-saving transitions.

Schema is a projection, not an independent source. The block, JSON-LD, map listing, business profile, and action links must agree. If synchronization fails, suppress uncertain derived states such as “Open now” and show the qualified last verified schedule.

Accessibility begins with semantic text. Use a heading, a list or description list for routes, and a table only when day-to-time relationships benefit from columns. Scope table headers, label today in text, keep exceptions available without hover, and expose the keyboard-operable expanded state.

Phone links use normalized tel: values with readable display numbers; email links use valid mailto: addresses. Accessible names describe the action, such as “Call Riverside Repair bookings.” Never trigger calls or email automatically, steal focus, or announce repetitive state updates.

Writing rules

Lead with the location name and current state. When showing a live state, add the next transition: “Open — closes at 17:30” is actionable; “Open now” alone is incomplete. Use local time and state the timezone when readers, staff, or locations span zones.

Show all seven days in the full variant. Combine consecutive days only when every period matches. Write Closed, Open 24 hours, or By appointment rather than leaving blanks. Show both split-shift periods and the starting day for overnight hours.

Publish exceptions as absolute dates and always state the consequence. Show them before they affect readers; remove expired entries after retaining them in the audit log. Seasonal schedules need start and end dates.

Keep the full block to one current-state line, seven daily rows or fewer grouped rows, zero to six relevant upcoming exceptions, and one to four contact routes. Each route label should be one to four words; each qualification should be no more than 40 words. Use calm operational language rather than sales copy.

Never include vague “hours may vary” text without the actual known exceptions, promotional claims, unrelated prices, staff biographies, product stock, appointment inventory, or a general contact form with no purpose or response expectation. Never publish a personal mobile number or employee email without explicit operational approval. Do not say a route is monitored 24/7 unless staffing and escalation procedures make that promise true.

Treat the location-management system as operational truth. Store E.164 telephone numbers, retain readable display formats, validate mailboxes, and record verification. Review before holidays, seasonal changes, relocations, closures, and routing changes; automated comparisons should flag rather than resolve mismatches.

Post types that use it

The postTypes frontmatter field drives this implementation matrix.

QA checklist

• The block names one real location or clearly identifies an organization-level route.
• A stable location ID joins the visible block, operational record, and structured entity.
• Every day has one explicit state, and split or overnight periods preserve their boundaries.
• Times use the location’s IANA timezone and behave correctly across daylight-saving transitions.
• Upcoming holiday, emergency, and seasonal exceptions have absolute dates and override only their stated range.
• Closed, open 24 hours, and by-appointment states are stored explicitly rather than inferred from blank times.
• Each phone and email route has a purpose label and an honest availability or response note when needed.
• Stored phone numbers use E.164, displayed numbers are readable, and every tel: and mailto: target works.
• No personal or unmonitored contact route is exposed without approval.
• The visible block, JSON-LD, business listings, map data, and contact actions agree.
• openingHoursSpecification, specialOpeningHoursSpecification, and contactPoint are emitted only from verified visible facts.
• “Open now” includes the next transition and degrades safely when current-state calculation is uncertain.
• Color, icons, hover, expansion, and JavaScript are not required to understand essential hours or exceptions.
• The verification date meets the organization’s freshness policy, and source mismatches enter an owned review queue.
• Markdown, Hugo, and WordPress examples preserve the same typed schedule, exception, and routes.

FAQ

Should holiday hours replace regular opening hours?

No. Keep the normal weekly schedule and publish each dated exception separately. The exception overrides the regular schedule only for its stated date or range, then expires without requiring an editor to restore the normal hours.

How should a business show that it is open 24 hours?

Label the relevant days as Open 24 hours and store that state explicitly. Do not encode it as 00:00–00:00 in authored content, because that pair is also used by some structured-data consumers to represent closed days and is easy to misread.

Can one hours and contact block cover several locations?

Not as a single undifferentiated schedule. Give each location its own labelled block, stable location identifier, timezone, hours, exceptions, and contact routes. A directory may summarize several branches, but each row must remain attributable to one branch.

Does every contact block need both a phone number and an email address?

No. It needs at least one working route appropriate to the task. Publish only routes the organization monitors, label their purpose, state material response or availability constraints, and provide an accessible alternative when a route excludes some users.

How often should opening hours be verified?

Verify them whenever an operational source changes and before every known holiday or seasonal transition. Also run a scheduled comparison between the website, structured data, location system, and major business listings; the acceptable interval depends on how often the organization changes hours.