Il concetto è semplice: si esaminano le pagine che hanno traffico in ingresso da motore di ricerca e si assegna a ciascuna pagina, un contenuto equivalente della nuova versione del sito web.

Dopo aver fatto l’elenco delle corrispondenze si effettua un’operazione a livello server, che permette di reindirizzare in modo permanente ogni richiesta alla vecchia pagina verso la nuova versione.

In questo modo, se i contenuti delle due pagine sono ugualmente rilevanti per il motore di ricerca, non viene perso il posizionamento.

Prevedere un piano di migrazione delle URL attraverso redirect 301 potrebbe aver senso anche per pagine o siti non posizionati.

Infatti il solo posizionamento delle vecchie pagine non è l’unica cosa da preservare quando si effettua un restyling di un sito web ma ci sono anche molti altri fattori che incidono sulla qualità del lavoro SEO.

1- Errori HTTP: le pagine che non vengono redirette, non esistendo più, restituiscono al motore di ricerca uno status code 404. Questi errori specificano al motore di ricerca che i contenuti non sono più presenti ed in genere l’incorrere di questi errori HTTP non è da considerarsi un fattore di qualità, bensì una situazione evitabile.

2- Link in ingresso e Page Rank: sebbene una pagina non sia posizionata, è possibile che nella sua “vita” abbia ricevuto dei link in ingresso magari durante una campagna di comunicati stampa o per una vecchia sponsorship, ormai dimenticata. È un peccato disperdere così a cuor leggero del buon Page Rank.

3- Tempo di assorbimento della nuova versione: un effetto indotto dai due punti precedenti è sicuramente le frequenza di spiderizzazione del sito.

Immaginiamo gli scenari (semplificati) per l’indicizzazione di una nuova pagina “contatti” che non ha redirezioni dalla vecchia URL e non è linkata direttamente dalla home page, ma da una pagina interna chiamata ‘azienda’.

Scenario 1 – non c’è redirezione:

La nuova pagina “contatti” per essere indicizzata da Google dovrà attendere che:

• la nuova homepage venga assorbita;
• la nuova pagina ‘azienda’venga assorbita;
• l’indicizzazione della pagina contatti.
• …nel frattempo la vecchia pagina contatti avrà fornito degli errori http e verrà probabilmente eliminata dall’indice.

Scenario 2 – con redirezioni:

La nuova pagina “contatti” per essere indicizzata da Google dovrà attendere che:

• lo spider passi sulla vecchia versione e rilevi il 301;
• la nuova pagina venga indicizzata.

Inoltre nel frattempo lo spider potrebbe passare attraverso il 301 alla pagina ‘azienda’ e l’assorbimento della pagina che contiene il link a contatti.

È inutile dire che lo scenario 2 ha un flusso delle operazioni più snello e quindi la presenza di redirezioni 301 su tutte le pagine potrebbero incidere notevolmente sul tempo di assorbimento della nuova versione del sito.

Il tempo di assorbimento ed i vantaggi di tale operazione su questo fronte dipendono, ovviamente, dal trust che il sito ha acquistato nel tempo, dalla frequenza di spiderizzazione delle pagine pre-restyling e dai backlinks presenti, sia sulle pagine interne, che sulla home page.

4- Sitelinks: spesso si tende ad ignorare le redirezioni su pagine istituzionali quali: “profilo”,”contatti”, “sedi”, ecc. Effettuare una redirezione puntuale di tali pagine potrebbe essere utile per mantenere i sitelinks su queste pagine, qualora si ritenga opportuno mostrarli agli utenti.

5- Google slot-time: …ebbene sì, è arrivato anche il momento della filosofia e di una affascinanate teoria, che a me piace moltissimo ma che potrebbe anche non essere condivisibile da chi legge questo post.J Un autorevolissimo nonchè canuto guru SEO Piersante Paneghel ha ipotizzato (semplificando) che Google assegni a ciascun sito, in base al suo trust, un certo slot di tempo per le elaborazioni su di esso (assorbimento delle pagine, eliminazione di pagine dall’indice, modifica del posizionamento, ecc.). Allora mi chiedo: perché allora fargli perdere tempo con errori HTTP, quando a noi interessa che faccia l’assorbimento delle nuove pagine?

È indubbio che fare dei 301 puntuali su ciascuna pagina sia un lavoro particolarmente oneroso e che sia molto difficile la fase di implementazione e testing ma se, oltre ai posizionamenti, vi interessa anche migliorare i fattori sopra elencati potrebbe essere il momento di agire J

E voi che cosa ne pensate? Avete altri fattori benefici in favore dei 301? Mi sono dimenticato qualcosa?

Consigli per la lettura:

• Introduzione al file .htaccess: a che cosa serve? - MasterNewMedia
• La pagina di errore 404: qualche consiglio utile – Andrea Vit Blog
• URL rewriting guide – Guida ufficiale di Apache
• URL rewriting – YourHTMLsource
• Schemi utili per uso mod_write e file htaccess – I love Jack Daniels Blog
• Impostazione pagina di errore 503 – Andrea Vit Vecchio Blog
• Search Engine Optimization in php di Jaimie Sirovich
• Come reindirizzare una pagina web di Steve Hargrove
• Migrazioni di dominio e trasferimenti di URL di Piersante Paneghel

Nel blog trovi anche:

• Gli status code HTTP e il SEO – qualche consiglio utile
  
• La riscrittura delle URL ed i caratteri speciali (Versione 2.0)
• Riscrittura delle URL ‘a cartella’: da maneggiare con cautela
• Riscrittura delle URL con htaccess Apache: consigli e esempi pratici.
• I permalink e le URL personalizzate di Wordpress.

Per fare questo tipo di operazione dovete utilizzare il pannello di gestione dei permalink che vi permette di personalizzare la struttura dell’URL attraverso la valorizzazione del campo Custom Structure.

All’interno di questo campo dovrete andare ad inserire un percorso come ad esempio:%category%/%postname%.html, che andrà a settare le URL dei post come: nome categoria + nome del post con estensione html.
Di seguito vengono elencati i valori che si possono impostare:

• %year%: l’anno del post a 4 cifre
• %monthnum%: il mese del post a 2 cifre
• %day%: il giorno del mese a 2 cifre
• %hour%: l’ora del post a due cifre
• %minute%: i minuti del post
• %second%: i secondi del post
• %postname%: una versione codificata del titolo del post
• %post_id%: l’id numerico del post
• %category%: una versione codificata del nome della categoria
• %author%: una versione codificata del nome dell’autore.

Se ridenominate delle categorie o avere bisogno di un sistema avanzato e più flessibile di gestione delle URL, potete anche utilizzare questa comoda plugin AskApache RewriteRules Viewer per l’editing del file .htaccess direttamente dal pannello di configurazione di Wordpress:

Consigli ed esempi:

1. Ricordatevi sempre che Wordpress per il suo funzionamento utilizza index.php e per questo al momento dell’installazione ci sono settate delle regole di default che è preferibile non modificare:

# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress.


2. Se la l’home page della vostra piattaforma non è direttamente nella root directory, ma è nella directory blog:


RewriteCond %{HTTP_HOST} ^miosito\.com
RewriteRule ^(.*)$ http://www.miosito.com/$1 [R=301,L]


3. Se volete eliminare i parametri dalle vostre URL:


RewriteCond %{THE_REQUEST} ^GET\ /.*\;.*\ HTTP/
RewriteCond %{QUERY_STRING} !^$
RewriteRule .* http://www.askapache.com%{REQUEST_URI}? [R=301,L]


4. Se avete ridenominato una categoria o un file e volete che gli utenti vengano rediretti verso URL conformi al nuovo naming:


RewriteRule /blog/vecchia-categoria/(.+) http://www.miosito.com/nuova-categoria/ [R=301,L]

RewriteRule /blog/vecchio-permalink$ http://www.miosito.com/nuovo-permalink/? [R=301,L]

5. Se volete congiurare il rischio di qualche loop infiinto per qualche regola errata:


RewriteCond %{REQUEST_URI} ^/(stats/|missing\.html|failed_auth\.html|error/).* [NC]
RewriteRule .* - [L]
RewriteCond %{ENV:REDIRECT_STATUS} 200
RewriteRule .* - [L]

6. Se volete redirigere le richieste al feed dal vostro blog al servizio di FeedBurner:


RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /(feed|wp-atom|wp-feed|wp-rss|wp-rdf|wp-commentsrss)(.+)\ HTTP/ [NC,OR]
RewriteCond %{QUERY_STRING} ^feed [NC]
RewriteCond %{HTTP_USER_AGENT} !^(FeedBurner|FeedValidator) [NC]
RewriteRule .* http://feeds.askapache.com/apache/htaccess? [R=307,L]
RewriteRule ^comments/?.*$ http://feeds.feedburner.com/apache/htaccess/comments [L,R=302]

Link utili:

• .htaccess mod_rewrite rewrite examples;
• Redirect wordpress for Feedburner;
• Askapache RewriteRule Viewer Plug-in di Wordpress
• Using Permalinks di Wordpress
• Permalink redirect Plug-in;
• Riscrittura delle URL con htaccess Apache: consigli e esempi pratici.
• Gli status code HTTP e il SEO – qualche consiglio utile

Situazione iniziale:

Un cliente sta per effettuare la pubblicazione del suo nuovo sito ed bisogna effettuare tutto il piano di migrazione delle URL attraverso l’ormai fantomatico .htaccess.

Immagine tratta da searchengineland.com

Le pagine prodotto del vecchio sito vengono generate attraverso uno script lato server che risiede nella directory cgi-bin.

Quindi, per effettuare le redirezioni dai vecchi ai nuovi contenuti avrei dovuto inserire all’interno dell’.htaccess delle regole ‘RewriteRule’ del tipo:

RewriteRule /cgi-bin/prodotto_1 http://www.miosito.it/nuova/prodotto_1.html

Problema

Sembrerebbe un’operazione di routine ma dopo una serie di test andati ad esito negativo si nota come le regole impostate nella directory cgi-bin non vengano processate da Apache.

La sintassi, però, è corretta in quanto le stesse regole su un percorso di partenza ‘cgibin’ anzichè ‘cgi-bin’ venivano processate e redirette nel modo corretto.

Significa, quindi, che Apache nell’elaborazione delle RewriteRule applica un’eccezione nella gestione della cartella cgi-bin.

La cartella cgi-bin non è come tutte le altre, infatti, è quella che viene utilizzata per memorizzare gli script CGi lato server. Nel file httpd.conf tale directory è oggetto di un’impostazione particolare, ovvero di un ScriptAlias che istruisce il web server a processare le richieste nel path di origine alla directory del file system locale del server.
Esempio:
ScriptAlias /cgi-bin/ /web/cgi-bin/
Una richiesta per un URL all’interno di http://www.miosito.it/cgi-bin/script verrà processata dal file sul web server di percorso /web/cgi-bin/script.

Quindi il web server non effettua alcuna redirezione poiché l’httpd.conf processa la richiesta HTTP direttamente in locale, ancora prima di eseguire mod_rewrite e quindi la redirezioni .htaccess.

Come agire

Per poter redirigere le richieste HTTP in questo caso non è sufficiente agire sul file .htaccess, bensì è necessario agire a livello di httpd.conf in due modi:

1- Disabilitare ScriptAlias

Si disabilita la direttiva ScriptAlias, se non necessaria ai fini del funzionamento delle applicazioni web:

#ScriptAlias /cgi-bin/ /web/cgi-bin/

2- Doppia redirezione usando una cartella fake

Se l’impostazione della directory come ScriptAlias determina un vincolo per il funzionamento dei vostri sistemi, si può aggirare l’ostacolo attraverso l’inserimento di una direttiva Redirectmatch nel file httpd.conf prima del settaggio dello ScriptAlias. In questo modo verrà effettuata una redirezione 301 con successo prima che il file di configurazione faccia processare al webserver le richieste HTTP direttamente in locale. La directory verso il quale dovrebbe essere fatta la ridirezione potrebbe essere un nome fake come ‘redirect’.

Nel caso esposto, una possibile applicazione potrebbe essere la sostituzione nell’URL della stringa ‘cgi-bin’ con la stringa fake “redirect”

RedirectMatch 301 /cgi-bin/prodotto_(.+) http://localhost/redirect/prodotto_$1

A questo punto non resta altro che riprendere le regole nel file .htaccess non funzionanti e sostituire cgi-bin con redirect:

RewriteRule /redirect/prodotto_1 http://www.miosito.it/nuova/prodotto_1.html

Ricapitolando il flusso delle redirezioni consta quindi di due ridirezioni 301 e la comunicazione via HTTP diventa:

1. il client fa una richiesta all’URL www.miosito.it/cgi-bin/prodotto_1;
2. il server risponde con status code 301 e la nuova URL www.miosito.it/redirect/prodotto_1 attraverso la direttiva nel httpd.conf;
3. il client richiede l’URL www.miosito.it/redirect/prodotto_1;
4. il server risponde con la seconda redirezione 301 e la nuova URL www.miosito.it/nuova/prodotto_1.html attraverso la direttiva del file .htaccess;
5. il client richiede www.miosito.it/nuova/prodotto_1.html e riceve il nuovo file all’URL corretta.

Sicuramente questo tipo di redirezioni carica molto il server poichè causa la gestione di 3 richieste HTTP anzichè 2, ma è un buon modo per aggirare l’ostacolo ed effettuare le ridirezioni anche in questo caso particolarmente spinoso.

Link utili:

Sperando di essere stato abbastanza chiaro nell’argomentazione, ti linko altro materiale utile per i redirect con Apache e .htaccess:

• Documentazione ufficiale Apache mod_rewrite;
• Gli status code HTTP e il SEO – qualche consiglio utile,
• Riscrittura delle URL con htaccess Apache: consigli e esempi pratici;
• La riscrittura delle URL ed i caratteri speciali (Versione 2.0)
• Come reindirizzare una pagina web di Steve Hargrove;

.htaccess (hypertext access) è il nome che normalmente prende il file di configurazione delle directory di Apache. E’ chiamato con il punto perchè generalmente i file di sistema nascosti nei sistemi operativi Unix sono denominati con il punto davanti (i cosiddetti dot files).

Che cosa mi permette di fare?

Le operazioni che generalmente sono eseguite con questo tipo di file sono:

• configurazione delle autorizzazioni e autenticazioni, per poter personalizzare l’accesso delle directory e la sicurezza delle varie directory.
• personalizzazione delle pagine di errore, mostrando messaggi (o pagine) customizzati a seconda degli errori che possono essere restituiti agli utenti.
• redirezioni delle richieste HTTP verso altre URL, utile per eseguire URL rewriting.

Dove posso inserirlo?

I file .htaccess sono inseribili in qualsiasi directory del web server e le impostazioni di ciascun file vengono applicate alla directory dov’è posizionato e alle sue sottodirectory.

Posso cambiare il nome al file .htaccess?

Sì, è possibile cambiare il nome del file usando la direttiva AccessFileName nel file httpd.conf.

Per ridenominarlo .urlwriting basta inserire la seguente riga di codice:

AccessFileName .urlwriting

Come posso impostare la pagina 404 personalizzata?

Bisogna impostare all’interno del file .htaccess una riga di codice del tipo:

ErrorDocument 404 http://www.miosito.it/pagina-404.html

Come posso personalizzare l’accesso alle cartelle con .htaccess?

E’ necessario impostare alcune direttive all’interno del file in grado di istruire il web server a gestire gli accessi in modo personalizzato.

Questo è un esempio di autenticazione regolata da .htaccess con l’ausilio dei file di configurazione utente (/www/passwords/password.file) e gruppi (/www/passwords/group.file).

AuthType Basic
AuthName "Password Required"
AuthUserFile /www/passwords/password.file
AuthGroupFile /www/passwords/group.file
Require Group admins

Sottolineo che l’uso di .htaccess per personalizzare l’autenticazione tramite password appare forzata sia per questioni di sicurezza, sia per questioni di performance del server.

Come posso riscrivere le URL?

L’URL rewriting viene implementato con l’ausilio di 4 direttive:

• RewriteEngine: è necessario settare a on questa direttiva per poter attivare la riscrittura;
• RewriteRule: definisce le regole di riscrittura, la forma delle URL, lo status code HTTP da restituire e i molti altri parametri impostabili con i flag;
• RewriteBase: definisce il percorso di base da applicare alle regole di riscrittura definite successivamente nel sorgente del file di configurazione.
• RewriteCond: imposta le condizioni a cui per poter applicare la regola di riscrittura specificata successivamente nel codice sorgente;

Per gestire in modo corretto l’URL rewriting è bene avere dimestichezza con la sintassi delle espressioni regolari.

Alcuni esempi di URL rewriting frequenti.

#Redirige con status 301 tutte le URL di forma miosito.com/* in www.miosito.com/*
RewriteCond %{HTTP_HOST} ^miosito\.com
RewriteRule ^(.*)$ http://www.miosito.com/$1 [R=301,L]

#Redirige con un 302 tutte le richieste da pagine HTML a pagine php
RewriteRule (.*).htm$ /$1.php [R=301,L]

#regola per eliminazione problema del trailing slash sulle URL a cartella
RewriteRule ^/directory$ directory/ [R=301,L]

#regola per eliminare la pagine con il solo parametro id all'interno
RewriteCond %{QUERY_STRING} ^id=([0-9]+)$
RewriteRule ^/web(.+)$ /web/? [R=301,L]

#regola per redirigere le richieste HTTP a seconda degli orari del giorno
RewriteCond %{TIME_HOUR}%{TIME_MIN} >0700
RewriteCond %{TIME_HOUR}%{TIME_MIN} <1900
RewriteRule ^file\.html$ file-giorno.html
RewriteRule ^file\.html$ file-notte.html

#regola per fornire contenuti diversi a seconda dello user agent
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/3.*
RewriteRule ^file\.html$ file.mozilla3.html [L]

RewriteCond %{HTTP_USER_AGENT} ^Googlebot/.* [OR]
RewriteRule ^file\.html$ file.meglio-non-fare-questo-cloaking.html [L]

#Regola per trasformare URL statiche in URL dinamiche con redirezione 302
RewriteRule ^notizia/(.*)_([0-9]+).html$ notizia/?id=$2 [L]


Alcuni link utili:

• Introduzione al file .htaccess: a che cosa serve? - MasterNewMedia
• La pagina di errore 404: qualche consiglio utile – Andrea Vit Blog
• URL rewriting guide – Guida ufficiale di Apache
• URL rewriting – YourHTMLsource
• Schemi utili per uso mod_write e file htaccess – I love Jack Daniels Blog
• Impostazione pagina di errore 503 – Andrea Vit Vecchio Blog

Questo tipo di struttura delle URL è molto utile perchè consente di:

• dare una visione gerarchica dei contenuti del sito;
• fornire agli utenti nomi delle risorse facili da ricordare;
• indicare all’utente in maniera intuitiva quale sia la posizione attuale all’interno della navigazione del sito;
• poter cambiare estensione dei file da visualizzare in modo agevole (.html, .php,.asp, ecc.) essendo un tipo di denominazione indipendente dalla tipologia di piattaforma utilizzata;

Questo tipo di tecnica, però, ha bisogno di alcuni piccoli accorgimenti per non essere realmente sfruttata al massimo per il SEO.

Un aspetto molto importante è infatti mantenere il più possibile coerente la denominazione delle risorse ed evitare che siano raggiungibili o linkabili URL in varie versioni, come ad esempio:

• www.il-mio-sito.it/cartella
• www.il-mio-sito.it/cartella/
• www.il-mio-sito.it/cartella/index.html

Questi documenti, infatti, all’occhio del motore risultato diversi poichè hanno URL distinte disperdendo di fatto il loro Page Rank, poichè ogni URL avrà un numero diverso di link in ingresso.

Per un veloce controllo, provate a dare un occhio alla barra del PR in alcuni siti che rispondono a URL diverse di questo genere, vi accorgerete che la barretta dà valori diversi.

Oltre a due versioni duplicate dello stesso contenuto, potrebbe essere possibile che URL ‘a cartella’ appartentemente identiche facciano incorrere errori 404 a seconda che la pagina sia richiamata con o senza barra finale.

Bisogna pensare a questo piccolo problema, non solo in relazione ai link interni del sito, ma a quelli provenienti dall’esterno, un utente sbadato che vuole linkare una pagina con URL a cartella, infatti, potrebbe non fare attenzione alla presenza dello slash finale e se la versione non è quella adottata di default dal sito si potrebbe perdere il valore del link in ingresso.

Qunado si opera sulla riscrittura delle URL a forma di cartella, è buona norma tenere in considerazione questo aspetto prevedendo una redirezione HTTP 301 alla versione di default.

Consigli per la lettura:

• 11 Best practices for URLs di RandFish SEOMOZ;
• URLs & Domains Made Fun and Interesting di Jane Copland
• La riscrittura delle URL ed i caratteri speciali
• URL rewriting, serve ancora di Simone Carletti
• 13 Tips to Design Your Links