webmaster tools robots.txt # v20121030 User-Agent: * Disallow: /

Vi è mai capitato di trovare in Google Webmaster Tools il vostro robots.txt in queste condizioni?
# v20121030
User-Agent: *
Disallow: /

Nei giorni scorsi ho avuto uno strana sorpresa su un paio di siti. Il primo allarme proveniva dal Google webmaster tool (GWT) che mi avvisava che il bot di Google non poteva accedere al mio sito in quanto il file robot.txt ne bloccava pagine importanti.

La prima cosa che ho fatto è stata quella di andare a verificare come appariva il file robots.txt richiamandolo tramite url. Non vi anticipo nulla per ora …. continuate a leggere.

Dopo questo primo passo, ho deciso di andarne a controllare lo stato nella pagina dedicata “Tester dei file robots.txt” all’interno del GWT (nell’immagine di destra potete vedere come trovare questo utile strumento, dopo aver seguito il link a inizio pagina).

Google webmaster tools robots.txt # v20121030 User-Agent: * Disallow: /

Quindi, abbiamo controllato 2 aspetti.
1) Come risultava il file richiamandolo direttamente da internet. (Riporto una parte del file originale)

# For syntax checking, see:
# http://tool.motoricerca.info/robots-checker.phtml

User-agent: *
Disallow: /search.html
Disallow: /search.html?*
Disallow: /account/*
Disallow: /account/profile.html
Disallow: /login.html

2) Come risultava invece a Google?

# v20121030
User-Agent: *
Disallow: /

Trattasi quindi di disallineamento tra quando vede il Googlebot e la realtà.

Ovviamente la cosa mi ha lasciato sorpreso. Perché Google lo vede in un modo, mentre invece richiamandolo da internet tramite il mio browser, questo appare in modo completamente diverso?

Tanto per essere chiari, per chi non lo sapesse, il testo:

# v20121030
User-Agent: *
Disallow: /

vieta a tutti gli spider (leggasi motori di ricerca quali Google, Yahoo, Bing) di accedere al sito, non permettendone quindi l’indicizzazione. Questo nella maggior parte dei casi si tramuta in perdita di pagerank, diminuzione delle pagine dalle SERP e nel caso più drammatico, qualora non si intervenga in modo celare, si rischia anche la sparizione del sito.
Il file robots infatti serve a dire CHI può o non può accedere e A COSA può o non può accedere all’interno del proprio sito. Di solito è buona norma non far indicizzare le pagine dei risultati di ricerca e le pagine private degli utenti; ma nel nostro caso:

• User-Agent: * risponde alla domanda “CHI? (può accedere)”
• Disallow: / (che risponde alla domanda “A COSA? (si può accedere)”

Fa si che nessuno possa accedere a nulla. E questo non è un bene 🙂 soprattutto dal punto di vista del SEO e della successiva visibilità del sito.

Se siete interessati ad approfondimenti su questo “magnifico” file, potete accedere al sito The Web Robots Pages.

Per risolvere velocemente il problema, nella pagina Tester dei file robots.txt , tramite il tasto INVIA in basso a destra nella pagina, ho forzato l’utilizzo della versione predente del file, e il tutto ha ricominciato a funzionare. GWT vedeva di nuovo il file che era correttamente pubblicato.
Problema temporaneamente superato.

Analisi e possibili cause

Ho iniziato ad analizzare il problema, cercando di capire quali potessero essere motivi di tale disallineamento.

Sul sito in questione è configurato il PageSpeed Service (PSS) di Google. Per chi non lo sapesse, il PSS è un servizio che ottimizza le pagine e …. per farla breve 😀 , le rende più veloci. In poche parole Google lo spiega così:

PageSpeed Service makes web pages load faster for your users.

Cosa fa praticamente? Richiama le tue pagine, le riscrive, ottimizzandole, e le offre all’utente che le ha richieste. Ho quindi subito pensato a un problema dovuto alla riscrittura del file da parte di PSS. Mi sembrava però un po strano che andasse a riscrivere il file che gli dice cosa può e non può accedere. Infatti il problema non era quello, in quanto, cancellando la cache dalla console di PSS, il risultato non cambiava. Persisteva il disallineamento.

Ho provato a cercare su internet, ma a parte un paio di post che segnalano lo stesso problema (sempre con PSS attivo), non esiste “letteratura” a riguardo.

Decido di farmi l’analisi per mio conto. Ho pensato potesse trattarsi di un hack.

Ho cercato traccia del nuovo contenuto del file all’interno dei file di log (sia access_log che erro_lo che access_ssl_log), ma con esito negativo.

Possibili cause? Cosa era cambiato rispetto a qualche giorno prima? Facciamo la lista della spesa:

1. Su uno dei domini presenti sul server in questione era stato attivato il servizio https.
2. Su un altro dominio, era stata creata una chiave di accesso a PSS tramite API di Google.

Possiamo quindi riassumere i due sospettati in SSL e PSS, chiamiamoli così.

Soluzione?

Seguendo la mia listino della spesa, ho proceduto passo-passo. Partiamo dal sospettato SSL.

• SSL

1) La prima cosa che ho fatto è stata quella di eseguire l’aggiornamento della versione di OpenSSL.

yum upgrade openssl

2) Dopo l’aggiornamento, ho provveduto a rigenerare la chiave con cui è stato creato il CSR. La chiave stavolta l’ho generata firmandola tramite algoritmo sha-2.

3) Ho richiesto alla mia Certification Authority di rigenerare il certificato digitale.

4) Ho provveduto ad aggiornare apache alla ultima 2.2 stabile (2.2.15):

yum upgrade httpd

Con questo comando viene aggiornata anche la versione del mod_ssl

5) Ho istallato il nuovo certificato.

• PSS

Vediamo ora quali sono gli indizi a carico di PSS. Probabilmente penserete … è sicuramente lui il colpevole. Qualcuno avrà usato le chiavi di accesso che hai appena creato e ha bucato i contenuti. Non credo. Questo perchè durante la creazione della chiave di PSS, Google recita:

“Use API keys to identify your project when you do not need to access user data.“

Il che non mi fa pensare a possibilità di editing.

Anche se … il fatto che solo Google veda una versione sbagliata, e tra l’altro inesistente del file, mi fa pensare (visto che PSS è un suo servizio) che la causa sia proprio li.

Come sia, per non saper ne leggere né scrivere, ho cancellato la chiave creata qualche giorno (un paio) prima.

Conclusioni

Tutto questo lavoro di aggiornamento e modifica è durato circa due mezze giornate. In questo periodo di tempo il problema si è presentato più di una volta. E per ciascuna di esse ho dovuto forzare la rilettura del file robots.
Ora, in tutta sincerità non so dirvi se le azioni intraprese abbiano risolto il problema oppure se l’accaduto è stato causato da un temporaneo problema di PSS.

Fatto sta che da quando ho apportato questi aggiornamenti, il problema non si è più presentato.

Vi aggiornerò, qualora si presenti di nuovo qualche altro “mistero”.

Buona navigazione, e se avete dei dubbi, commentate pure 🙂