Back to Blog

Restaurant websites get judged in about ten seconds, usually by someone standing on a street or sitting in a car deciding where to eat. That context should determine every decision, and it usually determines none of them.

The three-second test

If a visitor cannot get all three within a few seconds on a phone, the design has failed regardless of how it looks on a designer's monitor.

Why the PDF menu is the single worst decision

It is slow to open on mobile data. It requires zooming and panning to read. It cannot be updated without regenerating a file. And it is largely invisible as content, so the dishes you serve do not exist as far as search is concerned.

A menu built as a web page fixes all four at once. It loads instantly, reads properly on a phone, can be edited in a minute when a price changes, and makes every dish something a search engine can actually find.

Hours, stated like someone is asking right now

"Mon-Fri 11-9" is a table. What a visitor wants is whether you are open now, and whether you are open on the holiday coming up. Sites that answer the immediate question outperform sites that publish a schedule, and holiday hours are the single most common cause of an annoyed customer arriving at a closed door.

Photography, and the stock problem

Real photographs of your actual food and room do work that copy cannot. Stock food photography does the opposite: people recognise it, and recognising it plants the idea that the real thing will not match.

This is one of the few places where spending on a photographer returns more than spending on the site itself.

Ordering and reservations

If takeaway matters to your margins, taking orders on your own site avoids the commission third-party platforms charge. The honest tradeoff is that those platforms bring discovery, so the practical answer is usually both, with your own path made obvious.

If you take reservations, make it one tap from anywhere. If you do not, say so, because silence reads as maybe and loses the table either way.

We build hospitality sites as custom work rather than templates, and our piece on restaurants and AI search covers how these places get recommended when someone asks an assistant where to eat.

Questions

What do people actually want from a restaurant website?

The menu, the hours and the address, in that order, on a phone, in a hurry. Almost every other element is decoration. A site that delivers those three instantly outperforms a beautiful one that buries them.

Should the menu be a PDF?

No. PDFs are slow to open on a phone, difficult to read without zooming, invisible to search engines in the way a page is, and awkward to update. A menu as an actual web page solves all four problems.

Do restaurants need online ordering on their own site?

If takeaway is a meaningful part of the business, ordering on your own site avoids the commission that third-party platforms take. The tradeoff is that those platforms bring discovery you would otherwise have to earn.

How important is mobile for restaurant websites?

It is effectively the only thing that matters. This searching happens on phones, often while people are already out and deciding. A site that is acceptable on desktop and slow on mobile is failing at the only moment it is used.

Do restaurants need food photography?

Real photography of your actual food, yes. Stock food imagery is widely recognisable and actively harmful, because it signals that what arrives will not look like the picture.

What about reservations?

If you take them, make booking possible in one step from any page, not just a contact page. If you do not, say so plainly, because the absence of an answer reads as a maybe and costs you the walk-in.