Google GEO Contact Content: Service Hours Are Not Website Availability

A contact page that loads at any hour is a document, not a staffed channel. This note separates the two using the documented meanings of ContactPoint, hoursAvailable and OpeningHoursSpecification, then gives a reading order for weekly schedules, overnight ranges and date-specific exceptions, and a buyer check that ends with a direct question to the provider rather than an assumption about staffing.

The page that never closes is not the channel that answers

A contact page that loads at 3 a.m. proves one thing: the web server answered. It does not prove that anyone is at a desk, watching a shared inbox, or able to pick up the phone. Those are two different objects, and the vocabulary treats them as two different objects.

schema.org defines a ContactPoint as "a contact point—for example, a Customer Complaints department" ( https://schema.org/ContactPoint ). Separately, it defines hoursAvailable as "the hours during which this service or contact is available" ( https://schema.org/hoursAvailable ). One term names the channel; the other names the window in which that channel is available. Neither term describes the website.

That is the separation rule to apply before you trust a phone number or a form. Page reachability is a hosting fact. Channel staffing is an operating fact. A page that never closes tells you nothing about the second, and a page that does state hours is making a claim about the channel, not about the site.

Source reference

Which field actually carries a channel’s hours

If a page does state hours, the field to look for is hoursAvailable, and its scope is narrow. It is defined as the hours during which this service or contact is available, and its expected value type is OpeningHoursSpecification ( https://schema.org/hoursAvailable ). It is used on ContactPoint, LocationFeatureSpecification and Service ( https://schema.org/hoursAvailable ).

Read that list of types carefully, because it is the whole point. The field attaches to a contact point, a location feature, or a service. It does not attach to the website as a whole. A site-wide banner reading "open 24/7" is not the same statement as hoursAvailable on a specific contact point, and the two can coexist while meaning different things.

The official example shows the shape this takes in practice: hoursAvailable attached to a LocationFeatureSpecification, with an OpeningHoursSpecification value carrying dayOfWeek, opens and closes ( https://schema.org/hoursAvailable ). The hours belong to the feature being described, not to the page that describes it.

The relationship runs both ways. OpeningHoursSpecification lists hoursAvailable among the properties that may take it as a value, on ContactPoint, LocationFeatureSpecification or Service ( https://schema.org/OpeningHoursSpecification ). So when you find a schedule block, the question to ask is which contact point or service it is bound to.

Source reference

Reading a weekly schedule and its exceptions

OpeningHoursSpecification is "a structured value providing information about the opening hours of a place or a certain service inside a place" ( https://schema.org/OpeningHoursSpecification ). Its properties include closes, dayOfWeek, opens, validFrom and validThrough ( https://schema.org/OpeningHoursSpecification ). A useful reading order follows the properties rather than the visual layout.

Start with dayOfWeek, because it tells you which days the block covers. Then read opens and closes as the daily window. Two rules govern the edges. The place is open if the opens property is specified, and closed otherwise ( https://schema.org/OpeningHoursSpecification ). And if the value for closes is less than the value for opens, the hour range is assumed to span over the next day ( https://schema.org/OpeningHoursSpecification ). That second rule is the one readers miss: a block that opens late and closes in the early morning is not a typo, it is an overnight window.

Then check whether the block is general or dated. validFrom and validThrough mark the period in which the entry applies, and specialOpeningHoursSpecification is used to explicitly override general opening hours brought in scope by openingHoursSpecification or openingHours ( https://schema.org/OpeningHoursSpecification ). The official example shows the pattern: a general openingHours line for the normal week, plus dated OpeningHoursSpecification entries using validFrom and validThrough for date-specific exceptions ( https://schema.org/OpeningHoursSpecification ).

Hypothetical illustration, not a real provider or measured outcome. Hypothetical schedule, not a real provider: a support line carries a general weekly block, and a separate dated entry narrows the window on a public holiday. A reader who stops at the general block will assume the holiday follows the normal week. The dated entry is the one that answers the question they actually have.

Matching hours to the right channel

A schedule is only useful once you know which channel it belongs to. contactType is the property that specifies the kind of contact point, and schema.org notes that a person or organization can have different contact points for different purposes, giving a sales contact point and a PR contact point as examples ( https://schema.org/ContactPoint ). Different purposes can carry different hours.

Two more properties describe the channel without describing its schedule. contactOption is "an option available on this contact point (e.g. a toll-free number or support for hearing-impaired callers)" ( https://schema.org/ContactPoint ). availableLanguage is "a language someone may use with or at the item, service or place," with IETF BCP 47 codes recommended ( https://schema.org/ContactPoint ). Neither one is a statement about when someone is present.

The official example 3 illustrates the shape of a multi-channel contact list: several contact numbers for one company, including US toll-free numbers, a hearing-impaired number, and several contact categories ( https://schema.org/ContactPoint ). When a page looks like that, hours read as attached to a specific contact point rather than to the company as a whole.

Hypothetical illustration, not a real provider or measured outcome. Hypothetical contact list, not a real provider: a page shows a sales line, a support line and a general inbox. The support line carries a stated window; the sales line and the inbox carry none. The correct reading is that the support channel has stated hours while the other channels have unstated hours, not that the company is reachable whenever the support line is.

What the vocabulary does not tell you

The vocabulary defines fields, not staffing. Nothing in hoursAvailable, OpeningHoursSpecification or ContactPoint states a timezone, a response time, or how many people are on duty. A well-formed schedule can be complete as markup and still leave the reader’s actual question unanswered.

The neighbouring properties do not close that gap either. areaServed is "the geographic area where a service or offered item is provided," and it supersedes serviceArea ( https://schema.org/ContactPoint ). availableLanguage describes languages ( https://schema.org/ContactPoint ). contactOption describes options such as toll-free or hearing-impaired support ( https://schema.org/ContactPoint ). Coverage, language and channel options are all useful facts, and none of them is a staffing guarantee.

The official example 1 shows how much detail a page can carry without settling the question: it describes a GovernmentService with a Veterans Crisis Line, including phone contact line hours of operation, language and other details ( https://schema.org/ContactPoint ). That is a rich, well-specified contact description. It still does not tell a reader whether a human will answer at a particular moment.

So the unknowns to carry forward are concrete: the timezone the stated hours refer to, the expected response time for the channel you intend to use, and whether the channel is staffed by a person or handled asynchronously. Those values have to come from the provider. They are not in the markup, and no amount of careful reading will extract them.

A practical check before you rely on a contact channel

Run these steps in order, and stop at the first one that fails.

Read the page for a channel-specific hours statement, and check whether it is attached to the contact point you intend to use. A schedule bound to a different channel does not answer your question.

Check whether the stated hours include a timezone or a reference to your own location. If they do not, treat the timezone as unstated rather than assuming it matches yours.

Check whether exceptions are stated for the date you care about, using the validFrom and validThrough properties and the specialOpeningHoursSpecification override ( https://schema.org/OpeningHoursSpecification ). A general weekly block is not a statement about a holiday.

If the page does not state channel-specific hours, ask the provider directly for the hours, the timezone those hours refer to, and the expected response time of that channel.

Do not treat the presence of a form, a phone number, or a page that loads at any hour as evidence that the channel is staffed. Those are availability facts about the page, not about the people behind it.

For the adjacent question of how a provider’s delivery model changes what you are buying, see GEO Service Area Content: Reading Remote and Onsite Delivery Boundaries .