Uno degli errori in cui spesso si puo’ incorrere e’ sottovalutare l’utilita’ dei Google Webmaster Tools (GWT). Avevo gia’ letto qualcosa in merito su questo articolo, ma non credevo di dover cosi’ pesantemente ricredermi - a mie spese - sulla effettiva utilita’ di questo strumento.

Il problema che ho riscontrato e’ in realta’ legato ad una vera e propria “debolezza” di Wordpress. Personalmente uso Wordpress come piattaforma base per implementare siti che vanno anche ben oltre - in termini di funzionalita’ - il semplice blog. Costuisco i miei plugin ad hoc e, sfruttando le funzionalita’ del framework Wordpress, aggiungo le features piu’ disparate.

Ora il problema con cui ho avuto a che fare deriva da un fatto molto semplice. Wordpress modifica il file .htaccess aggiungendo delle regole rewrite per cui il riferimento a qualsiasi pagina e’ rediretto alla pagina index.php che a sua volta include in sequenza altri script php che producono man mano la pagina html passata al browser. Ad essere corretti, la configurazione del file .htaccess e’ tale per cui se l’utente richiede una pagina .html fisicamente presente sul server, la pagina e’ letta direttamente, altrimenti, il controllo e’ passato alla pagina index.php.

Sfruttando questo aspetto avevo realizzato le cose in modo tale da leggere nella pagina index.php (del mio template) la request_uri, quindi estraevo il riferimento al nome del file .html e in tempo reale generavo la pagina rispondente all’URL richiamata dall’utente.

A questo punto, ci si potrebbe chiedere il motivo per cui debba essere fatta questa cosa. In realta’, questo tipo di redirezione torna utile quando si vuole dare visibilita’ all’utente (inclusi i motori di ricerca) di pagine html dal nome particolarmente significativo (per esempio il nome potrebbe includere keywords), ma con l’opzione che queste pagine in realta’ non esistono fisicamente e sono create dinamicamente.

Per esempio quando l’utente richiama http://www.miosito.com/come-configurare-samsung-xx31.html, il web server redirige su index.php che legge la request_uri “come-configurare-samsung-xx31.html” e produce in tempo reale il contenuto desiderato (senza che esista il file html) .

Ovviamente tutto cio’ serve a garantire varie cose: url leggibili agli utenti; contenuto generato dinamicamente; url contenenti keywords in grado di agevolare l’accesso alle pagine del proprio sito dai motori di ricerca.

In effetti tutto questo funzionava correttamente fino a quando un giorno navigando nei GWT mi accorsi che Google riportava degli errori 404 di accesso ad alcune delle pagine. Cliccando sui link rilevati da Google, riuscivo pero’ ad accedere al contenuto delle pagine attraverso il browser. A questo punto la cosa si faceva molto interessante: per quale motivo il Googlebot rilevava degli errori 404 (pagine che non esistono) quando effettivamente gli utenti riuscivano ad accedere ad esse? Da interessante, la questione divenne molto grave quando mi torno’ alla mente come Google legge le sitemap di un sito.

In particolare il googlebot, una volta sottomessa la sitemap, accede al file (in tempi molto brevi), legge il contenuto e crea un campione di queste pagine. Quindi, prova ad accedere alle url del campione. Se le pagine del campione non dovessero essere accessibili, Google ne deduce che non vale la pena indicizzare TUTTE le pagine del sito o, in alternativa, tentera’ di indicizzare solo quelle accessibili ma in tempi molto piu’ lunghi. Google segnala l’errore nella pagina del GWT ed attende una azione del webmaster.

A questo punto l’errore che commettevo era quello di ritenere il problema limitato alle sole pagine del campione quando in realta’ trattavasi della punta di un iceberg disastroso. Le pagine del mio sito tardavano ad essere indicizzate anzi non lo erano affatto e la sottomissione delle sitemap era - praticamente - inutile.

L’origine di questo problema, come ho scritto all’inizio, e’ dovuta ad una scelta debole di Wordpress. In particolare, la pagina index.php su cui e’ eseguita la redirezione include altri script php ed uno di questi esegue un’analsi della request_uri verificando che la pagina specificata sia tra quelle attese da Wordpress. Se questa pagina non dovesse essere riconosciuta da Wordpress, viene prodotta una risposta indicante nell’http header un errore 404 ma, tuttavia, e’ anche restituito il contenuto html della pagina.

Questa particolarita’ (e non voglio definirla ulteriormente) e’ gestita dai browser (IE e FF in primis) in modo molto elementare: trascurano l’errore 404 e visualizzano comunque la pagina. Il problema e’ che il googlebot a differenza dei browser ha in grande considerazione il contenuto dell’header della riposta HTTP e blocca immediatamente l’accesso alla pagina trascurando l’eventuale contenuto HTML passato.

Un modo per accorgersi di questo problema e’ usare l’utility http://web-sniffer.net/ che permette di esaminare l’header della risposta HTTP oltre che l’eventuale contenuto passato.

Questo problema e una sua soluzione sono anche descritti qui.

La soluzione che ho adottato consiste nell’aggiungere nel file .htaccess una redirezione di qualsiasi pagina .html su un file .php fatto cosi’:

<?php
require(’./wp-config.php’);
$wp->init();
$wp->parse_request();
$wp->query_posts();
$wp->register_globals();

get_header();
include(TEMPLATEPATH . “/index.php”);

get_sidebar();

get_footer();
?>

Questo script fa le stesse cose del file originario index.php di Wordpress, pero’, evitando di invocare la parte di codice che produce il problema 404 suddetto.

Applicata la soluzione, risottomessa la sitemap.xml, dopo qualche minuto GWT mi informa che la sitemap e’ stata acquisita e che non ci sono piu’ errori. Thanks Google!

La conclusione e’: come avrei fatto ad accorgermi (e soprattutto in che tempi) di questo problema se non avessi usato GWT?