Una pagina raggiungibile con un link non deve necessariamente comparire su Google. Per una PMI che offre preventivatori, aree collaborative, documenti condivisi o strumenti AI sul proprio dominio, questa distinzione può evitare problemi di qualità e di esposizione dei contenuti. Il 26 ottobre 2026 Google ha aggiornato la guida contro lo spam generato dagli utenti, includendo indicazioni sulle pagine condivise tramite link e sul monitoraggio degli abusi in Search Console.
È un aggiornamento della documentazione: non è, di per sé, l’annuncio di una nuova penalizzazione o di un nuovo algoritmo. Il punto operativo è decidere quali contenuti hanno uno scopo pubblico nella ricerca e quali servono soltanto a completare un’attività. Di seguito proponiamo un metodo UHD per fare questa distinzione, soprattutto su WordPress, portali clienti e piccole applicazioni web.
Che cosa chiarisce Google
La guida cita esplicitamente piattaforme e strumenti che permettono agli utenti di pubblicare pagine condivise, contenuti generati o web app. Per materiali destinati alla condivisione diretta, alla collaborazione o a un’utilità specifica, invita a valutare l’esclusione predefinita dalla ricerca. Aggiunge inoltre indicazioni per rilevare abusi attraverso Search Console e anomalie nella creazione delle pagine.
Non significa che ogni contenuto creato da un utente o con l’AI debba sparire dall’indice. Un caso studio approvato, una scheda professionale curata o uno strumento pubblico possono avere un valore autonomo per chi cerca. Il criterio da fissare prima dello sviluppo è la destinazione del contenuto, non soltanto il modo in cui è stato prodotto.
Tre categorie da distinguere nel sito aziendale
1. Contenuti pensati per essere trovati
Servizi, guide, prodotti e pagine di presentazione devono rispondere a domande reali del pubblico. Una PMI può stabilire un controllo editoriale prima di renderli indicizzabili: titolo chiaro, informazioni verificabili, assenza di dati riservati e una persona responsabile. L’approvazione rende esplicito il passaggio da semplice output di un’applicazione a contenuto aziendale pubblicato.
2. Pagine di lavoro accessibili tramite link
Il risultato temporaneo di un configuratore, una bozza da discutere con un cliente o una pagina di confronto personalizzata potrebbero dover funzionare senza diventare una destinazione SEO. Come scelta progettuale, conviene assegnare a questi URL un comportamento distinto dalle pagine editoriali. Il pulsante “condividi” non dovrebbe attivare automaticamente la stessa visibilità del pulsante “pubblica”.
3. Materiali riservati
Preventivi nominativi, allegati dei clienti e dati dell’area personale richiedono una protezione dell’accesso. La documentazione Google distingue chiaramente questa esigenza dall’esclusione dai risultati: noindex non è una password. Una risorsa con noindex può restare visitabile da chi possiede il link. Per contenuti privati occorrono autenticazione e autorizzazioni adeguate, verificate anche sui file allegati.
Noindex e robots.txt: l’errore da evitare
Google supporta noindex tramite un meta tag nella pagina oppure un’intestazione HTTP X-Robots-Tag. Per leggere la regola deve poter accedere alla risorsa: se robots.txt blocca la scansione, Googlebot potrebbe non vedere noindex e l’URL potrebbe comunque apparire nei risultati, per esempio grazie a link esterni. Non basta quindi sommare blocchi diversi per ottenere una protezione migliore.
Per una pagina HTML pubblicamente accessibile ma da escludere dalla ricerca, si può valutare un meta robots con noindex lasciando possibile la scansione. Per PDF e altre risorse può essere appropriata l’intestazione HTTP. L’implementazione va scelta per tipo di contenuto e verificata sulla risposta realmente consegnata al crawler, non soltanto su un’impostazione nel pannello del CMS.
In WordPress suggeriamo di controllare separatamente articoli, pagine, tipi di contenuto personalizzati e URL prodotti dai plugin. Una configurazione corretta per il blog non prova che lo sia anche per il portale preventivi. Anche cache e template possono rendere diverso il risultato tra visitatore autenticato e anonimo.
Un esempio pratico: il preventivatore di una PMI
Immaginiamo un’azienda di serramenti con un configuratore. La pagina che spiega materiali, prestazioni e funzionamento del servizio è utile al pubblico. Il risultato generato per un singolo cliente, invece, contiene misure e preferenze specifiche. La prima può essere una destinazione editoriale; il secondo dovrebbe avere una politica di accesso e visibilità definita dal progetto.
Una soluzione proposta da UHD è separare il percorso pubblico del servizio dal percorso dei risultati. La creazione di un risultato non lo trasforma in una pagina di catalogo. Un eventuale caso studio nasce con una revisione separata, rimuovendo informazioni riservate e aggiungendo spiegazioni utili a un pubblico più ampio. Si evita così che migliaia di varianti quasi identiche diventino pagine pubbliche senza una decisione consapevole.
Lo stesso metodo vale per report AI, simulatori e piccole app generate dagli utenti. Prima si definisce chi deve vedere l’output; poi si decide se abbia senso proporlo anche a persone che arrivano dai motori di ricerca. Sono due scelte distinte, da rendere comprensibili anche nell’interfaccia.
Cosa controllare in Search Console
Google consiglia di verificare la proprietà e osservare indicizzazione e rendimento per individuare aumenti inattesi di pagine, impressioni o query estranee allo scopo del servizio. Suggerisce anche di confrontare questi segnali con la creazione di contenuti sulla piattaforma. Un’anomalia è un punto di partenza per l’indagine, non la prova automatica di spam.
Per una piccola azienda proponiamo un registro semplice: URL campione, tipo di contenuto, stato previsto, stato osservato, responsabile e ultima verifica. Se il portale genera molti risultati, il confronto tra nuove risorse e nuove pagine pubbliche aiuta a capire se una modifica ha allargato involontariamente la superficie esposta. Una campagna o una migrazione possono spiegare un picco legittimo: il contesto aziendale resta necessario.
Il controllo va collegato alla qualità della misurazione. La guida UHD sui filtri hostname in Google Analytics affronta un problema complementare: distinguere dati pertinenti da segnali contaminati. Search Console e analytics non descrivono la stessa cosa e non vanno usati come conferma reciproca automatica.
Una verifica operativa in cinque passaggi
- Inventariare i percorsi: elencare pagine editoriali, risultati di strumenti, documenti e aree clienti, includendo quelli introdotti dai plugin.
- Assegnare uno scopo: per ogni famiglia decidere se è destinata alla ricerca pubblica, alla condivisione diretta o ad accesso riservato.
- Provare esempi reali: controllare una risorsa appena creata e una esistente, come utente autorizzato e come visitatore anonimo.
- Verificare il risultato tecnico: confrontare accesso, risposta HTTP e direttive effettive con lo stato previsto, prima di estendere una modifica a tutto il sito.
- Registrare e riesaminare: annotare le correzioni e controllare gli effetti dopo il rilascio, senza promettere tempi certi di aggiornamento della ricerca.
Questo lavoro non richiede di nascondere indiscriminatamente il sito. Al contrario, permette di difendere la visibilità delle pagine che meritano una destinazione pubblica. Il tema si collega all’approfondimento UHD su scoperta dei contenuti da parte degli assistenti AI: prima di favorire l’accesso dei sistemi automatici, occorre sapere quali risorse si vogliono davvero rendere disponibili.
Da dove partire senza interventi affrettati
La priorità è un campione delle funzioni che generano URL, non una modifica globale a robots.txt. Chi gestisce un sito aziendale può chiedere al proprio sviluppatore una mappa della visibilità delle risorse e una verifica dei percorsi più delicati. Se servono correzioni, meglio applicarle per famiglia e con un controllo successivo. UHD può aiutare a verificare struttura e funzionamento del sito, trasformando il chiarimento di Google in una scelta progettuale concreta.
