fbpx

Perdita di indicizzazione anomala: un caso di studio

| Gianluca Gabella | Guide e Documentazione

In questo post del blog voglio esporre un'esperienza diretta che abbiamo avuto qualche mese fa con un sito appena creato. Questo sito, dopo una piccola modifica lato hosting ha cominciato a perdere inspiegabilmente indicizzazione. In questo post spiegherò come abbiamo individuato e risolto il problema.

Premessa

Il sito in questione (www.progettonpm.it) è la rivisitazione (sia strutturale che grafica) del sito originale che avevamo implementato nel 2012 con il supporto grafico di Cristiano Capelli, costruito ai tempi con Joomla 2.5.
Il sito "vecchio" era basato su un tema costruito a mano per rispondere a tutte le esigenze di progettazione e si appoggiava al componente standard com_content degli articoli per i contenuti, anche per la parte più interattiva, ossia quella che riguardava le offerte di lavoro.

Dopo otto anni era giustamente giunto il momento di aggiornare tutto quanto: sia la piattaforma che, ovviamente, la grafica. Per quest'ultima abbiamo nuovamente collaborato con Cristiano Capelli, per la prima è stato deciso di rifare tutto ex-novo con Joomla 3.9 per evitare i soliti probabili problemi dovuti ad una migrazione da 2.5 a 3.x.
Anche in questo caso il template è stato creato a mano con YoothemePro per rispondere a tutte le moderne esigenze di accessibilità e responsività.

Il sito, nel corso di questi otto anni, si è posizionato molto bene sia in generale (ricerche generiche di uno studio di progettazione a Bologna e in Italia) sia per quanto riguarda specifiche parole chiave. Era quindi imperativo, con il passaggio al nuovo sito, non perdere questo posizionamento e ovviamente, se possibile, migliorarlo ancora di più.

Fare un passaggio da un Joomla 2.5 ad un 3.x non è così complicato, ma possono sorgere problemi soprattutto se la versione PHP del server o la versione del database MySQL sono troppo vecchie per supportare la nuova versione. Più in particolare i requisiti minimi di Joomla 3 consigliano PHP 7.3+ e MySQL 5.5.3+, versioni che non erano selezionabili sul server dove si appoggiava il vecchio sito. E' stata quindi fatta una richiesta all'hosting di passaggio ad una nuova struttura server/database aggiornata, cosa che è avvenuta in breve tempo e senza problemi particolari.

Ma da questo momento sono partiti i problemi.

Il nuovo sito: i primi errori

Una volta fatto il passaggio sul nuovo server eravamo finalmente pronti per andare online con il nuovo sito. Abbiamo quindi fatto il trasferimento dei file e database dall'ambiente di test all'ambiente di produzione, senza alcun problema. Tutto era andato per il verso giusto: il sito funzionava, non c'erano rallentamenti e tutte le funzionalità erano operative senza intoppi. Ma dopo qualche giorno sono apparsi i primi segnali di allarme sulla Google Search Console. Per chi non lo conoscesse è uno strumento gratuito di Google che permette di monitorare il sito, sia come funzionalità che come indicizzazione, dando la possibilità, tra le altre cose, di inviare la sitemap.

Nella sezione della copertura è venuto fuori un insieme di errori 5xx (che sono errori di server) con conseguente notevole calo delle impressions. Facendo controlli incrociati con i feedback dell'azienda è venuto fuori che effettivamente, dalla messa online del nuovo sito, era stato perso del posizionamento sia generico che su molte parole chiave:

impressioni search console

La prima cosa che ci è venuto in mente è che ci fossero problemi di copertura. Ossia che alcune pagine non venissero indicizzate, o per problemi di sitemap o per problemi di mancato accesso alle singole pagine (per esempio per colpa di un htaccess o un robots.txt configurati male). Sempre dalla Search Console abbiamo però visto che la copertura c'era per tutte le pagine, e non c'erano errori di sorta:

copertura singole pagine

I primi test

Visto che tutte le pagine era correttamente indicizzate da Google (o almeno, così sembrava dalla Search Console) abbiamo pensato subito che ci fosse un problema strutturale delle pagine del sito. Per esempio testi non leggibili, o problemi evidenti di inserimento dei testi (struttura H1/H2..., oppure title delle pagine) che avessero provocato un crollo delle impressions. Sapevamo che non poteva essere l'unico problema perchè i testi inseriti male non potevano causare tutti gli errori 5xx ma era necessario fare anche questo controllo.

Affidandoci a strumenti avanzati di check SEO online (semrush, seozoom e altri) abbiamo visto che, in realtà, la struttura interna delle pagine era pressochè perfetta. Tutti i tag erano corretti, così come i dati strutturati, i meta tag e gli open graph. Anche dettagli "meno importanti" erano stati implementati ed erano ben riconoscibili. Il punteggio ricevuto da questi tool era infatti molto alto:

punteggio seo check

Da come si capisce dall'immagine qui sopra il problema non era la struttura di base ma bensì la velocità del sito/server (punteggo molto basso soprattutto su "velocità mobile"). La lentezza di un sito può essere causata da molteplici fattori. Se si parla di un CMS tipo Joomla o Wordpress i principali indiziati sono i plugin di terze parti aggiunti al sito per espanderne le funzionalità. Se questi plugin non sono sviluppati bene possono rallentare il caricamento di una pagina anche di diversi secondi. Su questo aspetto eravamo però fiduciosi: per cercare di rendere il sito il più leggero possibile avevamo usato quasi esclusivamente componenti del core di Joomla che sono ottimamente scritti ed estremamente veloci nel caricamento.

Testando il tutto con Google Lighthouse (e con il corrispettivo online PageSpeed Insights) abbiamo visto che la lentezza non era data dal sito in se, ma dal server, che aveva dei tempi di risposta iniziali molto elevati.

tempi risposta server

I tempi di risposta che vedete qui sopra sono anche "clementi". In molti altri test che abbiamo fatto "l'initial server response time" arrivava anche a 5/6 secondi nei casi peggiori: risultato decisamente disastroso se si cerca di posizionare un sito nel modo migliore (Google ama la velocità, se il sito è lento puoi avere i testi migliori del mondo ma Google tenderà sempre a tagliarti le gambe).

Cominciamo ad unire i puntini

Ricapitolando quello scoperto fino a quel momento, avevamo che:

  • Il sito era veloce e strutturato SEO come si deve;
  • Il server aveva dei tempi di risposta alti, in alcuni casi molto alti. Decisamente troppo alti anche per un server condivisio di fascia medio/bassa;
  • Search Console non segnava problemi nella copertura delle pagine: erano nell'indice;
  • Sempre Search Console ci segnalava però vari errori 5xx che potevano ovviamente influire sull'indicizzazione

Tutti gli indizi portavano ad un errore del server, che per qualche motivo rendeva la pagina visible a noi mortali ma non a Google. Problemi sull'htaccess o sul robots.txt li avevamo già esclusi, cosa poteva causare un disservizio del genere?

Ci sono molti modi per testare come Google riesce a "leggere" una pagina, uno dei più usati è quello di usare il test dei dati strutturati. I dati strutturati sono delle meta-informazioni inserite all'interno di un articolo che permettono a Google di catalogare meglio le informazioni, e renderle visibili al pubblico in formati diversi rispetto ai risultati di ricerca classici. I dati strutturati vengono, per esempio, usati nelle pagine delle ricette per segnare i tempi di cottura, gli ingredienti o la valutazione (le classiche 5 stelline) e permettono a Google di esporre i risultati di una ricerca in modo visivamente più carino e facile da capire per un utente, rendendo più immediate le comparazioni tra sito e sito.

Questo è un esempio di come i dati strutturati di una ricetta vengono visualizzati da Google nei risultati di ricerca:

google dati strutturati

Il tool che si può usare per testare i dati strutturati è gratuito, ed è messo a disposizione al pubblico da Google stesso. Lo potete trovare qui.

Il risultato ci ha lasciato di stucco:

risultato test dati strutturati

Non solo Google non vedeva correttamente correttamente i dati strutturati della pagina. Ma vedeva proprio una pagina diversa. Anzi, non vedeva neanche una pagina web!

Da quello che potete leggere nei risultati qui sopra, Google vedeva un application-type di tipo PDF al posto della homepage, con dati criptati e illeggibili. Quindi il problema non era che le pagine non venissero indicizzate (e infatti lo erano, la copertura della Search Console lo dimostrava) ma che semplicemenete venivano indicizzate in modo errato, con contenuti fittizi provenienti da chissà dove.

A questo punto abbiamo fatto la cosa più naturale del mondo, abbiamo cercato il dominio su Google per vedere cosa saltasse fuori. Ecco il risultato:

risultati google dominio

Il dominio era indicizzato, con un titolo e un contenuti non in italiano, che se cliccati portavano ad un sito web estero con contenuti malevoli (phishing).

Don't panic

La primissima cosa che abbiamo pensato è stato "ci hanno bucato il sito!": probabilmente un attacco hacker è riuscito ad entrare nel sito web e ha fatto qualche casino. Non è raro che un CMS venga bucato, soprattutto se non viene aggiornato da molto tempo o se usa molti plugin scritti male o non aggiornati, ma il nuovo sito era aggiornato all'ultimissima versione, non usava plugin di terze parti e soprattutto era online solo da pochi giorni: era altamente improbabile che fosse stato bucato in così poco tempo.

Per testare il tutto abbiamo copiato il sito attuale (quello che c'è ora su www.progettonpm.it) e spostato pari pari (stessi file e stesso database) su un hosting temporaneo:  https://npm.pixed.it . Abbiamo quindi ritestato il sito per i dati strutturati: se ci fosse stato un cambio di codice da parte di qualche hacker allora il problema dell'APPLICATION-TYPE/PDF si sarebbe ovviamente visto anche sul sito spostato.

Il test invece è andato a buon fine:

dati strutturati server di test

Il risultato, come potete vedere, è la struttura di una normalissma pagina HTML, con tutti i tag al loro posto (e tutti i dati strutturati configurati correttamente). Il problema, per fortuna, non era nel codice del sito ma a questo punto i colpevoli potevano essere soltanto due:

  • Server su cui è ospitato il sito hackerato
  • DNS sbagliati/hackerati in modo da creare un redirect verso siti malevoli

In entrambi i casi il problema era enorme, e di responsabilità dell'hosting. Per evitare quindi ulteriori perdite di tempo è stato deciso di spostare tutto (dominio, hosting ed email) su altro hosting più strutturato e più votato a siti aziendali performanti e SEO-oriented.

Scelto il nuovo hosting il passaggio è stato fatto nel giro di 24 ore e già la settimana dopo la Search Console ha smesso di segnalare errori 5xx e il posizionamento dei contenuti è tornato ai tempi pre-aggiornamento del sito.

Tutto è bene quel che finisce bene, ma è stata dura trovare il colpevole, in una situazione surreale e mai capitata in 12 anni di attività. Spero che questo resoconto possa aiutare altri webmaster a trovare colpevoli "nascosti" che possono creare ingenti danni ai siti web se non debuggati e risolti in tempi brevi.


Se ti è piaciuto questo articolo, condividilo!


 

pixed logo

Pixed di Gabella Gianluca
via del Lavoro 39, 40127 - Bologna (BO)
p.IVA: 03219311200 - C.F.: GBLGLC84T21A944B
Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo. - 051.514551

scarica teamveiwer

Ti è piaciuto quello che hai letto?

Condividi questo articolo: