Restaurants
Hours, menu, address, phone. In that order, in five seconds
Almost every visit to a restaurant website is somebody standing outside or sitting in a car, checking one of four things. A site that makes them wait for a video loop loses them to the place next door.
The four things, and nothing in front of them
- Are you open right now? Today's hours, including the ones that differ on holidays.
- What is on the menu, and what does it cost? As readable text on the page: never a PDF, and never a photograph of a printed menu.
- Where are you and how do I park? Address, a link to maps, and parking, which everybody asks and almost nobody publishes.
- How do I book or order? One tap to the phone, or a link to whichever booking or delivery service you actually use.
The PDF menu is the single most common mistake
A menu in a PDF is slow to open on a phone, difficult to read without zooming, invisible to search engines in any useful way, and unusable by anybody with a screen reader. It is also almost always out of date, because updating it means finding the design file. A menu written as a page is faster, findable, readable aloud, and something you can change yourself in minutes.
That last point does most of the work. A menu you can edit by asking gets updated when a price changes; a menu that requires a designer does not.
What we build for a restaurant
- The menu as real, readable pages: by section, with prices and dietary notes.
- Hours you can change yourself, including special hours, which is the most frequently wrong information on restaurant websites.
- <code>Restaurant</code> structured data with hours, address, phone, price range and cuisine, which is what feeds the panel people see in search results.
- Links out to whatever booking, ordering or delivery platform you actually use, rather than a copy of it.
- Photographs of your own food, compressed hard at build time so they load rather than merely exist.
- Pages for private dining, catering and events if you do them. These are the highest-value enquiries and usually the thinnest pages on the site.
If you already have a site
A rebuild keeps every existing address, redirects tested against the live site. Restaurant sites often have an old menu page or a location page carrying years of links, and those keep working. How a rebuild works.
What it costs
$1,500 new, $1,800 rebuild, at the launch rate for our first five clients, then $79 a month.
- New site / rebuild
- $1,500 / $1,800, launch rate
- Monthly
- $79
- Structured data type
- Restaurant
- Menu
- Readable pages, not a PDF. Changed by asking
- Booking and delivery
- Linked to the platforms you already use
Send us your current menu and your hours. That plus a few photographs is most of a restaurant site.
Restaurant website questions
Can we keep our menu as a PDF?
You can, and we will ask you not to. A PDF menu is slow on a phone, unreadable to a screen reader, invisible to search, and it is the reason most restaurant menus online are out of date. As a page it is faster, findable, and you can change a price yourself in minutes.
Can people book a table through the site?
Through whichever booking platform you already use, linked from the site. We will not rebuild a reservation system, and a static site should not pretend to hold your table availability.
What about our delivery apps?
Linked, prominently, if you want the orders. Worth knowing: a customer who orders direct is worth considerably more to you than the same order through a marketplace, so it is usually right to make your own phone number at least as prominent.
Do we need a page for catering?
If you do catering at all, yes, and a real one. Catering and private dining enquiries are the largest single orders most restaurants take and they are usually represented by one sentence and an email address.