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“.

Articoli correlati:

1. Come eliminare il JSESSIONID dalle url; pro e contro
2. JSESSIONID e SEO
3. JSESSIONID: Cosa è e perchè compare nelle URL?
4. “google.load()”: più velocità con Google AJAX Libraries API
5. Lunghezza massima dei link: 8 parole per Google e non oltre

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>).

Articoli correlati:

1. JSESSIONID: Cosa è e perchè compare nelle URL?
2. Come eliminare da Google le url indicizzate
3. JSESSIONID e SEO
4. Contenuti duplicati – identificazione

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!

Articoli correlati:

1. Come eliminare il JSESSIONID dalle url; pro e contro
2. JSESSIONID e SEO
3. Come eliminare da Google le url indicizzate
4. Contenuti duplicati – identificazione

“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à )

Articoli correlati:

1. Come eliminare da Google le url indicizzate
2. Come eliminare il JSESSIONID dalle url; pro e contro
3. JSESSIONID: Cosa è e perchè compare nelle URL?
4. URL rewrite