Se intendi di mescolare lingue in una pagina, non è da fare - già si crea confusione per gli utenti per non parlare dei motori di ricerca.

Se vuoi che guardo un'altro post, sarebbe utile avere un link per trovarlo :-).

Quindi avrai una:

pagina con "ciao"
pagina con "hi"
pagina con "cześć"
pagina con "hola"
pagina con "Hallo" ..ecc.

Sono tutte diverse...

Se le pagine sono in lingue diverse, non sono duplicate.

Nei risultati di Google ci sono risultati per pagine non indicizzati da Google ma che sono noti a Google grazie ai link in ingresso.

Ho discusso questo in un articolo su mio blog: RomeCamp2008 ed indagine SEO: avete notato un risultato strano nella ricerca per "Romecamp2008"?

Questo è anche il motivo che i link sulla pagina di SEO Camp Parma non sono così importanti :-).

Sembra che la "richiesta di primo contatto", se viene fatto in automatico (quantità di messaggi), non e' proprio previsto dalla legge.

C'e' una discussione in corso anche su mlist.it (area discussioni).

(Non sono un'avvocato - quindi non posso fornire una riposta definitiva)

Un sito .cl avrà una marcia in più per il Cile in confronto con un sito .es... come .at per Austria è più vicino (e più credibile) agli austriaci che un .de... Al fine è importante sapere **dove sono i soldi **- chi vuoi raggiungere e quali sono i comprimessi coinvolti.

Ciao a tutti,

sono d'accordo con Giorgio, ma noto che ci sono diversi punti da prendere in considerazione.

• si tratta di **un sito in essere **o da fare? Se è in essere, la situazione è da valutare – se si procede, è importante che le pagine vecchi vengono reindirizzati per bene (stato http 301).
• Un altro considerazione per lingue molto diffuse, come lo spagnolo e l'inglese: quale è la geografia che voglio raggiungere? Inghilterra? O tutto il mondo?

Ho tratto il problema di SEO per siti multilingue tempo fa sul mio blog (ma occhio, ci sono alcune novità nel UK con Google). Vi consiglio una lettura.

• Sean

L'orientamento sessuale è molto simile al mancinismo. C'è una forte maggioranza che generalmente non si pone il problema. Ci sono quelli dal altro parte che incontrano problemi quotidiani, le forbici che non funzione, ecc. E poi, ci sono anche le persone in mezzo, che ha un'esistenza più fluida, gli ambidestri.

Finché non c'è l'ignoranza e le persone che vogliano sfruttare una minoranza per i propri obiettivi di potere (o solo per spostare l'attenzione da problemi veri, come il lavoro, la casa), tutto bene.

Nel caso di una cosa così personale e delicata come la sessualità, esistono forti pressioni contro i mancini (gli omosessuali). Il momento che c'è uno che parla di una conversione senza che la gente ha le idee già chiare sulla varietà della sessualità umana, così come si trova nella natura, è solo prevedibile che manca poco prima che i soliti sospetti cominciano a fare una battaglia contro ?i mancini?, gli omosessuali. È un bersaglio troppo facile.

Alcuni tipi di hijacking, come il dns, possono essere evitati usufruendo del tag html base nelle pagine, ad esempio:

<base href="http://www.antezeta.it/notizie-news.html" />

(la pagina è necessaria se sono utilizzati i fragmenti, cioè #punto-nel-documento).

Mi pare che AlterWind Log Analyzer Lite è limitato a solo Windows. Peccato, la visualizzazione dei percorsi è molto utile - e una mancanza di AWStats.

Google Analytics è un ottima soluzione se non hai un accesso ai log. Come gli altri soluzioni che appongono ai tag JavaScript, deve mettere codice in ogni pagina da tracciare e sui link di ogni oggetto da scaricare (ad esempio .pdf) che vuoi tracciare. Non avrai informazioni sui ragni che non innescano JavaScript (quasi tutti). Inoltre, ci sono implicazioni su dove viene ubriacato il codice nelle pagine.

Dalle soluzioni per i log, a me piace AWStats. Ho steso un po' di informazioni e suggerimenti per AWStats in Italiano e anche una Guida all'Analisi delle Statistiche di Siti Web con AWStats.

Occhio al molto diffuso Webalizer ? è molto datato; non riconosce Firefox, ad esempio.

L'unica conclusione si può trarre è che entrambi metodi portano utenti che completano qualche attività presso il sito di destinazione (la conversione).

Ma a quali livelli e costi?

Se abbiamo 150 utenti che arrivano per via dei risultati organici, abbiamo 150 x 3,13% = 4,695 conversioni (si immagina che la gente è più propensa a cliccare sui risultati organici a sinistra ? sono più grande; noi leggiamo da sinistra a destra).

Nel stesso periodo abbiamo 100 utenti che arrivano mediante pay-per-click: 100 x 3,4% = 3,4 conversioni.

Ma anche se abbiamo questi dati, quanto ci ha costato questi conversioni? Cioè quanto ho dovuto pagare per l'ottimizzazione organica (e per quanto arco temporale)? Quanto ho dovuto pagare per i 100 click?

Probabilmente entrambi approcci sono vincenti ? ma occorre la misurazione continua di tutti i fattori per capire il guadagno effettivo in base alle spese fatte. Così si arriva al cosiddetto ROI, return on investment.

Prima di pensare ai motori di ricerca, mi chiedo chi saranno gli utenti?

   A mio avviso, vale la pena a dare una esperienza coerente agli utenti, quindi io                                      eviteria a miscelare le lingue sulle pagine di un sito.  Certo, ci saranno degli eccezioni dove si cita un documento in un altro lingua, ma si tratta di una eccezzione....  conviene cmq. a pensare prima agli utenti.

Per i motori, ci sono diverse fattori che sono prese in considerazione per decidere finché un documento risponde meglio alla lingua e cultura della persona che esegue la ricerca. I fattori al livello del sito comprendono il domino (.de, .it), dove reside il sito (Italia, Stati Uniti), eventuali header http e/o meta / html tag che indicano la lingua. A livello di pagina, ci sono modalità per analizzare il testo di un documento per arrivare con una certa fiducia alla lingua utilizzata.

Ho scritto un articolo su questa tema, Come i motori di ricerca rilevano la lingua dei documenti Html.

Ritengo il problema di nomedomino.it e www.nomedomino.it di essere più un problema di configurazione del sito che un problema di Teecno.

Noto che già Google fa fatica a gestire le versioni Canonical dei domini.

Non sarebbe male se Teecno sarà in grado di decidere, ma sarebbe meglio se il webmaster di nomedomino decidesse.

E' da tenere presente che i dati relativo ad Ask per siti Italiani non saranno molto attendibile.

L'api per Ask.com si appoggia ai dati raccolti per il mercato Americano (www.ask.com).

In generale, siti Italiani sono poco indicizzati in questa versione. Il problema sta che it.ask.com è stato progettato molto dopo l'api attuale - l'api non sa come accedere ai dati presso de|fr|nl|es|it.ask.com.

Ho riscontrato un problema con caratteri accettati. Nel caso specifico, l'uso di un riferimento numerico di carattere, cioè & #232; (senza spazio), viene reso come un numero, cioè "232", non "è" ecc.

Esempio: la ricerca yahoo site explorer ; i due risultati dal mio sito antezeta.it evidenziano il problema.

Sono del parere che sarebbe meglio di adottare il formato xml proposto da Google invece di inventare qualcosa di nuovo.

Tranne Google, Yahoo! è l'unico di offre un servizio simile. Al inizio hanno accettato una lista semplice di Url. In seguito hanno accetto liste nei formati Rss ed Atom. Ma non accettano, almeno a livello ufficiale, il formato Google, presumibilmente siccome viene dalla concorrente. Questo implica un lavoro doppio per gli amministratori di siti.

Ho trovato una soluzione tappa buchi, aggiungendo supporto per creare un feed Rss 2.0 alla programma sitemaps sviluppato da Google. Ma è una confusione che si potrebbe evitare...

Le parole comuni che generalmente non danno un valore semantico ad una ricerca sono chiamate stop words. Nel caso di Google, vengono ignorati nella ricerca se non sono specificate in modo esplicito. Cioè vengono indicizzati ma generalmente ignorati nella ricerca.

Sono utile in alcuni casi, ad esempio nel titolo del'opera di Shakespeare: to be or not to be.

Una lista di stop word italiane è disponibile dal progetto Snowball ; viene utilizzato, ad esempio, nel modulo Perl Lingua-StopWords.