Accueil/Ressources

Webjuin 202610 min de lecture

Menu en ligne de restaurant : HTML plutôt que PDF

Lisibilité mobile, indexation, mise à jour, accessibilité et données structurées : pourquoi publier la carte de votre restaurant en HTML plutôt qu'en PDF.

Une table dressée, pêches et verres sous une lumière tachetée

Votre carte est le contenu le plus consulté de votre site : avant de réserver, presque tout le monde veut voir ce qu'il y a dans l'assiette et à quel prix. La question est donc simple : faut-il publier votre menu en ligne de restaurant en HTML ou en PDF ?

La réponse courte : en HTML, c'est-à-dire en vraie page web avec du texte, dans la grande majorité des cas. Le PDF peut rester en complément pour l'impression, mais il ne devrait pas être la seule version. Ce guide explique pourquoi (lisibilité mobile, indexation, mise à jour, accessibilité), comment structurer la page et ce que disent schema.org et Google des données structurées pour une carte. Nous ne promettons aucun gain de trafic : nous décrivons une méthode.

Une grande part des visiteurs consultent votre carte sur téléphone. C'est là que le PDF est le plus faible :

  • il s'ouvre souvent dans une autre fenêtre ou une autre application, et le visiteur perd le fil de votre site ;
  • la mise en page est celle d'une feuille A4 ou d'une carte imprimée : il faut pincer et faire défiler en tous sens pour lire ;
  • le fichier peut être lourd, surtout s'il contient des photos, et se télécharge lentement en 4G ;
  • le texte ne s'adapte pas à la taille de l'écran ni aux réglages de police du téléphone.

Une page HTML, au contraire, s'adapte à la largeur de l'écran, charge vite si les images sont légères, et reste dans l'univers de votre site avec le bouton de réservation toujours à portée. Google indexe d'ailleurs la version mobile des sites (mobile-first indexing) et demande que le contenu principal soit équivalent à celui de la version ordinateur. Une page web répond naturellement à cette exigence.

Pour une carte lisible sur mobile :

  • une colonne unique, avec des sections claires (entrées, plats, desserts, boissons) ;
  • le nom du plat en gras, la description en une ligne ou deux, le prix à côté, sans points de conduite ni mise en page à deux colonnes ;
  • des ancres de navigation en haut de page pour sauter à une section ;
  • un bouton de réservation fixe pour ne pas obliger à remonter ;
  • une taille de texte confortable, et des zones tactiles suffisantes (web.dev recommande environ 48 × 48 pixels pour une cible tactile, avec environ 8 pixels d'écart).

C'est l'une des erreurs que nous détaillons dans notre article sur les 10 erreurs d'un site de restaurant.

Indexation : ce que Google voit de votre carte

Google peut indexer les PDF : ils figurent dans la liste officielle des types de fichiers indexables. Le PDF n'est donc pas « invisible ». Mais il pose trois problèmes concrets pour une carte.

  • Un PDF qui n'est qu'une image (export d'une maquette ou scan de la carte imprimée) ne contient pas de texte que Google puisse lire. Vos plats ne peuvent alors pas être trouvés par leurs noms.
  • Une page HTML se relie au reste du site : liens vers la réservation, la privatisation, les horaires, la fiche de l'établissement. Un PDF est une impasse.
  • Vous contrôlez le titre et la description d'une page, son adresse, ses intertitres. Ces éléments aident le visiteur comme le moteur de recherche à comprendre de quoi il s'agit.

Bonnes pratiques :

  • une page dédiée par carte (« Carte », « Carte des vins », « Menu déjeuner »), avec un titre (balise title) et un intertitre H1 clairs ;
  • le texte réel des plats, pas dans une image ;
  • si vous gardez un PDF, liez-le depuis la page HTML (« Télécharger la carte en PDF ») plutôt que l'inverse, et mettez-le à jour en même temps ;
  • dans la fiche Google Business Profile, indiquez le lien de la carte vers la page HTML (voir notre guide sur la fiche Google) ;
  • pour un site multilingue, une page de carte par langue, avec ses propres balises hreflang, comme expliqué dans notre guide du site de restaurant multilingue.

Mise à jour : la carte change, le site doit suivre

Une carte vit : produits de saison, plat épuisé, changement de prix, menu du déjeuner. Avec un PDF, chaque modification suppose de rouvrir le fichier source, d'exporter, de remplacer le fichier, et d'espérer que personne n'a gardé l'ancienne version dans ses favoris ou ses e-mails. En pratique, le PDF est souvent en retard.

Avec une page HTML gérée depuis un back-office simple, la personne en salle ou en cuisine modifie une ligne et publie. C'est tout l'intérêt d'un site où l'équipe peut changer menus et événements seule.

Organisez la mise à jour :

  • désignez un responsable de la carte en ligne, avec un remplaçant ;
  • fixez un rythme (chaque service pour le menu du jour, chaque saison pour la carte) ;
  • gardez une date de dernière mise à jour visible si votre carte change souvent ;
  • supprimez les anciens PDF du site et de vos autres supports : ils continuent d'exister et d'être trouvés ;
  • vérifiez que le prix affiché est toujours le prix TTC en vigueur, identique sur le site, sur la fiche Google et en salle.

Accessibilité : une carte que tout le monde peut lire

Une carte en ligne doit pouvoir être lue par des personnes qui utilisent un lecteur d'écran, qui agrandissent le texte ou qui ont une vue réduite. Là encore, le HTML a l'avantage :

  • un PDF issu d'une image n'est pas du texte : un lecteur d'écran n'a rien à lire ;
  • une page HTML porte une structure : titres de niveaux, listes, ordre de lecture logique ;
  • le texte s'agrandit et se réorganise selon l'écran, ce qui est plus difficile avec une page fixe ;
  • les images de plats reçoivent un texte alternatif, et le texte de la carte n'est jamais « dans » la photo ;
  • les contrastes et la taille de police sont réglables dans votre feuille de style.

Si vous conservez un PDF, ne vous reposez pas dessus comme seule version : un simple export visuel n'offre généralement pas cette structure.

Attention : les obligations d'information sur les allergènes et sur l'affichage des prix relèvent de la réglementation. Cet article ne les détaille pas : vérifiez vos obligations auprès des autorités compétentes avant de publier, et assurez-vous que la version en ligne est cohérente avec ce qui est affiché en salle.

Données structurées d'une carte de restaurant : schema.org et Google

Les données structurées décrivent votre carte à un moteur de recherche, en plus du texte visible. Voici ce que nous avons vérifié.

Dans schema.org :

  • Restaurant est un type de la famille des établissements de restauration (FoodEstablishment), lui-même sous-type de LocalBusiness. Il dispose notamment des propriétés servesCuisine (type de cuisine), acceptsReservations, priceRange et hasMenu ;
  • Menu existe aussi comme type : « une représentation structurée des aliments ou boissons proposés par un établissement de restauration ». Ses propriétés propres sont hasMenuSection (une section : par service, par type de plat…) et hasMenuItem (un plat ou une boisson). Il hérite de name, description et inLanguage ;
  • la propriété hasMenu (ou menu) d'un Restaurant accepte soit un objet Menu, soit un texte, soit l'adresse (URL) de la carte ;
  • les exemples de schema.org montrent un plat avec un prix (offers, avec price et priceCurrency), un régime compatible (suitableForDiet) et des informations nutritionnelles, et prévoient des cartes distinctes selon les langues.

Chez Google :

  • sa documentation sur les entreprises locales recommande d'utiliser le type le plus précis (par exemple Restaurant), au format JSON-LD, avec le nom et l'adresse (obligatoires), puis notamment les horaires, le téléphone, priceRange, servesCuisine et la propriété menu avec l'URL complète de la carte ;
  • elle demande que le balisage corresponde à ce qui est visible sur la page, et précise que le respect des consignes ne garantit pas un affichage enrichi ;
  • à la date de rédaction, nous n'avons trouvé dans cette documentation aucun résultat enrichi dédié aux plats d'une carte. Balisez donc les plats pour décrire correctement votre contenu, pas pour obtenir un affichage particulier.

Approche raisonnable :

  • minimum utile : un balisage Restaurant avec la propriété menu qui pointe vers l'URL de votre page de carte ;
  • version plus complète, si vous avez les moyens de la maintenir : un Menu avec ses sections et ses plats (nom, description, prix en euros), en conservant les mêmes textes que la page ;
  • une carte par langue, avec la langue indiquée sur chaque Menu ;
  • jamais de plat balisé qui n'est plus servi, ni de prix différent de celui affiché : un balisage périmé est pire que pas de balisage.

Vérifiez le résultat avec le validateur de schema.org.

Checklist : publier sa carte en ligne en HTML

  • une page de carte dédiée par carte et par langue, avec un titre clair ;
  • tout le texte en vrai texte (plats, descriptions, prix TTC) ;
  • une structure en sections, lisible sur mobile sans zoomer ;
  • un bouton de réservation toujours visible ;
  • les mentions réglementaires vérifiées (allergènes, prix) ;
  • un éventuel PDF imprimable, lié depuis la page et mis à jour en même temps ;
  • un responsable de la mise à jour et une date de dernière mise à jour ;
  • le lien de la carte renseigné dans la fiche Google Business Profile ;
  • un balisage Restaurant avec menu (et, si vous le maintenez, Menu) cohérent avec la page visible.

Questions fréquentes sur le menu en ligne d'un restaurant

Faut-il supprimer le PDF de la carte ?

Pas nécessairement. Gardez-le comme version imprimable si vous en avez l'usage, mais faites de la page HTML la version de référence, liez le PDF depuis cette page et mettez-le à jour en même temps. Un PDF seul pénalise la lecture sur mobile et la mise à jour.

Google indexe-t-il un menu en PDF ?

Oui, Google peut indexer les PDF, c'est dans sa liste de types de fichiers indexables. Mais si le PDF n'est qu'une image de la carte, il n'y a pas de texte à lire. Une page HTML avec le texte des plats est plus fiable et mieux reliée au reste du site.

Faut-il ajouter des données structurées Menu à ma page de carte ?

Ce n'est pas obligatoire. Au minimum, balisez votre établissement en Restaurant avec la propriété menu qui pointe vers la page de carte. Le type Menu de schema.org permet de décrire sections et plats, mais nous n'avons pas trouvé de résultat enrichi dédié dans la documentation Google : n'en attendez pas d'effet garanti.

Comment gérer une carte qui change tous les jours ?

Utilisez une page HTML modifiable par votre équipe depuis un back-office simple, avec un responsable désigné. Évitez de produire un nouveau PDF à chaque service : indiquez la date de mise à jour et gardez une seule adresse pour la carte.

Besoin d'aide pour publier le menu en ligne de votre restaurant ?

Une carte en ligne bien faite se lit sur mobile, se met à jour en deux minutes et reste cohérente partout : site, fiche Google, salle. Quand les menus, les langues et les adresses se multiplient, cela devient vite un vrai chantier.

māhie conçoit des sites Webflow pour la restauration et l'hôtellerie, avec plus de 70 sites à notre actif. Pour votre carte en ligne, nous pouvons :

  • concevoir la page de carte : structure, lisibilité mobile et lien avec la réservation ;
  • mettre en place un back-office simple, pour que vos équipes modifient menus et événements seules ;
  • gérer plusieurs langues, avec une carte par langue et un référencement propre ;
  • soigner le SEO et la performance : page rapide, bien référencée, mesurée ;
  • ajouter le balisage Restaurant et le relier à la fiche Google, en cohérence avec le contenu visible.

Découvrez nos sites web pour restaurants et hôtels, puis Contactez māhie : nous regardons ensemble comment publier votre carte.

Corentin
CorentinFondateur de māhie
Menu en ligne de restaurant : HTML ou PDF · māhie