Ogni scheda Google ha un campo per il sito web, e in molte reti punta alla home page. Il cliente che cerca la sede di Bergamo arriva su una pagina che parla del brand in generale, deve ritrovare la sede, e spesso non ci riesce. Le pagine sede servono a questo: una pagina per ogni sede reale, con le sue informazioni, raggiungibile dalla scheda e dal sito. Sono il punto in cui sito e schede locali si incontrano, e per questo devono dire esattamente le stesse cose.
In questo articolo vediamo cosa deve contenere una pagina sede, come si usano i dati strutturati e quali errori evitare per non trasformare le pagine locali in un problema. Fa parte della nostra guida al presence management per brand multisede; la scelta del link da mettere nella singola scheda è spiegata nell'articolo sul link al sito nella scheda Google.
Perché ogni sede ha bisogno della sua pagina
La scheda Google è uno spazio con campi fissi: nome, indirizzo, orari, telefono, categorie, servizi, foto. Molte informazioni che i clienti cercano prima di andare in una sede non ci stanno: come si arriva con i mezzi, dove si parcheggia, quali servizi sono disponibili solo lì, chi è il responsabile, quali eventi sono in programma. La pagina sede può ospitarle tutte, e diventa la destinazione naturale del link della scheda.
Per il motore di ricerca la pagina sede è anche una conferma. Quando la scheda e la pagina che la scheda linka riportano lo stesso nome, lo stesso indirizzo, lo stesso telefono e gli stessi orari, le informazioni si rafforzano a vicenda. Quando non coincidono, è il sito a contraddire la scheda. Ed è proprio dal sito che Google prende spesso conferma per pubblicare le modifiche proposte da altri, come spieghiamo nell'articolo sul controllo periodico delle schede.
Cosa deve contenere una pagina sede
La prima parte è la copia esatta dei dati della scheda: nome della sede come compare su Google, indirizzo completo, telefono della sede, orari settimanali e orari speciali delle festività. Questi dati non vanno scritti a mano nella pagina: devono arrivare dalla stessa anagrafica che alimenta le schede, altrimenti al primo cambio di orario sito e scheda divergono. La seconda parte è quella che rende la pagina utile: una descrizione scritta per quella sede, i servizi disponibili, le indicazioni per arrivare, le foto vere del punto vendita, i riferimenti del personale quando ha senso. È il contenuto che distingue la pagina di Bergamo da quella di Brescia.
Le pagine sede vanno collegate tra loro e al resto del sito: una pagina che elenca tutte le sedi, ordinate per regione e città, e da lì le singole pagine. Quando la scheda Google linka la pagina della sede, conviene aggiungere al link i parametri UTM, così in Google Analytics il traffico che arriva dalle schede si distingue da quello organico, come spieghiamo nell'articolo su UTM e Google Business Profile. È anche la base per misurare la presenza locale, tema dell'articolo sui KPI della presenza locale.
I dati strutturati: LocalBusiness, senza esagerare
I dati strutturati dicono al motore di ricerca, in un linguaggio standard, che la pagina descrive un'attività locale con quel nome, quell'indirizzo e quegli orari. Per Google il tipo da usare è LocalBusiness, o un suo sottotipo più specifico; le proprietà obbligatorie sono name e address, e tra quelle consigliate ci sono le coordinate geografiche (geo), gli orari (openingHoursSpecification, che con validFrom e validThrough permette di indicare anche gli orari di un periodo preciso), il telefono e l'url della pagina (documentazione di Google sui dati strutturati LocalBusiness). Per le reti con reparti distinti nella stessa sede esiste anche la proprietà department.
C'è un limite che molte reti ignorano. Le proprietà aggregateRating e review di LocalBusiness, quelle che possono far comparire le stelle nei risultati, secondo Google valgono per i siti che raccolgono recensioni di altre attività: non per le recensioni che un'azienda ha ricevuto sulla propria attività. Inserire nel codice della pagina sede la media delle recensioni Google della sede non porta le stelle nei risultati, e non è l'uso previsto. Le recensioni si possono mostrare nella pagina per i visitatori, ma il markup va lasciato alle informazioni che descrivono la sede.
| Informazione | Scheda Google | Pagina sede |
|---|---|---|
| Nome, indirizzo, telefono | Sì | Sì, identici alla scheda e nei dati strutturati |
| Orari settimanali e festivi | Sì | Sì, dalla stessa fonte della scheda |
| Come arrivare, parcheggio, accessibilità | In parte, con gli attributi | Sì, con il dettaglio che serve |
| Servizi e reparti della sede | Servizi e categorie | Sì, con descrizioni proprie |
| Link di tracciamento | Link alla pagina con UTM | Destinazione del link |
| Recensioni | Sì | Si possono mostrare, ma senza markup aggregateRating |
L'errore da non fare: le pagine per città senza sede
Le pagine locali attirano una tentazione: creare una pagina per ogni città in cui si vorrebbe comparire, anche dove non c'è una sede, con testi quasi identici in cui cambia solo il nome del comune. Google descrive questa pratica nelle sue norme antispam come abuso di doorway: pagine create per posizionarsi su ricerche specifiche che portano a pagine intermedie meno utili della destinazione finale, con l'esempio esplicito di più pagine destinate a regioni o città specifiche che rimandano gli utenti a un'unica pagina (norme di Google sullo spam).
La regola pratica è semplice: una pagina per ogni sede reale, con informazioni proprie e utili. Se una zona è servita senza una sede fisica, la si descrive nella pagina della sede che la serve, non con una pagina a sé. Il tema si collega a quello più ampio della visibilità locale di una rete, che trattiamo nell'articolo sulla local SEO per brand multisede.
Pagine sede e schede con gli stessi dati
Con il Local Listing di Calton orari e informazioni delle schede Google Business Profile di tutte le sedi si aggiornano da un'unica piattaforma: c'è un solo riferimento da cui il team del sito riprende i dati delle pagine sede.
Durante l'onboarding il team Calton fa l'audit delle schede insieme all'azienda, compreso il controllo dei link al sito: quali puntano alla home, quali alla pagina giusta, quali a pagine che non esistono più.
Le indicazioni su dati strutturati e spam vengono dalla documentazione ufficiale di Google Search Central, linkata nel testo e consultata il 16 ottobre 2026.






