regole-seostrumenti seo per creare siti ottimizzati

Prima parte » Url rewrite

Nello scorso articolo abbiamo visto cosa è l’url rewrite e le differenze tra url rewrite e redirect 301 per capire in quali casi conviene usare uno o l’altro, visto che spesso c’è chi li confonde.

Non ci resta che vedere come si realizza l’url rewrite, tramite modulo mod_rewrite di Apache e un po’ di esempi su come utilizzarlo per risolvere alcuni tra i problemi più classici.

Il modulo mod_rewrite di Apache è un modulo che fornisce un potente mezzo per la manipolazione delle url. Tramite il mod_rewrite è possibile ottenere qualsiasi tipo (o quasi) di manipolazione degli indirizzi. Questo in molti casi implica uno sforzo non indifferente da parte di chi dovrà scrivere le regole di rewrite, spesso molto complicate.

Nello scrivere queste regole è sempre importante essere certi della loro correttezza, poiché un cattivo uso potrebbe causare dei problemi al funzionamento dell’applicazione e al server che la ospita.

Prima di vedere alcuni esempi di regole da inserire nel file .htaccess occorre sapere cosa sono le Rewrite Conditions e le Rewrite Rules.

Rewrite Conditions

Realizzata dalla direttiva RewriteCond definisce una regola condizionale.
La RewriteRule che segue una o più RewriteCond viene applicata solo se la url richiesta al server corrisponde al pattern della RewriteRule stessa e se tutte le RewriteCond precedenti sono verificate.

Come vedremo negli esempi è possibile appendere a ogni RewriteCond i seguenti flag, separati da una virgola in caso siano più di uno:

• [NC] fa si che il pattern della RewriteCond sia valutato in modalità case insensitive
• [OR] utilizzato per valutare in OR logico due RewriteCond consecutive.

Rewrite Rules

Realizzata tramite la direttiva RewriteRule, si occupa di definire il rewrite effettivo.

Si compone di 4 parti:

Anche in questo caso dunque è possibile appendere i seguenti flag separati eventualmente da una virgola:

• [R] redirige la url invocata ad un indirizzo esterno al nostro dominio inviando un response code 302 (MOVED TEMPORARILY).
• [F] proibisce l’accesso alla url invocata restituendo un response code 403 (FORBIDDEN).
• [G] definisce la url invocata come non più presente restituendo un response code 410 (GONE).
• [L] forza il processo di rewrite a fermarsi e a non considerare le regole di rewrite successive.
• [P] identifica la url come una richiesta al proxy passando il controllo al modulo mod_proxy.

Espressioni regolari

Per comprendere il funzionamento dei pattern usati nelle nostre regole per identificare le url occorre conoscere la sintassi delle espressioni regolari.
Qui di seguito mi limiterò ad elencare solo alcuni punti chiave per la comprensione delle espressioni regolari usate negli esempi.
Esiste molto materiale sul web realivo alle espressioni regolari e a questo sito
http://www.devarticles.com/c/a/ASP/The-Complete-Regular-Expression-Guide/
potete trovare una guida che può essere un buon punto di partenza.

• Identificatori di testo:
  . qualsiasi carattere
  [abc] a, b oppure c
  [^abc] né a, né b né c
  abc|def abc oppure def
• Quantificatori:
  ? 0 o 1 occorrenze dell’identificatore di testo precedente
  * 0 o N occorrenze dell’identificatore di testo precedente (N>0)
  + 1 o N occorrenze dell’identificatore di testo precedente (N>1)
• Raggruppamento:
  (identificatori di testo) le parentesi tonde sono un modo per identificare un gruppo di identificatori di testo come una singola unità atomica.
• Ancore:
  ^ inizio linea
  $ fine linea
• Escape:
  \ esegue l’escape del carattere che segue
• Negazione:
  è possibile eseguire la “negazione” di un determinato pattern facendolo precedere dal carattere punto esclamativo !

Non resta che vedere qualche esempio delle regole di rewrite da inserire nel file .htaccess situato nella root del nostro sito per andare incontro ad alcune classiche esigenze.

Esempi di regole di rewrite per esigenze classiche

Va detto che perché le regole di rewrite funzionino il modulo mod_rewrite di Apache deve essere abilitato all’interno del file httpd.conf della configurazione di Apache. A questo indirizzo
http://www.mrwebmaster.it/apache/articoli/guida-pratica-modulo-rewrite-apache_819.html
potete trovare un’ottima guida su come abilitare il mod_rewrite di Apache.

NOTA: per ragioni di spazio alcune linee di codice molto lunghe che definiscono le regole vanno inevitabilemnte a capo. Per questo motivo accanto ad ogni riga effettiva ho inserito il numero di riga (Es: 1-)

• Realizzare url più brevi e SEO-friendly
  Spesso per vincoli implementativi dipendenti anche dalle tecnologie utilizzate ci troviamo di fronte ad url troppo lunghe e poco seo-friendly. E’ allora opportuno (prima della messa on-line per evitare problemi di duplicazione dei contenuti) adottare opportune regole come la seguente:

  1- RewriteEngine On

  2- RewriteRule /prodotti/([a-z]+)/([0-9]+).html http://www.MioDominio.com/

     gestione_prodotti/prodotti.action?categoria=$1&idProdotto=$2 [L]

  
  Questo ci permette di ottenere una url più breve e amichevole sia per gli utenti che per i motori di ricerca.
  Da notare alcune cose:
  Innanzitutto non bisogna appendere alla prima parte dell’istruzione il nome del dominio (http://www. MioDominio.com). Infatti occorre inserire l’indirizzo a partire dalla root del sito (/).
  Ricordo inoltre che nel caso di nomi di file contenenti degli spazi (cosa sempre altamente sconsigliata:)) occorre utilizzare i doppi apici per definire l’indirizzo.

  Le espressioni ([a-z]+) e ([0-9]+) indicano una porzione variabile della url che può contenere una qualsiasi serie di lettere nel primo caso e una qualsiasi serie di numeri nel secondo. Queste variabili verranno usate per realizzare la rewrite.
  Infatti il simbolo $ seguito da un numero ($1 e $2 nel nostro caso) utilizzato nella parte destra della nostra regola serve per richiamare (posizionalmente) tali variabili presenti nella parte di sinistra.

  Dunque avremmo che la url SEO-friendly da esporre sarà ad esempio http://www.MioDominio.com/prodotti/casa/150.html e grazie alla rewrite rule genererà in realtà il contenuto della url http://www.MioDominio.com/gestione_prodotti/prodotti.action?categoria=casa&idProdotto=150

• Proteggere file e immagini
  Talvolta alcuni webmaster espongono il link diretto al download di un file situato sul nostro sito o ad un’immagine presente su una nostra pagina web.
  Con le seguenti regole la richiesta viene rediretta a http://www.MioDominio.com/ se la chiamata non proviene da http://MioDominio.com, http://www.MioDominio.com o http://62.149.140.159

  1- RewriteEngine On

  2- RewriteCond %{HTTP_REFERER} !^$ [NC]

  3- RewriteCond %{HTTP_REFERER} !^http://MioDominio.com [NC]

  4- RewriteCond %{HTTP_REFERER} !^http://www.MioDominio.com [NC]

  5- RewriteCond %{HTTP_REFERER} !^http://62.149.140.159 [NC]

  6- RewriteRule ^.*$ http://www.MioDominio.com/ [R,L]

• Domini differenti per lo stesso sito
  In alcuni casi lo stesso sito deve essere accessibile da url differenti come ad esempio MioDominio.com e www.MioDominio.com.
  Con la seguente regola di rewrite una url come http://MioDominio.com/about.html si risolverà come un’effettiva chiamata alla url http://www.MioDominio.com/about.html.

  1- RewriteEngine On

  2- RewriteCond %{HTTP_HOST} !^MioDominio.com$ [NC]

  3- RewriteRule ^(.*)$ http://www.MioDominio.com/$1 [R,L]

  
  NOTA: nel caso di più domini che corrispondano allo stesso sito tenete sempre ben presente gli eventuali problemi di duplicazione dei contenuti.

• Rewrite del dominio su una directory
  Se si ha la necessità di fare rispondere una specifica directory all’invocazione del dominio è possibile usare la seguente regola:

  1- RewriteEngine On

  2- RewriteCond %{HTTP_HOST} ^www.MioDominio.com$

  3- RewriteCond %{REQUEST_URI} !^/miaDirectory/

  4- RewriteRule ^(.*)$ /miaDirectory/$1

  
  In tal caso l’invocazione del dominio http://www.MioDominio.com si risolve in una chiamata alla url http://www.MioDominio.com/miaDirectory/

• Visualizzare i contenuti opportuni in base allo user agent
  Se doveste avere la necessità di mostrare dei contenuti sulla base dello user agent dell’utente potete servirvi di una regola di rewrite simile alla seguente:

  1-  # MS Internet Explorer - Mozilla v4

  2-  RewriteEngine On

  3-  RewriteCond %{HTTP_USER_AGENT} ^Mozilla/4(.*)MSIE

  4-  RewriteRule ^index\.html$ /index.IE.html [L]

  5-  

  6-  # Netscape v6.+ - Mozilla v5

  7-  RewriteCond %{HTTP_USER_AGENT} ^Mozilla/5(.*)Gecko

  8-  RewriteRule ^index\.html$ /index.NS5.html [L]

  9-  

  10- # All other browsers

  11- RewriteRule ^index\.html$ /index.default.html [L]

  
  In questo caso, invocando la url http://www.MioDominio.com/index.html, se il campo User-Agent dell’ http header della richiesta inizia con “Mozilla/4″ e si tratta di Internet Explorer (MSIE), allora sarà eseguita una rewrite sulla pagina http://www.MioDominio.com/index.IE.html (e non verranno considerate le regole successive).
  Se invece il campo User-Agent inizia con Mozilla/5 e si tratta di Netscape (Gecko), sarà eseguita la rewrite su http://www.MioDominio.com/index.NS5.html
  Infine, per tutti gli altri browser verrà eseguita la rewrite alla url http://www.MioDominio.com/index.default.html

Per concludere ecco il link alla documentazione del modulo mod_rewrite di Apache.

Seconda parte » URL rewrite e .htaccess: nozioni ed esempi

Questo articolo, dedicato all’url rewrite, è rivolto soprattutto a coloro che hanno una gran confusione in testa dovuta al fatto che spesso anche chi ha una certa competenza in materia usa indistintamente il termine rewrite e redirect.
In realtà sono due cose ben distinte, con scopi diversi e che permettono quindi di andare incontro a esigenze diverse anche in ambito SEO.

E’ del tutto normale che, proprio a causa di questa leggerezza nell’uso dei due termini, ci siano clienti che richiedono un redirect 301 quando in realtà necessitano di un url rewrite o viceversa.
E forse è anche normale che uno sfortunato cliente che si trovi a interagire con un consulente di profilo junior, richiedendo un url rewrite per andare incontro alle proprie esigenze SEO, si ritrovi appunto implementata un url rewrite (come da lui richiesto) quando in realtà ciò che avrebbe dovuto essere realizzato era un redirect 301 .

Dividerò l’articolo in due parti. In questa prima parte vedremo cosa è l’url rewrite, quali sono le differenze tra url rewrite e redirect 301 e quando conviene usare uno o l’altro.
Nel prossimo articolo vedremo invece come realizzare l’url rewrite tramite il modulo mod_rewrite di Apache e un po’ di esempi per andare incontro ad alcune delle problematiche più comuni che richiedono l’utilizzo di url rewrite.

Che cos’ è l’url rewrite?

Effettuare un url rewrite significa fare in modo che quando il server riceve una richiesta http per una determinata url, tale richiesta viene “convertita” in una richiesta ad una url differente che sarà quella che effettivamente genererà il contenuto della pagina web.
Esiste dunque un mapping tra una determinata url richiesta (originaria) e un’altra che sarà quella effettiva che genererà il contenuto.
Il tutto avviene lato server e il browser dell’utente non si accorge di nulla. La url che l’utente continuerà a vedere nella barra degli indirizzi sarà quella originaria. Discorso analogo per gli spider dei motori di ricerca.

Questo significa anche che realizzando una url “A” SEO-friendly mappata su una url “B” che è l’effettiva url che genererà la pagina web, avremo due url che se invocate dal browser genereranno lo stesso contenuto.
A chi si occupa di SEO a questo punto dovrebbe suonare il campanello d’allarme relativo ai contenuti duplicati.

Come vedremo tra poco esistono comunque situazioni in cui ha decisamente più senso l’utilizzo dell’url rewrite anziche del redirect 301.

Differenza tra url rewrite e redirect 301

Dopo quanto detto relativamente all’url rewrite e dopo aver letto questo articolo http://www.regole-seo.com/redirect-301-pagerank dedicato al redirect 301 ci accorgiamo che in effetti sono due cose ben diverse.

Che cosa avviene con un url rewrite:

• CLIENT – Richiesta url A
• SERVER – Ricezione richiesta url A
• SERVER – Rewrite della url A con la url B
• SERVER – invio dei contenuti generati dalla url B al CLIENT
• CLIENT – Ricezione dei contenuti generati dalla url B

Il client dunque è ignaro dell’esistenza della url B. L’utente o lo spider di un motore di ricerca invocano la url A e ricevono i contenuti di una url differente (B) mai invocata.
L’utente nella sua barra degli indirizzi vedrà sempre la url A.

Che cosa avviene con un redirect 301:

• CLIENT – Richiesta url A
• SERVER – Ricezione richiesta url A
• SERVER – Invia al CLIENT un response code 301 indicando che la url A è stata permanentemente spostata alla url B
• CLINET – ricezione del response code 301 e invio richiesta per la url B
• SERVER – Ricezione richiesta url B
• SERVER – invio dei contenuti generati dalla url B al CLIENT
• CLIENT – Ricezione dei contenuti generati dalla url B

In questo caso il client è consapevole dell’esistenza delle due url A e B ed effettua effettivamente due richieste al server.
L’utente nella sua barra degli indirizzi vedrà comparire la url B.

Url rewrite o redirect 301? Che cosa conviene usare?

Vista la differenza di funzionamento, ragionando un poco diventa facile capire in quale caso sia più opportuno usare una tecnica piuttosto dell’altra.
Utilizzeremo due esempi che dovrebbero illustrare in maniera piuttosto completa le problematiche e i vantaggi relativi alle due soluzioni.

Per quanto riguarda le necessità SEO, possiamo dire che se il vostro sito è on-line e decidete di modificare delle url per renderle più seo-friendly allora quello che dovete fare è utilizzare dei redirect 301 per almeno due buoni motivi:

• Evitate i problemi di contenuti duplicati. Infatti con l’url rewrite avreste due indirizzi in grado di generare lo stesso contenuto: la url nuova (seo friendly) e quella vecchia che probabilmente è già presente nei link di altri siti e nelle SERP dei motori di ricerca.
• Nessuna perdita di PageRank (come descritto in questo articolo http://www.regole-seo.com/redirect-301-pagerank). Tramite url rewrite il valore di PageRank guadagnato dalla vecchia url non verrebbe trasferito alla nuova url.

Supponete invece che il vostro sito abbia una nuova sezione, diciamo relativa ad un concorso, in comune con altri siti e situata dunque su un suo dominio differente.
L’utente potrebbe essere spaesato nel cliccare il link del concorso sul vostro sito e ritrovarsi su un dominio diverso.
Anche da un punto di vista marketing potreste avere qualche problema visto che chi ha pagato per avere dei banner sul dominio del vostro sito se li ritroverebbe invece su un dominio sconosciuto.
Ecco che in questo caso ci viene in aiuto l’url rewrite:
nel nostro sito pubblicheremo il link al concorso con una url fittizia “www.mioDominio.com/concorso” (relativa al nostro dominio e seo-friendly) e imposteremmo una regola di mapping tra quest’ultima e l’effettiva url “www.amministrazione-concorsi/concorso” facendo felici utenti e marketing.
Infatti al click sul link del concorso “www.mioDominio.com/concorso” il server risponderà con i contenuti di “www.amministrazione-concorsi/concorso” ma l’utente continuerà a vedere nella barra degli indirizzi “www.mioDominio.com/concorso”.

Chiaramente poiché la url reale non verrà mai esposta sul web non dovrebbe mai entrare negli indici dei motori di ricerca o nei link di siti esterni e quindi anche in termini di duplicazione di contenuti non si corre alcun rischio.

Double result, double listing, indent listing. Sono tutti nomi per identificare un potente mezzo tramite il quale possiamo dare maggiore visibilità al nostro sito web all’interno dei risultati di Google.

Ottenere il double result tra i risultati di ricerca di Google significa ottenere per il proprio sito web due risultati uno in seguito all’altro, anziché uno solo tra i primi 10 risultati di Google.

Infatti, data una chiave di ricerca, quando Google trova due risultati per lo stesso sito aventi entrambi posizione compresa tra i primi 10 risultati, i due risultati vengono accorpati.
Il primo (il più rilevante) verrà visualizzato nella sua posizione naturale mentre il secondo verrà visualizzato indentato (indent listing) subito sotto al primo anche se la sua posizione naturale non sarebbe stata quella immediatamente successiva.
L’immagine qui sotto è un chiaro esempio di ciò che si ottiene con il double result.

E’ dunque ovvio che il nostro sito otterrebbe molti più click e visite in quanto una seconda pagina non posizionata bene come la prima potrebbe fare un bel salto in avanti nella SERP fino a raggiungere la posizione della pagina meglio posizionata.

Supponiamo ad esempio che nella prima pagina di Google (normalmente composta da 10 risultati), per una determinata query di ricerca si ottenga una pagina in posizione 1 e una in posizione 9. In questo caso si otterrebbe un duble listing che vede accorpati i due risultati nella prima e nella seconda posizione.

Dunque mi sento proprio di dire che il double result è un aspetto importante e che sarebbe da pazzi non tenerlo in considerazione per aumentare notevolmente la propria visibilità soprattutto per nicchie poco competitive.

Come ottenere il double result

• Innanzitutto, se già non lo avete fatto, occorre posizionare una pagina tra i primi 10 risultati di Google su una determinata keyword seguendo, ad esempio, le regole di seo on-page e seo off-page e gli articoli di approfondimento sul SEO che trovate qui su regole-seo.
• Il passo successivo è creare una seconda pagina ottimizzata per la stessa keyword per cui è stata ottimizzata la prima pagina. La cosa importante è che però i contenuti delle due pagine siano diversi per non incappare nei problemi di contenuti duplicati che molto probabilmente causerebbero l’uscita dalla SERP di una delle due pagine.
• Ora occorre collegare la seconda pagina con un link inserito nella prima usando nell’anchor text la keyword per cui le pagine sono state ottimizzate.
• Infine avremo bisogno di far salire la seconda pagina almeno fino alla decima posizione nel ranking di Google. Anche questa volta potremo affidarci alle regole SEO utilizzate nel primo punto o magari fare affidamento su pochi inbound link di buona qualità.

Chiaramente realizzare il double listing non è sempre semplice. Il mio consiglio è quello di identificare le pagine del vostro sito che già sono posizionate nei primi 10 risultati della SERP e creare per queste una seconda pagina che magari metta in luce altri aspetti dello stesso argomento o magari che approfondisca un aspetto ad esso correlato.
In questo modo dovrebbe essere più semplice ottenere un double result realizzando un contenuto interessante, senza duplicazioni, correlato a quello della prima pagina e ottimizzato sulla stessa keyword.

Indice articoli JSESSIONID

• JSESSIONID e SEO
• JSESSIONID: Cosa è e perchè compare nelle URL?
• Come elimnare il JSESSIONID dalle url; pro e contro
• Come eliminare da Google le url indicizzate

Rimuovere da Google le url indicizzate può risultare molto utile quando decidiamo di modificare gli indirizzi delle nostre pagine web per creare url più SEO friendly.
Uno di questi casi si ha quando negli indici di Google finiscono delle url in cui compare il JSESSIONID.
Una volta visto come eliminare il JSESSIONID dalle url nell’articolo precedente, vediamo come eliminare da Google le url indicizzate non più attuali.

Per rimuovere degli indirizzi dai risultati di ricerca di Google, occorre innanzitutto assicurarsi che il server restituisca un codice di stato HTTP 404 (Not Found) o 410 (Gone) quando le vecchie url vengono invocate.
Questi codici indicano a Google che la pagina non è più esistente e che quindi non deve più essere visualizzata tra i risultati di ricerca.
Questo è il primo e più importante passo da effettuare per assicurarsi la rimozione delle url dagli indici di Google.
A questo punto, dopo che Google avrà eseguito nuovamente la scansione del sito, i contenuti dovrebbero scomparire naturalmente dall’indice.

Se invece si desidera effettuare la rimozione da Google delle url con una certa urgenza, è possibile utilizzare lo strumento di rimozione di Google (in Strumenti per i Webmaster) per velocizzare la procedura.
Ciò è molto utile quando vengono cambiati i contenuti della pagina poichè viene eliminata anche la copia cache memorizzata da Google.
Se volete procedere in questo modo vi basterà accedere a “strumenti per i Webmaster” fare clic su “Configurazione sito” nel menu di navigazione a sinistra e successivamente su “Accesso crawler“, quindi seguire la procedura dalla voce “Rimuovi URL“.

Indice articoli JSESSIONID

• JSESSIONID e SEO
• JSESSIONID: Cosa è e perchè compare nelle URL?
• Come elimnare il JSESSIONID dalle url; pro e contro
• Come eliminare da Google le url indicizzate

Nell’articolo precedente abbiamo visto che cos’è il JSESSIONID e perché compare nelle url.
E’ arrivato dunque il momento di capire come eliminare il JSESSIONID dalle url e quali sono i pro e i contro di questa operazione.

La soluzione che propongo è una soluzione applicativa e prevede dunque l’inserimento di codice nella vostra applicazione web per eliminare definitivamente il JSESSIONID dalle vostre url.

Poiché, come visto in precedenza, il JSESSIONID rappresenta l’implementazione JAVA dell’HTTP session token, la soluzione è utilizzabile in una applicazione web JAVA e più precisamente quello realizzato altro non è che un Filter JAVA.

Ecco il codice completo:

package mio.package.filter;

import java.io.IOException;
import javax.servlet.*;
import javax.servlet.http.*;
import org.apache.log4j.Logger;

public class DisableJSID implements Filter{

   private static Logger log = Logger.getLogger(DisableUrlSessionFilter.class);

   public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
      throws IOException, ServletException{
      // Controllo per agire solamente su richieste di tipo http
      if (!(request instanceof HttpServletRequest)){
         chain.doFilter(request, response);
         return;
      }

      HttpServletRequest httpRequest = (HttpServletRequest) request;
      HttpServletResponse httpResponse = (HttpServletResponse) response;

      //Invalidiamo la sessione se viene trovato l'identificativo nella url
      if (httpRequest.isRequestedSessionIdFromURL()){
         log.info("Trovato identificativo di sessione nella url");
         HttpSession session = httpRequest.getSession();
         if (session != null){
            session.invalidate();
            log.info("sessione invalidata");
         }
      }

      // Wrapper di httpResponse per aggirare l'URL encoding
      HttpServletResponseWrapper wrappedResponse =
                                              new HttpServletResponseWrapper(httpResponse){
         @Override
         public String encodeRedirectUrl(String url) { return url; }

         @Override
         public String encodeRedirectURL(String url) { return url; }

         @Override
         public String encodeUrl(String url) { return url; }

         @Override
         public String encodeURL(String url) { return url; }
      };

      chain.doFilter(request, wrappedResponse);
   }

   public void init(FilterConfig config) throws ServletException {}

   public void destroy() {}
}

Il compito di questo Filter è quello di realizzare un wrapper per l’oggetto HttpServletResponse ridefinendo i seguenti metodi in modo tale che non realizzino più l’url rewriting che andrebbe ad appendere il JSESSIONID alle nostre url.

Una volta realizzato il filter basterà mapparlo nel file web.xml della nostra applicazione nel seguente modo:

<filter>
   <filter-name>DisableJSID</filter-name>
   <filter-class>mio.package.filter.DisableJSID</filter-class>
</filter>
<filter-mapping>
   <filter-name>DisableJSID</filter-name>
   <url-pattern>/*</url-pattern>
</filter-mapping>

Una volta che il nostro Filter è in azione il JSESSIONID scomparirà dalle nostre url.
Questo significa che un eventuale link costruito tramite il tag <c:url> o un’operazione di redirect eseguita tramite <c:redirect> della tag library JSTL non produrrà più una url contenente il JSESSIONID nel caso in cui il client abbia i cookie disabilitati.

Come abbiamo visto nell’articolo precedente “JSESSIONID: Cosa è e perchè compare nelle URL?” poiché gli spider dei motori di ricerca non accettano i cookie se non adottassimo il nostro Filter, ad ogni visita del nostro sito essi potrebbero indicizzare una determinata pagina sotto una url differente a causa del JSESSIONID che ogni volta viene creato per quella determinata sessione di navigazione.

Il vantaggio che deriva dunque dall’eliminazione del JSESSIONID dalle url è indubbiamente quello di evitare che gli spider dei motori di ricerca rilevino contenuti duplicati (sotto url che differiscono per JSESSIONID). Inoltre eliminando il JSESSIONID dalle url otteniamo delle url più amichevoli e inerenti al contenuto della pagina a cui si riferiscono.

Esiste però anche uno svantaggio derivante dall’eliminazione del JSESSIONID dalle url.
Infatti per tutti gli eventuali utenti che avranno i cookie disabilitati non sarà possibile mantenere traccia della sessione.
Il JSESSIONID è infatti l’unico modo tramite il quale il server è in grado di associare la sessione all’utente qualora quest’ultimo avesse i cookie disabilitati.

Le conseguenze di questo approccio vanno dunque determinate sulle singole applicazioni, cercando di valutare se questo aspetto è accettabile e verificando, ad esempio, se l’attuale navigazione del sito è stata costruita pensando agli utenti con cookie disabilitati (es. utilizzo del tag <c:url>).

Quanto incide la site age ovvero l’età di un dominio sul suo posizionamento nei motori di ricerca?

Matt Cutts interviene per darci delle risposte nel video che trovate infondo all’articolo.

Personalmente ritengo che l’età di un sito sia importante ma che incida solo indirettamente sul posizionamento. Prima di chiarire meglio questo aspetto ecco quanto ci dice Matt Cutts sull’argomento.

In sostanza alcune agenzie di web hosting stavano diffondendo delle e-mail secondo le quali Google “premiava” in termini di posizionamento nel caso di registrazione del proprio dominio per almeno tre anni.
Google però non ha mai detto nulla del genere.
Questa falsa informazione, suppone Matt Cutts, può essere derivata dal fatto che Google ha registrato (nel 2002) un brevetto che permette di utilizzare i dati storici di un sito per determinarne il posizionamento.

Dunque a livello teorico il periodo di tempo in cui un sito risulta registrato, così come anche l’autorevolezza e la popolarità durante il periodo di vita del sito potrebbero venire utilizzati da Google (insieme a tutti gli altri fattori) per determinare il ranking di un sito.

Matt Cutts precisa che Google brevetta moltissime idee ma questo non significa che tutte vengano utilizzate per determinare il posizionamento dei siti web in Google.

Il suo consiglio è dunque quello di puntare sempre e comunque sulla qualità del sito e dei suoi contenuti e la qualità dei link ricevuti. Questo fa la differenza indipendentemente dagli anni di registrazione del dominio.

Certamente l’età di un sito non incide direttamente sul posizionamento. Dire a prescindere, ad esempio, che un sito di quattro anni è posizionato meglio di un sito di un anno non ha assolutamente senso.
L’età però resta un fattore che può incidere indirettamente sul posizionamento in quanto maggiore è il tempo per cui un sito è presente sul web, maggiore sarà la possibilità di avere incrementato la sua presenza e la sua link popularity.

Come ci dice Matt Cutts Google può dunque basarsi sulle informazioni storiche relative ad un sito ma ciò che viene considerato è l’autorevolezza e la qualità allo scorrere del tempo.
Dobbiamo dunque ancora una volta tornare a concentrarci sui contenuti e sulle strategie per promuovere il nostro sito in modo efficace.

Il fatto poi, che grazie alla qualità e alla promozione dei contenuti, l’aumento della popolarità sia direttamente proporzionale all’età del sito credo che rientri nell’ordine naturale delle cose

Vi lascio al breve video di Matt Cutts relativo alla “site age e posizionamento”

Indice articoli JSESSIONID

• JSESSIONID e SEO
• JSESSIONID: Cosa è e perchè compare nelle URL?
• Come eliminare il JSESSIONID dalle url; pro e contro
• Come eliminare da Google le url indicizzate

Per capire che cosa è il JSESSIONID e a che cosa serve occorre prima capire cosa si intende con “sessione“.
In una rete informatica la sessione rappresenta un dialogo di scambio semi-permanente di informazioni tra due o più dispositivi o tra computer e utente.

Una sessione viene stabilita in un certo istante nel tempo, e viene distrutta in un certo istante successivo. Una sessione di comunicazione può coinvolgere più di un messaggio in ogni direzione.
Tipicamente (ma non sempre) una sessione è “stateful” ovvero almeno uno dei soggetti comunicanti necessita di salvare informazioni relativamente alla comunicazione per fare in modo che la comunicazione stessa possa avvenire.

Grazie alla sessione possono essere mantenute, ad esempio, informazioni sullo specifico utente autenticato in un forum o che sta partecipando ad un gioco oppure le informazioni dell’utente e dei suoi acquisti durante l’intera procedura di scelta e acquisto di prodotti in un sito di e-commerce.

Senza l’utilizzo della sessione le cose si farebbero molto più complicate e articolate poiché normalmente la comunicazione nel web avviene tramite protocollo HTTP che è un protocollo “stateless”, ovvero ogni singola richiesta non lascia alcuna informazione sul server.

Se la sessione rappresenta appunto un meccanismo utilizzato per memorizzare i dati della comunicazione tra client e server, il JSESSIONID rappresenta un identificatore univoco attraverso il quale il server può riconoscere lo specifico utente a cui è associata una determinata sessione.

In termini più generali si dovrebbe parlare anzichè di JSESSIONID, di HTTP session token.
Normalmente il client memorizza un codice univoco inviato dal server, chiamato HTTP session token, all’interno di un cookie. Questo token viene inviato ad ogni richiesta dell’utente in modo che il server possa riconoscere quale è la sessione associata a tale token e ottenere tutte le eventuali informazioni memorizzate durante la navigazione dell’utente.

Dunque mentre tutte le informazioni della comunicazione tra client e server sono memorizzate nella sessione su server, il client si occupa solo di inviare il token univoco memorizzato nel cookie.
Questo token prende il nome di PHPSESSID nel caso di applicazioni web sviluppate in PHP, di ASPSESSIONID in caso di applicazioni ASP e di JSESSIONID in caso di applicazioni web sviluppate in lingiaggio JAVA.
Pertanto il JSESSIONID non è che una specifica implementazione dell’ HTTP session token in ambiente JAVA.

Veniamo ora al nocciolo della questione: come mai il JSESSIONID compare all’interno delle url e viene indicizzato dai motori di ricerca?

Come saprete sui browser degli utenti vi è la possibilità di disabilitare i cookie. Questo impedirebbe ad alcune applicazioni web di funzionare correttamente dato che senza il cookie contenente il token, il server non avrebbe modo di riconoscere quale è la sessione memorizzata per lo specifico utente.
Tramite apposite tecniche di rewrite url (o url rewriting) è possibile fare in modo che qualora la richiesta arrivi da un browser con cookie disabilitati, il token venga appeso alle url anziché memorizzato in un cookie.
Utilizzando ad esempio i tag <c:url> o <c:redirect> della tag library JSTL il rewrite url che appende il JSESSIONID viene eseguito automaticamente.

In tal caso le url somiglierebbero a qualcosa del tipo
http://www.mioDominio/home.jsp;jsessionid=858E118F048008FF291355969D581130.mia-app

Tutto ciò può diventare un problema quando entrano in gioco i motori di ricerca.
Gli spider dei motori di ricerca non accettano cookie e di conseguenza ogni volta che uno spider viene a far visita al nostro sito rileverà una url differente (JSESSIONID differente) per lo stesso contenuto.
Come sappiamo la duplicazione dei contenuti non è una buona cosa in ambito SEO e ad ogni modo una url come quella sopra riportata non è una url SEO friendly.

Ora che abbiamo idea di cosa è il JSESSIONID, pur non essendoci spinti in dettagli tecnici, possiamo già intuire qualcosa a riguardo di ciò che affronteremo nel prossimo articolo dedicato ai pro e ai contro dell’eliminazione del JSESSIONID dalle url.

Se siete interessati invece a qualche dettaglio tecnico in più, possiamo continuare il discorso attarverso i commenti a questo post!

Indice articoli JSESSIONID

• JSESSIONID e SEO
• JSESSIONID: Cosa è e perchè compare nelle URL?
• Come eliminare il JSESSIONID dalle url; pro e contro
• Come eliminare da Google le url indicizzate

“JSESSIONID“. Quale è la prima cosa a cui pensi sentendo questo nome?

Quello che ho notato gironzolando per il web alla ricerca di correlazioni tra JSESSIONID e SEO, è che in molti messaggi nei forum o negli articoli di alcuni blog si parla con un po’ troppa leggerezza di come il JSESSIONID sia dannoso; qualcosa da non usare e da eliminare assolutamente dalle proprie url.

Raramente però chi da questi consigli si sofferma nello spiegare quale è il senso del JSESSIONID, perchè viene inserito nelle url e quali implicazioni negative possono esserci eliminandolo dalle nostre url.

Insomma spesso chi parla di JSESSIONID in ambito SEO, pur essendo documentato sugli svantaggi che il JSESSIONID nelle url può portare a livello di indicizzazione, è però forse poco documentato sul motivo per cui il JSESSIONID viene utilizzato nelle applicazioni web.

Che il JSESSIONID rappresenti un problema relativamente al SEO a all’indicizzazione è senza dubbio vero come accennato nell’articolo dedicato ai contenuti duplicati.
Fondamentalmente i problemi che derivano dalla presenza del JSESSIONID nelle url sono i seguenti:

• le url si allungano e contengono una porzione non esseziale che non ha nulla a che fare con le tematiche della pagina a cui la url fa riferimento;
• lo spider dei motori di ricerca potrebbe rilevare contenuti duplicati. Poichè il JSESSIONID cambia ad ogni nuova visita dello spider, quest’ultimo rileverebbe url differenti per lo stesso contenuto.
  (Per maggiori informazioni vedi l’articolo dedicato ai contenuti duplicati)

Va ricordato che relativamente alla duplicazione dei contenuti, ciò che potrebbe accadere è che negli indici compaia la url contenente anche il JSESSIONID anzichè quella tradizionale. Generalmente infatti Google trovandosi più url che puntano allo stesso contenuto, decide di escludere quelle che reputa superflue.
Vale a dire che il vostro contenuto resta indicizzato ma probabilmente non sotto la url che avreste desiderato.

Visti dunque quali sono i problemi che il JSESSIONID può causare in ambito SEO, vediamo di capire meglio negli articoli successivi, di cosa si tratta, perchè il JSESSIONID viene usato, come possiamo eliminarlo dalle url per favorire l’indicizzazione e quali sono i lati negativi che derivano dall’eliminarlo (dopotutto se il JSESSIONID viene usato un motivo ci sarà )

Google AJAX Libraries API è un network di distribuzione per le più popolari librerie Javascript open source.
Rappresenta un modo davvero utile per utilizzare librerie Javascript in modo più efficiente per aumentare la velocità di caricamento delle pagine di un sito.
Vediamo meglio di cosa si tratta.

Molto spesso nella realizzazione di un sito web si ricorre all’uso di potenti librerie Javascript come ad esempio Jquery, MooTools, Prototype ecc…
Queste librerie facilitano molto gli sviluppatori nella realizzazione di funzionalità client side permettendo anche di ottenere effetti grafici e animazioni davvero molto accattivanti con uno sforzo minimo.
Purtroppo però il peso di queste singole librerie può anche superare i 50 KB senza considerare eventuali plugin aggiuntivi per realizzare funzionalità specifiche.
Inoltre va anche considerato il fatto che molto spesso queste librerie vengono utilizzate contemporaneamente all’interno dello stesso sito.
Detto questo è facile intuire che raggiungere un peso di 100 KB per una singola pagina è una possibilità decisamente plausibile, con conseguenze negative sulla velocità di caricamento.

Una soluzione a questo problema è l’utilizzo delle Google AJAX API tramite la funzione google.load()

Prima di vedere come possiamo utilizzare google.load() per sfruttare Google AJAX API, vediamo brevemente quali sono i principali vantaggi che derivano dall’utilizzare le librerie sopra menzionate facendo si che sia Google a fornircele anziché il server che ospita il nostro stesso sito:

• Poiché Google possiede un grandissimo content delivery network con diversi centri sparsi in tutto il mondo, è in grado di fornire i file più velocemente del server che ospita il nostro sito, utilizzando il “data center” che geograficamente si trova più vicino all’utente, aumentando così la velocità di download della pagina web.
• Utilizzando questo modo comune di accedere alle migliori librerie Javascript e grazie al fatto che questo metodo viene usato dai webmaster più accorti, esistono grandi possibilità che l’utente che visita il nostro sito abbia già visitato precedentemente un sito che caricava le stesse librerie da noi usate sempre utilizzando utilizzare google.load().
  In tal caso le librerie si trovano già nella cache del browser dell’utente e non verranno scaricate nuovamente a vantaggio della velocità di caricamento delle nostre pagine.
• Grazie al fatto che ci sono alte probabilità che le librerie Javascript da noi usate si trovino già nella cache del browser dell’utente (come visto nel punto precedente), il numero di download delle librerie Javascript diminuirà insieme alla banda utilizzata dagli utenti in visita al nostro sito.

Vediamo ora come utilizzare la funzione google.load() per usufruire delle librerie Javascript di Google AJAX API attraverso i pochi passi descritti di seguito:

• Innanzi tutto occorre creare una API key che consentirà al vostro sito di potere utilizzare le di Google AJAX API. Potete generare l’API Kei al seguente indirizzo code.google.com/intl/it-IT/apis/ajaxsearch/signup.html
• A questo punto vi basterà inserire il seguente codice contenente l’API Kei generata nell’header delle vostre pagine web

  <script type="text/javascript" src="http://www.google.com/jsapi?key=TUA-API-KEY"></script>

• L’ultimo passaggio è quello di caricare le librerie Javascript di cui necessitate nella vostra pagina web come nell’esempio seguente:

  <script type="text/javascript">
google.load("jquery", "1.4.2");
google.load("jqueryui", "1.8.1");
google.load("prototype", "1.6.1.0");
google.load("scriptaculous", "1.8.3");
google.load("mootools", "1.2.4");
google.load("dojo", "1.4.1");
google.load("swfobject", "2.2");
google.load("yui", "2.8.0r4");
google.load("ext-core", "3.1.0");
</script>
  Il primo parametro passato nella fuznione google.load() è il nome della libreria mentre il secondo rappresenta la versione.

Per maggiori dettagli su come utilizzare Google AJAX API vi rimando alla documentazione ufficiale: AJAX Libraries API Developer’s Guide.

La gzip compression è un buon modo per ottenere due grandi vantaggi in termini di performance di un sito web.
In primo luogo grazie alla compressione gzip si risparmia sul bandwidth (larghezza di banda) ovvero sulla quantità di byte che occorre trasportare in giro per il web affinchè il nostro sito venga visualizzato.
In secondo luogo (diretta conseguenza del primo aspetto) potremo ottenere un vantaggio anche in termini di velocità.

Mentre il vantaggio che si acquisisce in termini di larghezza di banda attivando la gzip compression è fuori discussione, il beneficio effettivo che la gzip compression porta in termini di velocità dipende comunque da diversi altri fattori quali la quantità di traffico del vostro sito, la velocità della linee, l’effettive peso dei vostri contenuti ecc.

Quello che ad oggi mi sento proprio di dire, è che la compressione gzip attivata su un sito può solo portare vantaggi, anche nel caso in cui la velocità non dovesse aumentare in modo rilevante.

Tempo fa la scelta non era così semplice infatti non tutti i vecchi browser web supportavano la gzip compression. Stiamo però parlando delle versioni ormai datate dei browser; le versioni precedenti alla 4 di Internet Explorer e Netscape e di versioni di Opera precedenti la 5.12.
Insomma credo proprio che ormai sia acqua passata.

Prima di vedere due esempi su come attivare la gzip compression su web server Apache e la gzip compression su application server Apache Tomcat e verificarne il funzionamento tramite gzip-test, vediamo meglio di cosa si tratta.

Standard http request and respons

L’immagine precedente descrive ciò che generalmente avviene quando invochiamo un url come ad esempio http://www.mioSito.it/index.html

1. Browser: invia una richiesta al server per la pagina, http://www.mioSito.it/index.html
2. Server: riceve la richiesta e cerca la pagina da fornire
3. Server: trova la pagina e invia con un response code 200 (OK) il file trovato, supponiamo di 100KB
4. Browser: attende di scaricare i 100 KB per poi visualizzare la pagina all’utente.

Chiaramente questa operazione viene ripetuta per tutte le risorse riferite dalla pagina index.html (immagini script esterni ecc…)

In questo caso ipotetico dunque dobbiamo attendere il download di 100 KB… …decisamente troppo!

Gzip http request and respons

Con la gzip compression quello che avviene è che il server effettua una compressione del file richiesto prima di inviarlo al browser. Una volta ricevuto il file, il browser lo decomprimerà per poi visualizzarlo all’utente.

Ecco cosa avviene nel dettaglio:

1. Browser: invia una richiesta al server per la pagina, http://www.mioSito.it/index.html specificando al server che supporta la gzip compression
2. Server: Riceve la richiesta e cerca la pagina da fornire
3. Server: Trova la pagina e invia un response code 200 (OK), comprime il file da 100 KB ottenendo un file da 25 KB e lo invia al browser.
4. Browser: attende di scaricare i 25 KB per poi visualizzare la pagina all’utente.

Da notare che il guadagno ottenuto sulla compressione del codice della pagina può arrivare al 75%.

Come evidenziato anche nell’immagine, perché tutto ciò funzioni correttamente, il client (browser) e il server devono stabilire un accordo:

1. Il browser deve informare il server che è in grado di supportare il contenuto compresso. Per fare ciò invia nell’header della richiesta il seguente parametro:
   Accept-Encoding: gzip, deflate
2. Il server, nel caso il contenuto richiesto venga compresso, deve informare il browser che il contenuto che sta per inviare è compresso. Per fare ciò invia nell’header della risposta il seguente parametro:
   Content-Encoding: gzip

   NOTA: Se il server non invia tale parametro in risposta allora significa che il contenuto non è stato compresso e che quindi il browser (pur supportando contenuti comrpessi) dovrà trattarlo nel modo tradizionale.

Poiché come detto in precedenza, già da diversi anni i browser supportano la gzip comrpession, se vogliamo ottenere i vantaggi della compressione gzip tutto quello che ci resta da fare è configurare il server del nostro sito perché fornisca i contenuti compressi.

Vediamo come attivare la gzip compression su web server Apache e su application server Apache Tomcat

Apache gzip compression

Per abilitare la gzip compression su web server Apache occorre essenzialmente abilitare il modulo mod_deflate.so inserendo la seguente istruzione nel file httpd.conf situato nella cartella conf dell’installazione di Apache:

LoadModule deflate_module modules/mod_deflate.so

e aggiungere quanto segue per attivare la compressione:

#
# mod_deflate configuration
#
LoadModule deflate_module modules/mod_deflate.so
<IfModule mod_deflate.c>
      AddOutputFilterByType DEFLATE text/plain
      AddOutputFilterByType DEFLATE text/html
      AddOutputFilterByType DEFLATE text/xml
      AddOutputFilterByType DEFLATE text/css
      AddOutputFilterByType DEFLATE application/xml
      AddOutputFilterByType DEFLATE application/xhtml+xml
      AddOutputFilterByType DEFLATE application/rss+xml
      AddOutputFilterByType DEFLATE application/javascript
      AddOutputFilterByType DEFLATE application/x-javascript
      DeflateCompressionLevel 9
      BrowserMatch ^Mozilla/4 gzip-only-text/html
      BrowserMatch ^Mozilla/4\.0[678] no-gzip
      BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
      DeflateFilterNote Input instream
      DeflateFilterNote Output outstream
      DeflateFilterNote Ratio ratio
      LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate
</IfModule>

Per una descrizione dettagliata della configurazione vi rimando a questo articolo: how to Install and configure mod_deflate – Compress Web Content delivered by Apache e chiaramente anche alla documentazione ufficiale del modulo mod_deflate di Apache: http://httpd.apache.org/docs/2.0/mod/mod_deflate.html

Apache Tomcat gzip compression

Nel caso invece abbiate realizzato un’applicazione web Java e debba essere l’application server Tomcat a dovere operare la gzip compression, vi basterà configurare il Connector all’interno del file server.xml come nel seguente esempio:

<Connector port="8080" maxHttpHeaderSize="8192"
         maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
         enableLookups="false" redirectPort="8443" acceptCount="100"
         connectionTimeout="20000" disableUploadTimeout="true" useBodyEncodingForURI="true"
         compressableMimeType="text/html,text/xml,text/css,text/javascript,text/plain"
         compression="on" compressionMinSize="2048"
         noCompressionUserAgents="gozilla, traviata"/>

A questo indirizzo trovate la documentazione ufficiale per la configurazione del Connector di Tomcat: Tomcat Http connector

GZIP test

Una volta configurato il server non ci resta che verificare se tutto funziona correttamente.
A questo indirizzo www.gidnetwork.com/tools/gzip-test.php trovate gzip-test un semplice strumento che è in grado di dirvi se la gzip compression è attiva per il vostro sito e, in tal caso, quanto è il guadagno che ne avete avuto in termini di dimensioni.

Con la gzip compression, a fronte di una perdità di velocità generalmente irrisoria derivante dal lavoro operato dal server per realizzare la compressione, otterrete sicuramente un aumento più o meno sensibile della velocità di download dei contenuti e sicuramente un grande vantaggio in termini di banda utilizzata.