• Super User

    @agoago said:

    Everfluxx ricorda che per non essere spiderizzati basta il robots.

    Il primo spider ignora il robots, ma il bot eseguendo il contenuto letto dal primo spider vede se questo richiama un testo che non e' presente nella pagina spiderizzata.

    Ho scritto un post in merito un anno fa, se una pagina richiama un testo bloccato via robots, la pagine viene penalizzata.
    Questo perche' il primo spider vede un testo diverso dal testo catturato dal codice della pagina spiderizzata eseguito localmente in seconda battuta dal motore.

    Ma se si mette un testo dentro un iframe richiamato da un js, il testo letto dal primo spider ed eseguito poi localmente dal motore corrisponde perfettamente, coincidono.

    Un testo esterno bloccato via robots, ma visibile eseguendo la pagina che lo richiama, e' penalizzante, un testo bloccato o no via robots ma richiamato via iframe+js non e' visto quando il motore esegue localmente cosa ha spiderizzato il suo spider.
    Mi venisse un colpo se ho capito una parola di quello che hai scritto, ago.

    Vado per tentativi: tu stai dicendo che il motori non indicizzano i contenuti JavaScript perché altrimenti, così facendo, indicizzerebbero anche i propri annunci (es. AdSense). Giusto?

    Io dico che per impedire l'indicizzazione degli annunci AdSense basta e avanza il Disallow nel robots.txt che ho citato sopra.

    Tu dici che i motori hanno modo di "eseguire localmente" (?) gli script per verificare se il contenuto HTML statico + quello generato dinamicamente corrisponde a quello che vede l'utente, renderizzato dal browser. In caso contrario, è JS-based cloaking, e come tale va bannato. Okay.

    Poi dici che un modo per aggirare questo controllo è includere il testo che si desidera rendere "invisibile" ai motori in un iframe creato per mezzo di una funzione JavaScript, tecnica utilizzata per visualizzare gli annunci AdSense (vedi http://pagead2.googlesyndication.com/pagead/show_ads.js), e che questa è la tecnica che Google ha dovuto adottare appunto per impedire l'indicizzazione dei propri annunci da parte di altri motori di ricerca. Tale tecnica costituisce, a tua detta, una sorta di "backdoor" che permetterebbe ai webmaster di rendere invisibili a Google parte dei propri contenuti.

    Io credo che esistano modi più efficaci (e semplici) per impedire l'accesso ai contenuti degli annunci AdSense, anche da parte di motori che non rispettano robots.txt.

    Inoltre, se ammettiamo che Google sia in grado di eseguire il codice JavaScript per verificare la rispondenza fra quanto renderizzato dal browser e quanto "visto" dal bot, allora non vedo perché non dovrebbe essere tecnicamente in grado di renderizzare anche il contenuto di un iframe creato per mezzo di una funzione JavaScript.

    Infine, per mia esperienza, i maggiori motori di ricerca (Google, Yahoo!, Live, Ask) rispettano quasi religiosamente robots.txt (Slurp ogni tanto scazza, ma innocentemente).


  • User Attivo

    Mi sono spiegato poco chiaramente.

    Passa lo spider e legga il contenuto della pagina A.
    La pagina A contiene dei richiami a file esterni, per dire dei js.
    Questi file sono inibiti all'indicizzazione per via del robots.txt.
    Questi file esterni, ovviamente non sono letti dallo spider, in quanto il robots lo vieta.

    Nessun trucco nessun inganno da parte di nessuno, da sempre funziona cosi'.

    Fin qui tutto normale.


    Ora immaginiamoci che i motori abbiano anni fa deciso di eseguire il codice spiderizzato delle pagine, per dire la pagina A.

    Eseguono la pagina A, e la pagina A richiama dei file esterni, file che magari inseriscono del testo nuovo rispetto al testo letto dallo spider.

    Quando eseguono localmente la pagina A, il testo dei file js appare al motore, perche' il robots inibisce la spiderizzazione dei js, ma non inibisce che il js sia eseguito da un utente, vedi motore.


    A questo ipotizziamo che nel testo spiderizzato della pagina A ci sia solo la parola cane.

    Il testo che appare invece nella pagina A, dopo averla eseguita localmente dal motore e' cane - gatto.

    La parola gatto infatti viene prodotta in A dal file js richiamato da A.

    Fin qui tutto semplice.


    Cosa succede adesso?

    Per prima cosa il motore si arrabbia, perche' constata che il wm della pagina A ha falsato cosa percepito dal motore rispetto cosa percepisce-vede un utente.

    Il motore e' in grado di capire se cosa inibito sia voluto o indipendente dal wm, per dire Adsense non penalizza il wm, in quanto il wm si attiene allo sponsor e non e' una sua libera scelta.

    Se un wm inibisce sul suo sito Z un file richiamato da A (pagina A sul sito Z) file posto sempre sul sito Z... (il famoso js bloccato dal robots) al motore piace meno, ed eseguiendo la pagina A il motore se ne accorge, e penalizza.


    Questo il primo aspetto.

    I motori tuttavia non potevano sprecare una marea di risorse per capire se il testo nuovo richiamato dall'estermo dalla pagina A appartenesse a file esterni od interni rispetto al sito Z (che ospita la pagina A).

    Dovevano trovare un modo semplice, una tecnica concordata, per escludere immediatamente il "nuovo testo" di ogni pagina spiderizzata qualora appartenesse, fosse prodotto, da file esterni "loro".

    Da qui l'introduzione del iframe richiamto dal js.

    Il testo dentro l'iframe richiamato da un js non e' visibile con il "select all" e pertanto viene escluso immediatamente nella-dalla fase di controllo incrociato tra cosa ha letto lo spider e cosa ha visto il motore che ha eseguito localmente quanto letto dal suo spider.

    Siccome nessun wm stampa gatto in una sua pagina mettendo la parola gatto dentro un iframe richiamato da un js, il motore sa che, statisticamente, se vedesse gatto oltre che cane nella pagina A dovra' analizzare la situazione, mentre se gatto non lo vede e' perche' sara' all 99,999 % un testo prodotto da Adsense e simili.


    Ora ovvio che i motori potrebbero rinunciare a questo "trucco" per capire meglio cosa fa un wm, ma cosi' facendo dovrebbero usare immense risorse, perche' in questo caso dovrebbero sempre andare a confrontare se un testo nuovo appartenga a certi js preferenziali o ai js dei wm.

    Con questo sistema invece hanno risolto la questione.

    Quando fra x anni troppi wm userenno questa tecnica potranno stabilire un nuovo modo per evitare che i "loro" testi rientrino-appesantiscano il controllo incrociato tra spiderizzato ed esecuzione di quanto hanno spiderizzato.


    Si potrebbe obbiettare che protrebbero levare, prima di eseguire cosa hanno spiderizzato, tutti quei file esterni che appartengano a chi e' di loro interesse.

    Purtroppo questo sistema, che sarebbe per loro perfetto e molto pratico, non e' deotologicamente permesso.

    Un motore puo' scegliere qualsiasi strada per analizzare il web, ma qualsiasi essa sia deve valere universalmente, senza eccezioni.

    Iframe+js e' una strada, strada che chiunque di noi puo' percorrere, non e' una strada privata intestata ai soli motori.

    Trattare-escludere-valorizzare il testo loro e dei loro partner, in modo anamalo rispetto a qualsiasi altro testo, sarebbe uno scandalo che nessun motore potrebbe permettersi.

    Per questo motivo FuSioNmAn i motori non possono ignorare:

    "....i loro messaggi tramite controlli su loro stessi e non escludendo l'intero uso di iframe."

    Sarebbe' "de facto" un suicidio.


  • Super User

    My $0.02:

    • Il fatto che noi non abbiamo evidenza che i motori facciano una determinata cosa non significa che non la facciano.
    • Il fatto che i motori non facciano una determinata cosa non significa che non siano tecnicamente in grado di farla.

  • User Attivo

    Everfluxx scrive:

    "Il fatto che noi non abbiamo evidenza che i motori facciano una determinata cosa non significa che non la facciano."

    Per questo motivo e' preferibile basarsi sulla logica delle cose, sulla teoria, piuttosto che sul visibile-tangibile di ogni giorno.

    A volte pero' i motori fanno cio' che non solo non siamo in grado di "vedere", ma anche cosa non siamo in grado di prevedere-supporre, capita spesso nel caso dei brevetti.

    I seo lavorano con cosa vedono e cosa suppongono possa essere, di piu' non si puo' fare.

    "Il fatto che i motori non facciano una determinata cosa non significa che non siano tecnicamente in grado di farla."

    Indiscutibile, ma ci sono casi in cui non conta cosa sanno-decidono di fare i motori, ma cosa non possono permettersi di fare.

    E per esempio, trattare il proprio codice diversamente da un qualsiasi altro codice sarebbe deontologicamente aberrante, anche se tecnicamente potrebbero farlo in qualsiasi momento.


  • User Attivo

    @agoago said:

    Indiscutibile, ma ci sono casi in cui non conta cosa sanno-decidono di fare i motori, ma cosa non possono permettersi di fare.

    E per esempio, trattare il proprio codice diversamente da un qualsiasi altro codice sarebbe deontologicamente aberrante, anche se tecnicamente potrebbero farlo in qualsiasi momento.

    Agoago, vorrei che chiarissi questo punto: ho riletto più volte il 3d e in particolare i tuoi interventi, ma proprio non ho capito cosa intendi dire quando affermi che per un motore "sarebbe un suicidio" interpretare, tener conto (anche per calcoli interni e/o assegnazione di flag, non necessariamente per il sorting effettivo dei risultati) anche di determinate parti di codice, come gli annunci e in generale i contenuti -mi sembra sia questo il caso, correggimi se sbaglio- inseriti in un markup generato via javascipt.

    Perchè ritieni che sarebbe una mossa controproducente (aberrante e suicida, addirittura)?


  • User

    Ciao a turri,
    interessante questo argomento :

    in merito al posto di AGoAgo

    Ho scritto un post in merito un anno fa, se una pagina richiama un testo bloccato via robots, la pagine viene penalizzata.
    Questo perche' il primo spider vede un testo diverso dal testo catturato dal codice della pagina spiderizzata eseguito localmente in seconda battuta dal motore.

    Ma se si mette un testo dentro un iframe richiamato da un js, il testo letto dal primo spider ed eseguito poi localmente dal motore corrisponde perfettamente, coincidono.

    Un testo esterno bloccato via robots, ma visibile eseguendo la pagina che lo richiama, e' penalizzante, un testo bloccato o no via robots ma richiamato via iframe+js non e' visto quando il motore esegue localmente cosa ha spiderizzato il suo spider

    volevo chiederti: la tua riflessione vale anche per i codici che richiamo i banner esterni ?

    Ad esempio il codice che ci fornisce la ns agenzia publicitaria:
    prevede nell'head :

    <script type="text/javascript">
    var pageid=Math.floor(Math.random()*1000000);
    </script>

    e nell'html:

    <script type="text/javascript">
    <!--
    var sito="XXXXXXXXXX";
    now=new Date;
    bumber=now.getTime();
    sezione="HP";
    misura="728X90";
    document.write('<scr');
    document.write('ipt language="JavaScript1.1" type=text/javascript src=http://ads.XXX.it/jserver/SITE='+sito+'/AREA='+sezione+'/AAMSZ='+misura+'/ACC_RANDOM='+bumber+'/PAGEID='+pageid+'/POS=1 width=728 height=90></scr');
    document.write('ipt>');
    // -->
    </script>

    Secondo voi lìinserimento di Questo codice potrebbe comportare penalizzazioni alle nostre pagine ?

    Grazie per le risposte.

    Lino


  • User Attivo

    Mi fa male la testa 🙂

    Ad ogni modo se non ho capito male in una pagina potrei inserire dei contenuti in un iframe richiamato via javascript e tali contenuti non sarebbero visti dai motori?

    È corretto quanto scritto?

    Se Agoago sostiene una teoria del genere evidentemente ha dei test a supporto di quanto dice e non credo stia scrivendo frutto di sue teorie, giusto? 🙂


  • User Attivo

    @joker197cinque said:

    ...basta vedere come ancora oggi alcuni siti sono posizionati benissimo col trucchetto delle gif trasparenti 1X1 con i link...

    🙂 Ciao Joker

    essendo molto ignorante in materia potresti spieggarmi meglio questo tipo di tecnica ?

    Grazie
    Gianluca


  • User Attivo

    Ora ovvio che i motori potrebbero rinunciare a questo "trucco" per capire meglio cosa fa un wm, ma cosi' facendo dovrebbero usare immense risorse, perche' in questo caso dovrebbero sempre andare a confrontare se un testo nuovo appartenga a certi js preferenziali o ai js dei wm.
    Con questo sistema invece hanno risolto la questione.

    è solo questione di tempo.

    potrebbero passare 2 anni ma anche 1 mese prima che qualcosa si muova e google decida di mettere fine a un trick di questo tipo.

    Sono, come ogni soluzione di questo tipo, soluzioni temporanee, per la mia tranquillità preferisco sempre il buon vecchio "chi va piano, va sano, va lontano".

    conta che non stai parlando di 2 sprovveduti, ma di un infrastruttura che ha la maggior parte del guadagno proprio in quella che per te è una falla.

    Considerando quello che sono riscuti a fare in questi anni non credo sia un problema evitare che i loro spider non leggano i loro annunci.

    Sarebbe un problema se l'algoritmo usato fosse il tuo, ma non puoi avere la presunzione di pensare che sia l'unico modo fattibile 😉

    parli di gente che in 8 anni ha messo su il sito più visitato del mondo, ha rivoluzoinato i motori di ricerca, ha messo su adwords, adsense, earth, map, froogle, gruppi, gmail, calendar, base etc etc...

    vuoi che non perdano un mesetto a studiare un algoritmo migliore del tuo per fare quello che dici?

    senza offesa pensare che google chiami un "diff" è piuttosto riduttivo come idea 😉

    Cadere in queste tentazioni porta solo a impostare un modello di buisness non duraturo e non sicuro.

    complimenti comunque per l'intuizione, può avere i suoi (enormi) risvolti per progetti a medio breve termine.

    ciao


  • User Attivo

    Ciao a tutti,

    forse manco di fantasia e non mene voglia Agoago (che di intuizioni ne ha avute di ben più interessanti in passato) ma

    1- non vedo l'importanza epocale di quanto ipotizzato
    2- con i quality raters in giro vogliamo ancora scherzare?