Sito web per ristorante, la guida completa per portare coperti
C’è un momento preciso in cui un ristorante guadagna o perde un tavolo, e non succede in sala. Succede su un marciapiede, davanti a uno smartphone, quando qualcuno cerca “dove mangiare stasera” e apre tre siti in fila. Due si caricano lenti, uno ha il menu in PDF che non si legge. Il quarto risultato vince il coperto.
Il sito web di un ristorante non è una brochure: è il primo cameriere che i clienti incontrano. Questa guida mette in fila cosa deve avere per portare coperti, quali errori costano di più e perché delegare tutto a Google, TheFork o Instagram significa lavorare per qualcun altro.
Come deve essere il sito di un ristorante?
Veloce, con il menu leggibile da Google e aggiornabile in un minuto, con la prenotazione diretta a portata di pollice e con orari e indirizzo identici a quelli del profilo Google. Chi arriva sul sito ha tre domande — cosa si mangia, quanto costa, come si prenota — e deve trovare le risposte prima di perdere la pazienza.
I numeri dicono che il menu è il centro di tutto: secondo un sondaggio di US Foods, l’83% dei clienti consulta il menu online prima di mettere piede nel locale, e la metà di loro ha già deciso cosa ordinare prima di sedersi. Il Diner Trends Report di TouchBistro conferma: l’85% guarda il menu online prima di provare un ristorante nuovo. Tradotto: il menu sul sito non è un servizio accessorio, è il momento in cui il cliente sceglie te o il locale accanto.
E lo fa quasi sempre dal telefono. Il Restaurant Trend Report di BentoBox misura che il 75% del traffico dei siti di ristoranti arriva da mobile. Il sito di un ristorante si consulta per strada, in coda, sul divano alle 19:40 con la fame che monta. Se non è progettato per quel contesto, non è progettato.
Perché il menu deve essere una pagina web e non un PDF?
Perché un PDF si legge male su smartphone e per Google quasi non esiste. Il menu in PDF è l’errore più diffuso e più costoso dei siti di ristorazione, e vale la pena capire perché.
Sul piano dell’esperienza: zoom, trascinamenti, caricamento lento con la connessione del marciapiede. Chi sta decidendo tra tre locali non combatte con un documento, chiude e passa al prossimo. Sul piano della visibilità: Google indicizza i PDF con difficoltà e non li tratta come pagine ricche di segnali. Ogni piatto del tuo menu è una ricerca potenziale — “tagliatelle al ragù centro”, “ristorante senza glutine” più il quartiere, il nome di un vino raro — e un PDF le regala tutte ai concorrenti.
C’è poi il problema dell’aggiornamento. Un menu vero cambia: piatti del giorno, stagionalità, un prezzo ritoccato. Se ogni modifica richiede di rifare il PDF, ricaricarlo e incrociare le dita, il menu online resta indietro rispetto a quello in sala — e un cliente che trova al tavolo prezzi diversi da quelli letti online è un cliente che si sente ingannato. Il menu deve essere una pagina web modificabile in un minuto, senza chiamare nessuno. Dello stesso tema, sul lato sala, parliamo nella guida al menu digitale con QR code: il principio è identico, il menu vive sul tuo dominio e lavora sia al tavolo sia su Google.
Cosa deve avere il sito di un ristorante? La checklist
Dieci elementi, in ordine di importanza. Se ne mancano più di tre, il sito sta perdendo coperti.
- Menu in HTML, indicizzabile e aggiornabile — ogni piatto è testo che Google legge, modificabile senza passare da un tecnico.
- Prenotazione diretta — telefono cliccabile e modulo o sistema di prenotazione sul tuo dominio, senza commissioni per coperto.
- Foto vere dei piatti e della sala — scattate nel tuo locale, non stock: chi prenota vuole vedere dove si siederà e cosa mangerà.
- Orari e indirizzo coerenti con Google — stessi dati sul sito, sul profilo Google e ovunque: le incoerenze confondono i clienti e i motori.
- Velocità su mobile — la pagina si apre in un paio di secondi anche in 4G; ogni secondo in più è gente che chiude.
- Click-to-call e indicazioni stradali a un tap — chi cerca da smartphone vuole chiamare o farsi guidare, non copiare un indirizzo.
- Allergeni e diete indicati nel menu — celiaci, vegetariani, intolleranze: il tavolo con un’esigenza sceglie chi risponde prima.
- Dati strutturati (schema Restaurant e Menu) — il codice che dice a Google e alle AI cosa servi, dove, in che orari e a che fascia di prezzo.
- Pagine per le occasioni — pranzo di lavoro, cena di gruppo, brunch della domenica: ogni occasione è una ricerca che qualcuno sta facendo.
- Dominio di proprietà — tutto quanto sopra deve vivere su un dominio tuo, non su un sottodominio di piattaforma che smette di essere tuo quando smetti di pagare.
Quali sono gli errori che costano più coperti?
Sono cinque, e quasi tutti nascono dalla stessa idea sbagliata: che il sito sia una vetrina da guardare, invece che uno strumento da usare con una mano sola mentre si cammina.
| Errore | Costo per il locale | Soluzione |
|---|---|---|
| Menu in PDF | Invisibile a Google, illeggibile per strada: le ricerche sui piatti le vince un altro | Menu in HTML sul dominio del ristorante, aggiornabile in autonomia |
| Sito tutto immagini ed effetti, stile Flash | Caricamento lento su mobile, testi che i motori non leggono, utenti che chiudono | Design essenziale, testo vero, immagini ottimizzate |
| Delega totale a TheFork e ai social | Commissioni per coperto, dati dei clienti in mano ad altri, concorrenti a un tap | Prenotazione diretta dal sito; portali come canale secondario |
| Orari e indirizzo diversi da Google | Clienti davanti alla serranda abbassata, recensioni negative, fiducia dei motori in calo | Un’unica fonte di verità: sito e profilo Google sempre allineati |
| Foto stock o vecchie di anni | Aspettative sbagliate, delusione al tavolo, zero differenziazione | Servizio fotografico vero di piatti e sala, rinnovato a ogni cambio menu |
L’errore del “sito vetrina tutto scena” merita due righe in più. Sono i siti con la musica, l’animazione d’ingresso, le foto a schermo intero che pesano dieci megabyte. Sembrano eleganti sul computer di chi li ha fatti e sono inutilizzabili sul telefono di chi deve prenotare. L’eleganza di un sito di ristorazione si misura come quella di un servizio in sala: rapidità, precisione, nessun gesto superfluo.
Il profilo Google non basta?
No: il profilo Google porta la domanda, il sito la converte. Sono due pezzi dello stesso meccanismo e uno senza l’altro lavora a metà.
Il profilo Google (la scheda con mappa, orari, recensioni) è quasi sempre il primo contatto: le ricerche locali sono ormai il modo standard di scegliere dove mangiare, e i dati di Think with Google fotografano il fenomeno da anni — l’interesse per le ricerche “near me” è cresciuto di 34 volte dal 2011, l’80% arriva da mobile e metà di chi cerca un’attività vicina dal telefono la visita entro un giorno. Sono persone con la fame e le chiavi in mano.
Ma la scheda ha limiti strutturali: spazio contato, layout uguale per tutti, recensioni che non controlli e — dettaglio non piccolo — i concorrenti suggeriti proprio sotto la tua. Il sito è dove quella curiosità diventa una prenotazione: menu completo, foto tue, la storia del locale, il modulo per il tavolo da otto di sabato. E il collegamento funziona in entrambe le direzioni, perché un sito veloce e coerente con la scheda rafforza il posizionamento della scheda stessa. Chi ha solo il profilo Google ha una porta senza ristorante dietro.
Lo stesso ragionamento vale per TheFork e per i social. Sono canali, non case: le commissioni per coperto erodono margini che in ristorazione sono già sottili, e i follower restano un pubblico in affitto sull’algoritmo di qualcun altro. Il conto dettagliato lo facciamo in prenotazioni ristorante senza commissioni, ma il principio sta in una riga: i portali vanno usati per farsi scoprire, il sito per farsi prenotare.
Come fa il sito a intercettare “ristorante + zona” e “ristorante + occasione”?
Con pagine che rispondono a ricerche precise, non con una homepage generica. Nessuno cerca “ristorante”: si cerca “trattoria vicino ai Teatri”, “ristorante romantico” più la città, “pranzo di lavoro veloce” più il quartiere, “cena di laurea per venti persone”.
Ognuna di queste ricerche è una domanda specifica, e Google premia chi risponde in modo specifico. Un menu indicizzato risponde alle ricerche sui piatti. Una pagina sulla cena di gruppo, con il menu fisso e il modulo di richiesta, risponde a chi organizza. I dati strutturati e la coerenza con il profilo Google rispondono alle ricerche di zona. È un lavoro di precisione, non di volume: a un ristorante non servono mille visite generiche, servono le cinquanta persone che stasera cercano esattamente quello che offre, nel raggio in cui può servirle.
C’è anche un fronte nuovo: le risposte generate dalle AI, che pescano dai siti leggibili e ben strutturati. Chi chiede a un assistente “dove mangio il tartufo a Bologna” riceve risposte costruite sulle stesse fondamenta — testo indicizzabile, dati strutturati, coerenza. Il sito fatto bene oggi lavora anche lì.
Da dove iniziare?
Dal menu e dalla prenotazione: sono le due pagine che portano coperti, tutto il resto si costruisce intorno.
È l’idea da cui nasce ONE MENU, il prodotto DOGO per la ristorazione: menu digitale e sito del ristorante sullo stesso dominio, di proprietà del locale, senza commissioni e senza canoni verso piattaforme terze. Il menu si aggiorna in autonomia, ogni piatto è indicizzabile, il QR al tavolo e la ricerca su Google portano nello stesso posto: casa tua. Nel mondo hospitality l’approccio l’abbiamo già messo alla prova con Rococò a Bologna, dove identità del locale e presenza digitale vivono in un unico progetto invece di essere sparse tra piattaforme.
Il punto di arrivo è semplice da verificare: cerca il tuo ristorante da smartphone, per strada, come farebbe un cliente. Se in dieci secondi non riesci a leggere il menu e prenotare un tavolo, il sito non sta lavorando per te. Se vuoi capire dove si inceppa e cosa sistemare per primo, prenota una call: trenta minuti, telefono alla mano.
Domande frequenti
- Un ristorante ha davvero bisogno di un sito web se ha già il profilo Google?
- Sì. Il profilo Google è la vetrina, il sito è il locale: menu completo, foto, prenotazione, storie dei piatti. Google stesso premia le schede collegate a un sito coerente e veloce. Senza sito, ogni ricerca approfondita finisce su un concorrente o su un portale.
- Come deve essere il sito di un ristorante per funzionare davvero?
- Veloce su smartphone, con menu in HTML indicizzabile e aggiornabile, prenotazione diretta senza commissioni, foto vere dei piatti, orari e indirizzo identici a quelli del profilo Google. Deve rispondere in pochi secondi alle tre domande di chi cerca: cosa si mangia, quanto costa, come si prenota.
- Il menu in PDF sul sito va bene?
- No. Su smartphone costringe a zoomare, si carica lentamente e per Google è quasi invisibile: chi cerca un piatto o una cucina nella tua zona non ti troverà. Il menu deve essere una pagina web vera, indicizzabile e modificabile in un minuto.
- Quanto conta la velocità del sito per un ristorante?
- Moltissimo, perché il sito si consulta per strada, spesso con connessione debole. Il 75% del traffico dei siti di ristoranti arriva da mobile: se la pagina impiega più di qualche secondo, il cliente chiude e sceglie il locale successivo nei risultati.
- Meglio prenotazioni dal sito o da TheFork?
- Dal sito, quando possibile: niente commissioni per coperto, dati dei clienti tuoi, nessun confronto diretto con i concorrenti a un tap di distanza. I portali possono restare un canale in più, ma la prenotazione diretta deve essere la strada più semplice.