Multilingual restaurant website: URLs, hreflang and translation

Your restaurant or hotel welcomes guests who do not speak French: tourists, expats, business travellers. A well-built multilingual restaurant website lets them read the menu, understand your offer and book in their own language. Badly built, it shows the wrong language to the wrong visitor, and Google may never surface your translated pages.

This guide answers the technical questions restaurateurs and hoteliers ask: which URL structure to choose, how to set up hreflang tags according to Google Search Central documentation, how to translate, how to design the language selector and the sitemap. The technical points come from Google's and Webflow's official documentation; no traffic promise is made.

Multilingual restaurant website: do you really need several languages?

Before choosing a technique, ask the fundamental question: which languages do your actual guests speak? Look at your bookings, your reviews, the most frequent nationalities in your guest database and the languages of your site visitors in your analytics tool.

Common-sense rules:

• start with one extra language (often English), translated properly, rather than five approximate ones;
• translate the pages that drive bookings first: home, menu, booking, practical info, private hire;
• do not translate what you cannot keep up to date: an outdated English menu is worse than no English menu;
• a language is not a country: "English" does not mean "United Kingdom" or "United States". Only create country versions if the content really changes (prices, offers, contact channels).

At māhie, we build multilingual sites for an international clientele, from Dubai to Singapore, and the same logic applies to a Paris address that receives many foreign visitors.

Multilingual website URL structure: subdirectories, subdomains or domains

In its documentation on multi-regional sites, Google describes three usable structures, each with advantages and limits:

• subdirectories (example.com/en/): simple to set up and maintain on one host, but separation between sites is less clear;
• subdomains (en.example.com): easy to set up, but visitors cannot always tell whether "en" means a language or a country;
• country domains (example.fr, example.de): clear geotargeting, but expensive, sometimes with strict registration conditions, and only one country targeted per domain.

The documentation advises against URL parameters (example.com?loc=de), which are hard to segment and unclear to users.

For a restaurant or hotel, subdirectories are the most common choice: one site, one domain to maintain, shared administration. Also keep these rules:

• a different URL per language: Google recommends separate URLs rather than cookies or browser settings to serve the language;
• one language per page, for content and navigation, with no side-by-side translations;
• readable URLs, translated where possible (example.com/en/menu/), and stable over time.

Hreflang and sitemap: what Google Search Central asks for

Hreflang tags tell Google which version of a page matches which language (and, if needed, which region). Here is what Google's documentation on localized versions says.

Three equivalent methods. You can declare variants in the page code (link tags with rel="alternate" and hreflang, in the head), in an HTTP header (useful for non-HTML files such as PDFs), or in the XML sitemap. Google states the three methods are equivalent from its point of view: choose the one you can maintain, there is no point stacking them.

The rules to follow:

• each version lists itself and lists all the other versions;
• links must be reciprocal: if two pages do not point to each other, the tags are ignored;
• URLs must be fully qualified, with the protocol (https://example.com/en/, not /en/);
• language codes follow ISO 639-1 (fr, en, de…) and region codes ISO 3166-1 alpha 2 (FR, GB, US…). You can write fr or fr-FR, but never a country code alone;
• the value is case-insensitive;
• x-default designates the fallback page when no language matches; Google recommends it especially for language selector pages or auto-redirecting home pages.

Google also states that it uses neither hreflang nor the HTML lang attribute to determine a page's language: it works it out from the content itself. A genuinely translated page therefore remains the condition for everything else.

In the sitemap. The declaration uses xhtml:link elements, with the xhtml namespace declared on the urlset tag. Each URL in the sitemap contains an entry for every version of the page, itself included, and all entries in a group repeat the same set of links. Order does not matter. The sitemap must sit in a directory that covers the URLs it lists.

Illustration with fictional addresses: the French home page is example.com/, the English version example.com/en/. Each declares fr pointing to example.com/, en pointing to example.com/en/, and x-default pointing to the fallback page you have chosen.

Translating the website: human, reviewed and up to date

Translation is where restaurants lose the most quality. A few principles:

• have a person who masters the target language and knows hospitality translate or review. Dish names, cooking methods and seasonal products translate poorly word for word;
• keep a dish's original name if it is well known, and add a short description in the visitor's language;
• translate everything guests read to book: buttons, error messages, confirmation emails, cancellation terms. A translated site with a booking module left in French loses the conversion at the last click;
• do not translate halfway: Google warns against translating only the template while content stays in another language, because the experience is poor;
• do not publish machine-translated text in bulk without review. Google's spam policy targets content produced at scale with no value for users, including automated transformations such as translation when it is about copying other sites. It does not forbid translation as such, but it recalls the right criterion: each page must bring something to the reader.

Also think about everything that is not body text: title tags and meta descriptions in every language, image alt text, structured data (name, description, menu) and your Google Business Profile.

Language selector and redirects: let the visitor choose

The language selector is a simple component, but badly designed it costs guests and visibility.

• Place it in the header, visible on every page, on mobile and desktop;
• write each language in its own language (Français, English, Deutsch), rather than flags: a flag stands for a country, not a language;
• link to the equivalent page, not always to the other language's home page: the French menu leads to the English menu;
• make each choice a real link to a URL, not a script that swaps the text in place: links are what Google can crawl.

Avoid automatic redirects. Google's documentation warns that redirecting based on an assumed language can prevent users and search engines from seeing all versions of the site. Googlebot does not send an Accept-Language header and mostly crawls from the United States: detection by browser language or IP, or a choice stored in a cookie, may hide your other versions from it. Google also describes IP location analysis as difficult and generally not reliable. The safest approach: a visible link, and possibly a discreet banner that suggests the likely language without imposing it.

Multilingual site on Webflow: hreflang, sitemap and selector

Webflow offers a localization feature. According to Webflow's documentation and its updates, at the time of writing:

• hreflang tags are generated automatically for locales published in subdirectories; you can use page-level tags, the sitemap, or both, updated on every publish;
• only locales with a subdirectory and publishing enabled appear in the automatically generated sitemap. Since a September 2025 update, this sitemap lists all localized routes, each with a self-referencing hreflang;
• if you use a custom sitemap, you must add hreflang by hand, page by page;
• the language selector is built with a Dropdown element and the Locales list; switching language leads to the equivalent page;
• the primary locale has no subdirectory by default, but you can enable publishing to a subdirectory;
• before launch, Webflow's checklist recommends reviewing hreflang and the sitemap, adding 301 redirects for localized paths and avoiding subdirectory names that match an existing page, folder or collection.

These features and their labels evolve: check them in Webflow's help center before you start. In every case, test the result: open each page's source or the sitemap and check that links are reciprocal.

Launch checklist:

• one URL per language, in a subdirectory, without parameters;
• hreflang present, reciprocal, with full URLs and an x-default;
• sitemap up to date and submitted in Search Console;
• language selector visible, made of links, pointing to the equivalent page;
• booking module, emails and cancellation policy translated;
• title, meta description, alt text and structured data translated.

Multilingual restaurant website: frequently asked questions

Need help building your multilingual restaurant website?

A successful multilingual site depends on many details that overlap: URL structure, hreflang, translations, selector, sitemap, booking module. One mistake in one place makes the rest invisible or unreadable.

māhie is a Webflow partner agency, with more than 70 sites built, including multilingual sites for an international clientele. For your project, we can:

• define the structure: useful languages, URLs, hreflang and sitemap;
• build the site on Webflow, with a language selector and equivalent pages;
• integrate booking (SevenRooms or your own tool) in every language, without leaving the site;
• set up a simple back office, so your teams update menus and events in each language;
• check SEO and performance before launch, then after.

Discover our websites for restaurants and hotels, then Contact māhie: we review together which languages you really need.