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.

Grazie Andrea!
Come sempre illuminante.
L'osservazione sui log è importante, a questo aspetto non avevo pensato.

Mi metto al lavoro, vediamo se sono da rottamare o tiro fuori qualcosa di decente.

Francesco

C'ho messo un'ora per rileggervi e vado pure di corsaaaaa....

Per me il problema è dato dal fatto che non si può sapere prima se l'URL è generata a cavolo, la mia risposta di fatti faceva il confronto tra 301 e canonical, se fossi sicuro che è un duplicato generato da joomla 301 tutta la vita, ma se viene generato per scelta in una diversa visualizzazione come faccio a capirlo:

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

Qui per me l'unica soluzione è il canonical, e ho l'impressione che per risolvere questo sia necessario puntare sul canonical piuttosto che rischiare di perdere un contenuto reindirizzato da 301. L'alternativa potrebbe essere la combinata con un componete SEF che permette di specificare per le pagine che ho creato volontariamente la URL canonica, però come si gestisce la precedenza? Comanda il componente SEF o il plugin che fa il redirect?

Maurizio ZioPal

In realtà basterebbe dare un'opzione post based dove si può fare overhide delle impostazioni generali e dunque disabilitare il 301 e mettere il canonical o viceversa.

Penso che sia un'esigenza di davvero poche persone fare quello che descrivi sopra Dexter quindi un pannello avanzato post based dovrebbe essere più che sufficiente.

Ho visto che questo post ha generato una valanga di commenti...
Io personalmente mi sono scoraggiato e ho passato 2 giorni interi a rifare il sito in wordpress, appena pubblicato.
Deluso da Joomla penso di spostare le future realizzazioni su wp.

Ciao a tutti e grazie per i tanti suggerimenti.

@altraimmagine said:

Deluso da Joomla penso di spostare le future realizzazioni su wp.

Ciao a tutti e grazie per i tanti suggerimenti.

Ciao altraimmagine.
Comprendo il tuo punto di vista.
Esprimo la mia opinione (parlo a titolo personale, magari altri non condividono).

Un utente si comporta come un imprenditore, inteso nel senso più ampio del termine, che per realizzare la propria impresa persegue l'obiettivo senza alcuna guerra di religione. Dunque fai bene a scegliere WP se questo facilita i tuoi processi abbattendo i costi e riducendo i rischi.

Chi difende Joomla, però, non lo fa per guerra di religione. Quello che alcuni provano a spiegare è che Joomla e WordPress differiscono totalmente, con WP che nasce come piattaforma di blogging e si sviluppa grazie a un'architettura semplice che consente di aggiungere funzionalità (le più varie, incluso l'e-commerce) senza che siano richieste competenze avanzate di programmazione.
A mio avviso questo è un punto di forza di WP, la vera causa del suo successo: un webmaster junior configura in maniera accettabile il proprio sito seguendo i consigli sull'installazione di plugin e le migliori opzioni da scegliere via pannello di controllo; uno sviluppatore junior crea un plugin semplice in 1 ora.

Questa semplicità si riflette anche sul lato tecnico, il codice del CMS. Alcuni sviluppatori non ci pensano proprio a invischiarsi con Joomla perché lo considerano un investimento oneroso che non porta ai risultati sperati (e a volte hanno ragione). Non si tratta di bravura, è proprio che il gioco non vale la candela. Il discorso è: se voglio fare una cosa per bene allora uso Python, Ruby on rails o mi sviluppo un CMS proprietario con un framework PHP che scelgo secondo esigenze e gusti, altrimenti tanto vale puntare su WordPress.

Per fortuna non tutti ragionano come questi sviluppatori, ma io non ho pregiudizi e ascolto tutti, tanto più che sono "prestato" all'informatica, quindi mi considero un umile operaio apprendista e nulla di più.

In WordPress ogni post ha il suo url: questo non è normale.
Un software come si deve garantisce la separazione tra il dato e la presentazione dello stesso: condannare a priori un post con una relazione uno-a-uno con un url è limitante. Perché allora funziona? Perché quello non è un dato qualsiasi ma un post di un blog, che per la SEO è bene che sia associato biunivocamente a un url.
Quello che quindi in generale non sarebbe l'ottimale, dal punto di vista dello scopo che si prefigge WP è ben fatto!
Il discorso che ho fatto è molto semplificato.

WP, Joomla & la SEO facile
Teoricamente io potrei creare 2 pagine tra loro molto diverse, con scopi differenti, sugli stessi dati, ovvero su quelli che noi chiamiamo in Joomla article e in WordPress post.

WP separa dati e presentazione a livello di template, ma quella è un'altra cosa ancora. Per separazione noi intendiamo qualcosa ad un livello di astrazione superiore, compatibilmente con il modello MVC e, non caso, Joomla ha un'architettura Model-View-Controller e WordPress invece no.

Joomla nasce come piattaforma web e non come blog. L'errore di chi sviluppa il core di Joomla a mio parere è stato di conservare queste potenzialità senza valutare lo scopo per il quale molti utenti avrebbero potuto scegliere il cms.

Il risultato di questa non-focalizzazione sull'obiettivo da parte del team di Joomla è che tanti utenti, che non sono programmatori ma webmaster o addirittura blogger, usando Joomla in maniera "limitata" (non come web application ma come piattaforma cms per un sito semplice, ad esempio un *corporate *con poche pagine e/o un blog, cosa che faccio anche io), incontrano tantissime difficoltà che con WordPress sono assenti o presenti in quantità minore.

A Joomla manca il suo Joost de Valk (lo sviluppatore di Yoast).

Le URLs "pazze" legate agli id articolo
Grazie a te ci stiamo confrontando e nei prossimi giorni potremmo ipotizzare una soluzione al problema.
Per renderla "non limitante" potrebbe essere un plugin che non scrive nel database: in questa maniera non verrebbe toccata la logica del routing, non verrebbero modificati i file esistenti (db incluso), non ci sarebbero eccessivi rallentamenti (tranne quelli non evitabili, perché il tempo di un redirect non si può annullare), non si avrebbero problemi di aggiornamento (al massimo disattivi il plugin).

Se volessimo "andare oltre" dovremmo pensare a un componente, perché è il solo modo per realizzare quelle opzioni "post based" suggerite da Juanin e a cui ho accennato anche io quando ho parlato di metadata options.

Al momento sono sul plugin: ho intercettato queste URLs e devo soltanto restituire il 404 not found.
Ieri pomeriggio mi sono fermato a questo, ma quando stampo il codice in alto nella pagina non riesco a "forzare" il code 404 da fare restituire.
Si tratta di un problema di PHP/server, sono evidentemente ignorante e mi serve una mano.
Ho aperto questa discussione sul ForumGT, se avete suggerimenti sono i benvenuti!

http://www.giorgiotave.it/forum/php-mysql/220467-ottenere-un-code-404-not-found-via-php.html

Francesco