Oggi parliamo di ottimizzazione sito web.
Evitare errori che danneggiano la SEO
In un’ottica di posizionamento organico, essa intesa come la realizzazione di contenuti scritti secondo determinate regole matematiche che determinano il livello di ottimizzazione sito web, l’obbiettivo è quello di posizionare un sito internet naturalmente.
Questo significa senza utilizzare stratagemmi o tecniche particolari che altro non siano la scrittura di testi e la gestione di determinati tag (URL, H1, H2, Title, Description e testo) all’interno della pagina.
Ciò che è fondamentale, anche se spesso viene sottovalutato, è evitare errori che possono danneggiare l’attività fatta mediante la scrittura dei contenuti.
Nel vasto e complesso campo dei motori di ricerca, l’errore non è altro che una scorretta impostazione a livello tecnico del codice sorgente o di altre componenti del sito nel quale stiamo intervenendo.
Si tratta di errori (che approfondiremo in altri post più avanti) che, quando commessi, portano ad una perdita anche sostanziale di posizionamento o, se trattasi di lavoro effettuato ex-novo, a non ottenere affatto alcun risultato apprezzabile.
Il ritardo che si viene a creare nell’intervallo di tempo che va dall’analisi tecnica finalizzata ad individuare gli errori, alla ricerca delle soluzioni e alle implementazioni necessarie è minimo se paragonato ai tempi tecnici richiesti dai motori di ricerca per assorbire le variazioni di un ambiente già esistente, elaborarle e reagire di conseguenza.
Diventa quindi assolutamente fondamentale, per una buona ottimizzazione sito web, acquisire un set di competenze che ci consente di operare in modo corretto in qualsiasi scenario ci si possa presentare, proprio per evitare di dover, in tempi futuri, correggere errori pregressi e aver a che fare con i tempi di reazione dei motori di ricerca.
La struttura per i siti multilingua
Quando abbiamo a che fare con un sito che presenta più di una lingua, viene naturale seguire il ragionamento che ci porta a destinare delle sottocartelle per ogni lingua del sito che dobbiamo gestire.
Non è un comportamento del tutto errato, ma spesso il modo in cui viene implementato porta a grossolani errori di gestione.
Si prenda il classico esempio del dominio “miodominio.com”, che ha l’esigenza di avere 4 lingue: italiano, inglese, tedesco e francese. Una configurazione classica è questa:
- miodominio.com (per l’italiano)
- miodominio.com/en/
- miodominio.com/de/
- miodominio.com/fr/
Una configurazione del genere, o con nomi di cartella simili (ad es. “eng”, “deu”, ecc…) è errata dal punto di vista concettuale perchè si presuppone, agli occhi di un motore di ricerca, che esista un solo dominio con contenuti disponibili in più lingue, lasciando a un selettore linguistico o, ancor peggio, ad un riconoscimento automatico, la determinazione della lingua che deve essere mostrata all’utente.
Scenari di questo tipo, quindi, se non correttamente gestiti, portano a non ottenere risultati apprezzabili in termini di posizionamento organico per tutte le lingue cui sono realizzati.
Il problema si può correggere in diverse modalità:
- Assicurandoci che le singole lingue abbiano i loro metadati linguistici, completi quindi di lingua corrente e lingue alternative. In questo caso il motore di ricerca sarà in grado di trovare e determinare il fatto che la stessa pagina “dove-siamo” in italiano esiste anche in inglese con il nome di “where-we-are” e così via per tutte le lingue. Ciò che è completamente sbagliato è avere una pagina “mono URL” che cambia lingua dinamicamente.
- Spostando le varie lingue del sito in opportuni sottodomini, uno per ogni lingua, con nomi commercialmente utili (visto che comunque devono apparire in SERP) oppure con i riferimenti di geolocalizzazione (ad esempio “en.miodominio.com”).
- Usando domini di secondo livello con il TLD di ogni lingua specifica. Questo caso, però, potrebbe risultare più complesso per il fatto che alcune estensioni di dominio risultano difficili da acquistare (alcune nazioni richiedono la presenza locale per l’acquisto, e altre restrizioni particolari che potrebbero rendere difficoltosa la transazione e il mantenimento).
In ogni caso, quando si lavora con i CMS tradizionali, come ad esempio WordPress, il plugin che va per la maggiore, ossia WPML, permette di gestire la questione multilingua per tutte e tre le situazioni (di default sceglie la soluzione a “sottocartelle”).
Si tenga in considerazione questo particolare aspetto, perchè la gestione a cartelle non gestisce il corretto invio delle sitemap separate per lingua, il che potrebbe inficiare l’ottimizzazione sito web.
Una sitemap per ogni lingua
Quando un sito, in qualunque modo sia costruito, fa uso di contenuti che sono disponibili per l’utente finale in più lingue, detti riferimenti devono essere sempre presentati al motore di ricerca inserendoli in sitemap.
Ci sono sostanzialmente due modi per poter fare correttamente questa operazione:
- Se il sito non fa uso di piattaforme differenziate per lingua, è possibile inserire in sitemap l’URL principale di una risorsa e le relative derivazioni mediante il rel=”alternate”. Questa configurazione prevede la necessità di inserire le indicazioni delle lingue differenti nella sezione head della pagina specifica per completezza.
- Se il sito fa uso di piattaforme differenziate (sottodomini o domini differenti) è sufficiente inserire una sitemap specifica per ogni ambiente e si risolve il problema.
Nel primo caso, comunque, non è assolutamente una soluzione quella di creare una sitemap separata per ogni lingua e poi unirle con un indice di sitemap, perchè verremmo a perdere l’indicazione del target linguistico di riferimento.
Codice sorgente pulito e ordinato
Una regola d’oro della scrittura del codice HTML dice che, qualora venissero disattivati i CSS prima di visualizzare una pagina, il flusso con il quale si vedono i contenuti non formattati dovrebbe comunque permettere di capire come una pagina è strutturata.
Pertanto, questa sezione si concentra principalmente sul codice scarsamente qualitativo prodotto da alcuni IDE, come per esempio Wix o similari, che fanno uso di un ambiente grafico per la progettazione delle pagine dove l’utente può creare tutti gli elementi che vuole partendo da dove più desidera.
Bello da un punto di vista di semplicità di funzionamento, che però va, il 100% delle volte, a scapito della qualità del codice che poi viene prodotto.
Si tratta sempre di contenitori che vengono posizionati sulla pagina in modo assoluto nell’ordine arbitrario deciso dallo strumento. Effettuare modifiche su quel codice, anche in considerazione di tutti i selettori alfanumerici che lo stesso IDE va inutilmente a inserire, è pressochè impossibile.
Usare quel codice per creare landing page non è pensabile, perchè il motore di ricerca andrebbe seriamente a penalizzarle in quanto il codice non sfrutta le regole di pulizia e semantica a cui ora dobbiamo per forza abituarci.
Non importare risorse inutili
In un’ottica di ottimizzazione sito web, quando un determinato componente viene utilizzato solo in una specifica sezione del sito, teoricamente le sue dipendenze (Javascript, CSS, ecc…) dovrebbero essere importati solamente dove ce n’è effettivamente bisogno.
Nella realtà dei fatti, questo accade pochissime volte, soprattutto per quel che concerne i plugin per i CMS tradizionali, dove in quasi nessuno c’è la possibilità di gestire amministrativamente questo aspetto.
In un’ottica di CMS proprietario, la configurazione migliore è quella che controlla se effettivamente in una pagina va utilizzato un particolare componente, e solo se è così, ne importiamo tutte le dipendenze necessarie.
La fluidità della navigazione e i punteggi che i vari sistemi di benchmark ci possono dare saranno sicuramente migliori.
