A Restaurant Site You Cannot Read on a Phone

The situation the site is for

Somebody on a phone, on the street, at six in the evening, deciding between three places.

They want to know: is it open, what is on the menu, roughly what it costs, and where exactly it is.

They will spend perhaps twenty seconds finding that out before giving up and choosing somewhere else.

Almost every restaurant website is built for an entirely different visitor: somebody at a desk, with plenty of time, admiring the photography.

The menu as a PDF

The single most common and most damaging mistake in this trade.

A PDF downloads rather than opening, then appears at a size where the text is unreadable, and requires pinching and dragging to navigate.

On a phone that is three or four interactions before anybody can read a single dish.

It is also invisible to search, which means somebody searching for a dish you actually serve will never find you, and it cannot be read by anybody using a screen reader.

The menu should be text on a page. It is more work to maintain than a PDF, and it is by some distance the single highest-value page a restaurant has.

Hours in an image

The second most common, and it fails in the same ways.

Opening hours rendered as a graphic cannot be read by search engines, cannot be selected or copied, cannot be read aloud, and frequently displays at an unreadable size on a phone.

It also means the hours in your listing and the hours on your site are maintained separately, and they drift apart.

Hours should be text, near the top, with any variations stated: different on Mondays, closed between services, different at weekends.

And a note about holiday opening, kept updated, because a holiday weekend is exactly when somebody most needs to check and least expects the site to be right.

Where the address is

In the footer, in small text, not linked to a map.

Somebody trying to find you is copying it manually into their maps application, which on a phone is several steps and error-prone.

The address belongs near the top, as text, linked so that tapping it opens directions.

And the phone number beside it, tappable, since a proportion of people want to check availability rather than read a menu.

For a restaurant those two items are more important than the photography, and they are usually the two least prominent things on the page.

The photography, which is the good part

Worth saying, because restaurant sites frequently get this right.

The images are appetising, well lit and genuine rather than stock, which does real work in the decision.

The problem is not the photographs. It is that they occupy the entire first screen on a phone, so the practical information sits below three full screens of scrolling.

One good image, then the hours, address and menu link, then the rest of the photography further down.

That ordering serves both the person deciding tonight and the person browsing at leisure, and it costs nothing at all in visual quality.

A walkthrough on a phone

1. The page loads to a full-screen image with the name over it.
2. Scroll, to a paragraph about the chef's philosophy.
3. Scroll, to more images.
4. Scroll, to a Menu link that downloads a PDF.
5. The PDF opens at a size requiring zoom.
6. Give up, or persist and eventually find the hours as an image at the bottom.

That sequence takes over a minute and asks the visitor to do a lot of work to learn things the restaurant wanted them to know.

What the menu page should contain

Since converting it is the largest job on the list, worth being specific about the result.

Dish names as headings, descriptions as text, and prices beside them. Sections for courses, readable in order.

Dietary information marked consistently, which people genuinely need and frequently phone to ask about.

A note on how current it is, since menus change and a page dated last spring is treated with suspicion.

And no images between every dish, which turns a scannable list into an endless scroll on a phone.

Done properly, that page will be the most visited on the site by a wide margin, and it will bring people who searched for a dish rather than for a restaurant.

Booking

Handled inconsistently, and worth resolving.

If you take bookings, the option should be visible without scrolling, and it should work on a phone.

If you do not take bookings, say so plainly, because somebody looking for a booking button and not finding one assumes the site is broken rather than that the policy is walk-in only.

And if bookings go through a third-party system, make sure the link works and that the system knows your current hours, since a booking widget offering times you are closed is worse than no widget.

The counter-case

Where a different approach is right.

A fine dining restaurant where the site is part of the experience and somebody is planning weeks ahead at a desk, though even there the practical information should be findable.

A place with no menu in any fixed sense, where a daily board is the offer, and the site's job is to show today's rather than a permanent list.

And a business that is primarily delivery, where the ordering platform is the product and the site is a signpost to it.

None of those cases changes the address, hours and phone requirements. They only change what sits between them on the page.

What to change first

1. Menu as real text on a page.
2. Hours as text, near the top, with variations.
3. Address linked to directions, near the top.
4. Tappable phone number.
5. One image before the practical information, not four screens.
6. A clear statement about bookings.

The first is the most work and returns the most by a wide margin, because it makes every dish you serve findable by somebody searching for it, which no PDF ever will.

Why images of text cause this problem is covered in describing an image for somebody who cannot see it.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.