Built around the two minutes before someone books, and the ninety minutes between prep and doors

The running order follows the decision, not the design brief: status and booking first, menu second, photos third, the story about the chef last if at all. Most restaurant sites invert it, with a video hero and a paragraph about provenance ahead of the one thing anyone came for.

Nobody opens a restaurant website wanting to read. They arrive mid-decision, with a group chat open in another tab, and if the four facts they need aren't above the fold they close the tab and try the next result.

This matters more here than on any other site we build. A builder's portfolio goes stale over months and nobody notices for a week. A restaurant's menu goes stale over hours, and the only window to fix it is the ninety minutes when nobody is opening a CMS to find the block and clear the cache.

No ticket, no queue, nobody to chase. You send the message, it changes everywhere it's shown, and the site is still yours.

Say the corkage too, and say whether it's per bottle or per person. A group of eight deciding between two restaurants will pick on corkage, and the venue that published it wins the booking by default.

If you're licensed, say what that means in the diner's words: a wine list online, cocktails, local beer on tap, a non-alcoholic list that isn't just lemonade.

Australian states license differently, so the page states your venue's own licence rather than a national rule. Run more than one venue: the licence line sits on each venue's own page, because it can differ between them.

Walk-ins only is a position, not a gap. Say it plainly: walk-ins only, a few seats held at the bar, come early on Fridays. That converts better than a booking widget you can't honour.

Take bookings by phone: use a tel: link so it dials with one tap, and publish the hours the phone is actually answered.

You keep the platform you already pay for. We build the page around it rather than asking you to move. Large groups get routed to the functions page, not squeezed into a two-top widget.

Tell us what you run on a 15-minute call, between services if that's easier, and we'll say plainly whether it embeds, needs the API, or is better left as a phone number.

Name which apps you're on and which suburbs each one delivers to. 'Do you deliver to Grey Lynn' is a real search, and right now the answer is buried three screens into an app.

Keep the delivery menu and the dine-in menu visibly separate wherever the prices differ, and say so on the page rather than letting someone find out at the door.

The working sentence does most of it: tell us when you book and we'll tell you honestly what we can and can't do. That does more for a nervous diner than any icon set, because it names a kitchen willing to give a straight answer.

If you're building a cafe site alongside this one, the wording the law requires for food sold over a counter is set out on the cafe page: /websites-for-cafes. That's a display requirement for unlabelled food at a counter, which is a different situation from a table booking taken in advance.

The room during service

Shows the room as it will actually look when someone arrives, not staged and empty.

A two-top and a long table

A couple and a group of ten are choosing different things from the same photo set.

The bar

Tells a solo diner or an early group whether there's somewhere to wait.

The outdoor area, shot honestly

Covered or not decides a winter booking; an optimistic angle just loses the booking later, at the door.

The six dishes you actually sell most

What's ordered, not what the kitchen is proudest of, is what should be photographed.

Alt text naming the dish and the venue

Not 'food' or 'image1'. It's how the photo gets found, and how a screen reader reads it.

The date moves when the content moves: it's set by the same message that changes the menu, not by a separate task someone has to remember.

A stale-looking page reads as a closed kitchen even when the doors are open. The date is the smallest fix with the biggest effect on that assumption.

The practical list for a restaurant: name the suburb and the nearest landmark, name the cuisine the way people say it rather than the way a menu designer would, name dietary options explicitly, put a price range in text per head, keep the updated date visible, and write the FAQ in the diner's words.

Nobody can promise a ranking or a citation, and anyone who does is guessing or selling. The honest commitment is to do everything known to help and nothing known to hurt, which includes never marking up a review that wasn't given, or a menu that isn't actually on the page.

Each venue's page carries its own licence line, its own last orders, its own functions calendar and its own photos. A group brand identity can sit above all of it, but the facts that matter to a booking are set per venue.

If the venues share a kitchen or a booking system, say so once, in the place it's actually true, rather than repeating it on every page.

What moves the scope for a restaurant specifically: how many menus you run (dine-in, drinks, functions, delivery, seasonal), whether your booking platform needs an embed or an API, and whether each venue needs its own page, its own hours and its own licence line.

The part most studios leave out: we haven't built a restaurant site yet. Where we have built, and the client list, sits on the cafe page rather than repeated here: /websites-for-cafes. If what you want is a studio that can show you five restaurant sites, that's a fair thing to want, and you should go and find one.

What we can show you is the product working, in 15 minutes, on your own menu. You change something, you watch it change, and you leave the call knowing which build your venue needs and what it comes to.