Faccio SEO dal 2003 e in questi quasi 20 anni di lavoro ho affrontato varie problematiche a livello SEO; ho visto negli anni tanti progetti che di base avevano sempre gli stessi problemi.
Ecco quindi una carrellata di errori visti varie volte e su cui qualsiasi azienda dovrebbe prestate molta attenzione.
Il developer non è un SEO
Nella mia vita ho incontrato tanti sviluppatori di software con buone competenze SEO, ma di base un developer non è un SEO. Questo è il primo errore principale, che commettono moltissime aziende.
Non è colpa degli sviluppatori se un progetto non funziona dal punto di vista SEO, anche perché un buon developer fa quello per cui è stato pagato: far funzionare i siti. La questione di fondo è che non è detto che ciò che funziona e si vede online sia sempre ottimizzata a livello SEO.
Se sei un manager, che decide dove allocare il budget e su quali figure puntare, ricorda che un buon developer potrebbe non avere competenze SEO, ed è giusto così. Se vuoi risolvere i problemi con l’ottimizzazione per i motori di ricerca chiami un SEO.
Questo, di base, è il padre di tutti gli errori commessi sui siti.
E attenzione, perché quando parlo di SEO intendo un professionista, con background tecnico, in grado di snocciolare le tue pagine e indicarti quali sono i problemi. Stai alla larga dai SEO che ti parlano di grassetti e title, perché quelli sono copywriter, non SEO.
URL indicizzate
In base al business dell’azienda stessa, può succedere di dare in pasto a Google un’enorme quantità di URL, spesso di dubbia qualità. Questo problema l’ho rilevato principalmente sui siti classified, in particolar modo su quelli che si basano su tecnologia Windows.
Sono due problemi differenti da analizzare attentamente.
Classified con numerosi URL
Per far comprendere la questione facciamo un esempio banale: un portale con hotel, quindi con pagine di risultati tematizzate a singole città. Partiamo da qualche punto fermo, come per esempio il fatto che in Italia abbiamo:
- 20 regioni
- 105 province
- circa 8.000 comuni
Quindi, se facciamo una pagina con gli Hotel per ognuna di queste aree geografiche, presto ci ritroveremo con oltre 8.000 pagine indicizzate. Fin qui nulla di male, se riusciamo a dare un contenuto diverso in ognuna di queste pagine.
Avremo quindi URL come per esempio:
- /hotel/milano-provincia
- /hotel/milano
- /hotel/sesto-san-giovanni
e così via.
Il problema nasce quando inizieremo a filtrare per tipologia e per filtri vari. Quindi poniamo che la prima tipologia sia alberghi, così da distinguere, per esempio, dagli ostelli, da affittacamere e le altre tipologie differenti. In questo caso avremo delle URL come, per esempio:
- /alberghi/milano-provincia
- /alberghi/milano
e così via.
La problematica di queste URL sta nel contenuto, poiché un portale che contiene location per dormire, avrà nel 90% dei casi alberghi, quindi, se va bene, il 90% delle pagine /alberghi e /hotel saranno duplicate.
La problematica esplode quando inizieremo a filtrare. Facciamo per esempio il caso che il portale abbia 3 filtri (e per un classified sono veramente pochi):
- Stelle
- Prezzo
- Colazione
Le stelle sono 5, quindi le nostre 8.000 URL diventeranno molto velocemente 48.000 (8 mila senza filtri, 40.000 con nome comune e stelle). Ma fin qui siamo ancora nell’ordine delle cose, perché la search intent “Hotel Milano a 4 stelle” ha un senso di esistere.
Applichiamo quindi la disponibilità della colazione, ed essendo un filtro boolean vorrà dire che raddoppieremo le URL: 48.000 senza filtro e 48.000 con colazione, per un totale di 96.000 URL.
Quindi arriviamo alla bomba: il prezzo. Diciamo che il portale ha avuto un po’ di accortezza e ha dato la possibilità di filtrare solo per 5/6 fasce (da 0 a 50 euro – da 50 a 100 e così via). In tal caso, le nostre URL aumentano esponenzialmente (in caso di 5 fasce avremo 480 mila URL).
Pensiamo se il sito avesse il campo libero, potenzialmente avremmo URL con il filtro per ogni singolo prezzo possibile, significa tendere all’infinito con il numero di URL.
Ma un portale di accomodation (o in generale un classified) non ha solo 3 filtri. Ne ha decine e provate a replicare questo giochino appena fatto su decine di filtri con decine di possibilità. Presto tenderete all’infinito come URL.
Perché questo è un problema? Semplice: Google assegna un totale di risorse finite per scansionare il vostro sito (crawl budget), se state segnalando troppe URL rischiate di far vedere URL inutili e non far vedere le modifiche sulle pagine principali, o addirittura di non far indicizzare alcune URL di prodotti/alberghi, perché il budget non è sufficiente.
Questa problematica l’ho affrontata un po’ di anni fa, quando un classified stava andando nella direzione di indicizzare tutte le URL possibili, facendogli un veloce calcolo, stavano passando a Google circa 87 miliardi di URL (per fare un paragone, con il comando “site:” Facebook ne ha “solo” 2,3 miliardi), il 90% delle quali vuote. Inutile dire che sono stato contattato dopo una penalizzazione da parte del motore di ricerca e il primo lavoro su quel sito è stato proprio quello di pulire questo scempio.
Server su Windows
Passiamo quindi al secondo caso che, se non gestito, crea duplicazioni infinite. Oramai Internet gira quasi completamente su mondo Unix, i server sono per la maggior parte su distro linux, ma ancora qualche avventuriero ha portali su server IIS. Tipicamente, chi ha sempre sviluppato su Windows, ha sempre prestato poca attenzione al case sensitive, poiché Windows, a differenza di Unix, risponde con una risorsa a prescindere da come venga chiamata.
Lo standard vorrebbe che tutte le URL fossero formattate in minuscolo, ma gli sviluppatori che usano Windows questo standard spesso lo dimenticano, quindi non è difficile trovare URL che abbiano maiuscole e minuscole sparse a caso.
Riprendendo il caso precedente, facciamo finta che le URL rispondano su:
- /hotel/milano
- /Hotel/milano
- /Hotel/Milano
- /HOTEL/Milano
e tutte le varianti possibili. Le x mila URL create regolarmente hanno, potenzialmente, altre xxx migliaia di copie, pronte a essere indicizzate, poiché Google, giustamente, segue lo standard e quindi è case sensitive.
Google ovviamente ha la tecnologia per riconoscere questo errore e correggerlo autonomamente, ma ciò non cambia il fatto che le URL, se conosciute da Google, rimarranno nel proprio indice, per poi essere segnalate come URL duplicate con canonical (o peggio senza canonical).
Nel tempo Google ha limitato il budget che concede a queste varianti, ma comunque dello spreco c’è a prescindere, con il rischio di ritrovarsi centinaia di miglia di URL duplicate.
CSS/JS corposi
Abbandoniamo la questione duplicazione di URL ed entriamo nella sfera più intima dello sviluppo. Un altro errore che ho sempre (e dico sempre) incontrato è quello di creare un unico file di CSS e un unico file di JS per tutto il sito. Ovviamente il sito funziona perfettamente, quindi il developer non avrà alcun problema con il committente. I problemi nascono quando Google inizia a segnalare che sono presenti tonnellate di MB di JS/CSS non utilizzati dalla pagina.
Si tratta di una strategia oltretutto miope, poiché non tiene in considerazione il fatto che un utente potrebbe essere su un mobile, con una connessione lenta, e scaricare 5/10 MB (giuro ho incontrato file così grandi) di CSS/JS, che contengono la storia di tutte le versioni di codice prodotto negli anni, porta inevitabilmente la pagina a essere lenta e caricare in vari secondi.
Nell’epoca in cui un utente non aspetta oltre i 2 secondi per visualizzare una pagina, ciò significa che probabilmente state già perdendo un discreto numero di utenti che vi ha trovati, inoltre Google non apprezza pagine lente, quindi state perdendo migliaia di utenti che non vi vede nemmeno.
Di solito, quando sollevo la questione, i developer “svegli” mi rispondono che tanto il JS e il CSS sono in cache del browser, quindi l’utente non deve scaricarli ogni volta. I furboni dimenticano che comunque il browser sul device deve gestire MB di spazzatura per poter comporre la pagina, e anche questa è una lentezza.
Ma infine, e qui mi metto nei panni del povero utente, ma per quale diavolo di motivo dovrei occupare decine di MB di spazio sul mio device (o secondi di elaborazione su CPU o mega di RAM, per non parlare della banda per scaricare la spazzatura) per caricare una pagina su cui il proprietario non ha prestato alcuna attenzione? Qui fa bene Google a non farla comparire nei risultati.
Contenuti copiati
Tanti anni fa lavorai per un noto quotidiano, il quale, vista la carenza di giornalisti nella redazione online, per non “bucare” una notizia si era attaccata al flusso di Ansa e quindi per ogni agenzia creava un articolo con il solo testo dell’agenzia stessa.
In pratica il 99% degli articoli prodotti da tale quotidiano aveva due caratteristiche fondamentali: era corto e aveva una copia online (in realtà centinaia).
Qui mi metto nei panni del motore di ricerca: per quale motivo dovrei indicizzare, posizionare e mostrare agli utenti due volte (o decine di volte) la stessa notizia/pagina, semplicemente con un header/footer differente?
Inoltre in quegli anni era pratica comune fare questa attività, quindi Google, potenzialmente, avrebbe dovuto posizionare intere paginate della stessa copia. Follia…
E infatti Google ne posizionava una a caso (spessissimo Ansa ma non sempre) e faceva sparire la concorrenza.
Tale quotidiano aveva il picco di traffico alla mattina, quando veniva importato il cartaceo (vero contenuto originale), e praticamente spariva per il resto della giornata, nonostante ci fosse un flusso continuo di aggiornamento.
Pagine inutili
Di pagine inutili ne ho deindicizzate a migliaia, ma di recente mi è successo di trovare un sito, composto da poche decine di pagine “utili”, che presentava quasi un migliaio di URL valide su Google Search Console (e altrettante ignorate dal motore di ricerca). Andando un po’ più a fondo è apparso subito chiaro come quelle pagine fossero una strategia adottata da un consulente prima di me. Si trattava di landing, piazzate al volo sul dominio principale, con l’unico scopo di traghettare traffico di bassa qualità acquistato attraverso i più disparati modi. Il goal di quelle pagine era di traghettare l’utente, il più velocemente possibile, dalla landing verso il sito vetrina.
Landing orfane di qualsiasi link in ingresso, abbandonate là in attesa che si suicidassero da sole. Relativamente poche pagine uniche, con delle varianti in base al competitor (quindi guerrilla marketing, alla “carlona”, per rubicchiare traffico a qualche sito un po’ più grande), che quindi moltiplicavano esponenzialmente le URL conosciute.
Ecco, non fate una cosa del genere, perché ogni pagina inutile abbassa il ranking dell’intero dominio agli occhi di Google. Se siete piccoli fate il vostro e cercate di crescere per vie ortodosse, non con sotterfugi che poi, inevitabilmente, vi porteranno nelle mani di un SEO, il quale prima si fustiga e poi inizia il lavoro.
Link verso siti di dubbia qualità
Attenzione ai link in uscita, lo ripeto: attenzione ai link in uscita. Molto spesso si guardano i link in ingresso per paura di un attacco di negative SEO ma non si osservano i link in uscita.
Tralasciando i link rotti, verso siti non più esistenti, ecc, sui quali comunque andrebbe fatta attenzione e pulizia di tanto in tanto, concentriamoci sui link che non sarebbero mai dovuti essere inseriti nelle pagine.
Qualche anno fa mi chiese una mano un amico, il quale, dalla sera alla mattina, aveva visto dimezzarsi il traffico sul proprio sito amatoriale (quasi azzerato quello SEO). Analizzando il dominio, le pagine, le performance, ecc. pareva tutto in ordine (nulla di particolarmente professionale, ma comunque accettabile), poi, quasi per caso, trovai una pagina con qualche decina di link, chiesi lumi e vennero alla luce migliaia di pagine con qualche link. Si trattava di una directory, costruita a metà anni 2000 e ancora in piedi perché “è costata tanti sacrifici ed è un peccato spegnerla“.
Inutile dire che più della metà dei link presenti in quelle pagine puntavano oramai a domini spenti o, ancora peggio, a domini che erano stati riacquistati per farli puntare a siti adult, di pharma, a pagine di ecommerce e chi più ne ha più ne metta.
Inoltre l’amico non aveva nemmeno Search Console, che abbiamo abilitato insieme e nel quale era evidente che Google gli avesse notificato la presenza di link spam.
Questo è evidentemente un caso limite, ma attenzione ai link in uscita, evitate di linkare siti poco attendibili o rischiosi, perché sono un pericoloso boomerang.