Si,
è molto interessante.
Ed è anche l'idea di base che ha ispirato il film "Ex Machina", nel quale una robot dotato di una straordinaria intelligenza artificiale basata sui dati del "BlueBook Search Engine" (che sembra una sorta di mix fra facebook e google) viene sottoposto al test di Turing.
Non è che sia un capolavoro del cinema, ma è proprio centrato su questo tema.

@Panebianco3d said:

....solo per curiosità mi indicheresti il link da cui hai preso questa citazione?
Certo, lo avevo riportato sopra ma, non potendo postare link, non era ben evidenziato:
support.google.com/webmasters/answer/189077?hl=en

@Panebianco3d said:

Quindi ricapitolando? Come intenderesti inserire i tag?

Per me l'inserzione dei tag segue lo stesso principio in tutte le pagine che ricadono in uno dei tre casi riportati nella fonte di cui sopra.

Ad esempio supponiamo di avere le seguenti quattro pagine:
example.com/about (pagina tutta in inglese generico - 3°caso: fully translated)
example.it/about (pagina di cui la sola parte navigzionale è in italiano il contenuto è in inglese - 1 caso: translate only the template)
example.fr/about (pagina tutta in francese - 3°caso: fully translated)
example.au/about (pagina tutta in inglese diretta ad una utenza australiana -2° caso: small regional variations)

Ognuna di queste quattro pagine pagine conterrà nell'head tutti e quattro i seguenti tag:
<link href="example.com/about" hreflang="en" rel="alternate">
<link href="example.it/about" hreflang="it" rel="alternate">
<link href="example.fr/about" hreflang="fr" rel="alternate">
<link href="example.au/about" hreflang="en-au" rel="alternate">

@Panebianco3d said:

...ovviamente nessun canonical.
L'utilizzo del canonical dipende da altri fattori ma non è incompatibile con l'hreflang.
Ad esempio se l'url example.it/about?par=val restituisce lo stesso identico contenuto di example.it/about, allora bisogna scegliere quale di questi due url fare indicizzare a google.

Supponendo di scegliere il secondo, l'head della pagina example.it/about?par=val dovrà contenere il tag:
<link href="example.it/about" rel="canonical">
e non dovrà contenere i quattro tag rel="alternate" visti prima.

L'head della pagina example.it/about dovrà contenere i tag con l'hreflang ed il canonical:

<link href="example.it/about" rel="canonical">
<link href="example.com/about" hreflang="en" rel="alternate">
<link href="example.it/about" hreflang="it" rel="alternate">
<link href="example.fr/about" hreflang="fr" rel="alternate">
<link href="example.au/about" hreflang="en-au" rel="alternate">

Così google saprà che la pagina about da presentare ad utenti italiani è example.it/about e non example.it/about?par=val e saprà pure che questa pagina ha delle alternative nelle altre lingue.

Questo è lo schema che mi sembra più coerente con quanto letto sui vari articoli del supporto per webmaster di google e mi sembra anche lo schema usato dal play store di google.

@Panebianco3d said:

Ho ancora un dubbio pero' per la terza condizione che riporti, e non vorrei distruggere tutte le mie certezze! ^_^ :

• Your site content is fully translated. For example, you have both German and English versions of each page.

in che senso si intende questa cosa, secondo te?

Perche' se ho un sito in due lingue, due dirs diverse (it e en ad esempio), pagine distinte (dominio/it/pagina.html e dominio/en/page.html), come dovei usare l'hreflang=x secondo te nelle due pagine?

La terza condizione la intendo allo stesso modo delle altre condizioni, quindi secondo me dovresti mettere nell'head di entrambe le pagne i seguenti due tag:
<link href="dominio/it/pagina.html" hreflang="it" rel="alternate">
<link href="dominio/en/pagina.html" hreflang="en" rel="alternate">

ciao

Ok, abbiamo individuato il punto chiave sul quale dissentiamo.:)

Può darsi pure che io mi sbagli, però dai un'occhiata a questo: support.google.com/webmasters/answer/189077?hl=en

Some example scenarios where rel="alternate" hreflang="x" is recommended:

• You keep the main content in a single language and translate only the template, such as the navigation and footer. Pages that feature user-generated content like a forums typically do this.
• Your content has small regional variations with** similar content in a single language**. For example, you might have English-language content targeted to the US, GB, and Ireland.
• Your site content is fully translated. For example, you have both German and English versions of each page.

Il primo scenario è esattamente quello di cui stiamo discutendo e per me va gestito con gli hreflang e non con i canonical.

E il secondo scenario tratta di pagine ancora più simili, che ptrebbero differire anche solo per una data scritta con una notazione differente.

L'utilizzo dell'hreflang indica che le pagine sono una alternativa e tutela in automatico dalla penalizzazione per contenuti duplicati. Anche se le pagine sono quasi del tutto uguali.

Si Panebianco3d, anche io sono per i confronti costruttivi
Ho la sensazione che sul metodo da applicare siamo d'accordo. Però io parto dall'assunto che una pagina tradotta in italiano, anche se per la sola parte navigazionale (diciamo per il 5%), è da considerare pagina in lingua italiana. Tu sei d'accordo con questa affermazione?
Provo a rispondere.

Il canonical deve essere usato in presenza di pagine duplicate: se hai 3 pagine dello stesso prodotto, in 3 siti diversi (come nel caso di md4italy, 3 pagine identiche in inglese in 3 domini diversi), allora bisogna decidere quale sarà la pagina principale ed impostare il canonical sulle altre due, in modo che queste ultime puntino sulla principale.
Quindi quando parliamo di pagine duplicate parliamo di due pagine uguali E nella stessa lingua.
D'accordissimo. Ritengo però che, nel caso di md4italy, le pagine sul dominio .it non siano identiche a quelle in inglese. Infatti se è stata tradotta la parte navigazionale non sono da considerare duplicati di quelle sul .com ma alternative in lingua diversa (ovvero italiano) e vanno specificate usando l'hreflang.

Il canonical non è necessario e non deve essere inserito in una pagina (ad es.) in italiano verso il suo corrispettivo in inglese (come dici tu). Per questa cosa c'è l'hreflang.
Forse mi sono espresso male ma no. non dicevo questo. Io dicevo che le pagine in italiano (anche quelle tradotte parzialmente) devono avere il canonical url che punti al .it e non al .com.

Quindi, alla luce di questo, ricapitolando per come la vedo io: per un'ottimizzazione di tutti i siti/domini del case study di md4italy, si dovrebbe:

1. nei domini in lingua, far puntare tutte le pagine in inglese - tramite canonical - verso le medesime pagine del .com. In queste pagine non si deve impostar alcun hreflang.
2. Tutte le pagine del .com in inglese che hanno un corrispettivo tradotto in lingua dovranno includere la lista degli hreflang che puntino alle url tradotte che si trovano su altri domini;
3. allo stesso modo, tutte le pagine tradotte dei domini in lingua (it, es, fr, eccetera) dovranno avere la lista di hreflang verso le versioni tradotte sui vari domini;

Sono quasi d'accordo. Diopende da cosa intendi per "tutte le pagine in inglese dei domini in lingua".
Per me una pagina tradotta anche solo per il 5% non è da considerare in inglese ma è da considerare tradotta e ricade quindi nel punto 3.

Quindi, citando la domanda di md4italy, le "pagine non ancora tradotte in lingua italiana o meglio dove solo il 5% dei contenuti è tradotto (ovvero i link di navigazione)" per me sono da considerare pagine in lingua italiana e ricadono nel terzo punto.

Cosa ne pensi?

Concordo con Panebianco3d sull'inserire l'hreflang su tutte le pagine che hanno più versioni, dove per più versioni intendo anche la versione tradotta in italiano per il solo 5%.

Non sono d'accordo sull'inserire il canonical che punti al .com e ritengo che ogni pagina sulla versione italiana del sito, anche se tradotta solo al 5%, debba avere il canonical che punti a all'url canonico .it.

Se hai tradotto il 5% è giusto che la tua pagina in italiano sia indicizzata così come è ovvero con il 5% tradotto. Se metti il canonical al url .com google indicizzerà quella non tradotta.

Suggerisco una video che ritengo molto utile e che mi è servito in passato a chiarire alcuni dubbi.
www

Al minuto 8:46 dice che gli url indicati nell hreflang dovrebbero corrispondere a dei canonical url.

Ti consiglio anche di dare uno sguardo a come google gestisce l'aspetto multilingua nel play. Io l'ho trovato molto istruttivo.

Su LinkDetox, prima di generare il report, è possibile caricare il file che si sta usando nel disavow di google.
In base a tale file lui marca, nel report, alcuni link, come disavowed.
Ho notato che se nel file ho specificato un dominio lui mi marca come disavowed tutti i link provenienti dal dominio ma non quelli provenienti dai sotto-domini.
Farò qualche altra prova per verificare di non essermi sbagliato.

Rimane il fatto che se LinkDetox interpreta in un certo modo il disavow file, non è detto che google lo faccia esattamente allo stesso modo, anche se mi aspetterei di si.

Ciao Giorgio, grazie a voi per l'ottimo lavoro che fate e che condividete!

Mi fa piacere che i link tipo adfly non siano pericolosi.

Per quanto riguarda quelli sotto i vari blogspot.tk, blogspot.sg etc, essendo davvero tanti e spuntandone ogni giorno di nuovi, li ho inizialmente elencati nel disavow a livello di dominio.

Tuttavia poi mi è sorto un dubbio: se indico nel disavow "domain:blogspot.tk" sto effettivamente disabilitando anche tutti i sotto-domini tipo "nomeblog.blogspot.tk"?
Stando ai reports che ottengo con LinkDetox (ho deciso di farmi questo regalo ed ho sottoscritto un piano), sembrerebbe di no.

Quindi, tenuto conto di ciò e tenuto conto anche di quello che mi hai suggerito tu, sto provando a rendere più specifico il mio disavow file e spero di ottenere dei risultati.

Tra l'altro sto pure provando il Link Detox Boost, sul quale sono un po' scettico, boh... vedremo!

Ciao franzz,
penso sia importante capire che nesso c'è con il sito webmarketing-roma punto com.

Se è vostro, e avete quindi un sito nuovo su una piattaforma più aggiornata, non mi è chiaro perchè li teniate entrambi e non abbiate invece efttuato il passaggio al nuovo dominio seguendo la guida per webmaster:
support.google.com/webmasters/answer/83106?hl=it
In questa ipotesi forse non vale la pena cercare di riparare un sito che potrebbe essere molto compromesso e conviene invece effettuare il passaggio al nuovo dominio.

Se non è vostro allora è un clone, ed è un ulteriore problema.

Ciao lscarantino,
leggo molto in ritardo la discussione e mi chiedevo se hai aggiornamenti, spero positivi.

A febbraio mi è capiata una cosa molto simile: un mio sito è stato clonato in realtime compresa la pagina di login.
Me ne sono accorto ed ho iniziato a passare al sito clonante una scritta in rosso con un warning che avvertiva si trattasse di un clone.
Poi sono risalito al proprietario del dominio clonante. Un ragazzo vietnamita che dallo stesso dominio, con diversi sottodomini, clonava non solo il mio di sito ma anche altri siti simili.
Ho scritto all'azienda che gestiva il servizion di hosting per chiedergli di provvedere in qualche modo, ma non ho avuto risposta.
Poi ho scrito una email al proprietario del dominio minacciando di procedere per vie legali e dopo un paio d'ore è scattato il redirect dal sito clonante ad un altro di tematica simile.

Adesso il dominio clonante non ha più il redirect, non presenta più i miei contenuti ma contenuti simili ed usa comunque il nome del mio sito.
Nel frattempo ho segnalato la cosa a google svariate volte ma non ho avuto alcuna rispost, figurati! Il maledetto continua ad usare pure adsense senza problemi.

Vi ringrazio, perchè dopo aver letto questa discussione mi è più chiara la dinamica con cui sono andate le cose e forse il redirect del clone era già programmato e non è stato dovuto al mio intervento, come mi ero illuso.

Come misura preventiva ho fatto una indagine vedendo quali altri domini fossero di proprietà dello stesso tizio (o comunque a lui legati) e su quali server fossero ospitati.
Quindi ho vietato l'accsso a tutte le sottoreti corrispondenti ai servizi di hosting cui essi facevano riferimento.

Ti consiglio di agire in termini di range di ip piuttosto che di referer in quanto quest'ultimo è facilmente modificabile.
Nel mio caso il referer era vuoto e lo user agent era quello di googlebot

Ti consiglio pure di crearti degli alert di google per alcune keyword che sai sono presenti solo sulla tua home, così google ti avviserà in automatico se le dovesse trovare in un'altra pagina.

Per quanto riguarda il disavow, il mio consiglio è: usalo assolutamente!
Il fatto che google continui a visualizzare i link sul gwt non vuol dire che non stia prendendo in considerazione il tuo disavow file.
Se sai che sono link spazzatura messi apposta, per fare negative seo, segnalali; e non le singole pagine ma gli interi domini da cui essi provengono.

@gianrudi said:

Secondo me, se il dominio in serp fosse un sito clonante, come alcuni indizi sembrano suggerire, non avrebbe senso cercare di avvertirli, e probabilmente sarebbe anche impossibile; in tal caso potrebbero forse essere da avvisare i titolari del sito originale clonato e soppiantato in serp (che ho menzionato nel post sopra).

Bohh... non credo si tratti di clonazione, il dominio in serp è molto più vecchio di webmarketing-roma punto com.
Su webarchiveorg, si trovano versioni del sito rekuest del 2006 che riportano lo stesso numero di telefono attuale.

Chi sa...

Ma... più che giusto, penso che potrebbe essere un gesto carino, perchè no.
Concordo, Worpress in quanto a sicurezza è una frana e Joomla idem. Un po' meglio Drupal, ma bisogna sempre essere tempestivi nel fare gli aggiornamenti e configurare il server in modo opportuno.

Ciao seoside,
è passato circa un mese e mi chiedevo se hai ottenuto dei risultati.

Poi visto che anche io mi sto occupando di analisi dei backlink mi permetto di darti giusto un consiglio.

Per quel che ne so io, gli strumenti per Webmaster di Google ti mostrano solo una percentuale dei link al tuo sito.
Ti consiglio, se non lo hai già fatto, di analizzare i referral tramite Analitics. Io ho trovato un sacco di robaccia che non avevo trovato con GWT.

Come scrivevo in un altro post, ho cercato fra tutto il traffico degli ultimi anni proveniente da referral, tutto ciò che mi sembrava strano ed innaturale:

• traffico che aveva portato a sessioni di durata media nulla;
• traffico proveniente da domini con TLD poco usuali tipo .tk, .il, .ro e così via;
• traffico proveniente da domini striminziti composti da soli 4 caratteri, poi da 5 e da 6;
• domini che usavano nel loro nome parole chiave cruciali per il mio sito

Ovviamente non tutti i link che ho ottenuto erano da buttare ma molti si.

@LorenzoRoma said:

Si, credo che sia andata così:

1. i cinesi hackerano il sito cambiando il title (e forse aggiungendo un link nel testo della pagina)

2. google passa e indicizza il cambio di title (ecco perchè si vede quello su google)

3. rekuest si accorge del problema e corre ai ripari

4. noi siamo qui.

poi credo che...

5. google ripasserà sul sito e tornerà tutto ok.

Anche io penso sia andata così.
Sul tutto ok ho qualche dubbio. Credo infatti che rekuest non si sia accorta che c'è un div seminascosto nella home contenente una ventina di link dofollow con anchor text tipo "Cheap Nike Patriots Jerseys" e... a questo punto potrebbe esserci anche dell'altro.
Insomma... prefeirei non essere nei loro panni.

Buongiorno a tutti,
come da titolo sto cercando di affrontare dei problemi di negative SEO che da settembre 2013 soffocano il traffico organico del mio sito web (che si è ridotto improvvisamente dell' 80% ed è adesso quasi un decimo di quello di due anni fa).
Il crollo del traffico è stato causato probabilmente anche da altri motivi legati all'ottimizzazione ma, nel corso di questo anno e mezzo ho lavorato molto e penso di aver risolto la maggior parte di questi problemi (o almeno quelli di mia competenza) senza ottenere alcun risultato.

Ho sempre sospettato ci fosse qualcuno che mi stesse remando pesantemente contro per svariati motivi. Ho iniziato le indagini circa un anno fa spulciando tutti i backlink proposti dal webmaster tool di Google ed ho cercato di eliminare (aggiornando circa una volta al mese il file txt del disavow tool) tutti quelli che mi sembravano innaturali.
Preciso che non ho mai acquistato link, solo due articoli su due blog di cui uno con link di tipo nofollow. Inoltre non ho nessuna penalizzazione manuale segnalata su Google webmaster.

Dopo aver seguito il SEO Tool Day di martedì scorso ed in particolare gli interventi di Gabriele Benedetti (a cui vanno i miei ringraziamenti oltre che all'intero Staff di GT Idea) mi sono finalmente reso conto che avrei potuto utilizzare Google Analytics per l'analisi dei backlink ed ottenere molte più informazioni rispetto a quelle che ottenevo da Google Webmaster.
E così è stato!

Ho cercato fra tutto il traffico degli ultimi anni proveniente da referral, tutto ciò che mi sembrava strano ed innaturale:

• ho iniziato col cercare il traffico che aveva portato a sessioni di durata media nulla;
• poi ho filtrato il traffico proveniente da domini con TLD poco usuali tipo .tk, .il, .ro e così via;
• ho filtrato con delle regex tutto il traffico proveniente da domini striminziti composti da soli 4 caratteri, poi da 5 e da 6;
• ho ripetuto lo stesso filtraggio del punto precedente sul percorso referral;
• ho quindi cercato domini che usavano nel loro nome parole chiave cruciali per il mio sito;

Bene! (o forse dovrei dire male!) La quantità di robaccia che ho trovato è notevole, e tutto ciò mi era sfuggito analizzando solo dati del Google webmaster tool.
Son venuti fuori una sfilza di ghost referral e svariati servizi di short-url con integrato adevertising, ritenuti universalmente malevoli.
Ma la cosa che mi ha lasciato veramente di stucco è aver scoperto migliaia di blog implementati su blogspot; tutti chiaramente finti e fatti ad hoc, duplicati in termini di sotto-dominio su circa quaranta diversi domini di secondo livello di blogspot: blogspot.tk, blogspot.ro, blogspot.sg ecc.
Ogni blog contiene solo uno o due link, e sembra in tema col mio sito quindi non li avevo notati in precedenza.

Il mio stupore, misto a rabbia, è dovuto anche al fatto che mi trovo davanti all'ennesima contraddizione di Google che, da un lato ingaggia una lotta senza pari contro i backlink artificiali e dall'altro offre una piattaforma che, a quanto pare, si presta benissimo a crearli allo scopo di penalizzare un concorrente.
Mi chiedo: non potrebbe imporre l'uso del nofollow?
E ancora: è possibile che visitando uno di questi blog io non abbia la possibilità di risalire all'autore in modo semplice? ci sto lavorando ancora da poco, ma finora non ci sono riuscito.
Bohhh? i misteri di Google.

Dopo questo lungo preambolo/sfogo, chiedo l'aiuto di qualcuno più esperto di me perché ho un paio di dubbi.

1. Come trattare i backlink cattivi provenienti da blogspot?
   Trattandosi di almeno 80 sotto-domini diversi, ciascuno replicato circa 40 volte sui vari domini di secondo livello di blogspot, avevo pensato di aiutarmi con uno script per elencarli uno ad uno ed aggiungerli al file per il disavow tool.
   Poi, visto che continuavo a scovarne sempre di nuovi, mi son deciso ad includere nel file tutti i domini di secondo livello corrispondenti a blogspot, circa una quarantina.

Ho fatto bene o sarebbe stato meglio specificarli singolarmente a livello di sotto-domini?
So che così rischio di perdermi qualche buon link che potrebbe provenire da un blog serio ospitato su blogspot ma, da una prima analisi che ho fatto non mi sembra di averne, almeno per il momento.
Potrebbero esservi altri problemi legati a questa scelta? Quello che temo è che Google se la possa "prendere a male" perché gli ho chiesto di ignorare per intero la sua piattaforma di blog.
Ma del resto un video di Matt Cutts diceva che in alcuni casi non bisogna andare di scalpello ma di machete, ed io l'ho fatto.

2. Come trattare i link provenienti da adfly e simili?
   In sostanza si tratta di short-url, piazzati su altri siti, che presentano una pagina pubblicitaria prima di rimandare al mio sito. Credo che ciò accada tramite un redirect quindi non sono neppure sicuro che questi siano considerati come link nel calcolo del pagerank e non so se possono avermi penalizzato.
   Se guardo l'andamento nel tempo del traffico proveniente da questi referral noto però che è fortemente correlato al traffico organico del mio sito, quindi ho la sensazione che di danno ne abbiano fatto.
   Io per il momento li ho inseriti nel disavow tool e presto vedrò pure di bloccare l'accesso al sito quando vi si giunge tramite uno di questi referral. Voglio inoltre provare a risalire ai siti su cui sono piazzati gli short-url e contattare i webmaster.
   Secondo voi dovrei fare qualcos'altro?

Grazie per il vostro tempo e scusate se mi sono dilungato.

Ciao,
se posti per intero l'url di partenza e quello a cui vuoi che venga reindirizzato (magari sostituendo il nome dominio con "example", non vorrei violare alcuna regola) provo ad aiutarti.
Accertati di avere inserito la riga:
RewriteEngine On
prima delle condizioni di rewriting.

Ciao
Giuseppe

Si,
in effetti io valutavo la faccenda solo sotto il punto di vista della fattibilità tecnica. Son d'accordo con te, per un provider (e, finché l'SNI non diventa supportato da tutti i browser, anche per gli utenti) meglio andare sul sicuro.

Ciao servinf,
sono d'accordo: devi generare una chiave privata ed una pubblica, poi una richiesta di certificato ed inviarla ad una Autorità di Certificazione riconosciuta (GeoTrust, VeriSign, etc).
Ma per fare ciò ti serve un dominio, non un indirizzo ip dedicato. Il certificato che ti verrà rilasciato garantirà che la chiave usata dalle tue pagine cifrate appartenga al tuo dominio non al tuo indirizzo ip.

Il server web può tranquillamente condividere l'ip con diversi virtualhost (quindi diversi domini) ma deve essere configurato in modo da fornire un certificato differente per ogni virtualhost che gestisce.

Il warning cui mi riferivo nell'ultima parte del mio post precedente lo si ottiene se si usa un browser vecchio che non supporta il Server Name Indication (SNI) e ci si collega ad un sito ospitato in hosting condiviso.L'estensione SNI del protocollo TLS consente al browser di inviare il nome del dominio richiesto al server-web prima di stabilire la connessione cifrata. In questo modo il web-server, conoscendo il nome del dominio, può risponde al browser fornendo il certificato corretto, ovvero quello appartenente al dominio richiesto. Senza il Server Name Indication il web-server non è in grado di determinare il dominio richiesto e fornirà il certificato ssl del virtualhost di default. Poiché quest'ultimo non coinciderà con il dominio richiesto il browser darà un allarme.
Se non sei su hosting condiviso, ed hai un ip tutto tuo, questo problema non ce l'hai. Ecco perché dicevo che mi sembra l'unico inconveniente di avere un certificato SSL su hosting condiviso.

Ciao korg.
Secondo me la tua idea iniziale del VPS assieme al certificato SSL è la soluzione migliore.
Capisco pure che il VPS ti possa risultare difficile da gestire quindi, se vuoi qualcosa di "pronto all'uso", valuta altre soluzioni ma, fossi in te, non rinuncerei al certificato SSL.

Considera che i costi sono ridicoli, si parla di 50$ l'anno ma i vantaggi che ne ottieni sono tanti. Il sito ne guadagna sicuramente come immagine e gli utenti saranno più protetti.
Mi permetto di dissentire da quanto detto da vhosting a riguardo. Qualunque area clienti necessita di un accesso, e le credenziali d'accesso sono sempre dati sensibili. Io francamente provo un certo fastidio nell'inserire le mie credenziali d'accesso tramite una connessione non cifrata.

Per quanto riguarda il tuo dubbio sulla necessità di un ip fisso, il problema non si pone, perché potrai legare il certificato SSL al tuo al tuo dominio web a prescindere dall'indirizzo ip. Comunque, anche l'hosting condiviso ti fornisce un indirizzo ip fisso, solo che è condiviso fra più domini. Con il vps invece avresti un ip tutto tuo.
L'unico problema che mi viene in mente, in merito all'utilizzo del certificato SSL su hosting condiviso, è che il browser di qualche dispositivo Android più vecchiotto (con versione inferiore alla 2.3 se non ricordo male), potrebbe non accedere al certificato SSL corretto e dare un warning molto fastidioso.

ciao