We Looked at 30 Czech Restaurant Websites. 26 Had the Same Problem.

One Tuesday in April we ran an experiment. We took the Czech Google results for restaurace Praha 6, restaurant Brno centrum, obědové menu Ostrava, and seven other queries a hungry person actually types. We pulled the first thirty unique restaurant websites that came up. Then we opened each one on a phone, because that is where roughly 70% of restaurant traffic first sees you, and we audited them the way a customer making a Friday-night decision would.

The result surprised us less than it surprised everyone we showed the spreadsheet to. The designs were mostly fine. Hero photo of the dining room, brand colours, a couple of plate close-ups. Some elegant, some dated, a few genuinely beautiful. That part is not the story.

The story is that twenty-six of the thirty had the same critical problem in the same place: their menu was a PDF. Sometimes a designed PDF, sometimes a scan of a printed menu, occasionally an image saved from the kitchen's last reprint. In two cases the file weighed more than 8 MB. In one case, opening it on iPhone Safari simply failed.

If you own a restaurant in the Czech Republic, this is the post we wish we had written six months ago. The menu is the single most important page on your site. And on three quarters of Czech restaurant websites in 2026, it is also the page that is least usable, least findable, and least up to date.

The thirty we looked at

To keep this honest: we did not cherry-pick the bad ones. We searched the way an out-of-town visitor or a local with an empty Friday night would search. Six cities, ten query types, the first thirty unique domains we had not already seen. A bistro charging 220 CZK for a daily lunch sat next to a fine-dining restaurant charging 1,800 CZK for a tasting menu. We treated them the same.

For each site we ran six checks on a phone:

1. How is the menu published, HTML page, embedded PDF, downloadable PDF, image, or external link to a third-party site?
2. How fast does the homepage load on a mid-range Android device (mobile Lighthouse)?
3. Are the opening hours written in HTML text, or trapped in an image, PDF, or footer graphic?
4. Is there a working reservation flow on mobile, or do you have to call?
5. Is there Restaurant or LocalBusiness structured data on the page, as covered in our technical SEO checklist?
6. Does the Google snippet on the search results page show the menu, hours, and a working phone tap?

Below is what came back.

The findings, with numbers

The PDF menu was so universal we want to spend the rest of the post on it. If you only fix one thing on your restaurant's site this month, this is the one. The performance and reservation numbers matter too, and we covered the mechanics of speed in detail in why slow pages lose you customers.

Why the PDF menu is the most expensive cheap decision a restaurant makes

A PDF menu feels like the obvious choice. You already designed the printed menu. The kitchen prints from it. Drop the same file on the website and the website is done.

Here is what that decision actually does.

It hides your menu from Google. Google can technically read PDF text, but it does not index, snippet, or rank a PDF the way it ranks an HTML page. When a hungry diner in Letná searches for burger Praha 7, the restaurants whose burger names and prices live in HTML show up. The ones whose burgers live in a PDF do not. This is the single biggest lever you have for cheap, sustained local visibility, and it is the one you give away every time you upload menu.pdf. The underlying mechanic is in our local SEO guide.

It punishes mobile users. The diner taps menu, waits two to five seconds for a PDF to download, then has to pinch, zoom and swipe horizontally to read 9-point type set for paper. On a 6-inch phone screen the experience is genuinely bad. Roughly half of the diners who tap that link bounce before they decide. You do not see the bounce in your inbox. You see it in the empty seats on Tuesday.

It hides errors that cost you money. Three of the thirty sites we audited had PDF menus that listed prices the restaurant no longer charged. One had a dish that had been off the menu for over a year. When the menu is a printable file, updating it means redesigning, re-exporting, re-uploading. So nobody does it. An HTML menu changes in fifteen seconds, by anyone, from a phone.

It breaks translation and accessibility. Screen readers struggle with image-based PDFs. Browser auto-translate works on HTML, but not on a scanned image. If your restaurant is in a tourist district and your menu only exists as a Czech PDF, the German, English and Russian-speaking diners walking past your front door cannot read it before deciding to come in.

It drags down Core Web Vitals. Heavy PDF assets, especially when embedded in the page, hurt the loading metrics that Google now uses as a ranking signal. For restaurants competing on local search, that is rankings you are losing for a reason no diner ever sees.

What the four restaurants that got it right were doing

Four of the thirty had their menu in clean HTML. They had three things in common.

First, the menu was a page on the site, not a download. Dish name, two-line description, allergen icons, price, all in real text. Categories were headings, not images. You could scroll the menu on a phone the way you scroll a recipe.

Second, the menu page had Restaurant schema. That is the structured data that lets Google show your menu items, hours, and reservation link directly in search results. Three of the four restaurants had earned a Google place panel that displayed the daily menu without anyone having to click through. That is free advertising your competitors with PDF menus literally cannot buy.

Third, the page was light. Hero image under 200 KB, food photos served as WebP, fonts loaded with font-display: swap. Mobile Lighthouse scores in the eighties and nineties. Pages loaded in under two seconds on a city tram with two bars of signal.

None of these four sites were expensive. Two were built on WordPress with a custom theme. One was on Squarespace. One was custom Nuxt. The platform did not matter. The discipline did.

What to do this week

You do not need to redesign the site. You probably do not even need a new agency. You need to do four things, in order, none of which take more than half a day if you have the menu data in any digital form.

1. Open your own site on your phone. Tap the menu. Time it. If you waited more than three seconds, or had to zoom, or saw a PDF reader take over the screen, that is your customer's experience, twenty times a day.
2. Google your restaurant's name plus the word menu. Look at what shows up in the snippet. If it does not surface a dish or a price, Google does not know what you serve.
3. Get the menu into HTML. A single page with categories as H2s, dishes as H3s with two-line descriptions and prices, allergens as small icons. No PDF. No image of paper. Just text on a page. If your current site uses WordPress, this is a one-evening task. If it does not, almost any agency, including us, will do it as a fixed-fee fix without rebuilding anything.
4. Add Restaurant schema. Validate it with Google's Rich Results Test. Within a week or two, you will start showing up with menu data in local search.

Optional next steps once the menu is fixed: a real mobile reservation flow rather than a phone link, opening hours in HTML rather than baked into the footer image, and hero images compressed and served responsively. The full pre-flight inventory we use on launches is in our technical SEO checklist for new launches.

Frequently asked questions

Why do so many restaurants use PDF menus?

Because the kitchen already has one. Print, scan, upload, done. The decision is made by whoever is closest to the file, not by whoever is closest to the customer. There is no malice. There is no laziness. There is a tiny, reasonable shortcut that costs the restaurant covers every week for years.

Can we keep the PDF for printing and put an HTML version on the site as well?

Yes, and that is the right answer. Keep your PDF for guests at the table or for printers. Put the same content as an HTML page for the website. They are different jobs done by different formats.

What about Lunchtime, Zomato, TheFork: are those enough?

They help, but they are not your home base. Your menu on TheFork ranks for TheFork's domain, not yours. Diners searching your restaurant + menu still land on your site. If your site is a dead end, you have trained Google to send those diners somewhere else next time.

Do we need an English menu page?

If you are within walking distance of any tourist area in Prague, Brno, Český Krumlov, Karlovy Vary, or near major hotels, yes. The marginal cost of translating a single menu page is a couple of hours. The marginal benefit is every German-, English-, Russian- and Ukrainian-speaking diner who walks past your window after checking their phone. Our overview of restaurant websites covers the multilingual setup in more detail.

How much should a fix like this cost?

Pure menu-to-HTML conversion on an existing site: between 3,000 and 12,000 CZK depending on the platform and how the current site is built. Adding Restaurant schema on top: a few hours of work. A full restaurant website rebuild including reservations and a translated menu starts at around 25,000 CZK, with realistic numbers in our 2026 cost breakdown and on our pricing page.

The bottom line

Restaurant websites in the Czech Republic are not failing because of design. They are failing because the most important page on the site is locked inside a file format designed for paper. Twenty-six of thirty restaurants we looked at are leaving covers on the table every week because of a decision someone made in fifteen seconds two years ago.

If you want us to run this same audit on your restaurant specifically, your menu, your speed, your schema, your reservation flow, get in touch. We will send you the same six-line spreadsheet we used for the thirty, with your numbers in it. Whether you hire us to fix anything is a separate conversation.

The full overview of how we approach restaurant websites, including reservations, multilingual menus, and integrations, is on the dedicated page.