A hungry person with a phone in their hand has three questions and little patience - the rest of the site can wait. The questions are always the same and in this order: is it open now, what is on the menu and what does it cost, how do I book a table or order. If the site answers that in a few seconds, it is doing its job. If it makes them hunt, the guest does not even go back to the search results: they look up and read the sign next door. A decision about where to eat is made on the street, not in a search engine.
Everything else - the history of the place, a gallery of the interior, the kitchen’s philosophy - is an extra. Important for the mood, but it does not decide whether anyone eats with you today. How building a site like this looks from the process side I described more broadly under web development - the approach is always the same: diagnosis first, specifics second.
The menu as a PDF - this trade’s most common sin
I will start with the thing that costs the most and is easiest to fix. A menu uploaded as a PDF file or a photo of a printed card is the standard in Polish hospitality - and a standard that works against the venue in three ways at once.
First, the search engine does not read it as page content: dish names, prices and descriptions are locked inside a file, so when someone searches for a specific dish, Google has nothing to match. Second, phones handle PDFs terribly - an A4 sheet shrunk to screen width, pinch zooming, scrolling in two directions, giving up. Third - and this matters more and more - AI systems asked “where to eat in Krakow” have nothing to cite from a site like that. They do not know you have pierogi, ramen or a gluten-free menu, because that information does not exist anywhere as text.
The menu should be text on the page. Split into categories, with a price next to every item and a short note on the ingredients. Plus allergen markings and vegetarian or vegan options - for some guests that is not trivia but a condition of entry: someone with coeliac disease will not risk a place that says nothing about it.
You can keep the PDF as an extra, for printing. But it must not be the only version of the menu on the site.
What helps: open your own site on a phone in private mode, standing in the street, and try to check the price of one specific dish in 30 seconds. If you cannot - you now know what the guest who never reached you was looking for.
Opening hours - one place, always current
This is the first question anyone asks. Hours should be visible immediately, without scrolling, and kept in one place in the site’s system - so a change takes one edit, not a hunt for three different versions in the footer, on the contact page and in the “about us” section.
Second thing: the hours on the site have to match the maps listing. A discrepancy always ends the same way: someone turns up at a locked door and leaves a review you will be looking at for a year. The listing is usually the first point of contact, so treat it as part of the site.
Third: describe holidays and closures separately, next to the hours - Christmas Eve, the May long weekend or a refurbishment are exactly the days people check the site most often.
Table booking without needless friction
Booking can work in two ways and both are fine, as long as they are finished. The simpler one: a short form. Date, time, number of people, name, phone, a field for notes - that is enough. Do not ask for an address, do not force account creation, do not throw in a marketing consent. The more elaborate one: a booking module with availability - it makes sense when there are many tables and you want to avoid negotiating every reservation by phone.
Whichever you choose, the phone stays an equal channel, not a fallback - larger groups will call anyway. The number should be tappable, visible at the top and repeated next to the form.
And the thing venues forget most often: a confirmation back. A guest who sent the form and got nothing in reply does not know whether the booking exists - they will call to check, or go elsewhere. An automatic confirmation email or text is one of the cheapest things to implement and one of the most noticeable.
Delivery orders - a platform or your own ordering
There is no yes-or-no answer here. Delivery platforms give you reach you cannot buy on your own: people open the app with no particular venue in mind. You pay for it with a commission on every order.
It is worth calculating not the commission alone but the whole economics of one order together with the logistics. With platform delivery the kitchen controls neither the delivery time nor the state of the food after forty minutes in a backpack. The fries leave crisp and arrive soggy - and the complaint comes back to the venue anyway, because the guest is judging the food, not the courier. So the bill also carries the cost of a bad review and a portion given out free a second time.
Your own ordering makes sense where collection in person is realistic and the delivery radius is short - then you control the state the food reaches the guest in, and the margin and the contact stay with you. It costs work, though: someone has to watch the orders, handle the online payment and organise handover.
Honestly: for many venues both at once make sense - the platform for new guests and long-range delivery, your own channel for regulars from the neighbourhood, reminded on the receipt and on social media.
Food photos that do not kill the site
Photos sell in hospitality, but only your own - a stock burger that is not on the menu gets spotted instantly.
Something else matters more: the photo of a dish has to match the portion the guest gets at the table. If the site shows a loaded platter and half of it arrives, the disappointment does not end at the table - it lands in the reviews. Photography should raise appetite, not raise the stakes above what the kitchen serves.
The second matter is file weight: a gallery of twenty shots straight off a phone takes a genuinely long time to load in the city centre. The fix is technical and one-off - compression and modern image formats, which I wrote about in the piece on image optimization, and the rest is the standard hygiene covered by speeding up a WordPress site.
Menu and hours in a form a machine understands
Hospitality is the only trade where a search result can show items from the menu before anyone even reaches the site. That happens when the menu is not only text but also described by data in the background - so the search engine and AI systems recognise a menu: categories, names, prices, allergens. The same goes for hours - described technically, they are a signal a machine reads directly.
This has a very practical consequence. Queries like “open now”, “open on Sunday” and “near me” are served by systems that need your current schedule in machine-readable form. If the hours hang as an image or inside a paragraph about the venue’s atmosphere, you are absent from those answers - even when you happen to be open with free tables. Whether the changes work you can check without guessing - I described that in the piece on checking your website ranking in Google, and where AI models get their knowledge I explain in the piece on SEO and AI.
The hygiene the guest never thinks about but always feels
Three things that decide the impression, though nobody consciously grades them:
- Speed on mobile - the most common brake in this trade is a menu uploaded as an image or a gallery of dish photos loading at full resolution
- A menu readable without zooming - type size, the price on the same line as the dish, collapsible categories; if the guest has to pinch, the menu is too small
- An address that taps straight into navigation - one touch should open the map on the phone, without retyping the street from memory
What to avoid
- A years-old brochure site with an out-of-date menu - prices from three years ago are worse than no prices, because the guest feels misled at the table
- Music starting on entry - someone is checking the place at work or on a tram and simply closes the tab
- A menu with no prices - “prices in venue” reads as “this will be expensive” and filters guests out
- Contact only through social media - some people have no account there and will not order
What a restaurant website costs and where to start
If you have a site and want to know what is actually costing you guests - send me a link. I do a free diagnosis: I walk the site as someone looking for somewhere to have dinner and come back with a list of what to fix first.
A new site for a venue I do as a project with the price agreed up front, usually in the 5,000-10,000 PLN net range depending on scope - with the menu as content, booking, and preparation for local visibility. If you then do not want to keep an eye on menu updates, hours and the technical side yourself, there is ongoing support in three variants: Basic from 1,000 PLN, Pro from 2,000 PLN and Premium from 3,500 PLN net per month.
Frequently asked questions
Does a restaurant menu on the site have to be text rather than a PDF? Yes, if you care about anyone finding you. Search engines and AI systems do not read a PDF as page content, and on a phone such a file is simply awkward. A printable version can stay as an extra, but the basis has to be text with prices and categories.
Can ordering be added to a site I already have? Usually yes - it is a matter of an ordering module and connecting payments, rarely a reason to rebuild the site. What matters more is whether that channel makes sense for you: it works where collection in person is realistic and the delivery radius is short.
Is my own ordering worth it when I am already on delivery platforms? It is not an either-or. The platform gives reach, but with courier delivery you have no influence over the state the food arrives in - and the complaint comes back to you. Your own channel gives control over that stretch, and running both at once usually makes sense.
How do I get the restaurant to show up for “open now” queries? The hours have to be on the site as text described technically, not as an image or a sentence in a paragraph - only then does the system have something to read. Add the menu as content and the same data in the maps listing.
Looking for someone to handle it end to end? I do web development for companies with scoping and delivery run online. Send the scope and a quote comes back.