Restaurant Website Checklist for Dubai: Lessons from 537 Sites

A Dubai restaurant website needs five basics working together (HTTPS, a meta description, a menu as a web page, online booking and a WhatsApp button), and only 12 of 409 fully checked venue sites had all five.

Published 11 min read

A Dubai restaurant website needs five basics working together: HTTPS, a meta description, a menu as a web page, online booking and a WhatsApp button. In a check of Dubai venue sites, only 12 of 409 fully analysed sites (2.9%) had all five.

The numbers come from a study published in the Savage Media journal (Savage Media is the legal entity I work under). The sites were checked on 13 October 2026, starting from 582 Google Maps listings for Dubai restaurants and venues. Those listings led to 537 unique websites. Of those, 430 loaded and 409 could be parsed fully; 52 blocked automated checks. The full methodology and tables are in the Dubai Restaurant Websites Study 2026 on Savage Media.

This article skips the market overview. It turns each finding into a check you can run on your own site. It also lists the questions to put to whoever maintains the site.

Check 1: Does the site open at all?

Before you look at design, confirm that the address on your Google Business Profile loads. In the study, 55 of 537 sites (10.2%) did not open:

  • 22 domains did not resolve, which usually means an expired domain or broken DNS
  • 18 returned a 404 page
  • 12 timed out or had an SSL error
  • 3 returned a server error

How to check: 1. Open the exact URL from your Google listing on your phone, on mobile data, in a private tab. 2. Open it again with and without "www".

If either version fails, a guest who taps "Website" on Maps sees an error page instead of your menu. Your listing and your site need to agree. The local SEO checklist for Google Business Profile covers the listing side.

Also find out who owns the domain account. If a former agency registered it under their login, renewal depends on them.

Check 2: Is the menu a web page?

In the study: - 147 of 409 sites (35.9%) offered the menu only as a PDF. - 130 (31.8%) had the menu as a web page. - 29 (7.1%) sent guests to a menu platform or QR service.

A PDF on a phone means pinch, zoom and scroll sideways. It also hides your dishes from search. A guest searching "wagyu burger JBR" can land on an HTML page that names that dish. A PDF gives Google and AI assistants a harder file to read.

What a working menu page has:

  1. Dish names and prices in AED as plain text
  2. Sections that match how guests order (starters, mains, drinks)
  3. A last-updated date, so you notice when it goes stale
  4. A link to booking or WhatsApp at the top and bottom

Keep the PDF if your events team sends it to groups. Add the web page alongside it.

Check 3: Can a guest book in one or two taps?

The study found online booking on the homepage of 154 sites (37.7%). SevenRooms powered 100 of them (65%), Eat App 37 and OpenTable 18.

The bigger problem sits in the text. The word "book" appears on 66.3% of sites. Yet 76 sites (18.6%) say "book" and offer neither a booking tool nor WhatsApp. A guest reads "Book your table", taps, and finds a contact form or an Instagram link.

How to check: on your phone, start from the homepage and count taps until you have a confirmed request. - If it takes more than two taps, fix the path before anything else. - If the button opens a generic contact page, fix that too. - If your booking widget fails to load, the page should still show a phone number or WhatsApp link as a fallback.

Check 4: Is WhatsApp next to Instagram?

Only 139 of 409 sites (34.0%) had a WhatsApp button. Meanwhile, 226 sites (55.3%) linked to Instagram and skipped WhatsApp.

Instagram shows the food. WhatsApp is where a guest asks "Do you have a table for six at nine?" and gets an answer. Put a WhatsApp link with a pre-filled message ("Hi, I'd like to book a table for ___ on ___") in the header, or as a floating button on mobile.

Then decide who answers it during service. If nobody checks the number after 8 pm, route the chat to the shift manager's phone. If that is not possible, state the reply hours next to the button.

Check 5: How fast does it load on a phone?

Google publishes three Core Web Vitals thresholds for a good score: - Largest Contentful Paint (LCP): 2.5 seconds or less - Interaction to Next Paint (INP): 200 ms or less - Cumulative Layout Shift (CLS): 0.1 or less

You can read what each one measures in the Core Web Vitals entry.

Server response time comes before all of them. In the study, the median server response was 328 ms. WordPress ran 209 of 430 loaded sites (48.6%), with a median of 611 ms. 92 of those 209 sites (44%) took longer than 800 ms to start sending the page. On a slow server, a big hero video or a full-screen photo gallery pushes LCP past 2.5 seconds before the guest sees a single dish.

How to check: 1. Run your homepage and menu page through PageSpeed Insights on the mobile tab. 2. Look at the field data first, if Google has it. 3. Then look at server response time.

If the numbers come back red, Savage Media has a separate guide on website speed and Core Web Vitals for Dubai sites.

Check 6: Which languages do your guests read?

Of 409 sites: - 82 (20.0%) had an Arabic version. - 50 (12.2%) had Russian. - 38 (9.3%) had English, Arabic and Russian together.

Add a language when a real share of your bookings come from people who speak it. Then do it properly: - Each version gets its own URL (for example /ar/ and /ru/). - The menu and booking page exist in every language. - hreflang tags point the versions at each other.

The most common errors are listed in hreflang mistakes on RU/EN/AR sites. Arabic on signage, ads and websites can also carry legal requirements. Ask a lawyer or DET what applies to your licence.

Check 7: Can search engines and AI assistants read who you are?

Two quiet gaps showed up in the data: - 22.7% of sites had no meta description, so Google writes its own snippet from whatever text it finds. - 75.3% had some kind of schema markup, yet only 90 sites (22.0%) used the Restaurant type.

Restaurant schema gives search engines your cuisine, address, opening hours, price range, menu URL and booking URL in a structured way. A site with generic "Organization" or "WebSite" markup leaves those fields empty.

How to check: 1. Paste your homepage URL into the Schema Markup Validator (validator.schema.org). 2. Look for a "Restaurant" item in the results. 3. Write a meta description of one or two sentences with your cuisine, area and how to book.

Check 8: Do you know where bookings come from?

A third of sites (33.0%) had no analytics at all. The rest of the picture: - Google Analytics or Tag Manager: 66.3% - Meta pixel: 19.6% - TikTok pixel: 3.2%

Without analytics you cannot tell whether the website brings tables. At minimum: 1. Track clicks on the booking button and the WhatsApp button as events. 2. Add UTM parameters to the website link in your Instagram bio and Google listing, so visits from each source show separately.

The method for counting WhatsApp chats as leads is in tracking SEO leads from WhatsApp.

Also make sure form requests cannot vanish. On the Moon Mars site I built, every request is written to a file and also sent to Telegram, with a limit on requests per IP. If the notification fails, the request still sits in the file.

Check 9: Does the site look maintained?

Of 240 sites that printed a year in the footer, 58 (24%) showed 2024 or earlier. A guest may not read the footer. They do notice last season's brunch offer on the homepage, or opening hours that don't match Google.

How to check: 1. Open your site and your Google listing side by side. 2. Compare hours, phone, address and the current offer. 3. Set a monthly reminder to do the same. 4. Replace a hard-coded footer year with one that updates itself.

Questions to ask your web contractor

Use these before you sign or renew. The answers show whether the site will keep working after launch.

  1. When a price changes, who edits the menu page, and how long does it take?
  2. Which booking tool links from the homepage, and what does the guest see if it fails to load?
  3. Where do form and WhatsApp requests land, and how will I know a request came from the website?
  4. What is the server response time on mobile, and which hosting runs the site?
  5. Whose account holds the domain and SSL certificate, and when do they renew?
  6. Will each language have its own URL and hreflang tags?
  7. Which schema type will the homepage use?

If the contractor cannot answer questions 3 and 5, plan for those gaps yourself. If you want one person to handle the build from start to finish, see website development.

What not to do

  • Leave the PDF as the only menu. It hides dishes from search and frustrates phone users.
  • Write "Book now" and link to Instagram. That is the 18.6% pattern from the study: a booking promise with no booking path.
  • Put a 20 MB hero video on a slow WordPress host. The server delay and the file size stack up, and LCP goes past 2.5 seconds.
  • Run Arabic through a machine translator and publish it unchecked. Guests notice the errors, and the page may still fall under legal rules.
  • Install every pixel and never open the reports. Tracking helps only if someone reviews booking and WhatsApp clicks each month.
  • Let a past agency keep the domain login. One missed renewal and your site joins the 22 domains that did not resolve.

Checklist

# Check How to test it yourself Study figure (409 parsed sites unless noted)
1 Site opens from the Google listing Tap "Website" on Maps, on mobile data 55 of 537 (10.2%) did not open
2 HTTPS without errors Padlock in the browser, with and without www Part of the five basics
3 Menu as a web page Open the menu on a phone without zooming 130 (31.8%) had one; 147 (35.9%) PDF only
4 Booking reachable from the homepage Count taps to a confirmed request 154 (37.7%)
5 "Book" text leads somewhere Tap every "book" link 76 (18.6%) had dead ends
6 WhatsApp button Tap it, check the pre-filled message 139 (34.0%)
7 Server response and Core Web Vitals PageSpeed Insights, mobile tab Median 328 ms; WordPress median 611 ms
8 Language versions with own URLs Switch language, check URL and hreflang AR 20.0%, RU 12.2%, all three 9.3%
9 Meta description View page source or Search Console Missing on 22.7%
10 Restaurant schema Schema Markup Validator 90 (22.0%)
11 Analytics with booking and WhatsApp events Click both buttons, check the real-time report None on 33.0%
12 Hours, phone and offer match Google Compare site and listing side by side Footer year 2024 or earlier on 58 of 240 (24%)

Work through rows 1, 3, 4 and 6 first. They decide whether a guest who finds you on Maps can see the menu and get a table. Next, run row 7 on both the homepage and the menu page. Then put row 12 in your calendar as a monthly check.

Questions and answers

Is a PDF menu enough for a restaurant website in Dubai?

A PDF works as a download, but it should not be the only menu. In the Savage Media study, 147 of 409 venue sites (35.9%) offered the menu only as a PDF, which is hard to read on a phone and gives search engines and AI assistants less text to work with. Put the menu on an HTML page and keep the PDF as an extra.

Which booking system should a Dubai restaurant use?

The study found SevenRooms on 100 of the 154 sites with online booking on the homepage, followed by Eat App (37) and OpenTable (18). The tool matters less than the path: a guest on a phone should reach a working booking form or a WhatsApp chat in one or two taps from the homepage.

Do I need Arabic and Russian versions of my restaurant site?

It depends on who books your tables. In the study, 82 sites (20.0%) had Arabic, 50 (12.2%) had Russian and only 38 (9.3%) had English, Arabic and Russian together. If you add a language, give each version its own URL and set hreflang correctly, and ask a lawyer about Arabic requirements for your licence.

How fast should a restaurant website be?

Google's Core Web Vitals thresholds for a good score are LCP of 2.5 seconds or less, INP of 200 ms or less and CLS of 0.1 or less. In the study, the median server response across sites was 328 ms, while WordPress sites had a median of 611 ms and 92 of 209 took longer than 800 ms.