How to Build a Restaurant Website Without Code in 2026

To build a restaurant website without code, put your menu, hours and location where a hungry person finds them in one scroll, describe the rest in plain language, and let an AI builder generate the site. On Zugo a single-page restaurant site takes about a minute and publishing to a live address is one click.

Most restaurant sites are built as portfolios and used as reference cards. Someone is standing outside deciding, or sitting on a sofa at seven o'clock, and they want three facts. Design that first and everything else is bonus.

What do people actually come to a restaurant site for?

Four things, in this order: the menu, whether you are open, where you are, and how to get a table. Everything else, the story of the chef, the photography, the philosophy, is read by a small minority after those four are answered.

That ordering has a consequence most sites ignore. The menu should be text on the page, not a PDF and not an image. A PDF is unreadable on a phone, invisible to search engines, and a barrier at exactly the moment a customer was ready to decide.

The second consequence is that opening hours must be current, including the exception. "Closed Mondays" and "closed for two weeks in August" are the facts that generate an angry review when they are wrong on the page.

What should the prompt say?

Name your cuisine, your service style and your actual dishes. A generic prompt returns stock imagery and copy about seasonal ingredients that describes nothing.

Build a website for [restaurant], a [cuisine] [restaurant/bistro/cafe]
in [city, neighbourhood], seating [N].
Menu sections: [starters, mains, desserts, drinks] with real dish
names, short descriptions, prices and dietary tags (v, vg, gf).
Hero: name, one line, "Book a table" button, opening hours today.
Sections: menu, about with two paragraphs, gallery of 8 photos,
private events and group bookings, find us with map and transport,
opening hours table including exceptions, contact.
Booking: [link to our reservation system / form with name, phone,
date, time, party size, notes].
Tone: appetising but factual, no talk of culinary journeys.

Dietary tags are worth naming explicitly. A vegetarian or coeliac guest chooses the restaurant that answered the question on the page over the one that made them phone, and that is a booking decided before anyone spoke to you.

Zugo ships 25 ready templates. A landing or service template is close enough to a restaurant page that rewriting the sections in your own words gets a better first draft than a freeform prompt does. The prompt principles in general are in how to build an app with AI.

How do you keep the menu current without rebuilding the site?

By treating the menu as the thing that changes and everything else as the thing that does not. Keep the whole menu in one section, so a seasonal change is one edit rather than a hunt across five pages.

An edit costs 3 credits on Zugo, which makes the honest rhythm affordable: "replace the autumn starters with these six", "put the tasting menu at the top", "mark the risotto as vegan". Describe the change, keep the layout, move on.

Daily specials are the trap. A board that must be updated every morning will be wrong by Wednesday, and a wrong site is worse than a site without specials. Link to the account you already post on and let it carry the churn.

How do reservations and ordering work?

Two separate questions with different honest answers.

For reservations, most restaurants already have a system, and the right move is to link or embed it rather than to build a booking engine. Table management, covers per sitting, waitlists and no-show tracking are a product in their own right. If you have no system, a simple form with name, phone, date, time and party size plus Resend to deliver it to your inbox is a workable start, as long as somebody confirms by phone.

For ordering, be deliberate. Selling a fixed set of items, gift vouchers, a set menu deposit or event tickets through Stripe is straightforward and is described in Stripe payments in an AI-built app. Full takeaway ordering with modifiers, delivery zones, preparation times and kitchen printing is a different scale of project.

Connect Supabase if you want bookings or orders stored in a database you can sort, plus accounts if you later add a loyalty area. Google Analytics tells you whether people reach the menu, which is the only page metric that means anything here.

What does a restaurant site cost to build and run?

A single-page site is 6 credits and about a minute. A multi-page version with separate menu, events and contact pages is billed as a platform: 12 credits flat for the first three pages, then 3 credits for each additional page, and it takes a few minutes to assemble.

Zugo's Free tier gives you 5 credits to try the flow. Pro is $25 per month for 200 credits, which works out to 33 quick builds or 66 edits, and includes connecting your own domain. Business is $99 per month for teams.

Hi-Fi mode doubles both figures, 12 to build and 6 to edit. For a restaurant it is usually worth spending on the home page, where the photography does the selling, and not on the menu page, where legibility matters more than polish.

Until you attach a domain the site lives at yourrestaurant.zugo.run, which is fine for testing and thin on a napkin. A real domain takes a few minutes to point, as described in connecting a custom domain.

What should you check before sending anyone the link?

Four checks, all on a phone, all taking under five minutes.

Read the menu on a small screen without zooming. If you cannot, the type is too small or the menu is an image. Then check the hours block shows the right thing today, including whether you are closed. Then tap the phone number and confirm it dials. Then submit the booking form yourself and confirm the email arrives.

Before a build reaches you it is booted in a sandbox: the site has to load and render, and a failure is reported as a failure rather than handed over as a blank page. That lowers the risk of publishing something broken. It does not know that your Tuesday hours are wrong, which is why the four checks above are yours.

Where does an AI builder stop for a restaurant?

Three honest boundaries.

Point of sale and kitchen systems are integrations. If orders must reach your POS, print in the kitchen, or decrement stock, that is a development project with the vendor's API. The builder makes the pages, a developer makes the pipe, and GitHub export hands over a normal repository.

Delivery platforms have their own rules. Appearing on the large delivery apps means their onboarding, their commission and their software. A website does not replace that, and pretending otherwise costs you orders.

Complex ordering logic arrives through edits. Item modifiers, timed collection slots, delivery zones by postcode and minimum order values are all buildable, but through a sequence of refinements rather than one prompt. Budget an evening, and remember that Zugo does not replace a development team on a product of that size.

For the common case, a restaurant that wants a fast, readable page with a real menu, correct hours and a way to book, this is an evening. Write the menu out in a plain text file first, then describe the site around it. You can start on the free credits at zugo.dev and have a link worth printing by tomorrow.