regole-seostrumenti seo per creare siti ottimizzati

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.

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

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

Identificare e difenderci dalla duplicazione dei contenuti volontaria e involontaria. [Parte 2 di 2]

Prima parte » Contenuti duplicati – identificazione

Nella prima parte di questo articolo dedicato ai contenuti duplicati abbiamo visto cosa si intende con contenuto duplicato e in quali casi i motori di ricerca identificano un contenuto come duplicato.

Restano da chiarire ancora alcune cose molto interessanti: in quali casi di contenuto duplicato subiamo o rischiamo di subire una penalizzazione? Agli occhi di Google i casi visti nella prima parte dell’articolo hanno la stessa probabilità di causare un danno all’indicizzazione? Come si può evitare il contenuto duplicato?

Come premessa, basandoci su quanto si dice nel Centro Webmaster di Google (CWG), possiamo dire che non sempre il contenuto duplicato è dannoso.
Nel caso di due pagine contenenti lo stesso contenuto, dice il CWG, Google tenderà a visualizzarne una sola.
Ok, ma allora qualcosa non torna… …le due frasi precedenti non sono in contraddizione?
La risposta è “no” o meglio “non sempre”. Infatti in alcuni casi l’indicizzazione di una sola url delle due (o N) contenenti contenuto duplicato non ci reca alcun danno.

Vediamo allora nel dettaglio cosa ci dice il CWG.

GOOGLE COME TRATTA IL CONTENUTO DUPLICATO?

Sul CWG ci viene detto che molto spesso i contenuti duplicati non vengono creati a scopi ingannevoli.
Come abbiamo visto in “Quando i motori di ricerca rilevano un contenuto duplicato?” nella prima parte di questo articolo, spesso è così.
Viene citato anche qualche esempio di duplicazione non considerata dannosa:

Nell’ottica di CWG questi casi di duplicazione non sono dannosi.
Google infatti indicizzerà soltanto una versione delle pagine contenenti i contenuti duplicati.

E’ proprio quest’ultima frase a mio giudizio la chiave di volta su cui concentrare la nostra attenzione.
E’ vero che in questi casi citati una versione della pagina viene comunque indicizzata, ma si tratta della versione che avremmo voluto vedere indicizzata?
E se Google trovando contenuti duplicati togliesse dall’indicizzazione la pagina che noi avremmo voluto indicizzare?

A mio avviso è sempre bene porre attenzione alla duplicazione dei contenuti usando le tecniche descritte tra poco, sia che Google ci dica che si tratta di un caso dannoso che di un caso non dannoso.
Solo in tal modo potremo essere certi di evitare cattive sorprese nell’indicizzazione e soprattutto di avere sempre la situazione sotto controllo.

Qualora Google invece, interpreti il contenuto duplicato come “caso dannoso”, ovvero una duplicazione creata al puro scopo di maggiore visibilità nei motori, allora l’indicizzazione dei nostri contenuti potrebbe subire repentine variazioni nella SERP.
A maggior ragione allora adottare le seguenti tecniche per aiutare Google a rilevare correttamente i contenuti duplicati è sicuramente un valido modo per evitarci cattive sorprese.

Concludendo ecco il consiglio di CWG:

COME SI PUO’ EVITARE IL CONTENUTO DUPLICATO?

Visto quali sono i casi di duplicazione del contenuto e come questi possono incidere negativamente sull’indicizzazione nei motori, non ci resta che capire quali sono le armi a nostra disposizione per poterci difendere nel modo corretto. Ecco dunque l’elenco delle tecniche utilizzabili:

• Escludere i contenuti duplicati tramite robots.txt o metatag “robots”
• Coerenza nella creazione dei link
• Canonicalizzazione: utilizzo del tag “canonical”
• Prestare attenzione alla pubblicazione e diffusione dei propri articoli su altri siti (Article syndication)
• Uso attento dei CMS (Content Management System) per la gestione dei contenuti
• Segnalare la violazione del Copyright a Google
• Sfruttare la sitemap del sito

• Escludere i contenuti duplicati tramite robots.txt o metatag “robots”
  Tramilte l’utlizzo del file robots.txt possiamo essere noi stessi ad evitare che le pagine con contenuti duplicati vengano indicizzate. Tramite il campo “Disallow” possiamo infatti indicare che una determinata pagina o determinati indirizzi che iniziano con uno specifico percorso non devono essere indicizzati.
  Ad esempio il seguente codice
  
  dice che nessuno spider deve indicizzare i contenuti il cui percorso inizia con “/articoli/mobile/” e la pagina “/articoli/miaPagina.html”
  Al seguente indirizzo http://www.robotstxt.org/orig.html è disponibile una breve ma completa guida all’esclusione degli spider tramite robots.txt.
  
  Nel caso non sia possibile modificare il file robots.txt possiamo ricorrere all’utilizzo del metatag “robots” all’interno delle pagine che non vogliamo vengano indicizzate.
  Ad esempio il seguente metatag:
  <meta name=”robots” content=”noindex”>
  dichiara che il contenuto della pagina non deve essere indicizzato da nessuno spider.

  All’indirizzo http://www.robotstxt.org/meta.html potrete trovare tutti i dettagli sull’utilizzo del metatag robots.
  
  L’uso del robots.txt è utile anche nel caso si faccia ricorso asiti miror. In questi casi infatti occorrerebbe inibire l’accesso dei motori ai siti mirror tramite una regola come la seguente:
  User-agent: *
  Disallow: /
  Inoltre, sarebbe opportuno inserire l’attributo rel=”nofollow” all’interno di eventuali link presenti sul sito principale diretti verso le pagine dei siti miror.

• Coerenza nella creazione dei link
  Nel caso di più versioni di url a pagine contenenti lo stesso contenuto (o alla stessa pagina) è bene essere coerenti nella creazione dei link. Sarebbe bene inserire sempre la stessa url nei link che portano a tali contenuti.
  Ad esempio, evitare di creare link a
  http://www.example.com/articolo/miaPagina/
  http://www.example.com/ articolo/miaPagina
  http://www.example.com/ articolo/miaPagina/index.htm
  http://www.example.com/ articolo?titolo=miaPagina

  Il problema della creazione dei link si ha anche nel caso di possesso di più domini (ad esempio www.mioSitoe.com e http://mioSitoe.com) che si riferiscono allo stesso sito.
  Tramite gli Strumenti per i Webmaster di Google è possibile indicare il modo in cui si desidera indicizzare il proprio sito comunicando il “dominio preferito”

• Canonicalizzazione: utilizzo del tag “canonical”
  Il tag canonical permette di comunicare allo spider del motore di ricerca quale delle url che puntano ad un contenuto duplicato deve essere indicizzata.
  L’utilizzo del tag canonical è utilissimo in entrambi i seguenti casi:
  - definire quale delle diverse url che puntano a una pagina deve essere quella da indicizzare
  - definire quale delle diverse pagine contenenti lo stesso contenuto deve essere indicizzata.
  Per utilizzare il tag canonical basta inserire nelle pagine il seguente tag all’interno della <head>:
  <link rel=”canonical” href=”http://www.example.com/ articolo/miaPagina” />
  dove “http://www.example.com/ articolo/miaPagina” è la url “preferita” che vogliamo sia indicizzata per i nostri contenuti.
• Prestare attenzione alla pubblicazione e diffusione dei propri articoli su altri siti (Article syndication)
  Poiché i motori potrebbero indicizzare l’articolo presente nella pagina non appartenente al sito dell’autore, innanzitutto è sempre opportuno accertarsi che chi pubblica un nostro articolo inserisca un link alla fonte originale.
  In secondo luogo è anche possibile fare richiesta a chi utilizza il nostro materiale di bloccare mediante robots.txt la versione presente sul loro sito.
• Uso attento dei CMS (Content Management System) per la gestione dei contenuti
  I CMS in circolazione utilizzati soprattutto per la creazione e gestione di Blog creano spesso url differenti le cui pagine possono riportare gli stessi contenuti.
  Faccio un esempio per tutti: io sono un accanito fan di Wordpress. Reputo che sia un ottimo strumento e grazie agli innumerevoli plugin è davvero difficile avere esigenze che non possano essere accontentate.
  Bene, pensate a quando pubblicate un nuovo articolo con Wordpress (ma il discorso vale anche per altri CMS). Il contenuto sarà visibile attraverso più di una url:
  - l’url dell’articolo
  - l’url a un qualsiasi tag associato all’articolo
  - l’url alla categoria cui appartiene l’articolo
  - l’url dell’archivio degli articoli
  
  Per evitare che vengano rilevati contenuti duplicati dovremmo fare una buona analisi delle url create e procedere poi all’utilizzo degli opportuni metatag o del file robots.txt per avere controllo di ciò che deve e non deve essere indicizzato.
  
  Fortunatamente nel caso di Wordpress esiste più di un plugin che può risparmiarvi un sacco di lavoro.
  Personalmente utilizzo il plugin “All in one SEO pack“. Tra gli strumenti SEO che offre questo preziosissimo plugin, troviamo diverse funzionalità che se attivate inseriscono in automatico e in modo efficiente i tag di noindex e di canonicalizzazione in modo che non si abbiano problemi di duplicazione di contenuti a causa delle diverse url generate di cui sono stati riportati precedentemente alcuni esempi.
  
  La documentazione completa di All in one SEO pack è disponibile a questo indirizzo:
  http://semperfiwebdesign.com/portfolio/wordpress/wordpress-plugins/all-in-one-seo-pack/
• Segnalare la violazione del Copyright a Google
  Come accennato nella prima parte dell’articolo, Google permette di segnalare eventuali violazioni di Copyright tramite il suo servizio di “Notifica di presunta violazione del copyright“. All’ indirizzo http://www.google.it/dmca.html trovate tutte le informazioni su come procedere.
  Sarà chiaramente Google a decidere se e quali provvedimenti prendere a riguardo.
• Sfruttare la sitemap del sito
  Comunicare le pagine del sito che vanno indicizzate ai motori di ricerca per mezzo per mezzo della sitemap. In un precedente articolo abbiamo visto come invare la sitemap ai principali motori di ricerca:
  - inviare sitemap a Yahoo!
  - inviare sitemap a Bing
  - inviare sitemap ad Ask
  - inviare sitemap a MSN
  - inviare sitemap a Google
  - inviare sitemap a Windows Live
  - inviare sitemap a Moreover

Dopo aver visto come Google considera i contenuti duplicati e applicando le precedenti regole potremo dormire sonni tranquilli per quanto riguarda la duplicazione dei contenuti nella maggior parte dei casi visti nella prima parte di questo articolo.

Anche per questa volta è tutto!

Prima parte » Contenuti duplicati – identificazione

Identificare e difenderci dalla duplicazione dei contenuti volontaria e involontaria. [Parte 1 di 2]

Seconda parte » Contenuti duplicati – come difendersi

In questo articolo, diviso in due parti, parlerò della duplicazione dei contenuti sul web per cercare di capire meglio cosa si intende realmente quando si parla di “contenuto duplicato“, quali casi di contenuto duplicato (volontario e involontario) si possono avere e come possiamo difenderci dalla duplicazione dei contenuti.

La prima cosa che viene da pensare parlando di “duplicazione dei contenuti” è la violazione del copyright.
Come vedremo però in molti casi potremmo essere noi stessi la causa della duplicazione dei nostri stessi contenuti.

Prima di procedere ecco un breve elenco dei punti che verranno trattati:

• Prima parte:
  • Che cos’ è un contenuto duplicato?
  • Quando i motori di ricerca rilevano un contenuto duplicato?
• Seconda parte:
  • Google come tratta il contenuto duplicato?
  • Come si può evitare il contenuto duplicato?

CHE COS’ E’ UN CONTENUTO DUPLICATO?

Con contenuto duplicato si intende la fruibilità di porzioni di contenuto identico o molto simile attraverso due url differenti, siano esse all’interno dello stesso dominio o meno.

Detto questo la prima cosa che viene da pensare è:
“Ok. Mi serve un modo per proteggermi da chi copia i contenuti dal mio sito per pubblicarli altrove“.
Certo, questo è importantissimo, ma quello che può sfuggire è che in parecchie circostanze a duplicare il nostro contenuto siamo noi stessi all’interno del nostro sito e la cosa ancora più bella è che ciò avviene anche se inseriamo il contenuto in una sola pagina.
La cosa interessa tutti i tipi di siti, grandi e piccoli e tutti i blog che nella maggior parte dei casi vengono creati tramite l’utilizzo di CMS.
Molto probabilmente tra i casi descritti di seguito troverete anche una situazione che vi sembrerà familiare .

QUANDO I MOTORI DI RICERCA RILEVANO UN CONTENUTO DUPLICATO?

In effetti i casi in cui un motore di ricerca può identificare del contenuto come duplicato (intenzionalmente o meno) sono davvero parecchi.
Tramite strumenti come Copyscape è possibile monitorare se una porzione di contenuto di una nostra pagina web è accessibile da più url differenti (interne o esterne al nostro dominio).
Vediamo allora i casi di duplicazione in cui potremmo imbatterci per poi descrivere, nella seconda parte dell’articolo, le tecniche per evitare la duplicazione dei contenuti.

• Violazione del CopyRight
• Pagine che prelevano il contenuto di un feed rss tramite uno script server side per mostrarlo in pagina
• Pagine contenenti descrizioni di prodotti
• Pagine per la stampa
• Contenuto unico accessibile da url differenti
• Tecniche di Behavioural Targeting attraverso session ID o altri parametri in “get”
• Domini e sottodomini
• Article syndication
• Siti mirror

• Violazione del CopyRight:
  Il furto del nostro contenuto originale è il caso meno interessante, ma anche quello più difficile da combattere in quanto per risolverlo non ci basta sfruttare una tecnica “on-page“.
  Google, come vedremo nella seconda parte di questo articolo permette la “Notifica di presunta violazione del copyright” da parte degli utenti in modo da prendere i giusti provvedimenti.
• Pagine che prelevano il contenuto di un feed rss tramite uno script server side per mostrarlo in pagina:
  Che si tratti di una violazione del copyright o meno, in tal caso avremo una duplicazione in quanto il contenuto prelevato da un feed esterno e mostrato in una pagina, molto probabilmente sarà mostrato anche sulle pagine del sito cui il feed originariamente appartiene.
  Tramite uno script server side che conduce un’operazione di questo tipo, il rischio di fare indicizzare contenuto duplicato è molto più alto rispetto a quello che si correrebbe tramite uno script client side (usando ad esempio javascript). In genere gli spider dei motori di ricerca non eseguono script client side pertanto in tal caso non vedrebbero il contenuto importato.
• Pagine contenenti descrizioni di prodotti:
  Quando più di un sito vende lo stesso prodotto, spesso viene usato lo stesso testo, recuperato dal sito del produttore, per descriverlo.
• Pagine per la stampa:
  Alcuni siti offrono lo stesso contenuto in una seconda pagina ottimizzata per la stampa. In questo caso i motori di ricerca indicizzerebbero anche la pagina ottimizzata per la stampa e ci ritroveremmo con due pagine con lo stesso contenuto indicizzate.
• Contenuto unico accessibile da url differenti:
  Anche se spesso è normale, quando si parla di indicizzazione, porre poca attenzione al dire la parola “url” al posto della parola “pagina”, ricordatevi sempre questo: i motori di ricerca indicizzano url e non pagine.
  Detto questo è possibile che nel vostro sito/blog esistano url diverse che portano alla stessa pagina oppure url diverse che portano a pagine diverse costruite dinamicamente lato server e che in certi casi possono contenere lo stesso contenuto.
  Pensate ad esempio ad un articolo da poco pubblicato in un blog. Il suo contenuto potrebbe essere indicizzato per le seguenti url:
  http://www.mioBlog.it/nuovoArticolo (effettiva url della pagina dell’articolo)
  http://www.mioBlog.it/ultimiArticoli (url della pagina contenente gli ultimi articoli pubblicati)
  http://www.mioBlog.it/tag/mioTag (url della pagina contenente gli articoli taggati con “mioTag” )
  http://www.mioBlog.it/category/miaCategoria (pagina contenente tutti gli articoli della categoria “miaCategoria” )
  Anche la presenza di parametri in un’url può causare lo stesso problema:
  http://www.mioSito.it?category=cucina
  http://www.mioSito.it?category=pasta
  potrebbero essere due url contenenti articoli tra i quali “Come cucinare la pasta al forno”.
  Insomma di esempi se ne potrebbero fare davvero tantissimi, ma sostanzialmente ciò che interessa è che se due url diverse portano a pagine che contengono porzioni di contenuto uguali o molto simili allora rischiamo che i motori di ricerca indicizzino url differenti per lo stesso contenuto.
• Tecniche di Behavioural Targeting attraverso session ID o altri parametri in “get”:
  Per molti siti è importante determinare il comportamento dell’utente (quali pagine visita, in quale ordine ecc…). In alcuni casi l’utente viene tracciato tramite id di sessione o tramite opportuni parametri che vengono appesi alla url effettiva della pagina.
  Se anche il crawler di un motore di ricerca viene trattato come un utente allora è possibile che vengano indicizzate url che differiscono solo per questi parametri e che puntano in realtà agli stessi contenuti.
• Domini e sottodomini:
  Per molte aziende è importante possedere più di un dominio o più di un sottodominio per incrementare la propria popolarità.
  La presenza di contenuti duplicati nelle pagine di questi domini/sottodomini può comportare la non indicizzazione di alcune delle url interessate proprio a causa del rilevamento di contenuti duplicati da parte dei motori di ricerca.
• Article syndication:
  Molte persone creano e pubblicano articoli e li offrono per la pubblicazione su altri siti a patto che venga inserito il link alla fonte ufficiale e che ne venga indicata l’attribuzione.
  Questa azione può essere sicuramente vantaggiosa in termini di link popularity ma va tenuto presente il rischio che i motori di ricerca eliminino dall’indicizzazione l’articolo originale e che mantengano l’indicizzazione di una copia.
• Siti mirror:
  Spesso per siti molto visitati viene utilizzata la tecnica dei siti mirror. Questo senza le dovute precauzioni può portare all’ indicizzazione di contenuti duplicati.

Abbiamo dunque esaminato la casistica delle situazioni che possono portare alla duplicazione dei nostri preziosi contenuti. Nella seconda e ultima parte di questo articolo vedremo come Google tratta il contenuto duplicato e quali tecniche esistono per difenderci dalla duplicazione dei contenuti in molti dei casi sopra citati.

Seconda parte » Contenuti duplicati – come difendersi

Copyscape è un web utility gratuita in grado di identificare se il contenuto di una pagina web è presente anche in altri documenti in rete.

Mentre nel prossimo articolo ci occuperemo delle tecniche da utilizzare per tutearci dalla duplicazione dei contenuti, Copyscape è un ottimo strumenti che ci permette di identificarli.

La duplicazione di un contenuto può avvenire all’interno dello stesso dominio o tra domini differenti e può essere volontaria o involontaria.
Spesso la duplicazione involontaria si ha quando esistono url differenti che conducono alla stessa pagina del nostro sito. Ad esempio il contenuto di un articolo del nostro blog potrebbe essere visibile sia accedendo alla url vera e propria dell’articolo (http://mioSito/blog/MioArticolo) che accedendo alla pagina degli ultimi articoli pubblicati (http://mioSito/blog/Ultimi10Articoli).

Una cosa è certa, come spiegato anche in questo documento
http://www.google.com/support/webmasters/bin/answer.py?hl=it&answer=66359
i contenuti duplicati possono incidere negativamente sul posizionamento nei motori di ricerca.

Copyscape è un ottimo strumento che ci aiuta a non cadere nella trappola dei contenuti duplicati involontariamente ma ci permette anche di scoprire se qualcuno ha duplicato il contenuto di una nostra pagina sul proprio sito.

Accedendo alla home page di Copyscape, tutto quello che occorre fare è inserire la url della pagina di cui ci interessa identificare eventuali copie di contenuto e premere il pulsante “Go”.
Copyscape si collegherà alla pagina, ne leggerà il contenuto e verificherà se tale contenuto si ripete da qualche altra parte sul web.

Sito: www.copyscape.com
Licenza: free
Lingua:
Tipologia: web