Build · working notes

The website said 6pm. Google said 5pm.

How a seven-brand restaurant group in Singapore stopped relying on good intentions to keep its hours, events and booking links right, and built a small, boring checker instead.

By Lucas Lim Kai Yi, Digital Marketing Executive · 27 October 2026 · 9 min read

A small automated checker now reads every public place where our seven brands publish hours, events and booking links, twice a week, and lists where they disagree. In its first month it caught a bar whose website and Google listing were about to give different opening times. Nobody had to remember to look.

I call it a site truth monitor. It is a reconciliation check, not a change monitor. It compares what each website, Google listing, booking page and link page says with what should be true, and with each other, then hands the team one ranked list of fixes.

I scoped it on 21 September 2026 and built it with Claude Code, Anthropic's coding tool. The first checks ran on 25 September and the first scheduled run was on 28 September. This note covers what it found up to 27 October 2026, and what it still cannot see.

What happened with the bar's opening time?

In late September, our bar's website said its first seating would move to 6pm from 12 October. Google still said 5pm.

Nobody had done anything wrong. Google simply had not been told. It is the kind of gap that sits quietly until a couple turns up at five, finds the door shut, and walks to the next bar down the street.

The checker found it on its first run, 17 days before the change, and wrote one line: update the Google hours by Monday 12 October, or add special hours now. The team changed the listing, and on the next run the line cleared itself.

Why do multi-brand groups drift?

Our seven brands have six websites, nine Google listings, several booking systems, Chope listings, Linktree pages behind the Instagram bios and an online shop. Each is updated by a different person, at a different time, often in a different tool.

Nobody decides to publish the wrong thing. A change is made in one place and not in the four others. An event ends and the page stays up, because taking it down is nobody's job on a Monday. A developer update breaks a layout on phones, and nobody checks on a phone that week.

What does wrong information cost a restaurant?

We have not measured the revenue effect, and this note will not pretend we have. What I can describe is the mechanism.

Trust. In a 2022 survey of more than 1,000 US consumers by the listings company Yext, 44% said they had visited a closed business in the past year because its hours online were wrong. 73% said they were unlikely to return to a business listed as open that turned out to be closed. It is a vendor's survey from another market, so I read it as a direction, not a forecast.

Local search. Google says local results depend mainly on relevance, distance and how well known a business is. It adds that businesses with complete and accurate information, including hours and special hours, are more likely to show up.

Event search. Google's event structured data has four required properties, and the start date is one of them. Without them, a page is not eligible for enhanced event results. On the first run, the brewery's site in our group published all ten of its events without a start date in its structured data.

Answer engines. Google's guidance for AI Overviews and AI Mode asks for normal search basics, including current Business Profile information and structured data that matches the visible page. A tool that summarises our hours can only be as right as the places it reads.

What does the checker actually do?

At 7:45am on Mondays and Thursdays, a scheduled job runs in the cloud. Thursday's run is timed to catch problems before weekend trade.

Event pages. It flags past events still inviting bookings, and warns ahead: “take it down after Sunday”.

Layout. It loads key pages in a real browser at desktop and phone widths and measures them: misaligned cards, sideways scroll, “nothing found” messages where events should be.

Listings and booking pages. It compares Google, two Chope pages and one public booking form with each brand's website: hours day by day, phone, address, events and prices.

Links and products. It checks the Linktree pages for broken or expired links, and compares the brewery's beers with the same beers in our bottle shop on price, strength, bitterness and description.

Everything goes into one private tracker the team opens on their phones. P1 means wrong now, and customers can see it. P2 means likely to mislead or lose a booking soon. P3 is worth a look or a tidy-up.

The checker only reads. It never logs in, submits a form or changes a site. It identifies itself, waits between requests and respects each site's crawl rules. The system flags. People fix.

What has it caught so far?

Hours that disagreed. On the first run, Google showed our bottle shop open noon to 6pm, Tuesday to Saturday, closed Monday. The website said noon to 5pm, Monday to Saturday. That was a P1: open in one place, closed in the other. Google also showed the main restaurant open all afternoon from Thursday to Saturday, with no break between lunch and dinner.

Booking platforms with their own version. On the first Chope run, on 27 October, the brewery's page showed Tuesday as closed, opened half an hour early and gave a different phone number from Google. A restaurant's page showed one long opening every day, where Google and the website had separate lunch and dinner shifts.

Notes not meant for customers. A booking form showed a staff note above its events: “... to go up on 1st nov for public ...”.

Links that went nowhere. On the first Linktree run, the brewery's link to its beer list led to a page that did not exist. One letter was missing from the address. The link was corrected.

Small typos. A footer spelt a road name with “Getaway” in place of “Gateway”. A Chope description ended with the year “(Apr 2626)”. A homepage font was requested from a misspelled copy of our own domain. That one was harmless, as a backup loaded, so the checker now calls it a tidy-up.

Layout that broke. In September, after a developer update, the event cards on the brewery's homepage were out of line. Every word was correct, so a content check would never have noticed. That is why the layout check exists.

One thing it did not find: price gaps on the shared beers. The first product run, on 8 October, matched them on both sites. The real gaps were beers listed on one side and not the other.

How does a small team use the tracker?

Each item shows its severity, page, evidence and what to do. Anyone can set a status and add a note, or report something spotted by eye. A Coming up list shows dated events in the next 14 days, so changes are planned before the date. A Run check now button starts an extra run on demand. With several brands and several sites per brand to read, it takes around 15 minutes.

The Fixed log records when each problem stopped being found and how long it was open. If someone marks an item fixed but the next run still sees it, the tracker says so. An export gives management a spreadsheet or printable summary, which makes the work visible in a way “we tidied the website” never was.

What can it not see, and how does it avoid false alarms?

A checker that cries wolf gets ignored, so much of the work since has gone into removing false alarms.

Unverified is not confirmed. If the checker cannot see something properly, it says so and keeps the item at low priority. The first content run over-reported three items that sat in a site's data but were hidden on the page. Now only words a visitor can see count as confirmed.

Busy is not broken. In late September the bottle shop's site was reported as failing to load. It was not: a bot check kept the network busy while the checker waited for silence. It now gives a page fifteen seconds to settle, then checks it as it is. In late October the same site refused the checker's browser while a plain request worked. That is now a low-priority “could not be checked”, not an outage.

Sold out or unbookable? One booking system cannot tell a sold-out day from a day with no time slots. So a P1 “can't be booked” became a P3 “may be sold out”.

Renamed products. When the brewery renamed its beers, ten false product flags appeared. After the name matching was fixed on 19 October, they were gone.

Done on purpose. Three listings leave a phone number off Google deliberately. These are recorded as accepted gaps with their reasons, so they stop coming back.

How was it built?

I built it with Claude Code, running entirely in the cloud, with nothing installed on anyone's computer. Google was in the first checks. Products followed on 8 October, Linktree on 19 October and Chope on 27 October.

The key design choice was to keep the AI out of the judging. Every rule is plain code with unit tests, so it gives the same answer every time. Claude writes and runs that code and summarises the results, but it does not look at pages and decide by eye. That keeps runs cheap and predictable, and every flag traces back to a rule and its evidence.

Every decision and mistake is logged in one scope document with a dated revision history. I have not put a cost figure on the build. It was planned as part-time work, two to three focused hours per working day, and the scheduled runs need nobody's time until there is something to fix.

How could another group start?

Start with the check that would hurt most. Pick one source of truth per fact, such as the website for opening hours, and check the rest against it. Start with dates: past events still inviting bookings are easy to find and plainly wrong. Check where customers click. The bio link and booking button matter more than a page three levels deep.

Agree severity first, or everything becomes urgent. Plan for false alarms by marking what you cannot see as unverified and letting people record “this is on purpose”. Keep a fixed log. It is the part management reads, and it keeps the habit alive.

Questions people ask about it

Did it increase bookings? We do not know, because we did not measure it. What we can show is a dated list of problems found and cleared.

Will correct hours improve local ranking? Google says complete and accurate information makes a business more likely to appear in local results, and that a better local ranking cannot be bought. I have not measured any ranking change from these fixes.

Boring on purpose

Nothing in this system is clever. It reads pages, compares a few facts and writes a list. That is the point.

Good intentions do not run on Monday mornings. A quarterly website audit finds what is wrong on the day of the audit. A small, boring checker finds it on Monday and again on Thursday, and it does not get tired of looking.

The bar's opening time was a five-minute fix. The hard part was knowing it needed fixing.