Websites for restaurants: get found at the moment someone is hungry

Nobody researches a restaurant. Someone stands at a tram stop at half past six, types "food near me" into their phone and looks at three results. Whatever is not answered in those seconds does not get asked about, it gets swiped away.

Exactly three things have to be answered, in this order: are you open now. What is there to eat and roughly what does it cost. Can I get a table. Everything else, the history of the house, the team, the philosophy, matters for the brand and is irrelevant to that one minute. It belongs on the site, just not in front of those three.

So we build restaurant sites from the bottom up: the three answers first, then everything that makes people want to come back.

And the one most often wrong. The website shows last summer’s hours, the Google profile shows a different set, and Instagram has a Tuesday story saying you are closed for the holidays. In the end the guest trusts none of the three and goes somewhere else.

That is not a copy problem, it is a process problem. We maintain the hours in one place, hand them to Google in a structured form and build the exceptions in from the start: public holidays, annual closures, the rest day, the kitchen that shuts before the bar. When something changes you send us a message, or you change it yourself, whichever you prefer.

Some of your guests are happy to phone, others never phone and would rather book at eleven at night. Both should end up at a table, so both belong on the page: the number as a tappable link, so a call is one tap, and a booking option for everyone else.

Which version is right depends on your operation. An existing reservation system we integrate. Where there is none and none is needed, a short form is often enough, landing in the right inbox and asking what you would ask anyway: how many people, when, allergies, a high chair. Anyone who sees a confirmation after sending does not phone again just to be sure.