Senza dilungarmi oltre, ecco di seguito la presentazione.
Disclaimer: nessun sito è stato maltrattato nella realizzazione della presentazione.

Commenti, critiche e suggerimenti sono ovviamente ben accetti!

© 2011, Mauro Ginelli. “Son tutti SEO, col sito degli altri”

Circa 1.980.000.000 risultati (0,08 secondi)

Tuttavia, forse non tutti sanno che, indipendentemente dal numero di risultati indicato da Google, non è possibile andare oltre i primi 1.000 risultati.

Per rendersene conto, è sufficiente aggiungere o modificare un parametro nell’indirizzo della SERP (Search Engine Results Page, cioè Pagina dei Risultati del Motore di Ricerca). Il parametro start=NNN (dove NNN è un numero) indica che la pagina mostra i risultati a partire dal numero NNN+1.

Ad esempio, se i risultati mostrati iniziano dal numero 11 (per capirci, dopo i primi 10 risultati mostrati di default), il parametro start avrà il valore 10 (start=10); per i risultati tra 21 e 30, si avrà start=20; ecc.

Provando ad inserire il valore 1000 (o un numero superiore) per il parametro start, si scopre facilmente il messaggio di Google:

Spiacenti, Google non restituisce più di 1000 risultati per qualsiasi query. (Hai chiesto i risultati a partire da 1000.)

Ed ecco un esempio pratico:

• ricerca “standard”: http://www.google.it/webhp?hl=it#hl=it&q=una+ricerca
• ricerca con “start=1000″: http://www.google.it/webhp?hl=it#hl=it&q=una+ricerca&start=1000

E gli altri parametri, li conoscete o può essere utile un post di ripasso generale?

© 2010, Mauro Ginelli. “Son tutti SEO, col sito degli altri”

La novità ha subito attirato le attenzioni di utenti e lavoratori del web (webmaster, SEO, web designer, analisti web, ecc). Vorrei provare a fare un riepilogo di quanto avvenuto e ipotizzare cosa aspettarsi nel prossimo futuro, con qualche considerazione sugli aspetti legati all’ottimizzazione dei siti (Search Engine Optimization) e quelli relativi alla lettura dei dati di web analytics.

Come vengono generate le anteprime di Google Instant Previews

Stando alle informazioni ufficiali, gli screenshot dei siti sono generati automaticamente, durante le comuni attività di scansione che gli spider di Google seguono regolarmente.

Nei casi in cui Google non disponga già di un’immagine di anteprima, tuttavia, gli screenshot vengono generati “al volo” nel momento in cui l’utente clicca sulla lente di ingrandimento nei risultati. In questa situazione, gli spider di Google fanno un’istantanea del sito richiesto dall’utente. L’user-agent utilizzato dagli spider, in questo caso, è “Google Web Preview“. Per la precisione, la traccia lasciata nei file di log è simile alla seguente:

"Mozilla/5.0 (en-us) AppleWebKit/525.13

(KHTML, like Gecko; Google Web Preview)

Version/3.1 Safari/525.13"

Da alcuni test condotti personalmente,  ho rilevato come lo spider con user-agent “Google Web Preview” corra subito a generare tutte le anteprime mancanti nella SERP (pagina dei risultati).
In altre parole, l’anteprima viene generata anche senza che l’utente effettivamente clicchi su un risultato specifico: Google, per offrire una migliore esperienza di navigazione, genera tutte le anteprime mancanti, anche se non verranno poi richieste effettivamente dall’utente.

Google Instant Previews e SEO

Nel post di presentazione sul blog di Google Webmaster Center, è scritto che la nuova funzionalità non incide sul posizionamento nei risultati (ranking):

Instant Previews does not change our search algorithm or ranking in any way. It’s the same results, in the same order. There is also no change to how clicks are tracked. If a user clicks on the title of a result and visits your site, it will count as a normal click, regardless of whether the result was previewed. Previewing a result, however, doesn’t count as a click by itself.

Per evitare la generazione e visualizzazione dell’anteprima nei risultati di ricerca, l’indicazione a Google può essere data tramite il metatag Googlebot che già consente di non generare il cosiddetto snippet (le righe riportate sotto il link nei risultati). Il valore da utilizzare è il seguente:

<meta name="googlebot" content="nosnippet">

Google Instant Previews e Flash

L’anteprima viene generata per mezzo di uno spider che, come già visto sopra nei log files, “naviga” con un browser Safari (o Chrome).

Una sbirciata ai report di Google Analytics consente di risalire alla risoluzione (1024×1024), ma soprattutto di avere conferma che, almeno per adesso, Google Web Preview non “legge” Flash.

Da Google assicurano che nei prossimi sviluppi dovrebbe essere colmata anche questa mancanza.
Nell’attesa, vale la pena forse sapere che dai test si rileva facilmente che Google Web Preview interpreta correttamente il tag <noscript>, che può essere quindi utilizzato per offrire un contenuto alternativo, così che venga incluso nell’anteprima al posto della tessera del puzzle o del quadrato grigio-nero che compare adesso.

Si tratta, tutto sommato, di un intervento che andrebbe comunque previsto per tutti gli utenti – non solo gli spider – che navigano sul web senza il plugin Flash e che andrebbe inquadrato nei normali interventi per migliorare l’accessibilità di un sito.

Per le altre tecniche e tecnologie varie, le FAQ indicano che Google Web Preview interpreta JavaScript, AJAX e i CSS3, ma non Silverlight e le applet Java:

The preview generator renders JavaScript, AJAX, CSS3, frames, and iframes in the same way that a Safari / Webkit-based browser would. It currently does not support Flash, Silverlight, or Java applets. Flash-based content may be shown as a “puzzle piece” in the preview image. Font-replacement techniques that use Flash are currently not supported.

Google Instant Previews e Web Analytics

Dalla data di lancio di Google Instant Previews (9 novembre 2010), tra forum, blog e social network si è subito sparsa la voce che le visite di Google Web Preview erano rintracciabili nei report di Google Analytics, semplicemente cercando le visite provenienti dalla città “Mountain View” e/o dal fornitore di servizi “Google Inc” (v. screenshot seguente).

Questa situazione ha generato alcune domande e qualche dubbio. Innanzitutto è risultata evidente la necessità di valutare l’impatto di queste “visite” sui dati di web analytics. Devono essere ricomprese nel conteggio complessivo delle pagine viste e delle visite o sono solo dati che “inquinano” i report? Quanto incidono queste visite (quasi sempre riconosciute come “Nuovi visitatori”, con tassi di rimbalzo – bounce rate – pari al 100%) sull’andamento generale del sito?

A scanso di equivoci, Google ha già risolto questa situazione, semplicemente correggendo questa sorta di “bug”: nei report di Google Analytics dal 22 novembre in poi, le visite da “Google Web Preview” sono praticamente tornate a zero.

Stando a quanto rilevato nei test, eviterei di considerare il numero di visite/pagine viste da Google Web Preview come un indicatore delle visualizzazioni dell’anteprima del sito nelle SERP. Come visto sopra, l’anteprima può essere generata da Google durante la scansione “tradizionale” del sito e, anche se creata “su richiesta” dell’utente, viene poi tenuta per un certo periodo “in cache”, senza bisogno di ripassare sul sito per proporla ad altri utenti. In sintesi, il conteggio delle visite imputabili a Google Instant Previews per il periodo tra il 9 e il 22/11 non è un indicatore di quanti utenti hanno cliccato sulle anteprime, perché di fatto è una sottostima.

Per i curiosi, lo screenshot sopra è preso da un account in cui risultano circa 2.400 visite da “Google Inc” nel periodo 7-25/11. Ma si tratta di un sito che, nello stesso periodo, ha totalizzato oltre 1,5 milioni di visite. La percentuale di visite imputabili ad Instant Previews è quindi attorno ad un trascurabile 0,15%.

In sintesi (con qualche ipotesi)

1. Da un punto di vista SEO, Google sembra rassicurare sul fatto che la funzionalità non incide sul ranking delle pagine. Ma sarà da valutare l’impatto, in termini di Click-Through Rate (CTR), che può comportare il fatto di avere un layout gradevole – e completo – anche nell’anteprima dei risultati. Molto probabilmente, non basterà più avere title e meta description ottimizzati.
2. Mentre il “bug” dei dati in Google Analytics è già stato risolto, sarebbe interessante sapere se e quando i dati relativi all’uso delle immagini di anteprima verrà messo a disposizione nei Google Webmasters Tools, dove già si trovano i report relativi ad Impression e CTR nelle pagine dei risultati.
3. In attesa che i contenuti Flash vengano mostrati nelle preview, converrà lavorare sui siti con un occhio di riguardo ai temi legati all’accessibilità.

E voi, che ne pensate?

© 2010, Mauro Ginelli. “Son tutti SEO, col sito degli altri”

Mi limito a fare un po’ di auto-promozione (perdonatemi, ma a magari qualcuno dei quattro fidati lettori non l’ho ancora comunicato ufficialmente ): a maggio ho aggiunto la qualifica di Omniture Certified Professional: Implementation a quella di Google Analytics (Google Analytics Individual Qualification). La certificazione è arrivata dopo aver frequentato un corso di tre giorni a Londra nella sede Adobe/Omniture con i miei colleghi di GroupM e dopo un bell’esame tosto tenuto a Milano.

Magari qualcuno dei quattro lettori del blog non conosce bene Omniture e SiteCatalyst e quindi un paio di informazioni in più possono aiutare. Omniture è l’azienda statunitense che offre una suite completa di prodotti per l’analisi dei dati web, acquisita lo scorso autunno da Adobe. Tra i vari prodotti in catalogo, forse il più conosciuto è appunto SiteCatalyst, la soluzione più “classica” di web analytics, destinata alla fascia alta del mercato.

Se Google Analytics è ormai stabilmente al primo posto in termini di diffusione, soprattutto grazie alle migliaia di installazioni su siti di medio-piccole dimensioni e alla apparente semplicità di installazione (senza dimenticare che è gratis), Omniture SiteCatalyst segue al secondo posto, con una diffusione però concentrata in realtà più strutturate, in grado di affrontare – e far fruttare – l’investimento nella piattaforma di web analytics, da SiteCatalyst a Test&Target, da Discover a SearchCenter ecc.

Stando alle statistiche elaborate da BuiltWith, al 6 luglio 2010, Google Analytics e Omniture SiteCatalyst sono le due soluzioni di Web Analytics attualmente più diffuse, essendo presenti rispettivamente nel 54,2 e nel 13,45% dei siti analizzati.

Insomma, concedetemi un minuto di esagerazione, ma potrei sostenere di essere certificato per oltre 2/3 delle soluzioni di web analytics sul mercato!

© 2010, Mauro Ginelli. “Son tutti SEO, col sito degli altri”

Da una parte, è ora possibile gettare uno sguardo più attento a quanto avviene “prima” e “al di fuori” del sito, e più precisamente tra i risultati “naturali” (non a pagamento) su Google.
Dall’altra, Google ha annunciato che nelle prossime settimane nuovi dati e nuovi report di Google Analytics saranno disponibili per analizzare più a fondo gli investimenti in annunci a pagamento con Google AdWords.

Circa un mese fa, a metà aprile, sono state introdotte alcune nuove funzionalità legate alle query di ricerca disponibili negli Strumenti per i Webmaster (Google Webmasters Tools): in un’unica tabella, è possibile analizzare le impression (il numero di volte per cui le pagine di un sito sono state visualizzate nei risultati di ricerca) e le percentuali di clickthrough (CTR, le percentuali di impression che hanno portato a un clic per accedere al sito) tra i risultati naturali (per distinguerli dagli annunci a pagamento, v. AdWords).

Nemmeno un mese e arrivano altre novità ancora su questo fronte: balzano all’occhio, a parte il restyling grafico, la  nuova colonna per la “posizione media” raggiunta per ogni keyword nell’arco del periodo temporale selezionato e il grafico in “stile Google Analytics”.

Grazie a queste novità, è ora possibile analizzare (ed esportare) con maggiori dettagli le posizioni raggiunte tra i risultati organici e tenere sott’occhio miglioramenti e peggioramenti nel corso del tempo, con la possibilità di “marcare” con una stella le query ritenute più interessanti. È una piccola grande svolta, che consente di apprezzare l’impatto di piccoli miglioramenti/peggioramenti nel posizionamento delle singole keyword, potendo confrontare i CTR per ogni posizione nelle SERP.

Sull’altro fronte, le novità annunciate per Google Analytics riguardano i nuovi report che saranno presto disponibili per analizzare i rendimenti delle campagne di keyword advertising gestite con Google AdWords. Tra le altre novità, sarà finalmente possibile confrontare e analizzare la query effettivamente cercata dall’utente insieme a quella pagata dall’inserzionista per la pubblicazione degli annunci.
Rimando al video qui sotto per vedere un’anteprima dei nuovi report.

© 2010, Mauro Ginelli. “Son tutti SEO, col sito degli altri”

Rich snippets per gli eventi

Può essere utile allora fare qualche passo indietro per capire meglio le potenzialità dei microformat all’interno delle SERP (le pagine dei risultati dei motori di ricerca).

Cosa sono i microformat

Un microformat, in pratica, consiste in un’aggiunta di mark up grazie alla quale è possibile  fornire informazioni “semantiche” in una pagina web. Aggiungendo il markup del microformat, i contenuti di una pagina web vengono arricchiti con informazioni che possono essere estratte da software in grado di interpretarli, oppure dagli spider dei motori di ricerca (come Googlebot e Yahoo! Slurp).
Per il navigatore l’aspetto di una pagina con i microformat rimane di fatto invariato (sempre che il webmaster non abbia deciso diversamente, con l’applicazione di dichiarazioni specifiche nei CSS), né si rischiano rallentamenti nel caricamento della pagina stessa.

Per approfondire il discorso, oltre alla voce su Wikipedia, si può consultare il sito Microformats.org (in inglese), mentre su A List Apart è presente l’articolo Introduction to RDFa, con spiegazioni ed esempi esaurienti.

I microformats nei motori di ricerca

Sebbene Yahoo! già nel 2006 annunciasse sul proprio blog il supporto dei microformats in Yahoo! Local (“We now support microformats“), importanti novità sono arrivate nel corso del 2009, con l’annuncio di Google a maggio (Introducing Rich Snippets) seguìto ad agosto da quello di Yahoo! (See More SearchMonkey in Your Search Results).

Con queste novità, i due motori hanno deciso di puntare sulle informazioni semantiche per arricchire le pagine dei risultati, con l’obiettivo di migliorare l’esperienza degli utenti grazie ad informazioni utili legate ai termini ricercati: recensioni di prodotti, informazioni di contatto per le persone e per le aziende, ed ora appunto le informazioni sugli eventi.

esempio di Rich Snippet

Google Rich Snippets Testing Tool

Per testare la corretta implementazione dei microformat, Google ha messo a disposizione un semplice tool di controllo (Rich Snippets Testing Tool) e predisposto alcune pagine di domande e risposte sul supporto dei microformat nel suo indice.

Occorre ricordare però che, per il momento, non vi è garanzia di vedere i Rich Snippets per il proprio sito, soprattutto per i siti in lingua italiana: Google li incorporerà gradualmente, utilizzando i propri algoritmi per scegliere quando inserirli tra i risultati e quando ignorarli.

I webmaster possono comunque segnalare il proprio interesse a far comparire i Rich Snippets per i propri siti compilando il modulo apposito.

© 2010, Mauro Ginelli. “Son tutti SEO, col sito degli altri”

Mi è balzato subito all’occhio il titolo di un post pubblicato sul blog ufficiale di Google Docs: Shared folders and more in Google Docs. Ho voluto leggere subito il post, per verificare che si trattasse proprio di quello che un po’ tutti chiedevano da tempo: le cartelle pubbliche per condividere agevolmente i documenti tra colleghi/collaboratori/utenti di un dominio con Google Apps, proprio come succede da tempo con le cartelle pubbliche con Microsoft Exchange e Outlook. E, con un po’ di sorpresa, la risposta è: sì, finalmente ci sono le cartelle pubbliche in Google Apps!

Google Docs Shared Folders

In occasione dell’introduzione di altre funzionalità mi sono soffermato sugli aspetti tecnici, del tipo “come fare a condividere i documenti nelle cartelle pubbliche con Google Apps”, ma stavolta approfitterei per qualche considerazione. Se poi dovessi notare un aumento delle visite in ingresso per le chiavi associate a “cartelle condivise” e dintorni, potrei pensare ad integrare questo post.

Nell’esperienza quotidiana, discutendone e confrontandomi con Marco e gli altri amici di Epicentro, ci siamo resi conto che uno dei principali ostacoli all’adozione di Google Apps (o di altre soluzioni di cloud computing) nelle aziende sta nella difficoltà di abbandonare funzionalità  di uso quotidiano, soprattutto nelle organizzazioni più grandi.

Tra le funzionalità che mancavano a Google Apps per arrivare a competere con la soluzione di Microsoft, Exchange, c’erano appunto le cartelle pubbliche (o cartelle condivise: shared folders).

A parte le costanti migliorie alle componenti della suite (Gmail, Google Docs, Google Sites, Google Calendar), negli ultimi mesi alcune funzionalità sono state aggiunte per fronteggiare il colosso (Exchange) con il chiaro intento di offrire un’esperienza d’uso del tutto simile. In particolare, ricordo: l’accesso alla posta da parte di altri utenti autorizzati (la c.d. mail delegation; caso tipico: la segretaria che controlla e gestisce la posta per conto del proprio responsabile); il tool per la sincronizzazione di posta e calendario in Outlook (Google Apps Outlook Sync); e ora, per l’appunto, le cartelle pubbliche.

Ho avuto la fortuna di discutere di questi temi anche con il giornalista Juan Carlos Perez di IDG News Service, in uno scambio di email che è stato poi riassunto ed inserito nel suo articolo Outlook Separation Anxiety Holds Back Google Apps lo scorso mese di luglio, proprio in occasione del rilascio del tool per usare Google Apps con Outlook.

Il luogo comune delle aziende che non sono aperte all’innovazione andrebbe un po’ rivisto, a mio parere.
È vero che ci sono tante organizzazioni restie al cambiamento. Ma ci sono anche molte realtà che seguono con interesse le novità in ambito tecnologico.

La resistenza al cambiamento, a volte, è il risultato di un’analisi costi-benefici, in cui in misura più o meno consapevole vengono considerati anche i costi del cambiamento (“switching costs“), tali da convincere i responsabili IT a bocciare l’introduzione di nuove tecnologie.

Tornando al caso di Google Apps vs. Microsoft Exchange, è indubbio che tante aziende che si sono mosse come innovatori della prima ora, accettando la sfida di adottare al proprio interno una soluzione Web 2.0 (o forse sarebbe meglio etichettarla come SaaS – Software as a Service).

Altre aziende, invece, pur comprendendo la portata dell’innovazione (minori costi di infrastruttura e manutenzione, accesso ai servizi ovunque e in qualunque momento grazie all’interfaccia web, ecc), si sono limitate a seguirne gli sviluppi per adottare le soluzioni di cloud computing quando i benefici sull’organizzazione supereranno i costi totali.

Sarei curioso di sapere se altri hanno avuto le mie stesse impressioni su questi temi.

© 2009, Mauro Ginelli. “Son tutti SEO, col sito degli altri”

Per tracciare le campagne, Google Analytics mette a disposizione cinque parametri da aggiungere agli URL, di cui tre sono obbligatori:

1. utm_source [obbligatorio]
   serve ad identificare la sorgente da cui proviene la visita alla pagina monitorata (un motore di ricerca, un nome di newsletter, un sito, o un’altra fonte ancora).
2. utm_medium [obbligatorio]
   va indicato per identificare il mezzo, come può essere l’email, il banner o il CPC (costo per clic).
3. utm_campaign [obbligatorio]
   aiuta a ritrovare facilmente il nome della campagna nei report; la sua utilità è chiara nei casi in cui si susseguano più campagne nel tempo (es. campagne stagionali: primavera, estate, autunno, inverno), ma può essere impiegato praticamente in ogni occasione
4. utm_term
   questo parametro consente di tracciare le parole chiave legate alla campagna e risulta quindi utile per le ricerche a pagamento (keyword advertising)
5. utm_content
   consente di indicare il contenuto del messaggio per differenziare gli annunci o i link che puntano allo stesso URL (ad esempio nei test A/B)

Come riportato da Marco Cilia, i test effettuati da Lunametrics suggeriscono di indicare per primo il parametro utm_source per assicurarsi un corretto monitoraggio.

Se l’account Google Analytics è collegato a un account AdWords, non è necessario inserire i codici nei link AdWords, in quanto la funzione di codifica automatica lo farà automaticamente, aggiungendo un unico parametro gclid all’URL della pagina di destinazione.

Una volta che i parametri saranno aggiunti ai nostri URL, Google Analytics sarà in grado di interpretarli e riportarli correttamente nei report (v. Sorgenti di traffico > Campagne) e nei grafici appariranno come “Altro” tra le sorgenti di traffico.

Campagne con Google Analytics

Grafico sorgenti Google Analytics

Strumento di creazione URL di Google Analytics


Non è necessario imparare tutti i parametri a memoria, perché è sufficiente tenere tra i bookmark lo strumento di creazione URL che Google mette a disposizione. In questa pagina è sufficiente compilare i campi del modulo per ottenere l’URL correttamente formato. Tuttavia, se un URL del tipo

www.miosito.it/categoria/pagina/dettagli.html?utm_source=newsletter&utm=medium=email&utm_campaign=ottobre

sembra un po’ ostico (sì, in effetti lo è), si può ricorrere ad uno dei tanti abbreviatori di URL, come Tinyurl, Bit.ly e concorrenti, che offrono la possibilità di creare indirizzi di facile memorizzazione.

Tracciare campagne con Google Analytics e Google Apps


Per i domini che si appoggiano a Google Apps c’è un servizio gratuito realizzato direttamente da Google Labs: con Google Short Links, disponibile  nel Google Solutions Marketplace, è possibile riscrivere l’indirizzo lungo in uno più corto e semplice da memorizzare, tipo

links.miosito.it/keyword1-keyword2

Per attivarlo, bastano davvero pochi clic all’amministratore del dominio con Google Apps e il servizio è subito attivo. A questo punto basterà associare l’URL “lungo” alla versione “accorciata” e diffondere quest’ultima, col vantaggio di poter diffondere un URL riconducibile al nostro dominio (es. miosito.it) e non ad un servizio di terzi.

Plugin per WordPress

Ci sono molti plugin per integrare Google Analytics in WordPress. Segnalo ad esempio quelli di Joost de Valk o di Jack McIntyre, che offrono la possibilità di monitorare l’attività sui link diffusi tramite RSS.

© 2009, Mauro Ginelli. “Son tutti SEO, col sito degli altri”

Pur con poche pagine da gestire e pochi interventi nel blog (ha quattro anni, ma non li dimostra), il risultato era per nulla soddisfacente e richiedeva il doppio della fatica, a causa dei due sistemi separati. Ad esempio, per inserire una modifica qualsiasi nel codice di tracciamento di Google Analytics, bisognava intervenire sia sul blog, sia nelle pagine php. Da qui, la promessa di perdere un po’ di tempo per uniformare il tutto, sfruttando le funzionalità offerte da WordPress.

Dato che la transizione è ormai completata e tutto il sito è ora gestito dal motore di WordPress, semmai tornasse utile a qualcuno, ecco la trafila che ho seguito per usare WordPress come CMS.

Piccola premessa: questo post è stato scritto con riferimento ad un’installazione in lingua italiana di WordPress 2.8. Può darsi quindi che alcune voci di menu e/o impostazioni indicate non siano più valide o esistenti in futuro.

Modificare le impostazioni di lettura

Come già detto, l’installazione di WordPress su questo sito si trovava nella directory /blog. Il mio desiderio era di mantenere il flusso dei post allo stesso indirizzo e avere una homepage differente, con una pagina creata con WordPress.

WordPress consente questa opzione: basta andare, nel pannello di amministrazione, sotto Impostazioni -> Lettura, e indicare la pagina statica che verrà mostrata come homepage e la pagina in cui verranno pubblicati i post. Ecco uno screenshot.

Amministrazione WordPress: Impostazioni -> Lettura

Semplice, ma questa scelta avrebbe generato un problema, legato ai permalink e al file .htaccess. La pagina statica “blog”, se posizionata nella root (www.ginelli.it/blog), sarebbe coincisa con la directory di installazione di WordPress, causando problemi nella visualizzazione del blog stesso.

Modificare la cartella in cui è installato WordPress

Per risolvere il problema qui sopra, ho deciso di modificare il nome della cartella in cui è installato WordPress: da /blog a /wordpress. Probabilmente c’erano soluzioni più eleganti e professionali, ma questa mi sembrava rapida e senza rischi.

Modificare le impostazioni generali nel pannello di amministrazione di WordPress

Una volta ri-loggato nel pannello di controllo al nuovo indirizzo (non più /blog, ma /wordpress), è stata la volta della modifica dei parametri presenti sotto Impostazioni -> Generale. In questa pagina, sono presenti due voci, che solitamente coincidono:

• Indirizzo WordPress (URL): inserire l’indirizzo a cui è installato WordPress
• Indirizzo del blog (URL): inserire l’indirizzo che si desidera utilizzare, nel caso in cui la homepage del blog sia diversa dalla directory dove è installato WordPress.

Nel mio caso, vista la modifica già fatta e il punto di arrivo a cui volevo giungere, ho settato così:


• Indirizzo WordPress (URL): www.ginelli.it/wordpress
• Indirizzo del blog (URL): www.ginelli.it


Modificare i permalink

I permalink (v. nel pannello di WordPress: Impostazioni->Permalink) erano nel formato “Data e nome”. Se non avessi modificato questa impostazione, ora avrei avuto i post all’indirizzo www.ginelli.it/2008/03/14/esempio e non più www.ginelli.it/blog/03/14/esempio.

Ho quindi optato per i permalink  con “Struttura personalizzata”, inserendo i seguenti valori:

/blog/%year%/%monthnum%/%day%/%postname%/.

Aggiungendo “blog”, infatti, i post avrebbero mantenuto il vecchio indirizzo, mentre le altre pagine sarebbero rimaste direttamente dipendenti dalla root del sito. Ad esempio, www.ginelli.it/contatti e non www.ginelli.it/blog/contatti

Spostare i file index.php e .htaccess

A questo punto la cartella di WordPress è stata rinominata, le impostazioni sono sistemate, i permalink pure. È il momento di spostare i file index.php e .htaccess dalla cartella /wordpress a quella principale del sito. Una modifica al codice php del file index.php è però necessaria. La riga

require('./wp-blog-header.php');

deve diventare

require('./wordpress/wp-blog-header.php');


Interventi sul db per percorsi file e immagini

Spostati i file index.php e .htaccess, WordPress è diventato il CMS di tutto il sito, installato sotto /wordpress, mentre il blog è rimasto visibile al suo posto sotto /blog.

Il lavoro non è però ultimato: quando si usa l’editor di WordPress i percorsi delle immagini e degli altri elementi multimediali vengono inseriti nel database. Rinominando da /blog a /wordpress la cartella di installazione, si rende necessaria una bella istruzione SQL sul database per correggere i riferimenti sbagliati.

Ultimi ritocchi: le vecchie pagine statiche con redirect 301

Avendo importato i contenuti delle vecchie pagine php in WordPress, bisogna affrontare un’ultima piccola fatica. Le vecchie pagine php, già presenti negli indici dei motori di ricerca e magari nei bookmark di qualche navigatore, devono redirigere automaticamente alle corrispondenti pagine di WordPress. Ad esempio, la vecchia pagina /form.php è ora /contatti. Come fare?

La risposta si chiama “HTTP header 301″. Con php, le vecchie pagine statiche devono ora redirigere automaticamente alle nuove versioni, grazie alla funzione header(), come nell’esempio:

<?php
header('Location: http://www.sito.ext/nuova-destinazione');
?>

Buona migrazione a tutti!

© 2009 – 2011, Mauro Ginelli. “Son tutti SEO, col sito degli altri”

Per dimostrare le affermazioni, nel post viene fornita l’immagine riportata di seguito, in cui si può notare la differente visualizzazione della medesima email HTML nelle versioni di Outlook 2000 e 2010 (su Flickr si può vedere l’immagine ingrandita).

Outlook 2000 e 2010 a confronto

Per protestare contro la decisione di Microsoft di non aderire pienamente agli standard web, ormai diffusi su tutti i moderni browser e client di posta elettronica, è stato lanciato il sito www.fixoutlook.org.
La homepage del sito raccoglie automaticamente tutti i tweet lasciati sul popolare sito di microblogging Twitter contenenti il link al sito FixOutlook. In questo modo, gli utenti possono esprimere attraverso Twitter il proprio sostegno alla causa del rispetto degli standard web e dare un feedback a Microsoft. La società di Redmond, infatti, per bocca del suo Outlook Product Manager Dev Balasubramanian, si era detta aperta e interessata a ricevere feedback dagli utilizzatori di Outlook, per lo sviluppo della nuova release.

In un solo giorno dal lancio del sito, oltre 20.000 tweet sono stati indirizzati a Microsoft a sostegno della campagna di FixOutlook. Tali da non passare inosservati alla Microsoft, che nel blog ufficiale di Outlook prende atto delle richieste degli utenti e,  mentre motiva le ragioni della scelta di Word come motore di rendering, dichiara il proprio impegno a migliorare il supporto degli standard:

[...] Microsoft welcomes the development of broadly-adopted e-mail standards. We understand that e-mail is about interoperability among various e-mail programs

La risposta di Microsoft è sicuramente di buon auspicio, sebbene su alcuni punti siano già arrivate le osservazioni e precisazioni dei promotori dell’Email Standards Project.

© 2009, Mauro Ginelli. “Son tutti SEO, col sito degli altri”