A restaurant website has one job on a Friday evening: tell somebody standing on the pavement what you serve, when you are open, and how to book, in under three seconds on a phone with two bars of signal. Almost everything that goes wrong with these sites is a failure at that specific task.
The checklists are all similar — menu, hours, location, photos, reservations. They are not wrong. What they leave out is the ordering of importance, the traps that make an otherwise complete site useless, and the fact that a site is a recurring cost with a number attached rather than a one-off purchase.
Table of contents
- The four things that matter, in order
- The menu is the site
- Speed, because of who is looking and how
- Builder, WordPress, or static
- Own the domain, whatever else you do
- What it costs to run
- How this fits the rest of the stack
- FAQ
The four things that matter, in order
If a visitor can do these four things immediately, the site is doing its job. Everything else is decoration.
Read the menu. Not download it, not pinch-zoom a photograph of it — read it, as text, on a phone. This is the most visited page on every restaurant site and the one most often published as an unreadable PDF.
See whether you are open. Today’s hours, visible without scrolling, and correct on public holidays. A visitor who arrives at a closed restaurant because the site said otherwise does not come back.
Find you. Address as text, a tap-to-call phone number, and a map link that opens the phone’s map app rather than an embedded map that takes four seconds to load.
Book or order. One obvious action, above the fold, going somewhere that works on a phone.
That is the whole brief. A site that does those four things well and nothing else outperforms an elaborate one that buries them under a full-screen video.
The menu is the site
Worth its own section because it is where the most common and most costly mistake lives.
Menus get designed in print software and exported as PDFs or images. On a phone, a PDF either downloads or opens in a viewer where the text is too small, and pinch-zooming a menu on a pavement in the rain is exactly as pleasant as it sounds. Many visitors give up there.
It is also invisible to search engines. Every dish name and description — the specific words people search for — contributes nothing, because it is inside an image.
Publish the menu as a web page. Section headings as real headings, dishes and descriptions as real text, prices as text. It reflows on any screen, it can be read aloud by a screen reader, it can be copied, and it becomes several hundred searchable terms.
Keep the designed PDF as a download for anyone who wants to print it. Just do not make it the only version.
And keep it current. An out-of-date menu with wrong prices generates a difficult conversation at the table, and it is the single most common complaint restaurants get about their own sites.
Speed, because of who is looking and how
Restaurant sites are opened on phones, frequently on mobile data, often by someone who will decide within seconds. They are also, as a category, unusually heavy, because they are built around photographs of food.
The usual weight problem:
- A hero image several megabytes in size, displayed at a fraction of its dimensions.
- A gallery loading every photograph at full resolution before anything is visible.
- A video background, which is the most expensive single thing you can do to a mobile visitor.
- Several font weights blocking the text from appearing.
- A booking widget loading its own framework ahead of your content.
The fixes are all mechanical: resize images to display size, serve WebP or AVIF, use srcset so phones fetch small files, lazy-load below the fold, set explicit dimensions so the layout does not jump, subset fonts, and load the booking widget after the page renders.
The booking widget deserves specific attention. If it blocks rendering, the visitor stares at a blank screen while the thing designed to take their money downloads. Load it lazily or on interaction.
Builder, WordPress, or static
Three realistic options, with honest trade-offs.
A website builder is the fastest route to something live and the easiest for a non-technical owner to update. The costs are a monthly fee that rises, limited control over performance, and the domain question below. For a single restaurant with no in-house technical help, this is often the right answer and there is no shame in it.
WordPress gives you full control and a large ecosystem, and it needs maintaining — core and plugin updates, backups, and someone to look at it when a plugin conflicts. It suits a restaurant group, a site with a blog or events, or anyone who already has someone technical involved. Managed WordPress removes most of the operational burden; on RunxBuild it starts at $3 a month on the Starter plan with a file manager and database browser in the dashboard, which is the part that usually requires SFTP and phpMyAdmin elsewhere.
A static site is the fastest and cheapest to run, because the pages are files with nothing to execute. For a restaurant site that changes a few times a month, this fits well. The trade-off is that updating it means either editing content files or having a small CMS in front, so it wants someone comfortable with that. Static hosting on RunxBuild includes 120GB of bandwidth, which a restaurant site will not come close to using.
The choice matters less than the four things in the first section. A fast, readable builder site beats a slow custom one.
Own the domain, whatever else you do
This is the one decision that is difficult to reverse and costs almost nothing to get right.
Register the domain in the restaurant’s name, with the restaurant’s email as the contact, and keep the registrar login somewhere the owner can reach it. Not the designer’s account, not the marketing agency’s, not the platform’s.
The reason is simple: whoever is listed as registrant owns the name. When the relationship with a designer ends, or a platform’s pricing changes, or the site needs to move, the domain is what lets you take the business with you. Every link, every printed card, every listing that references your address keeps working.
The version of this that goes wrong is depressingly common: a restaurant discovers, years in, that the domain their menus and delivery listings all point at belongs to somebody who no longer returns emails.
Have the designer manage the DNS by all means. Just be the registrant.
What it costs to run
An honest monthly picture, because nobody publishes one.
- Domain: roughly the cost of a coffee, once a year. Check the renewal rate, not the promotional first year.
- Hosting: a static site or small managed WordPress plan is a few dollars a month. Builders are typically more, and rise.
- Bandwidth: usually within an included allowance for a restaurant, unless the site is heavy with unoptimised photographs.
- Booking or ordering platform: frequently the largest line, and often commission-based rather than flat.
- Someone to keep it current: the cost most often left out, and the reason so many restaurant sites show last year’s Christmas menu.
The commission on a third-party ordering platform is worth calculating annually rather than per order. A percentage of every order adds up to a number that often exceeds every other line on this list combined, which is a reason to make sure your own site and direct booking are the easy path rather than an afterthought.
The infrastructure end of this is genuinely small. If the site is expensive, it is almost always the platform fees and the commissions, not the hosting.
How this fits the rest of the stack
A restaurant website succeeds or fails on four things, and three of them are decided by how the menu is published and how heavy the images are. Both are one afternoon of work with a permanent effect. If you are choosing where the site lives, the RunxBuild hosting calculator shows static hosting, managed WordPress, and bandwidth as separate numbers, which makes it clear how small the hosting line really is next to platform fees and ordering commissions.
Useful related references:
- What Is a Static Website? Benefits, Examples, Hosting
- Website Management: What It Covers and What It Should Cost
- Deploy an Astro Website for Free
- Services on RunxBuild
FAQ
What should a restaurant website include?
A readable text menu, today’s opening hours visible without scrolling, the address with a tap-to-call number and a map link, and one obvious way to book or order. Photographs and story pages come after those four. A site that does the four well beats an elaborate one that buries them.
Should my menu be a PDF?
Not as the primary version. PDFs are hard to read on a phone, often download rather than open, and are invisible to search engines, so every dish name contributes nothing. Publish the menu as a web page with real text and keep the designed PDF as an optional download for printing.
How much does a restaurant website cost to run?
The hosting is genuinely small — a few dollars a month for a static site or a small managed WordPress plan, plus a domain renewal once a year. The larger costs are usually the booking or ordering platform, especially if it takes a commission per order, and whoever keeps the content current.
Who should own the restaurant domain name?
The restaurant, listed as registrant, with the registrar login accessible to the owner. Designers and agencies can manage the DNS without being the registrant. Restaurants discovering years later that their domain belongs to a former contractor is a common and entirely avoidable problem.
Why is my restaurant website slow on phones?
Almost always images. Hero photographs exported at full camera resolution, galleries loading everything at once, and video backgrounds are the usual causes, with a render-blocking booking widget close behind. Resizing images to display size and deferring third-party scripts fixes most of it without redesigning anything.