Website for a restaurant or cafe: menu, delivery, bookings

A restaurant is a business where the decision gets made fifteen minutes before dinner. Nobody studies you for a week. Someone opens their phone, searches for "where to eat nearby", looks at the menu and the prices, and either comes to you or goes to your neighbours. The website here is not for image, it is there to hold up through those fifteen minutes.

Why does a restaurant need a website if guests already find it on Instagram?

Instagram answers the question "does this place look good". It answers everything else badly: what is on the menu today, how much the business lunch costs, whether you are open on Monday evening, whether you can seat a party of eight. To find that out, the guest has to write into your DMs and wait for a reply. Some guests do not write - they leave.

Second: search. A card in Google and Yandex Maps pulls you up for "cafe nearby", but a card cannot compete for queries like "Uzbek cuisine restaurant Tashkent" or "where to celebrate a birthday" - those need pages with text. A profile on a social network is not that kind of page.

I covered the difference between a profile and a website separately: Website or Instagram: what should a business choose.

What should the menu on the site look like?

The menu is the main page of a restaurant website in practice, whatever you formally consider the main page. Three rules:

The menu is text, not a PDF and not an image. A scan of a menu cannot be read on a phone without zooming, is not indexed by search and does not make it into AI answers. Every item has to be text on the page.

Prices are there. A menu without prices produces exactly one thought: "probably expensive". If prices change often - you need a CMS where you edit them yourself in a minute.

Photos for the key items, not for all of them. Two hundred cards with photos means a slow page and a month of a photographer's work. You photograph what sells: the signature dishes, the sets, the desserts.

A separate question is how the menu gets updated. If every price change means writing to the developer, in two months the menu on the site will stop matching the menu in the dining room. This is the most common breakdown of restaurant websites, and it is cured by an admin panel, not by discipline.

Do you need delivery on the site if the aggregators are already there?

An aggregator gives you flow, but it takes a commission and does not hand you the contact of the guest. Your own ordering channel means orders without commission from people who already know you. The logic is simple: the aggregator brings new people, the site keeps the ones you have.

At the same time, a full online store with a cart, payment and order statuses is not for everyone. For most cafes the working minimum is a page with the menu and an order button that leads into a Telegram bot or into a form. The order lands in the kitchen as a message, the operator confirms it. That is an order of magnitude cheaper than a cart and it launches right away.

Where the line runs between a simple catalog and a real store, I covered here: Online Store or Catalog Website: What Your Business Needs.

How do you set up bookings people will actually use?

Bookings break in two ways. The first - there are none, there is only a phone number: some guests do not call. The second - they were made too complicated: a calendar, picking a specific table, registration, confirmation by email. Nobody in the dining room looks at that system.

The working option for a single venue is a short form: name, phone or Telegram, date, time, number of guests. The request goes into the work chat of the floor manager, who calls back and confirms. Five fields and one button. Automated seating is for chains with heavy flow, not for a cafe with forty seats.

What has to be on the first screen?

The guest should understand within three seconds where they have landed and what to do next:

The name and the type of cuisine - "Uzbek cuisine restaurant", "coffee house and bakery", not an abstract "atmosphere, taste, comfort".

The district or the address. A restaurant is a local business, geography matters more than a slogan.

Opening hours.

Two buttons: "Menu" and "Book a table". Not five. Two.

Further down the page - photos of the room, the key menu items, a map with the address, the booking form. Anything that pushes the menu lower pushes the order lower with it. If the site exists but there are no requests, the reason is usually in the structure: Why Your Website Gets No Leads.

What do you do about search?

A restaurant lives on local queries, so the basic set is this:

Cards in Google Business Profile and Yandex Business with up to date hours, photos and a link to the site.

A page with the address and a map - for queries that carry the name of the district.

Separate pages for separate occasions: banquets, business lunch, a kids birthday, a corporate event. These are different queries with different value, and one general page will not collect them.

The last point is the main argument for a multipage site instead of a landing page. If you take banquets, the page about banquets pays for itself faster than all the rest of the development.

How much does a website for a restaurant cost?

Reference points: a landing page from $190, if you have one venue, a menu and bookings. A multipage site from $490, if delivery, banquets, several locations or a blog get added. A complex project - on request.

The price is fixed for an agreed scope before the start. What it is made of and why sites that look the same cost differently: How much does a website cost in Tashkent in 2026.

If you want an estimate for your own venue - write to me through the form on the contact page, I will describe the structure and name the price the same day.