Restaurant and cafe websites: menus, bookings and the pages that fill tables

A restaurant or cafe website should make the current menu, opening hours and location easy to find. Then it should make the next step easy, whether that's booking a table, getting directions or ordering pickup. Build those journeys on accurate details and a process your staff can keep up.

Start with what diners need to do

Different venues have different main jobs. Someone deciding where to eat tonight needs the menu, hours and a way to book. Someone planning a group dinner next month needs capacity, packages and a person to talk to.

These are example priorities, not measured rankings. Here's a fuller planning comparison, including function venues:

Your diners may care about different things depending on the occasion. For the wider build, see what a business website needs.

Build a homepage around real diner tasks

The homepage should say what kind of venue you are, where you are and how you serve. Then it should point to the next action. Keep real hours and directions visible. Don't hide them behind an animated introduction.

It's a fictional planning structure. For a takeaway venue, ordering replaces the booking button. Not every link needs equal weight, so give the most prominence to your venue's main tasks.

Use labels that say what happens next. "View menu" and "Book a table" work when they match the real task. So do "Order pickup" and "Get directions".

Here's a fictional example of a useful opening line. "Wood fired pizza and natural wine in Fitzroy, open for dinner from Wednesday to Sunday." It names the food, the place and the service in one go. Check every detail against the real venue before anything like it goes live.

Publish and maintain a readable menu

Make the main menu readable web page text. Use clear sections and item names with short descriptions. Show current prices, explain any dietary markers and note items that change.

That comparison is about one specific setup, not every PDF. Google lists PDF as a file type it can index. A clean PDF can work as a download. A scanned image of a menu is harder to use. A messy web page can fail too.

So check the result, not the file type. Check headings, text resizing and contrast. Then check keyboard use and how dietary labels are explained. We recommend a web page menu for the customer task and easier upkeep. It isn't a ranking promise.

A common mistake is updating the printed menu and forgetting the website, the booking widget and Google.

Keep every menu in step

Menus live in more places than most venues track. Use one approved source and push changes out from it:

Don't assume these systems sync themselves. Check each public output after every change, from the ordering platform to the printed copies.

Google's tools can help, with care. Google's menu editor can import items from a menu photo or PDF using AI. It labels that feature experimental. Treat the result as a draft and check every name, price and dietary detail. Changes can take 24 to 48 hours to show on Maps and Search.

Dietary information and allergy requests

Dietary labels aren't interchangeable. "Gluten free" promises more than "gluten free option". Neither tells a customer the dish suits their particular allergy. Verify ingredients, preparation and each claim before you print it.

FSANZ's allergen guidance covers food that doesn't need a label, like cafe meals. Required allergen declarations must be displayed with the food or provided on request, using the required names. A generic "may contain traces" line doesn't replace staff who can answer accurately.

Tell customers how to ask about an allergy before they order. Then make sure the question reaches someone who can answer it. Ticking a dietary box on a form doesn't confirm the kitchen can meet the request.

Make booking work through to confirmation

A booking flow should collect what the venue needs and nothing more. Usually that means the date, time and party size. Add contact details, plus seating choices or requests where they're relevant. Show the conditions before the customer commits:

• any deposit or card hold, and when it's charged

• minimum spend or set menu requirements

• how long the table is held for the booking

• cancellation and no show conditions

You can embed a booking tool or link to the provider's page. Test whichever you choose on a phone, with a keyboard and with a screen reader. Try it on a slow connection too. A clearly labelled external journey can work well. An embed isn't automatically faster, more private or more accessible.

After you check the status, the booking is either confirmed or it needs follow up. A request or a waitlist spot isn't a confirmed reservation. The confirmation should say which it is. If you take a deposit or card hold, tie it to that status. A hold on its own doesn't confirm the table.

W3C's forms tutorial says to tell people clearly when a task succeeds or fails. A good confirmation shows:

• the status, in plain words

• the venue, date and local time

• the party size for the booking

• what happens next, and how to change or cancel

A common mistake is running two booking systems that both think the same table is free.

When booking goes wrong

Plan for failures before they happen:

Tell customers how to check their status before submitting again. Never suggest charging a card repeatedly to test whether a booking went through.

When you're full, offer real alternatives, like other times, other dates or a waitlist. A phone number and honest walk in guidance help too. None of them promises a table. Urgent contact options should match the staff you have on.

Access and allergy requests need a defined response process. A field that records a request isn't acceptance of it. Keep these details out of marketing analytics, URLs and general event labels.

Keep hours and visit information accurate

Hours are several facts, not one. These can all differ:

• regular service hours and any split service

• kitchen closing time

• coffee only periods

• public holidays and planned closures

Use verified facts only. A generic wheelchair icon isn't evidence of your arrangements. Describe the real arrangements.

If you run more than one venue, give each location its own page. Each page needs that venue's own details, from the menu to the booking link. Let customers choose the venue before they book or order. Keep that choice visible. Don't assume one menu applies everywhere.

Make the phone number a labelled, tappable link. Add entrance details and a directions link. Useful transport or parking notes help too. A map embed is optional. For more on calls, see making website phone contact easier.

Name an owner and a backup for urgent changes. When hours change, check every place they appear:

• the website and any active promotion

• booking availability and online ordering

• your Business Profile

Date a temporary notice, then remove it when things return to normal.

QR menus need a fallback. Print an ordinary web address too. Offer a paper menu for anyone who can't scan or doesn't have data. Keep the QR destination under your control. Check it whenever a platform changes.

Use photography without breaking mobile tasks

Use real photos of what you offer. Useful shots include:

• the food as it's served

• the room, the seating and the entrance

• any function space you hire out

Get permission from anyone identifiable. Don't show a dish, space or access arrangement you can't offer.

Optimise images without slowing the first screen. Use sensible dimensions and compression. Serve images sized to each screen, in modern formats where they're supported.

Give informative images useful alt text. Decorative images can have empty alt text, as W3C's image guidance explains.

Lazy loading delays images until they're needed. Don't use it on the main image at the top of the page. Google's web.dev guidance says never to lazy load the largest image people see first.

Test the essential tasks on real phones. Start with the menu, hours and directions. Then try booking, calling and ordering.

Keyboard use and zoom need testing too, along with error recovery and any third party steps. A one thumb test isn't a full accessibility review. For the full picture, see website accessibility in Australia.

When the site feels slow, look at the heavy extras first. Common suspects include:

• autoplay video and large galleries

• map embeds and social feeds

• booking or delivery scripts

• custom fonts loaded on every page

Essential details should still work if an optional feature lags. For the fixes, see diagnosing website speed problems. Only look at Australian website hosting options if hosting is the bottleneck.

Use your own device and task data. A high mobile exit or bounce rate can include people who found the hours and left happy. It can also include people handed off to a booking provider. Neither proves you need a redesign. Our guide to understanding website exits and bounce rate explains the limits.

Watch sticky controls too. A big booking button doesn't help if it covers the menu price or the conditions someone needs. WCAG 2.2 also expects keyboard focus not to be entirely hidden by content like this.

Make ordering and provider costs clear

Give each ordering route its own clear label. Pickup, delivery and dine in ordering each work differently. So do catering and third party marketplaces. For each route, state:

• the location, service area and times

• any minimum order and fees

• stock limits for popular items

• who handles problems when they happen

What happens after someone presses order matters as much as the button. These are separate states:

• payment authorisation, a hold on the card

• payment capture, the actual charge

• order acceptance by the venue

• kitchen receipt and completed service

Tell the customer what actually happened. Give staff a way to reconcile an order that was paid but never reached the kitchen.

Not every provider handles these the same way:

Compare provider quotes fairly

Compare quotes using the same order and booking assumptions. Check every cost:

• setup, subscription and support

• per cover, per booking or commission charges

• payment processing and SMS fees

• point of sale (POS) integration costs

• taxes, minimum term and exit costs

Check whether a "cover" means a person or a reservation. Check whether charges depend on where the diner found you or whether they turned up.

OpenTable's Australian plans page, checked in October 2026, shows why this matters. On two plans, it charges cover fees only for diners found through its site, app or affiliates. It also says you only pay for seated diners. Recheck the actual plan and contract. Ask for the Australian offer in Australian dollars, with GST stated.

A simple worked example helps. These figures are examples, in Australian dollars, excluding GST and not a market rate:

Only compare like with like. A quote that counts covers differently or leaves out payment fees isn't comparable.

A common mistake is comparing a quote with commission against one without, as if they cost the same.

Own your accounts and plan the exit

Record which legal entity owns the merchant and booking accounts. Note who can administer them and how access gets recovered. Before signing, ask about data export, retention, integrations and how links get replaced. Linking to a service doesn't make all its customer data yours.

Providers change, and some leave. When we checked in October 2026, Menulog's Australian site simply said "Menulog is closed". Keep a working alternative ready during any supplier change. Update every link and QR code as you go.

A direct ordering channel can change your fees and the customer experience. It isn't automatically cheaper overall. Count the setup, staff time and support involved. Then weigh marketing and payment costs against your real order volume.

Give functions and groups a useful path

Group and function enquiries need their own route. Show what you can offer:

• seated and standing capacity for each space

• whether spaces are private or semi private

• packages, minimum spend and food and drink options

• facilities, access details and current photos

Keep the enquiry form short. Ask for the date, approximate group size and event type. Then ask for reply details and any relevant requirements. Say when you'll respond and whether an enquiry holds anything. Don't force a large event through a table booking widget that can't handle it.

Each stage means something different to the customer. Publish conditions that match the actual contract and any legal review. Don't make up a cancellation fee. A disclosed fee isn't automatically enforceable either.

Function enquiries can differ in value, capacity and lead time. Let your own records decide how prominent they should be. For the form itself, see designing a function enquiry form.

Show prices and charges correctly

Card surcharges changed on 1 October 2026. The change works through card network rules, not a single law enforced by the RBA against venues.

The RBA's FAQ says surcharging stopped on eftpos, Mastercard and Visa from 1 October 2026. American Express and UnionPay also removed surcharges from that date. PayPal's rule took effect on 5 October 2026.

The RBA doesn't regulate venues directly. The networks set the rules. Your payment provider applies them. The FAQ also notes the networks' rules can change, so recheck before you publish.

Check every place a payment happens, not just the terminal on the counter:

• online ordering and booking deposits

• POS integrations

• payment provider settings

Renaming a card surcharge doesn't make it allowed. The ACCC warns that relabelling one as another fee may be misleading.

Weekend, holiday and other fees

The card change doesn't ban every other fee. As that FAQ notes, weekend and public holiday fees aren't payment surcharges. Nor are booking or service fees. They still have to be displayed correctly.

The ACCC's price display rules require a total price that includes GST and any unavoidable or preselected fees. Hospitality venues have one exception for surcharges on specified days. The menu must say "A surcharge of [percentage] applies on [day or days]". Those words must be at least as prominent as the most prominent price on the menu.

Here's an example, not a recommended surcharge. A $40 dish with a properly disclosed 10% Sunday surcharge costs $44 on a Sunday. That example says nothing about card surcharges.

Everyday fees belong in the menu price. Don't use the weekend exception to hide an everyday charge. Keep these clear wherever they apply:

• deposits and minimum spend

• cancellation conditions

• corkage and delivery charges

For the wider consumer law, see drip pricing and misleading website journeys.

Check privacy and alcohol sale obligations

Start by checking whether the Privacy Act covers your business. The OAIC's small business guidance sets out the turnover test and its exceptions. Then map the personal information your site handles, such as:

• names and contact details

• booking records and event details

• dietary or access requests

• anything passed to payment providers

Check who can access it, how long you keep it and whether any goes overseas. Make sure your policy or notice matches. The wording itself sits with our guide to privacy notices and booking terms.

Dietary and access requests can reveal health information. Collect only what you need and route it to the right staff. Keep it out of analytics, ad pixels and public URLs. Keep marketing permission separate from booking confirmations.

Alcohol rules start with your state or territory, your licence and how you sell. A dine in venue's information page and an online alcohol ordering service can carry different obligations. Your website can't authorise a sale your licence doesn't allow.

Take Victoria as an example:

The Victorian Government's guidance covers alcohol delivery and pickup orders. Two website rules stand out. The licence number must appear clearly on the website or ordering platform. The prescribed warning must appear where customers place their order. Use the current wording from that page rather than an old copy.

There's more to it than the website. Most licensees must notify Liquor Control Victoria before taking these orders. First time customers must confirm they're 18 or older. Deliveries have time and handover rules too.

An age gate on its own isn't a compliance process. Check every ordering and delivery duty with your regulator. Other states and territories need their own checks, not a copied Victorian footer.

Connect the website with Search and Maps

Some diners decide straight from your Business Profile without visiting the site. Keep every profile detail accurate. Recheck hours and menu or booking links whenever anything changes. Google's guidelines for restaurants say to use the hours when diners can sit down and eat. Menu links can't point straight to a third party ordering service.

Here, shared means you and the booking or ordering provider. The map shows who's responsible, not data that flows automatically between platforms.

Google can show menu details from your website, uploaded menus and other sources. Review your preferred menu and flag outdated customer menu photos through the profile tools. Editing your website doesn't prove every displayed menu has changed.

Structured data

Structured data helps search engines read your details. Use the Restaurant type or another fitting LocalBusiness subtype. Include the location page, address, phone and hours, plus the menu URL. Google's LocalBusiness documentation says it doesn't guarantee that features using the markup will show.

Markup must match what's visible on the page. It can't create availability or take bookings by itself. Reviews a business controls about itself aren't eligible for review stars on LocalBusiness or Organization markup. That includes embedded third party widgets.

Our local business schema generator is a starting point, then validate the result. For the concepts, see how structured data works. For acquisition, see local SEO for restaurants and managing Google Business Profile.

Measure results and run the final checks

Website actions and real outcomes are different things. Define each one separately:

A click is a useful signal of intent. It isn't a diner, an order or a sale. Google's own Business Profile metrics count call button clicks and direction requests, not visits.

These numbers are examples. Completion is 22 ÷ 30, or 73.3%. The no show rate is 3 ÷ 30, or 10%, against all reservations. Against the 25 that weren't cancelled, it's 3 ÷ 25, or 12%, so always say what you're dividing by. Parties aren't covers either.

Break results down by page or device only where events match reliably and privacy allows. Don't divide total website booking clicks by every provider reservation and call it a conversion rate. Note in your report where bookings move to a provider's site and tracking stops. For setup, see setting up Google Analytics 4.

A common mistake is reporting booking clicks as bookings, then wondering why the numbers never match the provider's.

Before launch, or after a big change, run these checks:

Mark anything unresolved and give it an owner. A high score can't hide a failed order or a wrong price. Our general website audit checklist covers the rest of the site.

What we recommend at Elev8d

Frequently asked questions

Next steps

Pick the situation that fits your venue.

Written by Ajay K.Co-founder, Elev8d

Ajay is the co-founder of Elev8d and writes most of what you will read here. Psychology grad turned marketer, which is a fancy way of saying he cares about why people click, not just where things rank. Every guide is written in plain English for Australian businesses, tested on real campaigns before it earns a spot on this site.