Ciao RomeoBlu,
che google faccia quello che gli pare è arcinoto, ma è sicuro che difficilmente mette in SERP duplicati dallo stesso sito, quindi per lui le pagine rilevanti del tuo sito sono quelle. Dovresti gestirle con il Rel canonical.
*
Maurizio ZioPal*

c'è un plugin per inserirlo o si può fare da sistema?

Ciao RomeoBlu.
Quoto Dexter al 101%!

Puoi trovare qualche buona dritta in questa Guida SEO Joomla, incluse estensioni per il rel=canonical:
giorgiotave.it/guide-webmaster/guida-seo-joomla/

Gli interventi di RomeoBlu e Dexter mi hanno stuzzicato.
In tema di contenuti duplicati, mi sovviene una domanda che giro a tutti gli utilizzatori di Joomla e a chi si occupa di SEO:
volendo costruire un plugin per Joomla! 2.5 che inserisca il rel=canonical dove opportuno, quali sono le condizioni e le opzioni da considerare per il suo inserimento?

Sappiamo che la pagina canonica di un url:
sito. com/categoria/articolo?parametro=valore
è:
sito. com/categoria/articolo

Se è attiva la riscrittura URL SEF non dovrebbero esserci url di questo tipo (esempio di un articolo):
sito. com/index . php?option=com_content&view=category&layout=blog&id=7&Itemid=109

Anche con la riscrittura, tuttavia, sono potenzialmente infinite le pagine con contenuto duplicato, senza considerare che ci sono componenti che potrebbero crearne altre. Ad esempio la versione stampabile di una pagina ha un url come questo:
sito. com/categoria/alias?tmpl=component&print=1&layout=default&page=

Ciò detto, ho pensato di procedere così:

• per ogni url che include ?parametro=valore e non include com_content -> inserisco nell'head il rel=canonical con href alla parte dell'url prima del punto interrogativo (es. a sito. com/categoria/articolo);
• per ogni url che include com_content -> inserisco nell'head un meta robots noindex, follow.

Il mio ragionamento è corretto?
Esistono eccezioni che non ho considerato?
Inserireste la possibilità di escludere alcune pagine e se sì quali?
Senza dovere realizzare una complicatissima estensione SEO/SEF (ce ne sono di ottime e non è il mio intento), inserireste opzioni per trattare a dovere la paginazione (che in Joomla si presenta nella visualizzazione blog con *?start=numeroarticolo *in coda all'url)?

Grazie a tutti quanti parteciperanno con suggerimenti e osservazioni.

Francesco

Personalmente, per due anni circa, ho lavorato su Joomla ed effettivamente sul CMS ho notato che la gestione degli URL SEF poteva essere migliorata. Ora è un po' che non lo tratto, ma da quello che vedo scritto qui è rimasto un problema. Per carità lungi da me fare critiche, anzi si deve solo ringraziare la community che fa un grosso lavoro, ma la considerazione che fa FDA è corretta. Non capisco perché non si migliori un aspetto così essenziale come le URL duplicate inserendo URL canonical da codice, invece di dover utilizzare componenti esterni. Io non sono ancora in grado di poter modificare il core in quel modo, ma concettualmente credo che la soluzione di FDA sia applicabile.

Ciao Giorgio Sanna.
Per la verità anche la soluzione da codice nasconde insidie, soprattutto per gli aggiornamenti e la manutenibilità.
Fortunatamente l'attuale Joomla 3.2 (e poi la 3.5 che verrà di lungo periodo) gestiscono i rel =canonical già nel core.
Continua a seguirci, spero che avremo modo di approfondire l'argomento.

Proverò le nuove versioni in locale magari così mi renderò conto delle novità. Grazie.

Comunque non credo che avere i rel canonical sia la stessa cosa di avere una sola versione, pulita, di ogni pagina del sito con un solo indirizzo. Con wordpress tutto questo non esiste, il tutto è gestito bene e in maniera più che semeplice. Credo che sia abbastanza ridicolo che si sia arrivati quasi al 2014 senza aver risolto questo problema su una piattaforma così diffusa....

Ciao RomeoBlu.
Sicuramente Joomla ha creato in passato qualche malumore per i tanti URL creati e la difficoltà nel gestirli, ma la 2.5 si comporta abbastanza bene.
Considera che i "tanti URL" di cui parliamo sono di tipi differenti e alcuni sono utili mentre altri sarebbero inevitabili su qualunque altro sito.
In pratica non sempre abbiamo più URL perché la versione è "sporca", mentre qualche volta la versione è "sporcata" con URL sbagliate per cattiva configurazione /manutenzione / gestione. Però si può intervenire e migliorare le cose.:)

Esempio: url utile.
Un componente che genera una vista/un layout particolare per quella che in alternativa è la classica visualizzazione blog (ad esempio visualizza tutti gli articoli in una griglia "infinita"), ha un URL diverso e questo è normale. Ciò che conta è inserire il rel = canonical sia in questa pagina che in quella che visualizza la classica categoria come blog.

Esempio: url inevitabile 1.
La gestione dei contenuti duplicati non è semplice. Pensa alle landing page: spesso presentano le stesse informazioni di altre pagine ma in maniera differente, in modo da massimizzare le conversioni con riferimento a una singola campagna/target. Queste pagine in molti casi non sono raggiungibili dal sito tramite link pubblico e non vengono indicizzate.

Esempio: url inevitabile 2.
La versione stampabile dell'articolo è un esempio di contenuto duplicato da non indicizzare (Joomla 2.5 inserisce il noindex).

Esempio: url inevitabile 3.
Tutti gli URL friendly possono divenire query e potenzialmente contenuti duplicati, basta aggiungere alla fine ?parametro=valore. Queste query sono in numero illimitato. Il vero limite di Joomla versioni 2.5.x e precedenti è non presentare già nel core la gestione del rel=canonical, problema che pare non si presenterà nella 3.5 (staremo a vedere).

Ricordo infine che alcuni blogger risolvono taluni problemi di WordPress con plugin come Yoast.
Come si diceva qui - giorgiotave.it/forum/joomla/214429-perche-passare-da-wordpress-joomla.html - la grande diffusione di WordPress tra i blogger ha indotto molti sviluppatori a produrre plugin che semplificassero la vita a persone che di mestiere non fanno i programmatori/webmaster.
Ma per fortuna anche Joomla ha tante estensioni e forse alcune potenzialità diverse.

Ciao FDA,
avevo perso metà discussione e avevo letto male un punto chiave della precedente non male.

@FDA said:

Ciò detto, ho pensato di procedere così:

• per ogni url che include ?parametro=valore e non include com_content -> inserisco nell'head il rel=canonical con href alla parte dell'url prima del punto interrogativo (es. a sito. com/categoria/articolo);
• per ogni url che include com_content -> inserisco nell'head un meta robots noindex, follow.

Credo sia giusto, per un attimo avevo pensato che volessi aggiungere il NoIndex alle pagine dove avevi inserito il canonical, cosa che la settimana scorsa al convegno GT Enrico Altavilla ha marcato come pericolosa. Se ti posso suggerire come confronto/ispirazione l'unico componente che secondo me ha risolto il problema Metageneretor, purtroppo per stessa ammissione dello sviluppatore funziona solo con il core di joomla.

Una piccola risposta la devo anche a RomeoBlu
@RomeoBlu said:

Comunque non credo che avere i rel canonical sia la stessa cosa di avere una sola versione, pulita, di ogni pagina del sito con un solo indirizzo. Con wordpress tutto questo non esiste, il tutto è gestito bene e in maniera più che semplice. Credo che sia abbastanza ridicolo che si sia arrivati quasi al 2014 senza aver risolto questo problema su una piattaforma così diffusa....

Magari io sono un po' di parte, però trovo un po' ridicolo che ci sia sempre qualcuno pronto a dire che la SEO con WP è meglio.

Wordpress risolve il problema dei duplicati con il Rel Canonical e con componenti SEO tipo Yoast. Se ti fai un giro su questo forum nella sezione penalizzazioni scopri che una delle penalizzazioni più diffusa in assoluto è quella data dai tag di Wordpress che per anni non sono stati in grado di risolvere. Il problema è che molti improvvisano, e su Wordpress questo si sembra più facile, salvo trovarsi nei casini quando si fa sul serio.

Maurizio ZioPal

Ciao Dexter.
Purtroppo ero assente al Convegno GT, ma ci sarà occasione di rifarmi.

Dovrei essere a posto sulla questione di noindex e canonical, ma adesso che mi ci hai fatto pensare l'annoto e domani controllo tutto per sicurezza.
Tra l'altro l'indicazione è doppiamente utile, perché forse l'utente che sceglie un'opzione diversa dovrebbe quanto meno ricevere un avviso da backend.

MetaGenerator lo reinstallo, perché non ricordo come lavora (e per fortuna è pure GPL).

Francesco

Dexter, una cosa non mi è chiara:
Ipotizziamo che sia index la url: tuosito.com/categoria/articolo

Una qualsiasi url come tuosito.com/categoria/articolo?idqualcosa=quellochevuoi è contenuto duplicato. Ci faccio stampare di default noindex senza rel canonical all'altra?

@FDA said:

Ipotizziamo che sia index la url: tuosito.com/categoria/articolo

Una qualsiasi url come tuosito.com/categoria/articolo?idqualcosa=quellochevuoi è contenuto duplicato. Ci faccio stampare di default noindex senza rel canonical all'altra?

Si, anche se sempre nello stesso intervento Enrico Altavilla (che il signore ce lo conservi), diceva che oggi google non ha nessuna difficoltà a comprendere la natura del duplicato e quindi situazioni come quella che hai ipotizzato non dovrebbero essere più tanto penalizzanti, anzi sembrerebbe che google chieda di lasciargli indicizzare più pagine possibili, quindi meglio il canonical al NoIndex.

Maurizio ZioPal

il problema dei duplicati su Wordpress non esiste e da quando lo uso non è mai esistito; per mettere a no index le pagine categoria e tag lo si fa con un click
nessuno mi paga per preferire wordpress, e dire che sulla seo WP è MOLTO più avanti non è ridicolo, è semplicemente un dato di fatto. anzi un FATTO.
non ho mai avuto problemi di penalizzazioni con WP, una cosa è che uno non lo sa usare, un'altra cosa sono i LIMITI STRUTTURALI, per cui un punto vista veramente costruttivo non è quello di difendere l'indifendibile secondo me, ma di trovare delle soluzioni che permettano agli sviluppatori di lavorare in maniera agevole e fluida. Ed è per questo motivo che ho aperto questo thread, per trovare delle soluzioni semplici.

Ciao RomeoBlu.
Sulla questione WordPress - Joomla - limiti strutturali lascio a Dexter l'eventuale replica perché vedo che è un argomento che fa discutere e argomentare.

Per la discussione aperta ti ringrazio, hai dato un input davvero utile. Spesso i webmaster / sviluppatori tendono a risolvere i problemi come possono, anche con soluzioni fai da te, senza però realizzare qualcosa di standard, ovvero che risponda a precise specifiche ed esigenze e che sia affidabile e riproducibile, come ad esempio può essere un'estensione facile da usare.
La tua discussione da questo punto di vista è uno sprone per noi tutti. Ne discutiamo nel Forum GT e speriamo di trovare presto la soluzione semplice di cui giustamente parli.
Segui ancora questa discussione e anzi invito tutti gli utenti a postare i propri contributi, perché sono preziosissimi i problemi evidenziati dagli utilizzatori del cms.

Joomla ha grandi potenzialità.

Francesco

Ciao RomeoBlu,
non devo difendere nulla non c'è nessun bisogno, noto semplicemente che ogni volta trovo qualcuno pronto a far presente che la SEO su WP è più facile, e io penso sempre ma perché WP scrive da solo buoni contenti? Fa link building da solo? La montagna di template gratuiti che installano su WP sono ottimizzati SEO meglio di quelli di Joomla? I webmaster e i SEO improvvisati di WP sono meno improvvisati di quelli di Joomla?

Alla fine la risposta è sempre la stessa: Se devi fare un vero progetto SEO il CMS non conta, conta il SEO, se non devi fare un progetto SEO WP ti aiuta, non è chiaro a far cosa visto che non hai un progetto SEO.

Un punto di vista costruttivo è, come faccio a fare questa cosa con questo CMS che non conosco bene? E no: questo CMS è ridicolo perché con quest'altro il problema non esiste (ed esiste).

Un approccio costruttivo è quello di FDA che ha pensato una soluzione e cerca d'implementarla per risolvere il problema anche a te.

Maurizio ZioPal

E' OVVIO che il CMS non fa tutte le azioni SEO da solo, ma è altrettanto OVVIO che un CMS può metterti i bastoni tra le ruote come in questo caso.
E tutto il resto non c'entra nulla. Stiamo parlando di un aspetto SEO molto importante non risolto = un ostacolo = un limite.

IL CMS conta e come. E deve essere il CMS che si mette a tua disposizione, non il contrario. Io non ho detto che è tutto ridicolo, ho detto che è ridicolo che stiamo ancora parlando di questo problema dopo che la SEO esiste non so da quanti anni. RISCRITTURA implica la sostituzione degli url, non la PROLIFERAZIONE.

Poi le ore impiegate per risolvere il problema sotto che voce gliele fatturi al cliente? Sotto la voce "hai un sistema che genera, non si capisce perchè, N versione di ogni pagina e ho impiegato 20 ore per risolverlo?"

Forza..siamo più pragmatici, perchè se facciamo finta che i limiti non esistano, poi succede che nel 2014 il problema persiste, perchè lavorare per correggerlo equivale ad ammettere la sua esistenza e la sua importanza....e mi sa che esiste ancora proprio per questo fenomeno qui, spero che non bisogni costituire un comitato scientifico per trovare una soluzione a questo punto....