Restaurant and Cafe Website Design

A restaurant website works inside a decision that takes a few minutes on a phone: are you open, what do you cook, how do I get there, can I get a table. When the site answers those questions quickly, guests come; when it does not, the decision moves to a delivery app listing or to the place next door.

This guide follows the decisions a restaurant, cafe or bistro owner makes during a website project, in the order they usually come up. Each section gives you a checklist, a criterion or a question to put to an agency, from turning the menu into text and printing QR codes to ordering routes, your Google Business Profile and measurement.

01The four questions your first screen must answer

The first screen of a restaurant website should answer four questions before the guest scrolls: are you open right now, where are you, what kind of food do you serve, and how do I get a table or place an order. If one of these is missing, the guest goes back to search.

In practice that means a short description of your cooking, today's hours and two clear buttons, not a slogan squeezed under a huge photo of the dining room. Sliders and intro videos push this information below the fold on a phone.

• Status line: one line such as "Open today from 8 am to 11 pm" that updates itself by weekday and on holidays.
• Cuisine line: a single sentence such as "Wood fired Neapolitan pizza and natural wine" that uses the words guests type into search.
• Location: the neighborhood and directions that open with one tap, with a note on parking or transit right beside it.
• Two main buttons: view the menu, and call or message; a third button only if you take takeaway or delivery orders.

At the design presentation, ask your agency one question: can I see these four things on a phone without scrolling? If the answer is no, the layout needs rework, however polished it looks.

02Turning the menu into text and writing descriptions

Moving the menu from a PDF to real text is the most labor intensive part of a restaurant website, and it pays back every week afterward, because an update takes minutes instead of a new file. Start it before design work, since the layout depends on how long the menu really is.

1. Collect the source: the printed menu, recent Instagram posts and what the kitchen actually cooks rarely match; agree on one current list.
2. Simplify categories: follow the order guests think in, such as breakfast, starters, mains, desserts and drinks; too many categories get lost on a phone.
3. Write each dish: the name guests would search for, a one sentence description, and markers such as vegetarian, vegan or spicy.
4. Check allergens with the kitchen: name one person responsible for changing the marker whenever a recipe changes.
5. Test the panel: before launch, hide a dish and bring it back with your team, so everyone sees how long an update takes.

A useful description answers what a guest would otherwise ask the server: what is in it, how is it cooked, is it for sharing. Words like "delicious", "signature" or "special sauce" answer none of this. "Braised short rib, six hours in the oven, with creamed polenta and pickled shallots" covers ingredients, method and sides in one line.

Keep regional names and explain them: under "Shakshuka", add eggs poached in a spiced tomato and pepper sauce. Read the descriptions with your chef; a sentence the kitchen did not approve becomes a promise someone has to correct during service.

03Allergens, prices and the rules behind your menu

Whether prices appear on the public website is a business decision; allergen information is not, wherever the law requires it. In the UK, official guidance says that for non prepacked food sold online or by phone, allergen information must be available free of charge before the purchase is concluded and again at delivery.

Outside the UK the details differ, so treat the website as the place where allergen information is complete and easy to find, then confirm local requirements with your food safety advisor. On prices, decide early: if the QR code on the table opens the same menu as the public site, that page is the price list guests rely on, and it has to match what you charge.

• Is allergen information on the menu page itself or one clear link away, never inside a PDF?
• Does every dish show the same markers on the website, the QR menu and any ordering page?
• Who updates prices, and do the printed menu and the online menu change on the same day?
• Is a printed menu ready for guests without a phone or who simply prefer paper?

We build the allergen section into the menu structure; the data and final compliance stay with your kitchen. If you change prices often, ask during the quote stage whether the panel supports bulk updates by category.

04Planning the table QR code before you print

A QR code should point to a menu page whose address never changes, not to a file. When the code leads to a PDF or a campaign page, every menu change means reprinting the cards on every table.

Test the code in different light and on different phones before printing. Dim evening light, glossy surfaces and codes printed too small all make scanning harder. A short line next to the code, such as "Scan for the menu", plus the same address in plain text helps guests whose camera does not pick it up.

• Permanent address: the code points to a short, permanent menu address on your own domain that stays the same when the menu changes.
• Table information: if guests will order from the table, each code carries the table number; if it only shows the menu, one code is enough.
• Right landing spot: the code opens the first menu category directly, not Instagram or the home page.
• Durable print: a wipeable, water resistant surface and enough blank margin around the code; a tight margin stops cameras from reading it.

You can create codes with our free QR code generator and test them on several phones before printing. A small source tag on the address lets you count visits from the tables separately.

05Table requests: phone and WhatsApp or a booking calendar

How you take table requests should follow how your dining room runs, not what a software demo shows. If one person can comfortably handle calls and WhatsApp messages, a calendar system adds a layer you do not need; if tables fill up every weekend and you run two seatings a night, a calendar reduces mistakes.

Look at the last few weeks before deciding: when requests arrive, who answers the phone during service, and how often guests fail to show up without notice.

• Phone and WhatsApp are enough: few tables, one seating and a team that can reply within the day.
• An enquiry form fits: group dinners and celebrations, with a short form asking for date, party size and notes.
• A calendar is needed: several seatings, deposits or prepayment, more than one room or a terrace.
• Common to all: an automatic reply telling guests their request arrived and when they will hear back.

If you move to a calendar, our page on a website with a reservation system explains how the setup works. Whichever route you choose, a prefilled WhatsApp message that asks for date and party size cuts down incomplete requests.

06Takeaway orders: delivery apps or your own channel

For takeaway and delivery there are two routes: send guests to the apps you already work with, or take orders through your own website. The first needs no setup and benefits from the app's audience; the second keeps the customer relationship and order data with you, but needs a kitchen and delivery routine that can carry it.

Before opening your own channel, answer four questions: who confirms orders, how payment is taken, who delivers, and can ordering be paused at peak times? If any of these is still open, starting with clear links to the apps is the safer step.

• App links: one clear, current button per delivery app; the link to an app you stop using is removed the same day.
• Your own ordering: Operox, the restaurant software we develop ourselves, can be added as an optional QR menu and ordering system.
• Start with pickup: without your own drivers, pickup orders alone are a low risk way to test your own channel.
• Separate tracking: clicks on each app button are measured individually, so you see which app gets guests from your site.

The decision is not permanent. Starting with the apps and adding your own channel once volume and team routines settle is a low risk sequence for most venues.

07Planning a food photo shoot around the menu

Restaurant photos are evidence that the menu and the room are real; an image that does not match what arrives on the plate costs trust. That is why a short, planned shoot of your own dishes is worth more than any stock photo of food.

Schedule the shoot after the menu text is final, because the menu decides which dishes need a picture: the ones guests order and ask about most. Shoot in afternoon daylight between services, with a cook plating exactly as for a guest.

• Dishes: the most ordered and most asked about plates, on your real tableware and in real portion sizes.
• Room: the view from the entrance, the terrace or garden and a table set for an occasion, with a natural level of guests rather than an empty room.
• Team: natural photos of the chef and service staff, taken with their consent.
• Exterior: a shot where the sign is readable and guests can recognize the door, which helps on a first visit.

Phone photos can work; consistent light and the same background matter more than expensive equipment. Note the setup of the shoot day so new seasonal dishes match the older pictures.

08Speed and mobile use on a photo heavy menu

If a photo heavy menu loads slowly on mobile data, guests close it before they read it, so speed is part of restaurant website design. Google's Core Web Vitals give a clear target, measured at the 75th percentile of visits: LCP, which measures how fast the main content loads, at 2.5 seconds or less; INP, which measures response to taps, at 200 milliseconds or less; CLS, which measures layout shifts, at 0.1 or less.

On a menu page, those targets are reached with a few concrete steps that do not cost the design anything:

• Sizing: each image is produced at the width it is shown on a phone and converted to modern formats.
• Order: images in the first category load first; the rest load as the guest scrolls.
• Reserved space: every image has its space reserved, so menu lines do not jump while photos load and nobody taps the wrong dish.
• Category bar: a category bar that stays at the top cuts down endless scrolling on a long menu.

Before launch, open the menu inside the restaurant, in the corner with the weakest signal, on a phone that is not on your guest WiFi; that is exactly what guests experience. Our mobile friendly test shows how your current site looks on a phone.

09Google Business Profile and near me searches

Many hungry searches end in the map results, so your website and Google Business Profile must say the same thing. Name, address, phone, hours and menu link should match in both places, and holiday hours should be updated in both on the same day.

The business name on the profile must be the real name on your sign. Names stuffed with keywords, such as "Luigi's Pizza Brooklyn Late Night Delivery", break Google's guidelines and put the profile at risk; put your cuisine in the category and the description instead.

• Category: the primary category describes your cooking as narrowly as possible, for example seafood restaurant or brunch restaurant rather than just restaurant.
• Menu link: the profile's menu link points to the menu page on your site, the same address as the table QR code.
• Photos: a selection from your real shoot goes onto the profile as well.
• Reviews: a short, specific and calm reply to negative reviews; if a complaint is about wrong hours, fix the hours first.

Your site's share of "brunch near me" or cuisine plus neighborhood searches grows with a visit page that describes the area and your cooking in natural language. If you want map and organic search handled together, see the scope of our SEO service.

10Winning searches for your own restaurant name

If guests searching for your restaurant name see delivery apps and directories first, your own site is giving that search too little. To hold your name, the site has to offer, clearly and in readable text, what the platforms cannot.

The technical side of this is structured data: code that tells search engines, in a machine readable way, that the page belongs to a restaurant, along with its address, hours, cuisine and menu address. With Restaurant markup, only information visible on the page is marked up; adding a review rating that does not appear on the page breaks the rules.

• Identity: name, address, phone and logo, spelled the same way everywhere on the site.
• Hours: opening hours by weekday, plus exceptions for holidays.
• Menu: the menu page address and the cuisine.
• Tables: whether you accept table requests and how guests make one.

You can review your current markup with our schema markup generator. On the content side, an our story page, the chef's approach, the producers you buy from and the history of the place are details that platform listings do not carry.

11Several locations and menus in other languages

If you run several locations, each one needs its own page with its address, hours and map; a list of addresses on one contact page performs poorly in location searches. Each location page links to its own Google Business Profile and shows the dishes or hours specific to that site.

The menu can be shared, with location specials marked in the menu data and shown only on that location's page. A bistro in a tourist area or near business districts with many international guests needs a separate menu page per language. Publishing raw machine translation confuses guests on dish names; keeping the name and explaining the dish briefly works better.

• Which languages are really needed? The languages you hear most in the dining room are a better guide than assumptions.
• Is allergen information equally complete in every language?
• Are the language versions linked with hreflang, each referencing the others and itself?
• Which language does the QR code open, and is the language switch visible at first glance?

For the technical setup and translation workflow, see our page on a multilingual website.

12Measurement, cookies and privacy notices

Visitor numbers alone say little on a restaurant website; what matters is which button brings calls, directions, WhatsApp messages or orders. Defining those clicks as conversions from the first day shows which page or campaign actually brings guests.

• Calls: taps on the click to call button, with page and time of day.
• Directions: clicks on the map link, the strongest sign that a guest is about to set off.
• WhatsApp and forms: table requests and group dining enquiries tracked separately.
• Orders: each delivery app button and your own ordering channel as separate events.

Measurement needs a legal footing. A table request form collects names and phone numbers, so it needs a clear privacy notice linked right beside it. In the EU, consent is needed before non essential cookies are set, and the UK has comparable rules; for users in the European Economic Area, Google also requires consent mode for its measurement and personalized advertising features.

If you plan to advertise, landing page experience is one of the three components of Google Ads Quality Score, and a fast, clear menu page is its foundation. For local campaign setup, see our Google Ads management.

13Common restaurant website mistakes

Most restaurant website mistakes come not from design but from information that goes stale and from forgetting how quickly guests decide. These six are the ones we see most often, each with the better alternative.

• Leaving the menu as a PDF: it loads slowly and search engines cannot read it; instead, a categorized text menu updated from a panel.
• Changing hours in one place: the site is updated and the Google profile is not; instead, one named person who updates both on the same day.
• Opening with a video: it pushes hours and location down on a phone; instead, one strong photo with the status line right below it.
• Linking the QR code to a file: every menu change means reprinting; instead, a code that points to a permanent menu address.
• A different number for every channel: guests do not know which one to call; instead, one phone number and one WhatsApp line across the site.
• Opening with stock photos: images that do not match the plate damage trust; instead, real dishes shot in consistent light, even on a phone.

One more mistake does not fit the list: not deciding who updates the site after launch. Choose the person who will keep menu, hours and photos current at the start of the project, and have that person attend the panel training.

14Choosing a partner and your next step

When choosing a partner for a restaurant website, look less at portfolio visuals and more at how the agency handles the menu, the QR code and the ordering flow.

• Who turns the menu into text, and who checks allergens and markers?
• Is the address behind the QR code permanent, and what happens when the menu changes?
• How many steps does it take in the panel to hide a dish or change its price?
• Are calls, directions and order clicks measured, and who will read the report?
• In whose name will the domain, the site files and the content be registered?

We do not have a live client website for a restaurant or cafe yet, so we show our approach on the live demo linked on this page. The demo is not a client site; it lets you try how the menu opens on a phone, where the QR code leads and how a table request is sent. You can also look at our wider web design service and how we work.

When you are ready, share your current menu, your number of locations and your order channels through our contact form; after a short call we send a written scope and timeline. To see what each package includes, visit the pricing section.