1. All’inizio fu l’introduzione di Google page Speed.
2. Poi venne il protocollo Spdy
3. Pochi giorni fa è stato rilasciato il codice JS asincrono di Google Analytics (che dovrebbe ridurre i tempi di caricamento)
4. Oggi è stata rilasciato, all’interno di Google Webmaster Central, il tool Site Performance per misurare la velocità di un sito.

Insomma, la velocità sembra essere un fattore chiave per il prossimo futuro. Che i tempi di caricamento avessero un effetto positivo sul SEO lo aveva ipotizzato l’anno scorso Piersante, parlandone al GT Forum.
Io ne ebbi la prova provata quando, a causa di un cambio di piattaforma, vidi su un mio sito personale un aumento delle pagine indicizzate al diminuire dei tempi di caricamento:

E voi come siete messi a tempi di caricamento? Se volete testare le performance del vostro sito, ecco alcuni tools che vi possono essere utili:

• Yslow (richiede Firebug)
• Google page Speed
• Fiddler
• Pingdom tool
• WebPageTest

Se volete incrementare le performance del sito, date un’occhiata alle linee guida ufficiali di Google e Yahoo:

• Yahoo! Best practices for speeding up your website
• Google web performance best practice

Che ridere…non ci volevo credere!

Qua il link al post originale: http://www.seomoz.org/blog/whiteboard-friday-futureproofing-your-seo

In conclusione posso dire di essere contento di questi 2 giorni. Abbiamo conosciuto persone che fino ad oggi avevamo solamente letto o visto in video ed abbiamo avuto uno scambio di opinioni aperto e sincero.

Tra poco ripartiamo, nella notte abbiamo l’aereo per Bologna e poi diretti a Correggio per scaricare e mettere nero su bianco tutte le idee raccolte in questa 2 giorni. Non c’è tempo per dormire

Cheers!

Altri aggiornamenti a breve.

Aggiornamento delle 00.15

La giornata si è conclusa. Molti gli speech interessanti, serrato il ritmo. La serata si è conclusa con una festa open bar in un pub di Londra. Io e Lucio abbiamo avuto modo di parlare con Rand del mercato italiano, dello strapotere di Google e del fatto che in Italia mancano eventi di formazione dedicati ai SEO. Tra le altre cose abbiamo scoperto che Rand è sposato con una ragazza italiana e ci ha promesso che il prossimo Whiteboard Friday sarà totalmente in italiano con sottotitoli in Inglese

Per me si tratta sicuramente di una grande esperienza, dato che SEOmoz è sempre stato un punto di riferimento sin dai tempi della gavetta SEO. Sarà inoltre un’ottima opportunità per vedere come si svolgono questo tipo di eventi di formazione fuori dall’Italia. 

Tra gli eventi in in programma, oltre agli speech giornalieri, anche una Seo Beer Lunedì sera ed un incontro con il gruppo SEO London il Martedì sera.

Tra i fuori programma, sicuramente una visita allo storico Ace Cafe.

Cheers!

Se il vostro sito genera contenuti duplicati, allora è probabile che troviate già alcuni parametri elencati nella lista di quelli da ignorare.
Il blog di Google Webmaster Central non ha ancora dato indicazioni ufficiali circa l’utilizzo di questo nuovo strumento. In pratica non sappiamo ancora se le pagine indicate tramite questo strumento vengono trattate come noindex follow o noindex nofollow.
Aspettiamo aggiornamenti ufficiali da Matt Cutts o Google Webmaster Blog.

Infatti la possibilità di creare pagine, ed assegnare loro una gerarchia, è molto utile per strutturare alberi di navigazione e ricreare quindi tutta la parte degli annunci classified.
Innanzitutto ho dovuto migrare i dati dal vecchio al nuovo database. Questa è stata l’operazione più frustrante in quanto, oltre ad un import – export, è necessario controllare record per record che tutte le pagine abbiano gli attributi corretti (esistono dei tool per la migrazione ma io ho preferito curare ogni aspetto nel minimo dettaglio). Infatti ogni pagina ha un suo template, che varia in base alla tipologia di pagina. Pagine poco profonde avranno template che mostrano la navigazione verso le pagine più interne mentre le pagine degli annunci dovranno avere una struttura lievemente differente. Per questo consiglio di sfruttare appieno la possibilità di assegnare ad ogni pagina un template diverso. Per imparare a gestire i template, ecco la risorsa ufficiale.

Dopo aver migrato tutte le pagine della parte classified, ed aver attribuito i giusti template, ho cominciato con la migrazione delle news. Questa operazione è meno difficoltosa in quanto tutte le news sono diventate dei post con un unico template. Per la personalizzazione dei meta mi sono affidato a HeadSpace 2 e, con un po’ di lavoro manuale, sono riuscito a riutilizzare i meta del vecchio sito importandoli nel nuovo DB.
Dopodiché ho scelto il template più adatto per gestire news e pagine in maniera bilanciata. Tra i temi che meglio si adattano ad un utilizzo di WordPress come CMS consiglio di dare un’occhiata a:

• Woredpress CMS  Templates
  
• WordPress Magazine Templates
• Altri temi stile Magazine

In alternativa fatevi un giro sull’onnipotente Smashing Magazine, troverete sicuramente il template giusto.

Alcune pagine hanno cambiato URL, per questo ho provveduto ad installare il plugin Redirection per gestire in maniera puntuale le redirezioni dai vecchi ai nuovi URL senza dover mettere mano sull’htaccess.
Si è rivelato fondamentale il plugin Breadcrumb diYoast per l’inserimento delle briciole di pane nelle pagine della parte classified.

I risultati post-migrazione sono ottimi. Il sito, oltre ad avere una veste grafica moderna, ha dimostrato una riduzione drastica dei tempi di caricamento.

L’efficienza di WordPress ha pemesso di aumentare il numero di pagine scansionate al giorno e, grazie all’ottima gestione dei meta tag, il sito sta compiendo buoni passi sulla via del posizionamento. Le keywords di accesso sono in costante aumento cosi come le visite da organico ed il numero di pagine visualizzate per utente.
Fondamentalmente sono molto contento di essere passato a WordPress. Tutte le operazioni di routine sono molto più veloci e l’inserimento di nuovi contenuti è ora più semplice e rapido.

Drupal è sicuramente un ottimo CMS ma ha alcune gravi lacune, per l’utlizzo che ne facevo io. Innanzitutto è uno strumento molto generico che, per poter essere adattato ad un utilizzo specifico, richiede l’installazione di numerosi moduli. Questo significa doversi preoccupare dei continui aggiornamenti che questi moduli necessitano. WordPress al contrario ha molte funzioni built-in e questo facilita molto la gestione degli aggiornamenti.
In secondo luogo, WordPress batte Drupal nel back-end. Drupal infatti è molto poco intuitivo nell’utilizzo da back end. Per poter prendere dimestichezza sono necessari diversi giorni di studio di tutte le opzioni. Questo si trasforma in un investimento di tempo non indifferente nel caso in cui si debbano istruire dei collaboratori per l’inserimento di news.

Ma non è tutto oro quel che luccica. WordPress a mio parere ha una grossa lacuna nella gestione degli utenti. Gli utenti che si registrano come sottoscrittori hanno infatti la possibilità di accedere allo stesso back end dell’amministratore (con le dovute restrizioni ovviamente). Questo non è quello che ci si aspetta, sarebbe molto meglio poter gestire il backend in maniera puntuale per ogni tipologia di utente, così come accade per il front end. Staremo a vedere nei prossimi sviluppi se decideranno di risolvere questo problema. Nel frattempo io ho ovviato utilizzando WP Hide Dashboard, un plugin che permette di nascondere completamente la dashboard agli occhi dei sottoscrittori.

Ultimo ma non ultimo, WordPress vanta una community di sviluppatori tra le più attive della rete. Questo significa risoluzioni dei bug in tempi ridotti e disponibilità di plugin per soddisfare qualsiasi (o quasi) esigenza.
WordPress come CMS? Promosso

Per chi non avesse avuto ancora modo di leggerla, ecco il link per scaricarla, buona lettura!

• Copertura: Riuscire a raccogliere il maggior numero di informazioni possibili. Buona parte dei conteuti è infatti nascosta dietro a form di ricerca, navigazioni realizzare in Flash, AJAX, javascript o altre tecnologie indigeste agli spiders dei motori di ricerca. Il protocollo Sitemap dovrebbe in questo caso aiutare i motori di ircerca nella scansione e nell’indicizzazione del cosidetto Deep Web
• Aggiornamento: I motori di ricerca hanno sempre dovuto fare i conti con un web in continuo cambiamento. Da questo puto di vista, la scansione del web deve essere estesa e temporizzata, nel senso che deve avere una frequenza di aggiornamento tale da fornire agli utenti dei motori di ricerca, risultati sempre aggiornati.

Fino a qui non emerge nulla di nuovo. Molto più interessante è scoprire come Google processa i dati provenienti dalle sitemap:

il processo comincia dalla Scoperta (Discovery). In questa fase troviamo un elenco di URL (detto Seed) ordinati per importanza, da cui parte la scansione del web. Oltre a questi URL, Google considera tutti gli URL inviati tramite Sitemap (sia questa pingata attraverso il serivzio Webmaster Central o prelevata dal file Robots.txt).
L’unione di queste 2 fonti viene sottoposta ad una iniziale scrematura per eliminare i link spam. Da notare che l’attività del Crawler comincia solo successivamente, solo dopo che sono stati eliminati i link Spam (come possa Google determinare, senza effettuare una scansione, il contenuto spam di un link rimane un mistero).
Dopo la pulizia, il Crawler scansiona le pagine. Gli URL che emergono dalla scansione formano un feedback con il blocco Discovery autoalimentando il ciclo.
Le pagine scansionate intanto vengono sottoposte ad un ulteriore filtro anti contenuti-duplicati ed indicizzati, secondo gli ormai celebri “parametri di qualità”.
Il risultato dell’indicizzazione è messo a disposizione del blocco Server che risponde alle query degli utenti pescando dall’indice costruito nelle precedenti fasi.

Come utilizzare le sitemap? Alcuni case study

Amazon
Chi ha detto che per siti di grosse dimensioni non ha senso creare una sitemap? Spero nessuno. Amazon, leader mondiale del commercio online, ha una strategia imponente. ha un sistema di sitemap contenente, in totale, circa 20 milioni di URL (importante: elencano solamente le versione Canoniche degli URL). Non potendo aggiornare tutti i giorni i dati relativi a 20 milioni di URL, vengono semplicemente aggiunte ogni giorno delle nuove sitemap. Queste nuove sitemap contengono gli URL dei nuovi prodotti. una volta inserita la nuova sitemap, questa non viene più aggiornata, eventuali cambiamenti ad url vengono inseriti in nuove sitemap.
Amazon ha una efficienza pari al 63% ovvero ogni 100 pagine scansionate, 63 sono pagie uniche e quindi utili.
Considerando anche gli URL contenuti nelle sitemap, Amazon ha un tasso di efficienza pari all’83%.

Cnn.com
Cnn ha un numero di URL inferiore ad Amazon ma ha un altro grande criticità: la freschezza dei contenuti.
Per fare in modo che le News di Cnn.com vengano pescate in maniera tempestiva, il sistema di sitemap è ordinato sulla base della frequenza di aggiornamento. La sitemap index indirizza gli spider verso la sitemap dedicata alle pagine di news con aggiornamento quotidiano, in seguito a quella dedicata alle pagine con aggiornamenti settimanali ed infine alla sitemap dedicata alle pagine con aggiornamento mensile.
Questo sistema permette a Cnn.com di pingare Google correttamente, ed in ordine di frequenza di aggiornamento.

Alcune conclusioni

Non è il caso di ricordare l’importanza delle sitemap ancora una volta. Basti sapere che, secondo uno studio fatto da Google su un campione di 5 miliardi di URl, il 78% delle pagine è scoperta prima via sitemap poi via crawling classico. Questo perchè la maggior parte dei siti ha una frequenza di scansione che non è in grado di cogliere tutte le nuove informazioni. In questi casi la sitemap è fondamentale.
Ancora più importante, le sitemap, insieme ad un utilizzo oculato dei rel canonical, aiuta gli spider a razionalizzare la scansione del sito. Per evitare di disperdere l’attenzione degli spider, costruiamo le nostre sitemap in maniera accurata, specifichiamo il canonical e utilizzziamo il tag Robots. Il fatto che Google abbia elaborato un indice per per valutare il numero di pagine uniche sul totale delle pagine scansionate è indicativo che l’efficienza di un sito è inversamente proporzionale alla quantità di contenuti duplicati.