Un site internet pour restaurant ne sert plus à faire joli. Il sert à faire réserver une table, directement, sans passer par un intermédiaire qui prélève sa part sur chaque couvert. C’est la seule bonne raison d’en avoir un en 2026, et c’est aussi la raison pour laquelle une page Facebook et une fiche Google ne suffisent plus tout à fait. Voici ce qui change vraiment le nombre de réservations, et ce qui ne change rien.
Pourquoi un restaurant a-t-il besoin d’un site internet alors qu’il a déjà une page Facebook et une fiche Google ?
Parce que la page Facebook et la fiche Google sont louées, pas possédées. Vous y publiez, mais vous ne décidez ni de l’affichage, ni de l’ordre, ni de qui voit quoi. Un site vous donne trois choses qu’aucune plateforme ne vous donnera : le contrôle total du contenu, un canal de réservation qui ne prélève rien sur vos couverts, et une adresse stable que les moteurs et les assistants IA peuvent citer.
Le détail qui surprend beaucoup de restaurateurs : la réservation depuis une fiche Google ne se branche pas sur votre propre système. Elle passe obligatoirement par un fournisseur partenaire, choisi dans une liste, dont la disponibilité varie selon le pays et dont la tarification est à vérifier auprès de lui. Et si vous contournez en posant un simple lien vers votre site, l’aide de Google est claire : « Les données sur les performances ne sont pas disponibles pour les liens personnalisés. » Vous perdez la mesure. Comptez aussi environ une semaine avant que la fonctionnalité s’affiche réellement sur la fiche après configuration (aide Google Business Profile).
Ajoutez le poids du secteur : l’INSEE recense 171 356 entreprises dans la restauration et les services de restauration mobile en France, dont 86,3 % du chiffre d’affaires réalisé auprès des particuliers (INSEE, fiche secteur 561, millésime 2021). Autrement dit, votre concurrence est dense et votre client est un particulier qui décide vite, sur son téléphone, entre deux établissements qui se ressemblent. Le site n’est pas une vitrine de plus. C’est l’endroit où vous reprenez la main sur cette décision, et c’est tout l’objet de notre page dédiée à la création de site internet pour restaurant.
Combien coûte un site internet pour un restaurant ?
Cela dépend d’une seule chose : est-ce qu’on livre une présence propre, ou un véritable outil de réservation. Un site de restaurant clair, rapide, avec une carte à jour et une prise de contact efficace se situe dans les quelques centaines d’euros. Un site complet avec blog, données structurées et SEO de base se situe autour de 960 €, et la formule avec référencement actif monte à un peu moins de deux mille euros la première année ; un système de réservation intégré ou une version multilingue se chiffrent sur devis. Ensuite, seule la maintenance reste.
Pour donner des repères honnêtes plutôt que des fourchettes creuses, voici comment nous le structurons.
| Formule | Ce que ça couvre | Ordre de grandeur |
|---|---|---|
| Simple | 1 page : carte lisible en HTML, horaires, accès, formulaire de réservation par email, cohérence avec la fiche Google | environ 530 € la première année |
| Complète | 5 à 8 pages avec blog : pages détaillées, données structurées Restaurant et Menu, SEO de base | environ 960 € la première année |
| Référencement actif | Le même périmètre, plus le SEO et le GEO travaillés chaque mois et un article rédigé | environ 1 830 € la première année |
| Besoins spécifiques | Widget de réservation sans commission par couvert, version multilingue, au-delà de 8 pages | sur devis |
| Ensuite | Hébergement, nom de domaine, mises à jour, corrections | environ 180 € par an |
Les montants exacts et à jour sont sur la page offre, avec le choix entre mensualisation et paiement unique. À ce budget, ajoutez le coût de votre outil de réservation si vous en prenez un : certains facturent un abonnement fixe, d’autres une commission par couvert, et la différence sur une année de service se compte en centaines d’euros. Si votre projet dépasse le cadre restaurant, par exemple un groupe avec plusieurs adresses, la création de site web au sens large répond mieux au besoin.
Faut-il mettre la carte en PDF sur le site d’un restaurant ?
Non. Un PDF, et pire encore un PDF scanné, est une image pour un moteur de recherche : illisible, non citable, impossible à afficher correctement sur un téléphone sans pincer et zoomer. La carte doit être du texte, dans une page, avec des sections et des prix. C’est plus simple pour votre client, et c’est la seule forme qu’un assistant IA peut reprendre pour répondre à une question sur vos plats.
Schema.org traite d’ailleurs le menu comme un contenu à part entière et non comme une pièce jointe : le type Menu appartient à la famille CreativeWork, se rattache au restaurant par la propriété hasMenu, et se structure en sections (hasMenuSection) contenant les plats (hasMenuItem), avec la possibilité d’imbriquer des sous-catégories, de préciser la langue et d’attacher les prix (schema.org/Menu).
Concrètement, pour un restaurant :
- une page carte en texte, découpée par sections, avec les prix affichés ;
- une mise à jour que vous pouvez faire vous-même en deux minutes quand le plat du jour change ;
- un PDF téléchargeable en complément si vous y tenez, jamais à la place ;
- des allergènes et régimes indiqués en clair, ils évitent des appels et des annulations.
Comment prendre des réservations depuis son site sans commission ?
Trois options fonctionnent, par ordre de complexité. Un formulaire de réservation maison, qui vous envoie la demande par email et confirme au client à l’écran. Un widget de réservation facturé à l’abonnement fixe, sans prélèvement par couvert. Ou, pour les plus petits volumes, un numéro cliquable en évidence, qui reste le canal le plus efficace du monde à midi moins dix.
Le point à trancher est économique, pas technique. Une plateforme qui prend une commission par couvert vous coûte proportionnellement à votre succès, et elle possède la relation avec votre client. Un système hébergé sur votre site vous coûte un montant fixe et vous laisse la liste des convives, les emails, les préférences, l’historique. Sur un service qui tourne, l’écart annuel dépasse souvent le prix du site lui-même.
Techniquement, deux propriétés valent d’être posées dans votre balisage : acceptsReservations, qui déclare aux moteurs que vous prenez des réservations, et potentialAction, que schema.org documente précisément pour décrire une action possible, y compris un lien vers une plateforme de réservation (schema.org/Restaurant). C’est ce qui fait la différence entre un site qui parle de vous et un site qui déclenche quelque chose. Notre méthode prévoit ce choix dès le premier échange, avant la moindre maquette, parce qu’il conditionne toute l’architecture des pages.
Un site de restaurant doit-il être pensé pour le mobile en priorité ?
Oui, sans discussion. Vos visiteurs cherchent debout, dans la rue, souvent à moins d’une heure du repas, avec une main libre. Un site de restaurant se conçoit d’abord pour un écran de téléphone tenu à une main, puis s’élargit pour l’ordinateur. L’inverse produit toujours le même résultat : un beau site sur grand écran, inutilisable au moment où la décision se prend.
Ce que ça implique, très concrètement :
- le nom, le quartier, les horaires du jour et le bouton de réservation visibles sans faire défiler ;
- un numéro de téléphone cliquable qui déclenche l’appel, pas un numéro en image ;
- un bouton de réservation qui reste accessible pendant tout le défilement ;
- des photos compressées, parce qu’un site lourd en 4G perd le client avant la première image ;
- l’adresse qui ouvre l’itinéraire d’un tap, sans étape intermédiaire.
Comment un restaurant peut-il apparaître dans les réponses de Google et des assistants IA ?
En donnant aux machines des données propres et cohérentes. Google recommande le format JSON-LD et considère deux propriétés comme essentielles pour un établissement local : name et address complète. Il recommande fortement telephone, openingHoursSpecification, geo, et, pour la restauration précisément, menu avec l’URL de votre page carte, servesCuisine et priceRange (Google Search Central).
Trois règles que nous appliquons systématiquement. Utiliser le sous-type le plus précis, donc Restaurant plutôt que LocalBusiness générique. Valider le balisage avec l’outil de test des résultats enrichis avant la mise en ligne, car un balisage incomplet n’ouvre droit à aucun affichage enrichi et peut valoir une action manuelle. Et prévoir plusieurs images en haute résolution dans différents formats, carré, 4/3 et 16/9, que Google réutilise selon les emplacements.
Ce n’est pas une astuce d’initié : d’après les données d’index web citées par schema.org en mai 2026, le type Restaurant est déjà déployé sur 100 000 à 1 000 000 de domaines. Vos concurrents balisent. Un site sans données structurées ne se contente pas de rater un bonus, il part avec un handicap. Dernier point trop souvent négligé : votre site et votre fiche Google doivent dire exactement la même chose, mêmes horaires, même adresse, même téléphone. Une divergence et vous perdez la confiance des deux côtés.
Quelles erreurs font perdre des réservations sur un site de restaurant déjà en ligne ?
Ce sont presque toujours les mêmes, et aucune n’est esthétique. Des horaires périmés depuis le dernier changement de saison. Une carte en PDF scanné. Un formulaire qui n’envoie aucune confirmation, si bien que le client réserve ailleurs par précaution. Un site lent parce que les photos sortent directement de l’appareil. Et une adresse ou un téléphone qui ne correspondent pas à la fiche Google.
À vérifier ce soir, en dix minutes, sur votre propre téléphone :
- Les horaires affichés sont-ils ceux de cette semaine, jours de fermeture compris ?
- Peut-on lire la carte sans zoomer ?
- Combien de taps entre l’arrivée sur le site et la demande de réservation envoyée ?
- Le client reçoit-il une confirmation écrite, immédiatement ?
- Le site se charge-t-il en moins de trois secondes en 4G, hors wifi de la salle ?
Si une seule réponse coince, vous perdez des couverts chaque semaine sans le voir. Nos réalisations montrent le détail de ces arbitrages, projet par projet, avec ce qui a été mesuré avant et après.
Faut-il un site en plusieurs langues pour un restaurant qui accueille des touristes ?
Si une part visible de votre salle vient de l’étranger, oui, mais pas n’importe comment. Une version anglaise soignée vaut mieux que six langues traduites à la machine. Ce qui compte pour un touriste tient en quatre éléments : comprendre la carte, connaître les horaires, savoir où vous êtes, et pouvoir réserver sans appeler dans une langue qu’il ne parle pas.
Deux principes de bon sens. Gardez le nom des plats en français, avec une description traduite en dessous : c’est ce que le client viendra chercher, et cela évite les traductions malheureuses. Et déclarez la langue de chaque version, y compris celle du menu, que schema.org permet de préciser via la propriété inLanguage héritée de CreativeWork. Un site multilingue mal déclaré finit indexé de travers, ce qui coûte plus cher que de ne pas traduire du tout.
Ce qu’il faut retenir avant de lancer le projet
Un site de restaurant qui fonctionne n’est pas un site plus beau que celui d’à côté. C’est un site qui charge vite sur un téléphone, dont la carte est lisible et à jour, qui prend une réservation en trois taps sans commission, et dont les données sont assez propres pour que Google et les assistants IA le citent quand quelqu’un demande où dîner ce soir. Le reste, aussi soigné soit-il, ne remplit pas la salle.
