In breve
Un percorso diagnostico per distinguere mancata indicizzazione, scarso posizionamento e problemi di visibilità locale.
- Verificare prima se l’URL è indicizzato
- Controllare accesso, noindex e canonical
- Separare problemi tecnici e mancata rilevanza
- Usare Search Console per una diagnosi per URL
Non indicizzato, non posizionato o non visibile localmente
Una pagina indicizzata può non apparire nelle prime posizioni per la query che interessa. In quel caso il problema non è l’accesso all’indice, ma la corrispondenza con l’intento, la qualità del contenuto, la concorrenza e i segnali che aiutano il motore a comprenderne il valore.
La visibilità locale aggiunge altri elementi: pertinenza del sito, informazioni dell’attività, coerenza tra fonti e capacità di rispondere a un bisogno legato al luogo. Prima di intervenire è quindi necessario nominare correttamente il sintomo.
Come verificare la presenza nell’indice
Il controllo più utile è l’ispezione dell’URL in Google Search Console, che mostra se la pagina è conosciuta, quale canonical è stata selezionata e se sono presenti impedimenti. Una ricerca con l’operatore site: può offrire un’indicazione rapida, ma non è un inventario completo né sostituisce gli strumenti del proprietario.
È importante testare l’URL esatto, inclusi protocollo, sottodominio e slash. Versioni apparentemente simili possono essere indirizzi distinti e reindirizzarsi in modo inatteso.
Problemi di accesso e scansione
La pagina deve rispondere correttamente, essere raggiungibile da link scansionabili e non essere bloccata da autenticazione o regole incompatibili. Errori 4xx o 5xx, redirect ciclici, tempi di risposta instabili e risorse indispensabili bloccate possono impedire o complicare la scansione.
Robots.txt gestisce la scansione, ma non è il metodo corretto per chiedere la rimozione di una pagina dall’indice. Una combinazione incoerente tra blocco robots e direttive di indicizzazione può impedire al motore di leggere proprio le istruzioni che dovrebbe elaborare.
Primi controlli tecnici
- Stato HTTP dell’URL finale
- Redirect e dominio preferito
- Regole di robots.txt
- Meta robots e header X-Robots-Tag
- Canonical dichiarata e selezionata
- Presenza di link interni reali
Noindex, canonical, duplicati e soft 404
Una direttiva noindex chiede di non indicizzare la pagina. Può essere rimasta da un ambiente di prova o essere applicata da un template. La canonical, invece, indica la versione preferita tra contenuti simili: se punta altrove, Google può scegliere un altro URL come rappresentativo.
Pagine quasi vuote, risultati senza contenuto o URL che mostrano messaggi di errore pur rispondendo 200 possono essere trattati come soft 404. Anche grandi quantità di duplicati e parametri rendono meno chiaro quale pagina debba essere mostrata.
Sitemap, link interni e pagine orfane
La sitemap segnala URL che il sito considera importanti, ma non garantisce scansione, indicizzazione o posizionamento. Dovrebbe contenere soltanto pagine canoniche e indicizzabili. Gli URL devono inoltre essere raggiungibili da collegamenti HTML coerenti, con testi che aiutino a comprenderne il contenuto.
Una pagina presente soltanto nella sitemap ma assente dalla navigazione e dai contenuti è debole nel sistema interno. L’architettura deve mostrare relazioni sensate tra servizio, guida, caso reale e area territoriale, evitando pagine isolate.
Quando il problema è il contenuto
Se l’URL è accessibile e indicizzato, occorre verificare se risponde davvero alla ricerca. Un testo generico, creato soltanto per ripetere parole chiave o quasi identico ad altre pagine, offre pochi motivi per essere scelto. Titolo, apertura, sezioni, esempi e collegamenti devono affrontare il bisogno con un livello di dettaglio proporzionato.
Non esiste un numero minimo di parole valido per ogni pagina. Conta la capacità di risolvere il compito dell’utente, mostrare esperienza reale e rendere verificabili le informazioni. Per attività locali, dati pratici e prove del luogo sono spesso più utili di lunghe descrizioni astratte.
Ordine dei controlli e quando serve un audit
| Passaggio | Domanda | Strumento o evidenza |
|---|---|---|
| 1. Accesso | L’URL risponde ed è scansionabile? | Browser, header, robots e test URL |
| 2. Indice | È indicizzato e con quale canonical? | Ispezione URL in Search Console |
| 3. Architettura | È collegato e presente nella sitemap corretta? | Scansione del sito e link interni |
| 4. Rilevanza | Risponde meglio delle alternative all’intento? | Contenuto, SERP e query reali |
| 5. Qualità complessiva | Esistono pattern tecnici o editoriali più ampi? | Audit per template, sezione e sito |
Un audit è utile quando il problema riguarda molte pagine, quando cause tecniche ed editoriali si sovrappongono o quando una migrazione recente ha modificato URL e contenuti. La priorità deve derivare dalle evidenze, non dall’applicazione indiscriminata di una checklist.
Esempi reali da progetti pubblicati
Questi progetti non vengono presentati come prova di risultati quantitativi non documentati. Mostrano come architettura, contenuti e funzioni siano stati applicati a esigenze concrete.
- Farmacia Delogu Roma: Servizi, informazioni locali e contatti organizzati per ricerche concrete.
- Sanylab: Servizi specialistici e area operativa collegati a bisogni specifici.
Per inquadrare l’intervento nel suo insieme, consulta anche il servizio SEO e posizionamento organico.
Fonti e approfondimenti
Riferimenti ufficiali utilizzati per gli aspetti tecnici o normativi che richiedono verifica. Le indicazioni vanno sempre applicate al contesto specifico.
