Sito web per pizzeria: come riportare gli ordini sul canale diretto invece che sulle app
Il sabato sera è pieno, il numero di coperti e di consegne cresce, ma a fine trimestre il margine è più basso dell’anno precedente. Il volume passa dalle app, le commissioni delivery lo erodono a monte, e il locale lavora di più per guadagnare uguale. È il punto in cui quasi tutti si chiedono se valga la pena avere un sito proprio.
Sito web per pizzeria
Un sito web per pizzeria serve a una cosa sola in termini economici: spostare quota di ordini dal canale intermediato al canale diretto, dove il margine resta al locale. Perché funzioni deve permettere di completare un ordine o una prenotazione in pochi click da smartphone, avere un menu strutturato e aggiornabile senza intervento tecnico, ed essere coerente con la scheda Google Business Profile. Un sito vetrina con menu in PDF, da solo, raramente produce ordini diretti.
Il problema non è “fare un sito”: è capire quanti ordini servono sul canale diretto perché il conto torni, quale architettura regge il volume reale, e cosa si rompe nelle prime settimane. Questo articolo ricostruisce il percorso: il calcolo iniziale, il primo assetto che si spacca, la diagnosi, il cambio di rotta e la parte del problema che non sta nel sito.
Il conto che quasi nessuno fa prima: quanto pesano le commissioni delivery su 12 mesi
La decisione di investire in un sito proprio nasce spesso dalla sensazione che “le app mangino tutto”. Per trasformarla in una scelta serve un numero, calcolato su 12 mesi: la stagionalità di una pizzeria rende ingannevole qualunque proiezione fatta su poche settimane.
La formula da compilare con i tuoi dati, non con medie di settore:
Costo annuo del canale intermediato = (Ordini_app_mese × Scontrino_medio_app × Commissione_effettiva) × 12 + eventuali costi fissi di piattaforma + costo del personale dedicato alla gestione tablet/ordini
La variabile Commissione_effettiva non è una percentuale unica: dipende dal contratto, dal piano di visibilità e dal fatto che la consegna sia fatta dai rider della piattaforma o dal tuo personale. Si legge sull’estratto conto mensile, dividendo il totale trattenuto per il valore lordo degli ordini, su almeno tre mesi, prendendo il valore più alto.
Esempio ipotetico: 300 ordini al mese con scontrino medio di 24 euro generano 86.400 euro lordi l’anno. Con trattenuta effettiva del 20% il canale costa 17.280 euro l’anno; al 30%, 25.920 euro. La forbice tra le due ipotesi vale spesso più di un sito professionale. Sostituisci le variabili con i tuoi numeri prima di trarre conclusioni.
Sull’altra colonna va il costo reale del canale diretto su 12 mesi: sviluppo ammortizzato, hosting e dominio, canone del modulo ordini o del gateway di pagamento, aggiornamento menu, e il costo della consegna se gestita internamente — un rider proprio non è gratis, un ritiro in negozio sì.
Il punto di pareggio è: quanti ordini diretti al mese servono perché il costo annuo del canale proprio sia inferiore alla commissione risparmiata. Spesso il numero è più basso del previsto, e si raggiunge convertendo i clienti già abituali: il primo obiettivo di un sito web per pizzeria è trattenere sul canale giusto chi già ordina da te. Sul tasso di trasformazione delle visite in ordini vale la logica del conversion marketing e del tasso di conversione applicata al food.
L’assetto iniziale è quasi sempre lo stesso, perché costa meno e si consegna in due settimane: home con foto del forno, “chi siamo”, galleria fotografica, contatti con mappa, e menu in PDF. Tecnicamente è un sito. Operativamente non produce ordini.
Il primo punto di rottura è il PDF. Su smartphone si apre in un viewer esterno e richiede zoom continuo. Un PDF può essere indicizzato, ma offre una navigazione mobile debole, rende più difficile aggiornare prezzi e disponibilità e non consente una struttura di prodotto e azione d’ordine comparabile a pagine HTML. Chi cerca “pizza con la mortadella” nella tua zona difficilmente atterra su un file pensato per essere scaricato, non per rispondere a una ricerca.
Il secondo è il ciclo di aggiornamento: ogni modifica al menu richiede riaprire il file di grafica, riesportare, ricaricare. Dopo due mesi nessuno lo fa più, il prezzo online resta vecchio e nascono contestazioni in cassa — al punto che alcuni locali disattivano la pagina menu, rimuovendo l’informazione che le persone cercavano davvero.
Il terzo è la richiesta d’ordine: se l’unica azione è “chiamaci”, il venerdì alle 20:15 il telefono è occupato, il cliente non richiama e apre l’app.
Il quarto è la qualità visiva: foto scattate al volo riducono la percezione di prezzo giusto. Nel food la fotografia è informazione di prodotto, non decorazione, con le stesse logiche delle foto per e-commerce.
Il sito vetrina non è una versione ridotta del sito che serve, è un oggetto diverso che risolve un problema diverso. Conviene partire con un impianto pensato per l’ordine fin dall’inizio, come nella realizzazione di siti internet professionali dove il flusso di conversione precede la grafica.
Diagnosi: dove si perde l’ordine tra la ricerca su Google e il carrello
Quando un sito riceve traffico ma non genera ordini diretti, il problema è quasi sempre nel numero di passaggi richiesti. Per un flusso di riordino mobile, progettiamo l’accesso al checkout con un’azione primaria immediatamente visibile e riduciamo al minimo campi, passaggi e cambi di dominio: scelta pizze, indirizzo e orario devono stare in un flusso continuo, senza registrazione obbligatoria né doppia conferma via email.
La mappatura del percorso si fa a mano, con il telefono in modalità dati mobili e cronometro:
- Cerca su Google il nome della tua pizzeria: scheda Google Business Profile, sito o aggregatori — da dove atterra davvero la gente?
- Conta i secondi fino a quando il contenuto principale è visibile e stabile. Le soglie ufficiali per i Core Web Vitals sono LCP ≤ 2,5 secondi, INP ≤ 200 ms, CLS ≤ 0,1: un menu con 40 foto non compresse le supera tutte.
- Individua il pulsante d’azione senza scorrere.
- Completa un ordine reale: conta click, campi obbligatori, richieste di creare un account.
- Verifica cosa succede fuori orario di consegna: il sistema dice “chiuso” o accetta un ordine che non potrai evadere?
Il pattern più ricorrente è che l’abbandono si concentra su due punti: la registrazione obbligatoria prima del carrello e la richiesta dell’indirizzo prima che il cliente sappia se lo servi. Invertire questi passaggi — prima il CAP, poi il menu, poi i dati alla conferma — è un intervento da poche ore che spesso modifica la curva di completamento già nella settimana successiva.
Sul pagamento: obbligarlo online riduce i no-show ma esclude chi è abituato al contante. Una soluzione praticabile è tenere entrambi i metodi, con pagamento anticipato solo sopra una certa soglia o nei giorni ad alta pressione, da tarare sul proprio storico.
L’analisi del percorso mobile è un lavoro di usabilità del sito web applicata a un contesto specifico: una mano sola, luce esterna, connessione instabile, fretta. Partiamo dalla mappa dei touchpoint del customer journey, perché l’ordine di venerdì sera nasce spesso da un contatto avvenuto giorni prima sui social.
Tre architetture per un sito web per pizzeria: quale regge il volume che hai davvero
Non esiste una configurazione giusta in assoluto: esistono tre architetture operative, con costi, complessità e punti di rottura diversi. La scelta si fa sul volume di ordini e sulla capacità di gestione in cucina, non sull’estetica.
| Architettura | Quando ha senso | Punto di rottura | Impegno gestionale |
|---|---|---|---|
| A — Vetrina + prenotazione tavolo | Pizzeria prevalentemente in sala, asporto marginale, forte identità di locale | Non intercetta la domanda di delivery: chi vuole ordinare a casa va altrove | Basso: menu testuale aggiornabile, calendario prenotazioni |
| B — Sito + modulo ordini con slot orari | Volume medio di asporto e consegna, cucina con capacità limitata per fascia | Sovrapposizione tra ordini web e ordini telefonici se non c’è un unico punto di raccolta | Medio: qualcuno deve presidiare la coda ordini in servizio |
| C — E-commerce food completo | Volumi alti, più punti vendita, catalogo ampio con varianti e allergeni | Costo di gestione e sincronizzazione con cassa/gestionale; richiede processi già strutturati | Alto: serve un responsabile del canale digitale |
L’errore più frequente è saltare dalla A alla C perché “tanto poi cresciamo”. Un’architettura C con volumi da B produce spesso un catalogo mai aggiornato e un backend che nessuno apre, con più disallineamenti tra menu online e disponibilità reale.
Un criterio pratico: conta quanti prodotti distinti hai con varianti (impasto, dimensione, aggiunte). Sotto le 40 combinazioni gestibili, l’architettura B basta e avanza; sopra, e con più sedi, serve l’infrastruttura di shop online per gestire catalogo, disponibilità e ordini ricorrenti.
Quando il volume è ancora basso vale la pena considerare una singola landing page ottimizzata per il mobile, con menu strutturato e pulsante d’ordine, affiancata alla scheda Google: permette di validare la domanda prima di investire nell’architettura definitiva.
Nota tecnica: il modulo ordini deve poter esportare i dati (CSV o API) verso il gestionale. Un sistema chiuso che tiene gli ordini prigionieri riproduce, in piccolo, la stessa dipendenza delle piattaforme di delivery.
Sistemato il flusso d’ordine, il traffico spesso non arriva comunque. Per una pizzeria il punto d’ingresso principale è spesso la scheda Google Business Profile, che compare in ricerca e mappe con orari, foto, recensioni e, spesso, un link “Ordina online” gestito da terzi.
Se quel pulsante punta a una piattaforma intermediata, il cliente che ti sta cercando per nome — già acquisito, già convinto — viene instradato sul canale che ti costa di più.
La correzione richiede tre operazioni: inserire il link diretto al tuo sistema d’ordine nei campi dedicati della scheda, caricare il menu strutturato nella sezione apposita, e verificare che non compaiano link aggiunti da terzi. Aggiungi anche dati strutturati Schema.org sul sito, così che le informazioni siano leggibili in modo univoco:
{ "@context": "https://schema.org", "@type": "Restaurant", "name": "Nome della pizzeria", "servesCuisine": "Pizza", "menu": "https://esempio-pizzeria.it/menu/", "acceptsReservations": "True", "openingHoursSpecification": [{ "@type": "OpeningHoursSpecification", "dayOfWeek": ["Tuesday","Wednesday","Thursday","Friday","Saturday","Sunday"], "opens": "18:30", "closes": "23:30" }], "hasMenu": { "@type": "Menu", "hasMenuSection": { "@type": "MenuSection", "name": "Pizze classiche", "hasMenuItem": { "@type": "MenuItem", "name": "Margherita", "offers": { "@type": "Offer", "price": "7.00", "priceCurrency": "EUR" } } } }
}Nel 2026 abbiamo seguito un caso in cui il flusso funzionava perfettamente in test, finché il locale ha cambiato il giorno di chiusura aggiornando solo la lavagna all’ingresso: per due settimane il modulo ha accettato ordini a cucina spenta, mentre la scheda Google diceva “aperto”, con un aumento delle recensioni negative. Abbiamo introdotto un’unica fonte di verità — un solo pannello da cui aggiornare sito, scheda e modulo ordini insieme.
La fragilità non sta nel codice, sta nel disallineamento tra ciò che succede nel locale e ciò che il sistema dichiara: è un problema di processo, perimetro della SEO locale.
Checklist mensile:
- Dati strutturati Schema.org aggiornati (orari, menu, prezzi) e senza errori.
- Google Search Console controllata per copertura e indicizzazione delle pagine menu.
- Disponibilità prodotti e allergeni allineati tra sito, scheda e cucina.
- Checkout mobile e tracciamento conversioni testati manualmente ogni mese.
Verifica anche: nome, indirizzo e telefono identici su sito, scheda e directory; orari festivi in anticipo; foto recenti; risposta alle recensioni. Un menu non indicizzato è invisibile: le cause tipiche sono banali quanto un noindex dimenticato in staging, verificabile con la indicizzazione SEO.
Perché “sito web per pizzeria” non è la query che ti porta ordini
Serve chiarire un equivoco sulla domanda di ricerca. La query intercetta soprattutto ristoratori che valutano un fornitore, non clienti pronti a ordinare: è largamente irrilevante per il fatturato di una pizzeria. Per verificare l’intento reale conviene incrociare due fonti: Google Search Console, guardando quali query portano già impression e click sulle pagine esistenti, e Google Ads Keyword Planner, per stimare volumi e concorrenza sulle query che interessano il tuo bacino locale.
La domanda che porta ordini è un’altra: nomi di locale, “pizzeria aperta adesso”, “pizza asporto” con riferimento geografico implicito, “pizza senza glutine”, “pizza napoletana consegna”. Sono query con intento immediato, spesso vocali: l’ottimizzazione per la ricerca vocale in questo settore non è un esercizio futuribile.
La conseguenza sull’architettura dei contenuti è concreta: le pagine utili non spiegano cos’è la pizza, rispondono a condizioni d’acquisto — impasti e tempi di lievitazione, allergeni e senza glutine, asporto con fasce orarie reali, eventi con capienza e menu fisso.
Le persone chiedono al personale sempre le stesse cose: prenotazione per gruppi, birra artigianale, costo della consegna, apertura a pranzo, parcheggio. Trasformarle in sezioni del sito riduce le telefonate e alimenta il tipo di risposta che i motori generativi estraggono. Le pagine informative di dettaglio operativo ottengono spesso un CTR superiore alle pagine istituzionali, pur con posizioni medie simili: rispondono, non raccontano. Conviene partire da un SEO audit che dica quali pagine esistenti ricevono già impression senza click.
Per una singola pizzeria non serve un piano editoriale da trenta articoli al mese: bastano otto o dieci pagine fatte bene e mantenute aggiornate.
La configurazione misurabile: cosa tracciare dal primo giorno per sapere se sta funzionando
Un sito senza misurazione è un investimento che non potrai difendere fra sei mesi. La configurazione minima va messa in piedi prima del lancio, non dopo.
Eventi da tracciare: apertura menu, aggiunta al carrello, inizio checkout, ordine completato, click su “chiama ora”, click su WhatsApp, invio prenotazione — ognuno con il valore economico associato dove disponibile. Senza il valore, il dato dice quanti ordini ma non quanto margine.
Nei progetti SEO che seguiamo nel 2026, verifichiamo prima la corrispondenza tra ordine completato, valore transato e sorgente: senza questi tre campi il confronto tra canale diretto e piattaforme non è affidabile.
Segmentazione per sorgente: ricerca organica, scheda Google Business Profile, social, traffico diretto, QR code su scontrino o scatola — quest’ultimo canale, spesso sottovalutato, converte al canale diretto chi ha ordinato la prima volta tramite piattaforma. Usa un parametro UTM dedicato.
Metriche di controllo settimanale: numero di ordini diretti, scontrino medio del canale diretto, tasso di completamento del checkout, percentuale di ordini ripetuti a 60 giorni — la metrica che dice se stai costruendo una base clienti o solo comprando transazioni.
La distinzione tra ordine attribuito e ordine effettivamente causato dal canale si gestisce con un modello esplicito di marketing attribution; una raccolta dati impostata bene evita di ricostruire mesi di storico quando serve decidere.
Due integrazioni fanno una differenza sproporzionata rispetto al costo: la ricezione ordini via WhatsApp con un chatbot WhatsApp Business, e il richiamo dei clienti dormienti con un flusso di email marketing automation che dopo 45 giorni di inattività propone un ritiro in negozio con vantaggio dedicato.
Nei progetti AI-driven usiamo modelli generativi per le varianti descrittive delle schede prodotto e le risposte alle domande ricorrenti, con revisione umana obbligatoria su allergeni e prezzi: un errore lì non è un problema di marketing.
UX, integrazione ordini, SEO locale e misurazione vanno definiti nello stesso documento tecnico prima della riga di codice. Per parlare del tuo caso, scrivici o chiamaci: ti rispondiamo direttamente noi.
Da dove partire se hai già un sito che non produce ordini diretti
Se il sito esiste già, buttarlo è quasi sempre la scelta sbagliata. L’ordine di intervento che dà il ritorno più rapido è questo, in quattro mosse.
Prima: sostituisci il menu PDF con pagine HTML strutturate, prezzi inclusi — spesso l’intervento con il miglior rapporto impatto/costo. Seconda: metti un unico pulsante d’azione visibile senza scorrere, su ogni pagina, che porti al flusso d’ordine in pochi click. Terza: allinea la scheda Google Business Profile con il link diretto e gli orari reali, e istituisci la regola dell’unica fonte di verità. Quarta: attiva il tracciamento degli eventi e lascia correre quattro settimane prima di toccare altro.
Solo dopo queste quattro mosse ha senso ragionare su campagne a pagamento: mandare traffico su un flusso che perde gran parte delle persone al checkout significa pagare per confermare un problema che già conoscevi. Prima si ripara il flusso, poi si aumenta la pressione con campagne Google Ads.
Il canale diretto non elimina le piattaforme: le app portano clienti nuovi, un servizio per cui ha senso pagare una commissione. L’obiettivo ragionevole è cambiare il mix — lasciare alle piattaforme l’acquisizione e tenere sul canale proprio la ricorrenza. Un cliente conquistato tramite app che alla terza pizza ordina dal tuo sito ha ripagato la commissione iniziale: è così che un sito web per pizzeria produce un ritorno misurabile su 12 mesi, criterio utile anche per qualsiasi attività per aumentare la visibilità del sito.
Se vuoi capire quale architettura regge il tuo volume attuale e quanti ordini diretti al mese ti servono per rientrare, mandaci un messaggio: guardiamo i numeri insieme.
