What a restaurant website is actually for

A visitor arriving at a restaurant website is almost always doing one of four things: checking the menu, checking the hours, finding the location, or trying to order or book. Everything else on the site is secondary to those four, and any design decision that slows them down is costing business.

## The four tasks

**The menu.** The most requested item and the most frequently mishandled. A menu published as a PDF is a menu that cannot be read comfortably on a phone, cannot be found by search, and is usually out of date because updating it requires a designer.

**The hours.** Including today's hours specifically, and including whether the venue is open right now. Inherited opening hours that were correct two seasons ago are worse than none.

**The location.** With a working map link, and with parking or access information if it is not obvious.

**Order or book.** One step from the homepage, in the way the venue actually takes orders and bookings.

If those four are fast and correct, the site is doing its job. If they are not, no amount of photography compensates.

## Why the PDF menu is worth singling out

It fails on every axis at once. It is slow to load, awkward to zoom, invisible to search engines, inaccessible to screen readers, and impossible for a team member to update without going back to whoever made it. The result is a menu that drifts out of date, which then makes the whole site untrustworthy.

A menu published as web content — text, in both languages, editable by the team — solves all of those problems at once, and it is also the single highest-value page for search.

## Bilingual as a build decision, not a toggle

In a bilingual market, Arabic and English are not two versions of the same site with a switch between them. They are two audiences with different reading directions, different typography needs and often different content priorities.

A site where the Arabic version is a translated afterthought is visible instantly: line lengths that do not work, type that is too small, layouts that were designed left-to-right and mirrored without being redrawn. Building both from the start costs less than fixing one later.

## The site you own versus the platforms you rent

Aggregator listings deliver reach, and they take a commission for it. A website is the only channel where the relationship and the margin are entirely yours.

That does not mean abandoning the platforms; it means using the site to convert the guests who already know you into direct orders, where the same meal earns materially more. The direct channel needs a reason to be used — and that reason has to be given, not assumed.

## The technical basics that are not optional

Structured data so that hours, location and menu appear correctly in search results. Fast loading on a mobile connection. Content editable by the team without a developer. Accurate metadata in both languages. None of these are visible to a guest, and all of them decide whether the guest arrives at all.

## Practical recommendations

1. Open your own site on a phone, on mobile data, and time how long it takes to answer each of the four tasks.
2. Replace any PDF menu with editable web content in both languages.
3. Check that today's hours are correct — and that they update for holidays.
4. Make ordering or booking reachable in one step from the homepage.
5. Build the Arabic experience as an equal, not as a translation layer.
6. Give guests a specific reason to order direct rather than through a platform.

## In short

A restaurant website is a utility before it is a brand expression. Make the four tasks fast and correct first; everything else on the site is only worth doing once those are done.