Site de restaurant multilingue : URL, hreflang et traduction

Votre restaurant ou votre hôtel accueille des clients qui ne parlent pas français : touristes, expatriés, clientèle d'affaires. Un site de restaurant multilingue bien construit leur permet de lire la carte, de comprendre l'offre et de réserver dans leur langue. Mal construit, il affiche la mauvaise langue au mauvais visiteur, et Google peut ne jamais montrer vos pages traduites.

Ce guide répond aux questions techniques que se posent les restaurateurs et hôteliers : quelle structure d'URL choisir, comment poser les balises hreflang selon la documentation Google Search Central, comment traduire, comment concevoir le sélecteur de langue et le sitemap. Les points techniques viennent de la documentation officielle de Google et de Webflow ; aucune promesse de trafic n'est faite.

Site de restaurant multilingue : faut-il vraiment plusieurs langues ?

Avant de choisir une technique, posez la question de fond : quelles langues parlent vos clients réels ? Regardez vos réservations, vos avis, les nationalités les plus fréquentes dans votre fichier client et les langues des visiteurs de votre site dans votre outil de mesure.

Règles de bon sens :

• commencez par une seule langue de plus (souvent l'anglais), traduite correctement, plutôt que cinq langues approximatives ;
• traduisez d'abord les pages qui font réserver : accueil, carte, réservation, infos pratiques, privatisation ;
• ne traduisez pas ce que vous ne pouvez pas tenir à jour : une carte anglaise périmée est pire que pas de carte anglaise ;
• une langue n'est pas un pays : « anglais » ne dit pas « Royaume-Uni » ou « États-Unis ». Ne créez des versions par pays que si le contenu change vraiment (prix, offres, moyens de contact).

Chez māhie, nous construisons des sites multilingues pour une clientèle internationale, de Dubaï à Singapour, et la même logique s'applique à une adresse parisienne qui reçoit beaucoup de visiteurs étrangers.

Structure d'URL d'un site multilingue : sous-dossiers, sous-domaines ou domaines

Google décrit dans sa documentation sur les sites multirégionaux trois structures utilisables, chacune avec ses avantages et ses limites :

• sous-dossiers (exemple.com/en/) : simples à mettre en place et à maintenir sur un seul hébergement, mais la séparation entre sites est moins nette ;
• sous-domaines (en.exemple.com) : faciles à installer, mais le visiteur ne sait pas toujours si « en » désigne une langue ou un pays ;
• domaines par pays (exemple.fr, exemple.de) : géociblage clair, mais coûteux, avec parfois des conditions strictes d'enregistrement, et un seul pays ciblé par domaine.

La documentation déconseille les paramètres d'URL (exemple.com?loc=de), difficiles à segmenter et peu clairs pour l'utilisateur.

Pour un restaurant ou un hôtel, les sous-dossiers sont le choix le plus courant : un seul site, un seul domaine à faire vivre, une administration commune. Gardez aussi ces règles :

• une URL différente par langue : Google recommande des URL distinctes plutôt que des cookies ou des réglages du navigateur pour servir la langue ;
• une seule langue par page, pour le contenu comme pour la navigation, sans traductions côte à côte ;
• des URL lisibles, traduites si possible (exemple.com/en/menu/), et stables dans le temps.

Hreflang et sitemap : ce que demande Google Search Central

Les balises hreflang indiquent à Google quelle version d'une page correspond à quelle langue (et, si besoin, à quelle région). Voici ce que dit la documentation de Google sur les versions localisées.

Trois méthodes équivalentes. On peut déclarer les variantes dans le code de la page (balises link avec rel="alternate" et hreflang, dans l'en-tête), dans un en-tête HTTP (utile pour les fichiers non HTML comme les PDF), ou dans le sitemap XML. Google précise que les trois méthodes sont équivalentes de son point de vue : choisissez celle que vous pouvez maintenir, inutile de les cumuler.

Les règles à respecter :

• Chaque version se liste elle-même et liste toutes les autres versions ;
• les liens doivent être réciproques : si deux pages ne se pointent pas l'une l'autre, les balises sont ignorées ;
• les URL doivent être complètes, avec le protocole (https://exemple.com/en/, et non /en/) ;
• les codes de langue suivent la norme ISO 639-1 (fr, en, de…) et les codes de région l'ISO 3166-1 alpha 2 (FR, GB, US…). On peut écrire fr, ou fr-FR, mais jamais un code pays seul ;
• la valeur est insensible à la casse ;
• x-default désigne la page de repli quand aucune langue ne correspond ; Google le recommande en particulier pour les pages de sélection de langue ou les pages d'accueil qui redirigent automatiquement.

Google précise aussi qu'il ne se sert ni de hreflang ni de l'attribut HTML lang pour déterminer la langue d'une page : il l'établit lui-même à partir du contenu. Donc une page traduite pour de bon reste la condition de tout.

Dans le sitemap. La déclaration passe par des éléments xhtml:link, avec l'espace de noms xhtml déclaré dans la balise urlset. Chaque URL du sitemap contient une entrée pour chaque version de la page, elle-même comprise, et toutes les entrées d'un même groupe répètent le même ensemble de liens. L'ordre n'a pas d'importance. Le sitemap doit être placé dans un répertoire qui couvre les URL listées.

Illustration avec des adresses fictives : la page d'accueil française est exemple.com/, la version anglaise exemple.com/en/. Chacune déclare fr vers exemple.com/, en vers exemple.com/en/, et x-default vers la page de repli que vous aurez choisie.

Traduction du site : humaine, relue et à jour

La traduction est le point où les restaurants perdent le plus de qualité. Quelques principes :

• faites traduire, ou relire, par une personne qui maîtrise la langue cible et connaît la restauration. Les noms de plats, les modes de cuisson et les produits de saison se traduisent mal mot à mot ;
• gardez le nom d'un plat dans sa langue d'origine s'il est connu, et ajoutez une courte description dans la langue du visiteur ;
• traduisez tout ce que le client lit pour réserver : boutons, messages d'erreur, e-mails de confirmation, conditions d'annulation. Un site traduit avec un module de réservation resté en français perd la conversion au dernier clic ;
• ne traduisez pas à moitié : Google met en garde contre la traduction du seul gabarit, avec un contenu laissé dans une autre langue : l'expérience est mauvaise ;
• ne publiez pas en masse du texte traduit automatiquement sans relecture. La politique anti-spam de Google vise le contenu produit à grande échelle sans valeur pour l'utilisateur, y compris par des transformations automatiques comme la traduction lorsqu'il s'agit de copier d'autres sites. Elle n'interdit pas la traduction en soi, mais elle rappelle le bon critère : chaque page doit apporter quelque chose au lecteur.

Pensez aussi à tout ce qui n'est pas du texte : balises title et meta descriptions de chaque langue, textes alternatifs des images, données structurées (nom, description, carte) et fiche Google Business Profile.

Sélecteur de langue et redirections : laisser le choix au visiteur

Le sélecteur de langue est un composant simple, mais mal conçu, il fait perdre des clients et de la visibilité.

• Placez-le dans l'en-tête, visible sur toutes les pages, sur mobile comme sur ordinateur ;
• écrivez chaque langue dans sa propre langue (Français, English, Deutsch), plutôt que des drapeaux : un drapeau désigne un pays, pas une langue ;
• renvoyez vers la page équivalente, pas toujours vers l'accueil de l'autre langue : la carte française mène à la carte anglaise ;
• faites de chaque choix un vrai lien vers une URL, pas un script qui change le texte sur place : c'est ce que Google peut explorer.

Évitez les redirections automatiques. La documentation de Google avertit qu'une redirection fondée sur une langue supposée peut empêcher les utilisateurs et les moteurs de voir toutes les versions du site. Googlebot n'envoie pas d'en-tête Accept-Language et explore surtout depuis les États-Unis : une détection par langue du navigateur ou par IP, ou un choix mémorisé par cookie, peut lui cacher vos autres versions. Google juge d'ailleurs l'analyse de la localisation par IP difficile et en général peu fiable. Le plus sûr : un lien visible, et éventuellement un bandeau discret qui propose la langue probable sans l'imposer.

Site multilingue sur Webflow : hreflang, sitemap et sélecteur

Webflow propose une fonction de localisation. D'après la documentation Webflow et ses mises à jour, à la date de rédaction :

• les balises hreflang sont générées automatiquement pour les langues publiées dans des sous-dossiers ; vous pouvez utiliser les balises au niveau de la page, le sitemap, ou les deux, mises à jour à chaque publication ;
• seules les langues avec un sous-dossier et la publication activée apparaissent dans le sitemap généré automatiquement. Depuis une mise à jour de septembre 2025, ce sitemap liste toutes les routes localisées, chacune avec son hreflang d'auto-référence ;
• si vous utilisez un sitemap personnalisé, il faut ajouter les hreflang à la main, page par page ;
• le sélecteur de langue se construit avec un élément Dropdown et la liste des langues (Locales list) ; passer d'une langue à l'autre renvoie vers la page équivalente ;
• la langue principale n'a pas de sous-dossier par défaut, mais vous pouvez activer la publication dans un sous-dossier ;
• avant le lancement, la liste de contrôle de Webflow recommande de vérifier les hreflang et le sitemap, d'ajouter des redirections 301 pour les chemins localisés et d'éviter les noms de sous-dossier qui reprennent une page, un dossier ou une collection existants.

Ces fonctions et leurs libellés évoluent : vérifiez-les dans l'aide de Webflow avant de vous lancer. Dans tous les cas, testez le résultat : ouvrez le code source de chaque page ou le sitemap, et contrôlez la réciprocité des liens.

Checklist de lancement :

• une URL par langue, en sous-dossier, sans paramètre ;
• hreflang présents, réciproques, avec des URL complètes et un x-default ;
• sitemap à jour et déclaré dans la Search Console ;
• sélecteur de langue visible, en liens, vers la page équivalente ;
• module de réservation, e-mails et politique d'annulation traduits ;
• title, meta description, textes alternatifs et données structurées traduits.

Questions fréquentes sur le site de restaurant multilingue

Besoin d'aide pour créer votre site de restaurant multilingue ?

Un site multilingue réussi tient à de nombreux détails qui se croisent : structure d'URL, hreflang, traductions, sélecteur, sitemap, module de réservation. Une erreur à un endroit rend le reste invisible ou illisible.

māhie est agence partenaire Webflow, avec plus de 70 sites réalisés, dont des sites multilingues pour une clientèle internationale. Pour votre projet, nous pouvons :

• définir la structure : langues utiles, URL, hreflang et sitemap ;
• construire le site sur Webflow, avec sélecteur de langue et pages équivalentes ;
• intégrer la réservation (SevenRooms ou votre outil) dans chaque langue, sans quitter le site ;
• configurer un back-office simple, pour que vos équipes mettent à jour menus et événements dans chaque langue ;
• vérifier le référencement et la performance avant la mise en ligne, puis après.

Découvrez nos sites web pour restaurants et hôtels, puis Contactez māhie : nous regardons ensemble les langues dont vous avez besoin.