@Federico Sasso said:

Sì, esatto, preferisco anch'io.

Nota che un 302 all'indirizzo di root che instrada a seconda della lingua nell'header accept-language, o in base all'indirizzo IP, in sé non è un errore per il motore di ricerca.
E' più una scelta. Personalmente non mi piace molto per due motivi:

1. il redirect 302 implica ogni volta che si invoca l'indirizzo di root ci sia una doppia chiamata HTTP. Alcuni non se ne accorgeranno nemmeno, ma per altri è un'esperienza utente meno brillante a causa del ritardo causato dal redirect.
2. in generale non amo reindirizzamenti basati su lingua o IP, perché in molti casi accept-language e IP rilevato non rispecchiano veramente la preferenza linguistica dell'utente.

Ciao

Grazie mille, sei stato chiarissimo e gentilissimo. Mi hai risolto dei dubbi e dato certezza su alcune mie considerazioni da "novello".

Ciao

@Federico Sasso said:

Ciao gp[11],

Nel lungo termine non avrà effetti negativi.

Nel periodo transitorio i motori di ricerca dovranno per ogni URL redirezionato scoprire il redirect 301, esplorare la destinazione, paragonare il nuovo contenuto con il vecchio, accertarsi il 301 persista nel tempo, aggiornare il proprio indice, etc... Durante questo periodo transitorio - che può durare un tempo variabile che dipende dalla frequenza con cui il bot del motore di ricerca visita il sito e ri-visita gli URL e dal numero degli URL stesso - è normale attendersi una flessione temporanea nel posizionamento.

Puoi tentare di accelerare i tempi creando una sitemap XML temporanea con i soli URL redirezionati da segnalare a Google, e per gli URL (vecchi) più strategici manualmente richiederne l'indicizzazione tramite Google Search Console "Esplora come Google" per tentare di fare scoprire pù velocemente i redirect.

Nota: non entro nel merito del se lo spostare la versione italiana da /it/ a root ti porterebbe un beneficio. E' un approccio personalmente preferisco perché evita un redirect 302 agli utenti della lingua principale, ma non è detto si tramuterà in un miglioramento del posizionamento.

Spero d'esserti stato utile.

Grazie mille, sei stato davvero utile.

@Federico Sasso said:

Nota: non entro nel merito del se lo spostare la versione italiana da /it/ a root ti porterebbe un beneficio. E' un approccio personalmente preferisco perché evita un redirect 302 agli utenti della lingua principale, ma non è detto si tramuterà in un miglioramento del posizionamento.
Quindi se ho capito bene, pure tu preferisci tenere la lingua principale nella root?
Sono giunto a questa conclusione proprio perché in molti tool SEO noto continuamente un redirect 302 dalla pagina principale.

Adesso non mi resta che valutare bene se il gioco può valere la candela.

Ciao a tutti,
ho da circa tre anni un sito multilingua con estensione .com dove le varie localizzazioni sono gestite con sottocartelle, quindi .com/it e .com/en.
Quel /it sono convinto abbia un impatto negativo nelle ricerche e per la lingua principale, italiano, vorrei eliminare la sottocartella /it mettendo tutto sul dominio principale.
La mia domanda è: dovrò ovviamente impostare dei redirect 301 per le pagine già indicizzate, questo redirect avrà un impatto negativo sulle pagine già indicizzate facendomi perdere ranking oppure non dovrò preoccuparmi?

Grazie mille

@micropedia said:

e verificare ovviamente che le lingue dichiarate nei meta tag coincidano con quelli in google webmaster
Intendi il targeting internazionale?
Ma se non volessi mirare a nessun paese nello specifico ma solo servire pagine in italiano e inglese devo ugualmente impostarlo? In tal caso, come? Ho solo la possibilità di scelta per paese.
La lingua non dovrebbe rilevarla automaticamente proprio grazie alle direttive hreflang ?

Utilissimo, grazie mille!

Ciao a tutti,

ho letto un po' tutte le guide di Google circa i siti multilingua ma una cosa ancora non mi è del tutto chiara circa la Sitemap.

Appurato che Google consiglia di generare un'unica Sitemap per tutte le lingue, non mi è chiaro se sia necessario inserire hreflag all'interno della sitemap se questo è già presente come meta tag all'interno di ogni pagina. Contestualmente non mi è chiaro pure per il viceversa, ovvero se sia necessario inserirlo come meta tag se già presente nella Sitemap.

Spero di essermi riuscito a spiegare bene.

Un grazie in anticipo.

@Federico Sasso said:

Ciao albza,

Ti fornisco la mia interpretazione, non sono un legale e ti invito poi a verificare da te.

Il sito del garante della privacy distingue chiaramente cookie di profilazione - per i quali è necessario il banner o simile artificio per l'accettazione esplicita dei cookie prima che siano scaricati - dai cookie "tecnici" (sessione, autenticazione, personalizzazione, etc..) per i quali tale obbligo non esiste, occorre solo notificare l'informativa.

I cookie di Google Analytics rientrano tra i cookie "tecnici" solo quando sono usati solamente dal gestore del sito per raccogliere informazioni in forma aggregata sull'uso del sito (vedi [cut] punto 4), quindi a mia interpretazione nell'uso classico di Google Analytics.

Diverso è il caso (mia interpretazione) delle informazioni estese fornibili da Universal Analytics, in questo caso a mio avviso rientrerebbero tra i cookie di profilazione e richiederebbero l'uso del banner per l'accettazione esplicita.

Quindi rispondendo strettamente alla tua domanda, ecco come mi sono finora regolato nei siti da me gestiti:

• Mi sono limitato a inserire nel footer un link a una pagina dedicata in cui, citando la normativa corrente, spiego in parole semplici che il sito usa solo cookie tecnici.
• Non ho abilitato le informazioni estese di Google Analytics, pur avendone da tempo aggiornato il codice, rinunciando ai dati aggiuntivi.
• Evito altresì altri cookie di terze parti categorizzabili come di profilazione
• Incrocio le dita

Per la mia realtà ritengo il banner sia ostacolo al miglior rendimento del sito, e per evitarne l'obbligo preferisco fare a meno dei dati aggiuntivi forniti da Universal Analytics (età, sesso, etc...) a mio avviso categorizzabili come di "profilazione". Penso il beneficio aggiuntivo possano fornire in termini di informazioni non valga la perdita di rendimento causata dal banner (è una mia valutazione personalissima, ovviamente).

Spero d'esserti stato utile.
Interessantissimo.

Quindi se:

• Da Google Analytcs disabilito Attiva funzioni pubblicitarie, Attiva i rapporti sulle categorie demografiche e gli interessi e Analisi dati In-Page
• Per quanto riguarda i social utilizzo solo dei semplici link (con logo - immagine) che rimandano alla pagina - account del social (es : il classico seguimi su facebook ma non un widget generato da facebook)
• Non usare più nient'altro che possa generare Cookie di prolifazione

Posso evitare di utilizzare il banner di avviso.
Ho interpretato correttamente?

Grazie mille.

Ciao a tutti,

avendo la necessità di reindirizzare tutti gli accessi "non www" verso "www [dot] miosito [dot] com" e tutti gli accessi a "www [dot] miosito [dot] it" e "[dot] miosito [dot] it" verso "www [dot] miosito [dot] com" ho inserito queste regole all'interno di htaccess (uso Pastebin in quanto risulterebbe difficoltoso incollarle sul forum non essendo ancora un utente Premium):
pastebin.com/gcenU3Jc

La sintassi, soprattutto per il primo set di regole, è corretta?

Per completezza, se può tornare utile nel seguente link ho copia incollato il mio htaccess:
pastebin.com/Ea5gVC8s

Grazie Mille.

Grazie

Capito, quindi anche se semanticamente non è corretto al 100% non dovrebbe influire?

Un'informazione circa l'utilizzo del tag < picture > e immagini responsive.

Nel voler risolvere i problemi su PageSpeed circa le immagini non ottimizzate e ridimensionate per dispositivi mobili mi sono imbattuto in un dilemma.

Come da raccomandazioni il tag < picture > dovrebbe essere utilizzato solo se bisogna fornire diverse versioni di un'immagine in base alla risoluzione\dispositivo.
Al contrario per usare dimensioni diverse della stessa immagine è necessario usare il tag img + srcset.

Utilizzando Drupal, per esigenze implementative risulterebbe abbastanza comodo usare il modulo Picture che però ha il problema, almeno per il momento, di utilizzare in ogni caso <picture>.

Mi domandavo, questo può rappresentare un problema per Google? Sia in termini semantici che di indicizzazione?

O posso trascurare il problema?

Grazie

Perfetto, grazie ancora, mi sei stato veramente d'aiuto.

Ciao

Utilissimo grazie, mi hai messo un po' di ordine in testa.

Il redirect 301 da / a /it è fatto sempre e comunque.

Il tag alternate/hreflang lo sto usando, senza il tag canonical, in questa maniera:
hreflang="it" rel="alternate" href=" miosito DOT com/it"
hreflang="en" rel="alternate" href=" miosito DOT com/en"
hreflang="ru" rel="alternate" href=" miosito DOT com/ru"

Spero sia il modo corretto, soprattutto l'assenza del tag canonical, che immagino perderebbe senso (o creerebbe problemi) visto che con alternate indico espressamente una versione alternativa dello stesso contenuto.
Dico bene?

Grazie ancora.

@Federico Sasso said:

Ciao gp[11],

Scusa, non mi è chiara una cosa: qual è il tuo scopo?

Nello specifico:
controllando le Risorse bloccate ho notato che ci stavano 7 pagine con risorse bloccate, quindi sono andato a correggere il mio file **robots.txt **.
Adesso volevo inviare nuovamente la index tramite **Visualizza come Google **ma ottengo un errore:
**
miosito DOT com/
Tipo Googlebot: Desktop (rendering richiesto)
Reindirizzata il giorno mercoledì 11 marzo 2015 14:12:25 GMT-7
*L'URL reindirizzava a: *
miosito DOT com/it

Quindi mi chiedevo se fosse il caso di Recuperare e poi Inviare solo miosito DOT com/itoppure individualmente anche miosito DOT com/en e miosito DOT com/ru visto che ognuno rappresenta una lingua diversa, oppure è del tutto ininfluente?
Inoltre quell'avviso di reindirizzo può rappresentare un problema?

Più in generale invece:
in una struttura del genere:
miosito DOT com/ [301]-> miosito DOT com/it
miosito DOT com/en
miosito DOT com/ru

dove i contenuti sono i medesimi ma semplicemente tradotti nelle rispettive lingue, se in seguito a delle modifiche volessi inviare nuovamente le pagine all'indice di google, da Visualizza come Google devo recuperare e poi inviare solo miosito DOT com/it oppure devo fare lo stesso lavoro per ogni lingua indicando "Esegui la scansione di questo URL e dei suoi link diretti" ?
Oppure è un qualcosa che posso trascurare?

Spero di essere stato più chiaro.

Grazie tante.

Ciao a tutti.

Mi trovo in questa situazione:
ho realizzato un sito cui in un secondo momento ho aggiunto traduzioni in inglese e russo.
Per gestire le traduzioni l'ho organizzato con sotto directory /it per l'italiano, /en per l'inglese e /ru per il russo, conseguentemente adesso la root (/) reindirizza alla lingua di default e quindi alla subdirectory /it.
Dagli strumenti per i WebMaster ho inserito tre nuove Sitemap per lingua (/it/sitemap.xml, en/sitemap.xml, etc...).
Quindi sono andato a controllare in Visualizza come Google e, giustamente, ottengo come risultato: Reindirizzata (al miosito /it).
A questo punto mi domando:
conviene inviare all'indice sia /it, /en che /ru ed indicare "Esegui la scansione di questo URL e dei suoi link diretti" oppure è sufficiente inviare solo /it con "Esegui la scansione di questo URL e dei suoi link diretti" ?
Nell'eventualità scegliessi in ogni caso la mia prima soluzione potrei riscontrare problemi di sorta?
Vi ringrazio per la pazienza.

Un saluto a tutti,

su Yandex sto iscrivendo un sito multilingua che ho realizzato.

Il sito è strutturato per avere una ulr del tipo nome a dominio /ru per il russo, /en per l'inglese, /it per l'italiano, etc...

La mia domanda è, questo può rappresentare un problema per far indicizzare il sito nella sua traduzione in russo?

Ad esempio io su google ho inserito una sitemap per lingua, su Yandex come converrebbe procedere?
E' la prima volta che ho a che fare con Yandex e mi sento un attimo spaesato.

Grazie Mille.

Grazie!

Grazie per la risposta.

Al momento ho fatto proprio un redirect 301 ma non "link a link", cioè da "www . miosito . it/ contatti" a "www . miosito . com/contatti" ma semplicemente dal dominio ". it" alla root del dominio ". com", quindi ". it/contatti" reindirizza sempre alla home del ". com" .

Dopotutto il sito è appena stato messo online.

Ciao Giorgiotave e grazie mille per la risposta.

Per i domini a dire il vero non c'è una vera ragione. Il mio cliente aveva già acquistato entrambi i domini e quindi mi sono già ritrovato in questa situazione. Ad oggi mi sono sempre occupato di sviluppo e design e adesso cercavo di orientarmi in questa nuova materia.
Credo che le intenzioni del mio cliente siano quelle di evitare che qualche "concorrente" usi un nome a dominio uguale (estensione a parte ovviamente), idea non so fino a che punto corretta.

Posso permettermi di fare una contro-domanda?
Perché mi hai fatto questa domanda? Immagino ci sia una ragione.

Grazie e buone feste.

Grazi mille!