How to Add a Restaurant Menu to Your Website

On most restaurant websites the menu is the most visited page by a wide margin. It is also, reliably, the worst maintained thing on the site: a PDF from two summers ago, or a photograph of a printed card, or a list with prices that no longer match the till.

This is a solvable problem and the fix is unglamorous. A menu is structured data that happens to be presented beautifully, and treating it that way makes it readable on a phone, visible to search engines, and quick enough to update that it actually gets updated.

What follows is about the menu itself rather than about building a restaurant website. If you need the site first, the wider guide to building a restaurant website covers that groundwork, and this picks up at the point where you have somewhere to put the menu.

Why the Menu Page Matters More Than the Rest of the Site

Think about how somebody actually arrives. They have already chosen you, or nearly, and they are checking one of three things: whether you serve the thing they want, roughly what it costs, and whether you are open. The menu answers two of the three.

That is a different job from the homepage. The homepage is persuasion. The menu is a reference document being consulted under mild time pressure, often on a phone, often outdoors, sometimes by somebody standing near your door. Everything about how you publish it should follow from that.

The PDF Problem

A PDF menu is the default because the restaurant already has one for printing, and reusing it costs nothing. The costs come later.

A PDF has a fixed page width. A phone does not. So the reader gets a document they must pinch, zoom and drag, and every price they want to check requires re-aiming. Text designed for A4 at reading distance becomes unreadably small on a five-inch screen, and zooming in means losing the column alongside it.

Then there is maintenance. Changing one price means editing the source document, exporting a new PDF, and uploading it over the old one. That is a five-minute job that requires the person who owns the design file, which is why it does not happen and why so many menus online are quietly wrong.

Finally, discovery. Somebody searching for a specific dish in your town is looking for text a search engine can read and connect to your restaurant. Text locked inside a PDF is much harder to use that way, and a photograph of a menu is worse still, because there is no text at all.

Structure the Menu Before You Style It

A menu is a small, regular data structure and it pays to name the parts. There are sections, such as starters, mains, sides and desserts. Each section holds items. Each item has a name, a price, usually a description, sometimes a label such as vegetarian or spicy, and a state: available or not.

Once you have that, everything else is a presentation choice, and presentation choices become cheap. You can render the same menu as a single scrolling list, as tabs per section, or as two columns on a desktop and one on a phone, without retyping a single dish.

The alternative, which is writing the menu directly into the page as formatted text, works exactly once. The second time you need to change something you are editing layout and content together, and that is where prices get orphaned from the dishes they belong to.

A worked shape makes it concrete. A section called Mains holds an item called Slow-Roast Pork Shoulder, with a price of 18, a description of "apple, mustard mash, greens", a label of nothing in particular, and a state of available. Next to it sits Cauliflower Steak, price 14, labelled vegan, currently unavailable. Both are rows in the same structure, and the page decides how rows are drawn.

The value of writing it down like that is what it makes cheap later. Adding a spice-level label to every dish becomes one change to how rows are drawn rather than an edit to forty lines of text. Adding a second language becomes a second description field. Neither is a rebuild.

Where the Menu Should Live

Give it its own page at its own address, linked from the main navigation with the word "Menu". This sounds too obvious to state, and it is routinely got wrong in two ways.

The first is burying the menu inside a longer page, so a reader has to scroll past the story of the restaurant to reach it. The menu is the reason most people came; it does not need an introduction.

The second is making the menu link open a file or a new tab. A link that downloads something, or that throws the reader into a document viewer, breaks the back button and loses them. The menu should be a page on your site that behaves like every other page.

A stable address also matters more than it seems. People bookmark menus, send them to each other, and paste them into group chats when deciding where to eat. An address that survives a redesign keeps all of that working, and an address that changes quietly breaks every link anybody ever shared.

Prices, and Why They Are the Whole Problem

Prices are the part that changes, and they are the part where being wrong has a cost that is not just embarrassment. A diner who chose you based on a price on your site and then sees a higher one on the bill has a legitimate complaint, and staff have to absorb it.

So the test for any approach is simple: how long does it take the person who actually sets prices to change one, and do they need anybody's help? If the answer involves a design file, an agency, or a developer, the menu will drift out of date. If it is editing a field and saving, it will stay current.

A related decision is what to do about currency and formatting. Pick one format and keep it consistent across every item, including the ones ending in zero. A list where some prices read 12 and others 12.00 looks careless in a way that makes people wonder what else is careless.

Descriptions: Short, Concrete, and Not Marketing

The purpose of a description is to answer what arrives on the plate. Ingredients, method if it matters, and anything a diner needs to know before ordering. Two lines is usually enough and one is often plenty.

Resist adjectives that carry no information. "Succulent", "mouth-watering" and "artisanal" occupy space without telling anybody what is in the dish, and on a phone that space is expensive. "Slow-roast pork shoulder, apple, mustard mash" does more work in fewer words, and it is the kind of text that also matches what somebody might search for.

Showing What Is Not Available

Kitchens run out. Suppliers miss deliveries. A dish comes off for a fortnight. The instinct is to delete the item, and it is the wrong instinct.

Deleting makes the menu inaccurate in a way that is harder to recover from than being out of stock. A regular who came for one dish sees it missing and concludes you no longer serve it, which is a permanent loss caused by a temporary problem. Marking the item unavailable tells the truth: it exists, not tonight.

It is also operationally lighter. An availability toggle is something a manager can flip from a phone at four in the afternoon. Re-adding a deleted item means retyping the name, the description and the price, and hoping all three match what they were.

Multiple Menus: Lunch, Dinner, Kids, Wine

Most restaurants have more than one menu even if they think of it as one. Lunch is often cheaper or shorter. There may be a set menu, a kids menu, a wine list, a specials board that changes weekly.

Keep them separate. A single merged list with qualifiers in brackets, "12 at lunch, 16 in the evening", is how billing disputes start, and it makes the page longer and harder to scan for everybody. Separate sections or a switcher, each labelled with its serving times, answers the question the reader is actually asking, which is what can I have right now and what will it cost.

The wine list deserves a specific note. It is usually the longest document and the least interesting to scroll, and it is often the one people want to check before booking. Giving it its own place, rather than appending it to the food, respects both audiences.

Allergens and Dietary Labels

This is the part where a website has to be careful about what it promises. Labels for vegetarian, vegan and gluten-free are genuinely useful and easy to get right at the level of a menu item. Detailed allergen claims are harder, because a kitchen's suppliers and a night's substitutions are outside what a web page knows.

The workable pattern is honest labels per dish for the common cases, plus one clear, prominent line telling people to speak to staff about specific allergies. That combination gives most readers what they need to choose while not implying a precision the site cannot guarantee. Depending on where you operate there may also be a legal requirement here, so it is worth checking rather than assuming.

Making It Work on a Phone

Assume the phone is the primary case and the desktop is the accommodation, because that is the actual traffic pattern for a menu.

That means one column, generous line spacing, prices aligned so the eye can run down them, and section headings that stay findable while scrolling. It means not putting the menu inside a scrollable box within the page, because two nested scroll areas on a touchscreen is a small torture. And it means the whole thing is readable at default text size, because a diner in a hurry is not going to zoom.

A related mistake is loading a large image per dish. Photographs can be worth it for some restaurants, but twenty images on a menu page turns a quick check into a slow download, often on poor signal outside the restaurant. If you use photographs, use them sparingly and make sure they load lazily.

The "Google Menu" Question

Some of the people looking for this want something adjacent: getting their menu to appear on their Google Business Profile, the panel that shows up alongside search results and maps. That is a separate system from your website, managed through your business profile rather than your pages.

It is worth doing, and it is not a substitute for a menu on your own site. The profile reaches people searching for you nearby; your site is where the full, current, detailed version lives, and it is the one you control. Doing the profile and neglecting the site leaves you dependent on a summary you cannot fully shape.

If You Are on a Theme Like Avada

Plenty of restaurants run a WordPress theme with menu features built in, and some of the traffic to this topic is people on exactly that. If the theme's menu component structures items properly and lets the right person edit prices, use it.

Check two things before committing. First, whether the menu content is stored as structured items or as a block of formatted text, because the second option is the maintenance problem again in a new place. Second, whether it survives a theme change. A menu that lives inside a theme's proprietary format has to be rebuilt if you ever move, and restaurants change their websites more often than they expect to.

Specials, Seasons and How Often to Change It

There are really three tempos in a restaurant menu and they want different handling.

The core menu changes rarely, a few times a year, and it is the thing worth getting properly structured and well written. The seasonal or monthly section changes on a predictable rhythm, which makes it a natural candidate for its own clearly-labelled block that can be swapped without touching the core. And the daily special changes faster than any website process will keep up with, which is worth being honest about.

For the daily case, the choice is between publishing it and accepting it will sometimes be stale, or not publishing it and saying where to find it. Both are defensible. What fails is publishing it and forgetting, so that a specials board dated three weeks ago sits at the top of the page announcing that nobody is looking after this.

If you do run a fast-changing section, put it below the core menu rather than above it. The reader's main question is about the permanent offering, and a stale special at the top of the page casts doubt on the accurate prices underneath it.

Ordering, Delivery and the Third-Party Problem

Many restaurants take orders through a delivery platform, and the menu on that platform is usually different: fewer dishes, higher prices to absorb commission, different descriptions. That creates two versions of the truth, and diners notice.

The clean approach is to treat your own menu as the reference version and be explicit that delivery pricing differs. A single line does it. What causes complaints is silence, where somebody reads your prices, orders through an app, and pays more without ever being told why.

If you link out to a delivery platform, put that link after the menu rather than instead of it. Somebody who wanted to see what you serve should not be handed off to a third-party app before they have read it, and a link that leaves your site is a poor answer to a question you could answer yourself.

Give the Menu Page a Job to Do

A menu answers questions, and a reader who finishes it has usually decided. That is the moment to make the next step obvious: booking a table, ordering for collection, or finding you.

One clear action at the end of the menu is enough, and it should match how you actually take business. If bookings come by phone, the number is the call to action and it should be tappable. If you use a booking system, the button goes there. What does not work is three competing options, which is a general truth about calls to action and is covered properly in the guide to writing a call to action that works.

Keeping It Current Without It Becoming a Chore

The menu will only stay accurate if updating it is trivial for the person who knows the answers. That is usually a manager or an owner, not whoever built the website.

So the practical test of any setup is whether that person can change a price, mark a dish unavailable, and add a special, on a phone, in under a minute, without being able to break anything else. If the answer is yes, the menu stays right. If it involves anybody else's calendar, it does not.

One useful habit is to check the menu on your own phone, standing outside, on mobile data rather than the restaurant's wifi. That is the real condition it gets read in, and it surfaces problems that never appear on a laptop at a desk: text that is a shade too small, a price column that wraps awkwardly, a photograph that takes four seconds to arrive.

It is also worth setting a rhythm rather than relying on noticing. A quick pass every time the kitchen changes something, and a proper read-through once a season, catches the drift that nobody reports because nobody is responsible for it.

How to Add One Without Rebuilding the Site

Everything above is achievable with a component that stores the menu as data and renders it responsively. A restaurant menu list widget handles the sections, the items, the prices, the descriptions, the dietary labels and the availability toggles, and puts the editing behind a simple form rather than behind the page's markup.

Adding it is pasting one line of embed code where the menu belongs. From then on, changing a price is editing a field: no export, no upload, no waiting for anybody. The layout adapts to the screen, the text stays real text a search engine can read, and the person who knows what things cost is the person who can change what things cost.

A Short Checklist

Real text rather than a PDF or a photograph. Items structured as data, not typed into the layout. One consistent price format. Descriptions that say what arrives. Unavailable dishes marked rather than deleted. Separate menus for separate services, each with its times. Honest dietary labels plus a line pointing to staff. One column and no nested scrolling on a phone. One clear next step at the end. And an update path short enough that it actually gets used.