Nessun plugin seo.
Sto pensando seriamente di tradire joomla per wordpress
Per fortuna il problema non esiste su virtuemart, ho un ecommerce posizionato benissimo su centinaia di articoli, se google avesse comiciato ad indicizzare in maniera pazzoide anche quello sarebbero stati problemi seri

Aspetta, però.
Il problema non è Joomla ma sempre la configurazione.
Devo prima capire quando e perché quelle url non portano a 404 e se ciò sia corretto, altrimenti rischio di scrivere sciocchezze.
Una volta analizzata la situazione si corregge la configurazione, ad esempio con rel=canonical o redirect 301 dove servono.

A proposito, in questo caso potrebbe tornare utile: avete una lista di plugin Joomla per il rel=canonical da testare? Grazie!

Francesco

Ciao FDA, hai un'installazione Joomla su cui verificare?
Prova, lo stesso problema lo hai con qualsiasi sito joomla.
Anche su installazioni base, senza url sef, indipendentemente dall'host, dall'htaccess, con qualsiasi versione (1.5, 2.5, 3.3)
E' assurdo che joomla abbia un problema così serio e che la comunità non sia intervenuta.

Proviamo su un'installazione vergine di Joomla 2.5 e poi 3.3, ma ripeto che la questione è la configurazione ottima.
Non fasciamoci la testa prima di cadere.
Anche WordPress ha problemi, la differenza è che alcuni vengono risolti da Yoast.

"Indipendentemente dal htaccess e da tutto il resto" è un'affermazione corretta fino a quando non interveniamo "nell'htaccess e in tutto il resto".

Con "Indipendentemente dal htaccess e da tutto il resto" intendo che ho provato anche eliminando il .htaccess e le impostazioni seo joomla con installazione vergine su server pulito.
In questo caso l'unica differenza è che l'url pazzo si genera dopo index.php
altraweb .it / index.php/39scriviquellochevuoi .html

@altraimmagine said:

Probabilmente mi sono spiegato male:
per FDA:
so bene come gestire l'url, quando hai controllato stavo facendo prove con l'htaccess e disabilitando "Riscrivi URL SEF" e "Suffisso URL"
Allora...

Ho una pagina che descrive la mia agenzia:
altraweb .it/altraweb/l-agenzia .html
Questo articolo su joomla ha id 39

Se io sul browser provo a scrivere url "immaginari" con il numero 39 come questi:
altraweb .it /39pippo .html
altraweb .it /39ciaoatutti .html
O inventare directory
altraweb .it /pippo/39 .html
Joomla mi visualizza sempre la pagina dell'agenzia.

Questo non accade nel mio sito ma su tutti i siti joomla!!!

Ora Google sta indicizzando centinaia di pagine inesistenti, che naturalmente risultano duplicati!!!
Lo stesso problema ce l'ha joomla 3.3

Questo è un bug vero e riscontrato in altre occasioni, personalmente non ho mai dovuto combattere con questo problema ma è anche vero che io normalmente installo componenti SEF (e probabilmente è la soluzione).

Però se non c'è qualcuno che ti sta attaccando di proposito non vedo come sia possibile che tu abbia diverse centinaia di duplicati, per la verifica che ho fatto io hai 150 pagine indicizzate su Google e tra queste non visto pagine che mi facciano pensare al problema che sottolinei (se pure effettivamente esiste). Per quella che è la mia esperienza google è in grado di scindere i duplicati generati dal CMS e a meno che non siano davvero centinaia non ti penalizza, sicuramente non in maniera seria.

è giusto tu voglia risolvere il bug ma non pensare che questa sia la vera/unica causa del declassamento che dici di aver subito.

Maurizio ZioPal

Il problema è probabilmente dovuto al fatto che ho lasciato semivisibile il sito durante un mese di prove e Google ci ha dato dentro con l'indicizzazione.
Quale componente SEF mi consigli?

io normalmente uso artio JoomSEF che ha anche una versione gratuita, alrimenti sh404SEF

Maurizio ZioPal

Il comportamento è dovuto al meccanismo di routing di Joomla.

Prendi queste tre url riferite allo stesso articolo con id=39:

1. http:// altraweb.it/altraweb/l-agenzia.html
2. http:// altraweb.it/altraweb/39
3. http:// altraweb.it/39

La 1) è generata da un menu ed ha in comune con la 2) il segmento /altraweb/ , cosa che non ha la 3).

Il segmento /altraweb/ è il primo dopo la base http:// altraweb.it ed è relativo proprio al menu. Il fatto che 1) e 2) condividano questo segmento fa sì che abbiano praticamente la stessa vista.
Le pagine 1) e 2) differiscono infatti per pochissimi dettagli e tutti modificabili (si tratta delle article options e metadata options, definite una volta da voce di menu e l'altra dall'articolo).

La pagina 3) è diversa perché non condivide con le altre due il segmento relativo al menu, che è quello della ... homepage! E infatti dalla home page prende gli altri elementi. Se guardi nel codice ti accorgi anche che alcuni elementi dell'head di 2) e 3) sono uguali, questo perché le options di cui sopra sono in entrambi i casi quelle dell'articolo e non quelle della voce di menu, che "serve" solo la 1).

Ogni componente deve fare i conti con il routing e infatti ha il suo bel file router.php piazzato nella propria root. La notizia buona è che c'è sempre la possibilità di modificare il meccanismo di routing per i componenti ed è di fatto quello che fanno i produttori di estensioni. Quando malediciamo un componente che crea url brutte in verità ce la prendiamo con il suo routing, o meglio, con il fatto che un nostro eventuale componente SEO/SEF non sia in grado di "aggiustare" le url.

E vengo alle 3 url prodotte inserendo un numero a caso. Anzi, voglio esagerare e ne aggiungo altre due:
4) http:// altraweb.it/39blabla
5) http:// altraweb.it/tizio/39caio

4. e 5) si comportano come la 3), in pratica è "la stessa pagina".

Joomla non ragiona male, non è impazzito. Quando gli diamo un url cerca di capire a quale contenuto si riferisca. Non tira a indovinare ma segue la logica di routing secondo un meccanismo che prevede la connessione al db per verificare se il contenuto è presente.

Nel caso delle nostre 5 url la prima cosa che verifica è la presenza del menu item, che si trova nel primo segmento. Dopo passa al resto, che significa categorie e articoli. Quando incontra un numero all'inizio di un segmento, Joomla si chiede se non sia l'id di un articolo: così va a verificare se l'articolo si trova in db e quale sia la sua categoria.

Quando scrivo "all'inizio di un segmento" intendo ad esempio dire che, se in:
http:// altraweb.it/tizio/39caio
inverti "39" con "caio":
http:// altraweb.it/tizio/caio39
allora ottieni un 404, perché all'inizio del segmento Joomla trova la stringa "caio" e non un numero da cercare nel campo id degli articoli.

Premesso che nulla vieta come detto di installare componenti SEO/SEF che modifichino il meccanismo di routing, secondo me Joomla non sbaglia affatto.
Se il mio articolo ha url:
http:// altraweb.it/altraweb/39-l-agenzia.html
ci sta che se un utente digiti:
http:// altraweb.it/altraweb/39
il sito web risponda con l'articolo con id=39, che tra tutte le cose che l'utente potrebbe avere cercato è la più probabile.

Dalla documentazione ufficiale di Joomla:
"How can I get rid of the numbers in the SEF URLs?

The numbers in the SEF URL are needed by Joomla!'s router to know how to direct site traffic. Once the router logic stabilizes, simple third party system plugins can be developed to augment the router capabilities by allowing more choice. At that time, numbers will likely be removed from the URL."

A mio parere Google riconosce queste pagine e non le indicizza, prova è che non sono indicizzate non soltanto per *altraweb *ma neppure per altri siti (ma possono essere indicizzate). Che poi si possa migliorare la situazione non v'è dubbio, sta ai SEO stabilire se con redirect 301 oppure con rel=canonical correttamente implementati verso gli articoli originari.

Ci possono essere delle eccezioni (es. stessi articoli con più viste, eventualmente accessibili solo per utenti con privilegi e/o non indicizzate per scelta) e poi la vista è separata dal dato.

A questo punto **chiedo **agli utenti del ForumGT: come andrebbero trattate queste url per soddisfare le esigenze dei vostri siti? Inserireste redirect 301 all'articolo (quello del menu?), il rel=canonical (a quale url?) o fareste altro?

Francesco
(Salvo sviste da paura, che è notte fonda. )

Grande Francesco,
che disamina accurata personalmente credo nel redirect 301, definitivo e quindi, il più corretto in caso di duplicati. Credo anche che forse in questi casi sia più corretto il rel canonical perché più flessibile e perché a differenza del 301 mi permette di mostrare anche la pagina "duplicata" qualora le differenze fossero minime e fosse comunqeu interessante mostrarle, tipo un contenuto mostrato in un contesto diverso o il classico caso dell'ordinamento di un elenco.

Comunque ancora un bravo a Francesco, vediamo se smuoviamo qualcuno a commentare.

Maurizio ZioPal

Grazie Maurizio e grazie a *altraimmagine *che mi ha "costretto" (si fa per dire) a documentarmi.

@Maurizio Zio Pal: dicevi meglio il rel=canonical, ma come faccio a determinare la pagina a cui puntare? Potremmo dire: quella del menu, ok ... e se nel menu ci sono più voci che si rifanno ad esempio ad uno stesso id articolo? La soluzione potrebbe essere scandagliare prima il menu per vedere se è presente una voce per quell'articolo? Credi che un plugin dovrebbe fare "tutto da solo" oppure consentire all'utente di fare scelte in base all'url dal pannello di back end?

Non ho ancora capito esattamente come fare per "selezionare" l'url canonico, vorrei anche vedere almeno un plugin open source che lo implementa bene. *Metagenerator *se non sbaglio risolve soltanto il com_content (ma è già tanto).

@altraimagine: la index.php negli url usciva non per errata configurazione ma perché non era attivato il mod_rewrite di Apache, poi devi averlo riattivato perché ieri sul tardi era già tutto a posto.

Francesco

@FDA si direi quella del menu.

Per chi trovasse la discussione interessante ci sono sviluppi anche su google plus.
*
Maurizio ZioPal*

Ho studiato la cosa e ho scoperto un po' di cose interessanti.

Partiamo da MetaGenerator, plugin SEO per Joomla 2.5
MetaGenerator implementa bene il rel=canonical sulle url del com_content, ma fa cilecca su queste:

demo.com/35

per il quale il route di Joomla riconosce l'articolo con id=35 e "lo inserisce nella Home"; MetaGenerator ci piazza un bel rel=canonical alla Home, questa sì una pazzia!

Rel canonical con Joomla 2.5 e MetaGenerator
Nella demo di un'installazione base di Joomla 2.5.20 l'articolo con id=35 ha questo URL SEF:

http://demo.com/using-joomla/extensions/components/content-component/article-category-list/35-professionals

Per questo url e per tutti quelli che seguono:

http://demo.com/using-joomla/extensions/components/content-component/35
http://demo.com/using-joomla/extensions/components/35blabla
http://demo.com/using-joomla/blabla/35

il link con rel=canonical inserito da MetaGenerator è sempre lo stesso:

<link href="http://demo.com/using-joomla/extensions/components/content-component/article-category-list/35-professionals" rel="canonical" />

Come detto sopra, MetaGenerator sbaglia invece per:

http://demo.com/35

e infatti ci mette questo:

<link href="http://demo.com" rel="canonical" />

che è ovviamente sbagliato, in quanto in demo.com/35 c'è l'articolo con id=35 e non certo il contenuto della Homepage.

Perché MetaGenerator sbaglia?
Io credo che lo sviluppatore abbia male interpretato la documentazione di Joomla!

Come determinare se l'utente visualizza la Homepage secondo la documentazione di Joomla
In docs . jooma. org c'è un articolo dal titolo "How to determine if the user is viewing the front page" con istruzioni aggiornate al 29 aprile 2013 valide per 1.0, 1.5, 2.5, 3.

Per Joomla 2.5 e 3 la documentazione prevede questo codice:

<?php
$app = JFactory::getApplication();
$menu = $app->getMenu();
$lang = JFactory::getLanguage();
if ($menu->getActive() == $menu->getDefault($lang->getTag())) {
        echo 'This is the front page';
}
else {
        echo 'Accueil';
}
?>

In pratica, la documentazione suggerisce di fare un confronto tra il menu attivo e quello di default: se coincidono allora l'utente è "sulla vista della Home", che non significa che si trovi in Homepage. Eppure la traduzione non è molto chiara, potrebbe anche significare: "Come determinare se l'utente sta visualizzando la Homepage".

La funzione isFrontPage di MetaGenerator
Lo sviluppatore di MetaGenerator ha preso sul serio la documentazione ed ha inserito una funzione nel codice del suo plugin:

function isFrontPage()
    {
       $app = JFactory::getApplication();
        $menu = $app->getMenu();
       $lang = JFactory::getLanguage();
       if ($menu->getActive() == $menu->getDefault($lang->getTag())) {
             return true;
        }
       return false;
    }

Evidentemente voleva individuare la Homepage e solo quella, ma non è andata così.
Comunque, prima di aggiungere la riga del link rel canonical all'head della pagina, ha aggiunto questa porzione di codice per trattare la Homepage:

if ($this->isFrontPage() && $usecanonical==0) {
       if($start!=''){
              $ucanonical = $sitedomain.JRoute::_('index.php').$start;
       } else {
              $ucanonical = $sitedomain;
       }
}

Andrebbe tutto bene se soltanto la funzione isFrontPage non restituisse true anche sulle url come demo.com/35

La variabile $ucanonical contiene infatti l'url da inserire nel link rel canonical, e quando isFrontPage restituisce true questa url è pari a $sitedomain ... un bel guaio:

if(isset($ucanonical) && $ucanonical!='')$document->addHeadLink( $ucanonical, 'canonical', 'rel', '' );

Come eliminare il falso rel canonical
Non possiamo stampare il rel canonical alla Home quando il contenuto è quello di un articolo, e questo soltanto perché la voce menu è quella di default.
Racchiudiamo allora l'istruzione di stampa del rel canonical in una If:

if (!(($this->isFrontPage()) && ($view=='article'))) {
      if(isset($ucanonical) && $ucanonical!='')$document->addHeadLink( $ucanonical, 'canonical', 'rel', '' );
}

Conclusioni
Non abbiamo risolto il problema completamente, poiché le url come demo.com/35 non hanno rel canonical che punta all'url "migliore" ... ma qual è l'url migliore?
Il problema è che l'articolo con id=35 potrebbe essere associato a più voci di menu: chi può stabilire quale sia l'url canonica?
Il mio parere è che il componente SEO/SEF (non può farlo un plugin) dovrebbe estendere le metadata options degli articoli per trattare situazioni di questo tipo, consentendo di inserire a mano un url canonica, eventualmente suggerita dal componente stesso "scandagliando" i menu.

Tutto questo in attesa di altri test, anche su Joomla 3.

Cosa ne pensate?

Francesco

Grandissimo complimenti, la cosa che non capisco è perchè non viene gestito con la pagina di errore 404, dopo tutto la pagina non esiste e quindi non capisco perchè se io cambio qualcosa nell'url la pagina viene caricata correttamente e viene messo il canonical.
Secondo me dovrebbero gestirla con il 404, ho anche scritto nel forum di Joomla.org ma praticamente nessuno ha risposto e mi ha dato una giustificazione.

Ciao Stefano,
secondo me ci sono due questioni: da una parte la separazione che c'è tra i dati e la loro presentazione, tipica del pattern MVC (Model-View-Controller); dall'altra il sistema di routing di Joomla.

Questa pagina in verità esiste:

http://demo.com/35

Maurizio parlava di rel canonical, tu invece sei per il 404?
Penso che il 404 si possa fornire in risposta con una modifica a MetaGenerator, ma il rischio è che si perdano alcune pagine in cui il rel canonical andrebbe bene.

Faccio una prova. Fatemi sapere se ci sono tipologie di url che vorreste trattare in un modo invece che in un altro (rel canonical, noindex, 404).

Francesco

Poi magari mi sbaglio ma se l'url corretto è:
www.miosito.it/verdura/patate-americane.html
e uno per un motivo strano mette www.miosito.it/verdura/patate-american.html
quella pagina non esiste e quindi la solzuione migliore dovrebbe essere la 404, il canonical andfrebbe usato in altri casi, tipo in un ordinamento dei prezzi in un e-commerce..... IMHO

Sono d'accordo con Riga. Secondo me se l'URL della pagina non esiste deve tornare 404.

Nel caso indicato da te Joomla fornisce il 404, perché non riesce a individuare l'articolo dal momento che ha a disposizione un alias diverso (nulla vieta che due alias differiscano per un unico carattere).

Gli URLs di cui parlavamo sopra, invece, hanno la seguente particolarità: presentano un numero all'inizio di un segmento, come questi:

http://miosito.it/verdura/43-patata
http://miosito.it/verdura/43americana
http://miosito.it/verdura/patata/43

Per tutti questi il sistema di routing identifica l'articolo con id=43, che potrebbe essere ad esempio quello delle patate americane, cioè quello che dovrebbe avere come canonica:

http://miosito.it/verdura/patate-americane

Non ho messo "html" alla fine per non creare una complicazione che gestisce comunque con il rewrite.

Il sistema di routing invece non identifica l'articolo con id=43 per queste URLs:

http://miosito.it/verdure/patate-american
http://miosito.it/verdire/patate43

In pratica l'identificazione dell'articolo tramite id avviene soltanto se il numero è all'inizio di un segmento dell'url, cioè dopo uno slash.

Maurizio Zio Pal parlava di rel canonical come soluzione preferibile: per alcuni casi io concordo, perché il contenuto principale è sempre lo stesso, ma ho anche dubbi per quei casi in cui il contenuto "non principale" pesa molto rispetto all'intero contenuto.

Bel dubbio.

@Juanin: intendi il 404 per tutte?

Mi aiutate per piacere a capire come devo rispondere per i diversi gruppi di URLs? Intendo 404, rel canonical, redirect o noindex.

Primo gruppo
In pratica queste tre pagine sono identiche:

http://miosito.it/verdure/patata-americana
http://miosito.it/verdure/43patata
http://miosito.it/verdure/43

perché l'articolo con id=43 è "immerso" nella vista generata dal medesimo menu, che è definito a partire dal segmento ../verdure/ .
Per il primo gruppo sopra mettereste 404 a tutte tranne la prima (che è l'"originale")? Oppure?

Secondo gruppo

http://miosito.it/verdure/blabla/43
http://miosito.it/verdure/blabla/43patata

Queste pagine sono identiche a quelle del primo gruppo se il segmento /blabla/ non definisce nulla, cioè se non è relativo a un menu esistente.
Per il secondo gruppo sopra mettereste 404? Oppure?

Terzo gruppo
Solo per questo esempio del terzo gruppo facciamo l'potesi che ci sia una categorizzazione su più livelli e che quindi la url "originale" sia miosito . it/verdure/patate/americana , cioè abbiamo un sottomenu legato alla sottocategoria "patate".

http://miosito.it/verdure/43
http://miosito.it/verdure/ciakciak/43americana

In pratica qui Joomla fornisce pagine molto simili, il più delle volte uguali (ma non è detto, dipende dai menu), e continua ad associare l'articolo con id=43 alla vista definita dal menu con segmento /verdure/ , eventualmente ignorando quel falso /ciakciak/ (che non esiste, come negli esempi del secondo gruppo non esisteva /blabla/ ... ribadisco però che le pagine sono nella maggiore parte dei casi identiche, e tuttavia queste ottenute inserendo segmenti che non esistono io le tratterei con 404).

Per il terzo gruppo sopra mettereste 404? Oppure?

Quarto gruppo

http://miosito.com/43
http://miosito.com/frutta/43

Questo URL è fastidioso perché il segmento di riferimento è quello che fa capo alla homepage, cioè il menu di default, e sono gli URLs per i quali MetaGenerator fornisce come rel canonical la Home nonostante il contenuto principale della pagina sia quello dell'articolo con id=43.

Per il quarto gruppo sopra mettereste 404? Oppure?

Attendo i vostri suggerimenti e grazie a tutti.
Francesco

Non conosco Joomla, ma se ad un URL corrisponde un ID univoco allora ha senso usare il canonical altrimenti no.

Insomma il discorso è questo:

Se american-patate ha id 43 e lo ha generato l'utente
e
american-pat non ha id allora american-pat va 404.

Se american-pat ha id perché la pagina è generata dall'utente e con lo stesso id 43 allora il canonical è corretto.

Se american-pat ha id 43 perché lo genera automaticamente Joomla creando alias ad cazzum secondo me non è corretto il canonical

Se ovviamente sono limitazioni di Joomla il canonical non fa male però va considerato che poi diventa più difficile per il webmaster leggere i log e i vari errori se tutte le pagine tornano un 200.
Magari il motore riesce a districarsi grazie ai canonical, ma il webmaster farà più fatica a scovare pagine linkate male e errori di altra natura.

Delle due se proprio Joomla non ce la fa quelli che dovrebbero essere errori autogenerati da Joomla li gestirei con 301 piuttosto che con canonical in modo che il webmaster possa comprendere che c'è un'anomalia.