Pagine locali e visibilità AI: come renderle accessibili e affidabili

Un’attività locale se non compare nelle risposte di ChatGPT, Perplexity o negli AI Overviews quando un utente vuole effettuare la ricerca di un servizio nella tua città, si pensa che la soluzione migliore sia intervenire subito sui testi, aggiungendo domande frequenti o riscrivendo le pagine di servizio in chiave conversazionale. 

Prima di ritoccare i contenuti, però, conviene però verificare due condizioni: se i sistemi AI riescono effettivamente a raggiungere e leggere le pagine locali del sito e se le informazioni aziendali che si trovano sono corrette e allineate con quelle presenti altrove.

Un sito impeccabile dal punto di vista editoriale resta invisibile se un crawler viene bloccato, e allo stesso modo una pagina ben scritta può fare danni se riporta un numero di telefono o un indirizzo che l’azienda non usa più, motivo per cui chi lavora come agenzia SEO a Torino o in qualsiasi altro mercato locale parte sempre dai controlli tecnici prima di svolgere delle modifiche sui testi.

Ecco da dove partire e quali verifiche fare, con gli strumenti più adatti per ciascuna.

Accesso dei crawler AI e rendering delle pagine locali

La prima verifica da fare riguarda le impostazioni che decidono se un bot può entrare nel sito, e quindi il file robots.txt, i tag noindex rimasti per errore dopo la messa online, le sitemap e le regole di sicurezza del server o della CDN.

Un caso frequente è quello di Cloudflare, che su molti siti blocca i crawler AI per impostazione predefinita, spesso senza che il titolare dell’attività o il team marketing ne sia al corrente perché l’opzione è stata attivata dallo sviluppatore o dall’hosting.

Ha senso per un editore che ha bisogno di proteggere i suoi articoli, mentre per un dentista, un idraulico o un ristorante questo potrebbe voler dire rinunciare a una fonte di visibilità.

Il controllo si fa aprendo il pannello di Cloudflare e verificando le regole sui bot, e poi leggendo il robots.txt per capire se user agent come GPTBot, OAI-SearchBot, PerplexityBot o ClaudeBot che invece sono esclusi.

Bisogna ricordare che il robots.txt è un’indicazione rispettata solo dai crawler corretti, per cui i contenuti davvero riservati vanno protetti a livello di server.

Il secondo aspetto è il rendering, perché Google esegue JavaScript con buoni risultati mentre buona parte dei sistemi AI legge solo l’HTML restituito dal server.

Se si ha un sito su WordPress, Wix o piattaforme simili ricevendo già pagine renderizzate in genere non si corrono dei rischi, mentre sui siti costruiti con framework che caricano i contenuti lato client, compresi quelli generati velocemente con strumenti di sviluppo basati sull’AI, possono mostrare ai crawler una pagina quasi vuota. Per verificarlo basta confrontare la sorgente HTML con la pagina visualizzata, oppure lanciare una scansione con Screaming Frog prima senza e poi con il rendering JavaScript attivo, facendo attenzione agli elementi caricati da widget esterni come i caroselli di recensioni.

URL duplicati e dati obsoleti nella SEO locale

Anche quando l’accesso è garantito, i sistemi AI possono ricavare dal sito informazioni sbagliate, e la causa più comune sono le pagine duplicate o dimenticate che sopravvivono ai restyling. 

Durante il rifacimento di un sito capita che gli sviluppatori clonino le pagine esistenti per lavorare sulle nuove versioni, lasciando online URL con suffissi come “-old”, “-copia”, “v2” o “/home” che nessuno ha più deindicizzato.

I visitatori non le trovano perché sono escluse dai menu, ma i crawler sì, e se una di queste pagine riporta il vecchio indirizzo dello studio o un numero di telefono dismesso, nulla impedisce a un assistente AI di usarlo in una risposta.

Un audit tecnico che si limita a cercare errori 404 e redirect non intercetta questo problema, per cui conviene aggiungere un passaggio specifico: scansiona il sito con Screaming Frog o con lo strumento di audit di SEOZoom, filtra gli URL che contengono quei suffissi e verifica che nessuno risulti indicizzabile, poi controlla in Search Console il report sulle pagine indicizzate e cerca su Google con l’operatore sito, le versioni sospette.

Lo stesso ragionamento vale per i dati che vivono fuori dal sito, come le directory locali, le pagine Facebook e le schede su portali di settore, che un sistema AI confronta con quanto trova sulle tue pagine. 

Se il nome, l’indirizzo e il telefono non coincidono tra le diverse fonti, il modello deve scegliere quale versione credere, e non è detto che scelga la tua.

Schema LocalBusiness e Google Business Profile: allineare i dati aziendali

Sull’utilità dei dati strutturati per la visibilità AI le opinioni degli specialisti divergono, perché non esistono studi solidi che dimostrino un aumento diretto delle citazioni o del posizionamento grazie allo schema, mentre è riconosciuto il suo ruolo nel rendere inequivocabili informazioni che nel layout della pagina restano ambigue.

L’approccio più ragionevole è considerare lo schema LocalBusiness come uno strumento di conferma, che replica sul sito ogni dato presente nel Profilo dell’attività su Google, dalla categoria agli orari, dall’area servita ai servizi offerti, così che sito, scheda e markup presentino le stesse informazioni. 

Il rischio concreto, in questo caso, riguarda la manutenzione nel tempo. Molti siti hanno uno schema inserito anni prima dallo sviluppatore, magari tramite un’impostazione di Rank Math o Yoast che il proprietario non sa nemmeno di avere, e quando l’azienda cambia numero di telefono o sede aggiorna la pagina contatti ma lascia il vecchio dato nel markup.

Il problema, a ben vedere, è di processo dato che ogni volta che cambia un indirizzo, un recapito, un servizio o una zona servita, la procedura di aggiornamento deve includere la verifica di tutti i punti in cui quel dato compare, schema compreso, e un controllo con lo Schema Markup Validator dopo ogni modifica richiede pochi minuti.

Quanto allo schema FAQ, da quando Google ha ridotto la visualizzazione dei risultati arricchiti ha perso gran parte del suo valore in SERP, e per gli LLM serve soprattutto quando le domande vengono caricate via JavaScript e non compaiono nell’HTML, mentre se sono già visibili nella pagina il markup si limita a ripeterle.

Come strutturare le pagine di servizio per le risposte AI

Risolti gli aspetti tecnici e la coerenza dei dati, il lavoro sui contenuti parte dalla domanda che un utente farebbe a un assistente AI per trovare il tuo servizio, ad esempio un idraulico disponibile la sera in un certo quartiere o uno studio che offre una prestazione specifica in città. 

Per capire cosa cercano i sistemi puoi fare le stesse richieste su Chat GPT e Perplexity, osservare quali informazioni compaiono nelle risposte e quali siti vengono citati, e incrociare questi dati con le query locali per la tua zona.

Una pagina di servizio efficace deve dedicare a ogni prestazione e a ogni area servita un contenuto proprio, con passaggi che abbiano senso anche estratti dal resto della pagina, perché gli LLM tendono a prelevare singoli blocchi di testo e non la pagina nella sua interezza. 

I dettagli pratici che un utente vuole conoscere prima di contattarti, come gli orari, le zone coperte, i tempi di intervento o un’indicazione sui costi, vanno scritti in modo esplicito nel testo invece di essere affidati a immagini, mappe incorporate o widget.

Informazioni fornite in modo indipendente da un nostro partner nell’ambito di un accordo commerciale tra le parti. Contenuti riservati a un pubblico maggiorenne.