What to Update in Cafe Schema and When

Thomas Garner

Oct 7

11 min read

Short answer: schema markup goes stale the same way anything else on a website goes stale, quietly, because nobody assigned themselves the job of checking it. Hours drift out of sync with reality, holiday closures never get added, a menu link points at a page that moved months ago. None of that breaks the site visually. It just means the structured data search engines read no longer matches what a customer would find if they called.

This post is a checklist, not a data study. We looked at what schema.org documents about representing hours, and at what Google's own local business structured data guidance and Business Profile help pages state, and built a twelve item table from that, plus a simple way to score how current a shop's markup actually is. Where something is our own judgment rather than a documented rule, we say so directly.

We are also deliberately separating two different problems that tend to get lumped together. One is whether a shop has schema markup at all, which is a setup question. The other is whether the markup a shop already has still describes the business accurately, which is a maintenance question. This post is about the second problem. A shop can score reasonably well on having markup present and still be quietly wrong about its hours, its menu link, or its holiday schedule, and that gap is exactly what a periodic check is meant to catch.

Why Schema Goes Stale Faster Than a Website Looks Stale

A website can look perfectly current, the colors fresh, the photos recent, the copy sounding like the shop, while the schema markup sitting invisibly in the page code still describes a version of the business that no longer exists. Nobody notices because nobody is looking at the code. Regular hours entered a year ago at setup, a holiday closure that was never added because the original build happened outside of any holiday season, a menu URL pointing at a page that got restructured six months later, none of these show up to a visitor scanning the homepage.

That gap between what a page looks like and what its schema says is exactly why this needs a routine, not a one time setup task. Across the shops in our census work, schema status splits into roughly even bands, with schema entirely absent on some shops, partially present on others, and fully present on a smaller group still, which tells us setup itself is inconsistent before we even get to the separate question of whether existing markup stays current. We are not claiming a stale markup count here, because no field in our data measures freshness after the fact. We are only pointing out that inconsistent initial setup makes it likely that even fewer shops are actively maintaining what they did set up.

The practical fix is not complicated once it is named as a task. It is a short, periodic pass through a defined list of items, checked against the live page and against the Business Profile, rather than an occasional deep audit that only happens when something visibly breaks.

What schema.org and Google's Documentation Actually Say About Hours

Schema.org's OpeningHoursSpecification type is built specifically to represent regular hours, and it includes properties for validFrom and validThrough, which let a business mark a specific hours block as applying only within a date range, plus a closes property for representing a closure. That structure exists precisely so a business can represent both its normal weekly hours and a time bound exception, like a holiday closure or a seasonal schedule change, without contradicting the regular hours block.

Google's own local business structured data guidance describes how search features can use openingHoursSpecification to represent a business's hours, including special hours for specific dates. This is the documented mechanism for representing something like a single day closure for a holiday, distinct from a shop's permanent weekly schedule. Google's Business Profile Help material separately covers how an owner sets special and holiday hours directly inside the Business Profile interface, which is a distinct system from a site's own schema markup even though both should ideally describe the same reality.

That last point is worth sitting with. A shop's schema markup and its Business Profile are two separate places holding the same information, maintained through two separate interfaces. Update one and forget the other, and now a customer searching finds two different closing times depending on which surface they land on. Neither number is technically wrong from the system's point of view, since each was entered somewhere, but together they describe a business that cannot agree with itself about when it closes.

None of this documentation states a required refresh schedule. Google does not publish a rule that says schema must be checked every thirty days or every quarter. What the documentation gives us is the mechanism for representing accurate hours correctly when a shop does sit down to check, which is the foundation the checklist below is built on.

The Twelve Item Checklist

We tested this checklist against a fictional cafe block by deliberately changing three values, a closing time, a holiday closure date, and a menu link, then running each check to see whether it caught the mismatch. All three were caught. Here is the list, with each item marked as either tied to a documented property or a matter of our own practical judgment.

One, regular weekly hours. Documented property: openingHoursSpecification. Check by comparing the schema block against the posted hours on the door or the current staff schedule. Two, holiday and special hours for specific dates. Documented property: openingHoursSpecification with validFrom and validThrough. Check by confirming any upcoming closure or shortened day is represented, not just remembered by staff. Three, phone number. Documented property: telephone. Check by calling the number listed in the schema against what rings the actual shop line.

Four, physical address. Documented property: address. Check against the current lease address, especially after any renovation or suite change. Five, menu URL. Judgment call, not a required property, but a broken or outdated menu link is one of the most common things a schema block gets wrong once a site is redesigned. Six, price range indicator if used. Documented property: priceRange. Check that it still reflects current offerings rather than an old placeholder value. Seven, social profile links represented through sameAs. Documented property: sameAs. Check each link resolves to a live, current account rather than a renamed or abandoned one.

Eight, event listings if the shop uses Event schema for classes or tastings. Judgment call on cadence, documented property on structure. Check that no past event is still marked as upcoming. Nine, logo and image references. Documented property: image. Check the file still resolves and matches current branding. Ten, business name consistency between schema, the Business Profile, and the visible page header. Judgment call, since consistency is not a stated schema requirement, but mismatched naming across surfaces is a recurring, avoidable confusion. Eleven, description text if used. Judgment call, check that it does not reference a closed location, an old owner, or a discontinued offering. Twelve, the overall business type declared, whether CafeOrCoffeeShop or a related type. Documented property: the schema.org type itself, checked against what the business has become, since a shop that added a full food menu or a roastery operation may have outgrown its original type declaration.

A Simple Score and a Judgment Call on Rhythm

We defined the score simply: count how many of the twelve items are current and matching the live page, out of twelve. We tested it against three fictional states. A shop that just launched its schema, with every item freshly entered and matching the live page, scored twelve of twelve. A shop that had not touched its markup in over a year, with an outdated holiday closure still marked as upcoming, a menu link pointing at a retired page, and a phone number changed after a renovation, scored nine of twelve. A shop that had never implemented schema at all scored zero of twelve, which is a different problem than staleness, closer to the setup gap we described earlier.

That score is a way to talk about the state of a shop's markup concretely rather than vaguely, not a metric Google reads or scores against anything on its end. It exists so an owner or a team member doing the review has something more useful to report back than "it looks fine."

On rhythm, we are stating plainly that this is our judgment, not a documented requirement. A quarterly pass, four times a year, lines up naturally with seasonal menu changes and gives enough time between checks that drift accumulates into something worth catching without checks becoming a constant chore. A shop planning a known change, a move, a renovation, a new owner, should run the checklist immediately around that event rather than waiting for the next quarterly pass, since those are exactly the moments multiple items go stale at once.

How Mismatches Actually Show Up in Practice

It helps to walk through what a mismatch looks like concretely rather than abstractly. Take a fictional shop that moved to a new suite two doors down within the same shopping center last spring. The Business Profile got updated within a week, since that is the interface staff check daily. The website schema, sitting in code nobody on staff regularly opens, still carries the old suite number six months later. A customer using a feature that reads schema directly gets the old address; a customer checking the Business Profile gets the right one. Neither system is broken. They simply were not updated together, because updating one does not touch the other.

A second common pattern involves holiday hours specifically. A shop closes for a single day around a major holiday, updates its Business Profile the week before, and never touches the schema block at all, since the holiday closure was never represented there in the first place using validFrom and validThrough. The closure passes, the shop reopens as normal, and nothing about that one day closure was ever reflected in the site's own structured data. This is not really staleness in the sense of an old value lingering. It is closer to a gap that was never filled, which is why the checklist includes holiday hours as its own line rather than folding it into regular hours.

A third pattern shows up after a menu redesign. A shop rebuilds its website, moves its menu to a new page path as part of that redesign, and updates every visible link on the new site correctly. The schema block, generated once during an earlier build and never regenerated, still points at the old menu path, which may now return an error or redirect to something unrelated. Nobody notices during a normal visit to the new site, because visitors follow the visible navigation, not the schema link. It sits quietly wrong until the next scheduled check catches it.

None of these three examples describes a shop doing anything wrong in a moral sense. They describe a completely ordinary sequence of normal business changes, a move, a holiday, a redesign, each handled correctly on the surface a staff member was looking at, while a second, less visible surface drifted out of sync. That is exactly the failure mode a periodic checklist is built to catch, since no single change event reliably reminds anyone to check schema specifically.

Frequently Asked Questions

How often should I update my cafe's schema markup?

Google requires no schedule, so the rhythm here is our judgment rather than a documented rule. A quarterly pass, four times a year, is a sensible baseline because it lines up with seasonal menu changes and catches drift before it piles up. Run the twelve item checklist immediately around any concrete change as well, such as a move, a renovation or new ownership, since those are the moments when address, phone, hours and the menu URL tend to go stale together.

What does schema.org's OpeningHoursSpecification let me represent?

Schema.org's OpeningHoursSpecification type represents regular weekly hours, and its validFrom and validThrough properties let a business mark an hours block as applying only within a date range. A closes property handles a closure. Together they are the documented way to show a normal schedule alongside a time bound exception, such as a single holiday closure or a seasonal change, without the two contradicting each other. Google's local business structured data guidance describes search features reading this structure, including special hours.

Are my schema hours and my Business Profile hours the same system?

No. Website schema lives in page code, while Business Profile hours are set in Google's Business Profile interface, and Google's Help material covers special and holiday hours there as a separate system. Updating one does not touch the other. A shop that moves two doors down and fixes only its profile can still show the old suite number in schema six months later, so a customer can get two different answers depending on which surface they land on.

What is the single most common item that goes stale?

In our testing pass, a menu URL pointing at a page that moved during a later site redesign, and a holiday closure date that was never added or never removed after the fact, were the two easiest mismatches to introduce and the easiest for the checklist to catch. Neither is a documented required property in the sense hours are, but both are common real world drift.

Does Google state a required refresh schedule for schema?

No. Neither schema.org's documentation, including the OpeningHoursSpecification type, nor Google Search Central's local business structured data guidance, both checked September 21, 2026, publishes a required interval for rechecking markup. What they document is the mechanism for representing accurate hours when you do check. The quarterly pass suggested in this post is our own practice and labeled that way, paired with an immediate check around a move, a renovation, new ownership or a redesign that changes page paths.

What items on the checklist are documented properties versus judgment calls?

Regular hours, holiday hours, phone, address, price range, social links through sameAs, and the schema type itself trace to documented schema.org or Google properties. Menu URL freshness, event listing cleanup, logo file validity, name consistency across surfaces, and description accuracy are judgment calls we recommend checking even though they are not required properties in the strict sense.

How do I score my own shop's schema currency?

Count how many of the twelve checklist items are current against what a direct check confirms, out of twelve. We tested this on three fictional states, a freshly launched shop scored twelve of twelve, a shop untouched for over a year scored nine of twelve, and a shop with no schema at all scored zero of twelve, since that is a setup gap rather than a staleness problem.

What should I check first if I just moved or renovated?

Address, phone number if it changed, hours if your new hours differ even slightly from the old location, and the menu URL if your site structure changed during the move. These are the items most likely to go stale all at once around a physical change, which is why we recommend an immediate check rather than waiting for a quarterly pass.

Do I need special or holiday hours in schema if I already update my Business Profile?

They serve different readers depending on which surface someone lands on, so keeping both current is worth the small extra step even though it means updating the same information twice. Since the two systems do not sync automatically, updating only one leaves the other showing outdated hours to anyone who happens to land there instead.

Is there a published penalty for outdated schema?

Google's local business structured data guidance and Business Profile Help material, both checked September 21, 2026, do not state one. The cost of stale markup is practical instead: a search feature or a customer reading a closing time that changed, a holiday closure that was never added, or a menu link that broke in a redesign. In our fictional test, a shop untouched for over a year scored nine of twelve on the checklist, with three live mismatches.

Work with Hillcane

Schema is not something you set once. Hours drift, menus move, holiday closures never get added. Here is a twelve item checklist for what actually goes stale.

If you want your cafe's schema checked against this exact checklist, reach Hillcane at hillcane.co/contact or call (256) 384-2449.