E' abitudine diffusa affermare che i crawler dei motori di ricerca non siano in grado di leggere file JavaScript o CSS. In realtà quest'affermazione è falsa e facilmente documentabile da una semplice analisi dei log.
Ma allora, come mai frasi come Google non legge i JavaScript o Yahoo! non capisce i CSS sono così diffuse? Come in ogni leggenda che si rispetti, anche in questa c'è un fondo di verità. In questo articolo cercherò di dimostrare entrambi i punti di vista.
I motori di ricerca leggono JavaScript e CSS
Cominciamo dalla parte più facile, ovvero dimostrare che i motori di ricerca leggono i file JavaScript e CSS. Per fugare definitivamente ogni dubbio possiamo analizzare i log di accesso di un comune sito web.
I motori di ricerca ed i file CSS
Proviamo, ad esempio, a controllare tutti gli accessi ai un file CSS di questo blog.
$ grep '.css' access.log 85-18-66-25.ip.fastwebnet.it - - [20/Sep/2008:13:03:31 -0700] "GET /blog/styles.css HTTP/1.1" 200 720 "http://www.simonecarletti.com/blog/2006/02/perche_ho_scelto_feeddemon.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)" 85-18-66-25.ip.fastwebnet.it - - [20/Sep/2008:13:03:31 -0700] "GET /static/mt4/themes-base/blog.css HTTP/1.1" 200 9767 "http://www.simonecarletti.com/blog/2006/02/perche_ho_scelto_feeddemon.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)" 85-18-66-25.ip.fastwebnet.it - - [20/Sep/2008:13:03:31 -0700] "GET /static/mt4/support/themes/professional-blue/professional-blue.css HTTP/1.1" 200 13665 "http://www.simonecarletti.com/blog/2006/02/perche_ho_scelto_feeddemon.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)" 85-18-66-25.ip.fastwebnet.it - - [20/Sep/2008:13:03:32 -0700] "GET /static/stylesheets/blog.css HTTP/1.1" 200 5559 "http://www.simonecarletti.com/blog/2006/02/perche_ho_scelto_feeddemon.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)" 85-18-66-25.ip.fastwebnet.it - - [20/Sep/2008:13:03:32 -0700] "GET /static/stylesheets/alignments.css HTTP/1.1" 200 1815 "http://www.simonecarletti.com/blog/2006/02/perche_ho_scelto_feeddemon.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)" 85-18-66-25.ip.fastwebnet.it - - [20/Sep/2008:13:03:32 -0700] "GET /static/stylesheets/messages.css HTTP/1.1" 200 3198 "http://www.simonecarletti.com/blog/2006/02/perche_ho_scelto_feeddemon.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)" 85-18-66-25.ip.fastwebnet.it - - [20/Sep/2008:13:03:32 -0700] "GET /static/mt4/SyntaxHighlighter/Styles/SyntaxHighlighter.css HTTP/1.1" 200 4352 "http://www.simonecarletti.com/blog/2006/02/perche_ho_scelto_feeddemon.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)" crawl-66-249-70-72.googlebot.com - - [20/Sep/2008:13:06:07 -0700] "GET /static/tools/style.css HTTP/1.1" 200 10046 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" host64-86-dynamic.61-82-r.retail.telecomitalia.it - - [20/Sep/2008:13:10:22 -0700] "GET /blog/styles.css HTTP/1.1" 200 721 "http://www.simonecarletti.com/blog/2007/03/individuare-cloni-fake.php" "Opera/9.52 (Windows NT 5.1; U; it)" host64-86-dynamic.61-82-r.retail.telecomitalia.it - - [20/Sep/2008:13:10:22 -0700] "GET /static/mt4/themes-base/blog.css HTTP/1.1" 200 9767 "http://www.simonecarletti.com/blog/2007/03/individuare-cloni-fake.php" "Opera/9.52 (Windows NT 5.1; U; it)" host64-86-dynamic.61-82-r.retail.telecomitalia.it - - [20/Sep/2008:13:10:22 -0700] "GET /static/stylesheets/blog.css HTTP/1.1" 200 5560 "http://www.simonecarletti.com/blog/2007/03/individuare-cloni-fake.php" "Opera/9.52 (Windows NT 5.1; U; it)"
Non notate nulla di strano? Alla riga numero 8 è presente un accesso da un client con useragent Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html): il crawler di Google!
La user agent è facilmente modificabile e chiunque può spacciarsi, senza troppa fatica, per il crawler di Google. Per rendere il test ancora più affidabile è quindi necessario eseguire un reverse DNS dell'indirizzo IP. Per semplicità ho delegato ad Apache questo lavoro, così che il log contenga direttamente il nome dell'host al posto del corrispondente IP.
Come potete vedere, l'host associato a quella richiesta corrisponde a crawl-66-249-70-72.googlebot.com, un host di proprietà di Google. A questo punto, vale la pena eseguire una ricerca mirata nei log solo per questo host, limitando ovviamente i risultati ai soli file CSS.
$ zgrep '.css ' access.* | egrep '^.*?\.googlebot\.com' crawl-66-249-70-72.googlebot.com - - [20/Sep/2008:01:44:17 -0700] "GET /static/mt4/support/themes/professional-blue/professional-blue.css HTTP/1.1" 200 13666 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" crawl-66-249-70-72.googlebot.com - - [20/Sep/2008:13:06:07 -0700] "GET /static/tools/style.css HTTP/1.1" 200 10046 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" crawl-66-249-70-72.googlebot.com - - [22/Sep/2008:12:00:41 -0700] "GET /static/stylesheets/messages.css HTTP/1.1" 200 3199 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" crawl-66-249-70-72.googlebot.com - - [22/Sep/2008:16:28:17 -0700] "GET /static/stylesheets/messages.css HTTP/1.1" 304 256 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" crawl-66-249-70-72.googlebot.com - - [24/Sep/2008:21:32:38 -0700] "GET /mt4/mt-search.cgi?IncludeBlogs=1&search=css HTTP/1.1" 200 18391 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" crawl-66-249-70-72.googlebot.com - - [25/Sep/2008:09:11:06 -0700] "GET /static/stylesheets/blog.css HTTP/1.1" 200 5560 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" crawl-66-249-70-72.googlebot.com - - [25/Sep/2008:12:09:48 -0700] "GET /static/mt4/themes-base/blog.css HTTP/1.1" 200 9768 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" crawl-66-249-70-72.googlebot.com - - [03/Oct/2008:17:09:31 -0700] "GET /static/toolsdesign/style.css HTTP/1.1" 200 10046 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" crawl-66-249-70-72.googlebot.com - - [04/Oct/2008:11:06:55 -0700] "GET /static/tools/style.css HTTP/1.1" 200 10046 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
In modo del tutto analogo, andiamo alla ricerca di tracce del bot di MSN e Yahoo!.
Il primo si identifica normalmente con un host che termina per search.msn.com.
$ zgrep '.css ' access.* | egrep '^.*?\.search\.msn\.com' msnbot-65-55-110-231.search.msn.com - - [06/Oct/2008:23:09:26 -0700] "GET /static/mt4/themes-base/blog.css HTTP/1.0" 200 9767 "http://www.simonecarletti.com/mt4/mt-search.cgi?tag=luca conti&blog_id=1" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)" msnbot-65-55-110-231.search.msn.com - - [06/Oct/2008:23:09:27 -0700] "GET /static/stylesheets/blog.css HTTP/1.0" 200 5535 "http://www.simonecarletti.com/mt4/mt-search.cgi?tag=luca conti&blog_id=1" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)" msnbot-65-55-110-231.search.msn.com - - [06/Oct/2008:23:09:27 -0700] "GET /static/stylesheets/alignments.css HTTP/1.0" 200 1815 "http://www.simonecarletti.com/mt4/mt-search.cgi?tag=luca conti&blog_id=1" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)" msnbot-65-55-110-231.search.msn.com - - [06/Oct/2008:23:09:27 -0700] "GET /static/stylesheets/messages.css HTTP/1.0" 200 3198 "http://www.simonecarletti.com/mt4/mt-search.cgi?tag=luca conti&blog_id=1" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)" msnbot-65-55-110-231.search.msn.com - - [06/Oct/2008:23:09:27 -0700] "GET /static/mt4/support/themes/professional-blue/professional-blue.css HTTP/1.0" 200 13666 "http://www.simonecarletti.com/mt4/mt-search.cgi?tag=luca conti&blog_id=1" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)" msnbot-65-55-110-231.search.msn.com - - [06/Oct/2008:23:09:27 -0700] "GET /static/mt4/SyntaxHighlighter/Styles/SyntaxHighlighter.css HTTP/1.0" 200 4352 "http://www.simonecarletti.com/mt4/mt-search.cgi?tag=luca conti&blog_id=1" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)"
Il secondo, invece, utilizza un host tipo *.crawl.yahoo.net.
$ zgrep '.css ' access.* | egrep '^.*?\.crawl\.yahoo\.net' llf320045.crawl.yahoo.net - - [07/Oct/2008:00:02:22 -0700] "GET /blog/styles.css HTTP/1.0" 304 218 "http://www.simonecarletti.com/blog/2006/05/piu_trackback_per_tutti.php" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)" llf320045.crawl.yahoo.net - - [07/Oct/2008:00:02:25 -0700] "GET /static/mt4/themes-base/blog.css HTTP/1.0" 304 220 "http://www.simonecarletti.com/blog/styles.css" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)" llf320045.crawl.yahoo.net - - [07/Oct/2008:00:02:25 -0700] "GET /static/stylesheets/blog.css HTTP/1.0" 304 219 "http://www.simonecarletti.com/blog/styles.css" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)" llf320045.crawl.yahoo.net - - [07/Oct/2008:00:02:27 -0700] "GET /static/stylesheets/alignments.css HTTP/1.0" 304 218 "http://www.simonecarletti.com/static/stylesheets/blog.css" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)" llf320045.crawl.yahoo.net - - [07/Oct/2008:00:02:27 -0700] "GET /static/stylesheets/messages.css HTTP/1.0" 304 219 "http://www.simonecarletti.com/static/stylesheets/blog.css" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)" llf320045.crawl.yahoo.net - - [07/Oct/2008:00:02:35 -0700] "GET /static/mt4/support/themes/professional-blue/professional-blue.css HTTP/1.0" 304 220 "http://www.simonecarletti.com/blog/styles.css" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)" llf320045.crawl.yahoo.net - - [07/Oct/2008:00:02:35 -0700] "GET /static/mt4/SyntaxHighlighter/Styles/SyntaxHighlighter.css HTTP/1.0" 304 219 "http://www.simonecarletti.com/blog/2006/05/piu_trackback_per_tutti.php" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)"
Fermi tutti, abbiamo dimenticato Ask.com! Quest'ultimo si identifica normalmente con un host tipo *.ask.com.
$ zgrep '.css ' access.* | egrep '^.*?\.ask\.com' $ zgrep '.css ' access.* | egrep '^.*?\.ask.com' | wc -l 0 $ egrep '^.*?\.ask.com' access.* | wc -l 29
Niente da fare! Una ricerca per Ask.com non fornisce alcun risultato per i file CSS, mentre fornisce 29 risultati per richieste a normali pagine del blog. Possiamo quindi affermare che, tra Google, Yahoo, MSN ed Ask, Ask è l'unico motore di ricerca a non leggere alcun file .css.
I motori di ricerca ed i file JavaScript
Fino ad ora abbiamo parlato soltanto dei file CSS. Possiamo affermare che i motori di ricerca leggono anche i file JavaScript? Proviamo!
$ zgrep '.js ' access.* | egrep '^.*?\.googlebot\.com' | wc -l 26 $ zgrep '.js ' access.* | egrep '^.*?\.search\.msn\.com' | wc -l 2485 $ zgrep '.js ' access.* | egrep '^.*?\.crawl\.yahoo\.net' | wc -l 1 $ zgrep '.js ' access.* | egrep '^.*?\.ask.com' | wc -l 79
Per i file JavaScript lo scenario è nettamente differente. Ask.com legge i file JavaScript mentre, così come Google e MSN che, nello specifico, non sembra preoccuparsi che file identici linkati da documenti differenti... sono identici!
La sorpresa, in questo caso, è Yahoo! che sembra aver letto 1 solo file in 30 giorni. Come se non bastasse, questo file non è in alcun modo collegato alle pagine del blog ma si tratta di un file che avevo creato per eseguire la registrazione di un nuovo handler di feed con Firefox 2.0.
llf520133.crawl.yahoo.net - - [23/Sep/2008:01:54:53 -0700] "GET /blog/public/2006/11/firefox_new_feed_handler/firefox2-registerFeedHandler.js HTTP/1.0" 200 1623 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)"
Frequenza di accesso
Per i più curiosi, ecco la frequenza di accesso ai file JavaScript e CSS calcolata negli ultimi 30 giorni, suddivisa per motori.
| Motore di Ricerca | CSS | JavaScript |
|---|---|---|
| 9 | 26 | |
| MSN | 2915 | 2485 |
| Yahoo! | 1887 | 1 |
| Ask | 0 | 79 |
Scaricare non vuol dire leggere!
A questo punto qualcuno potrebbe obiettare che, analizzando i log, non è dato sapere se il crawler abbia realmente letto il contenuto file o se si è limitato a richiederlo. E' vero, ma è illogico pensare che un crawler decida di sua spontanea volontà di scaricare un file JavaScript collegato esternamente da un tag script... solo per generare accessi al server!
Inoltre ci sono diversi modi per dimostrare come il file, in seguito, in effetti venga letto. Non mi dilungo ulteriormente, alcuni di questi sono contenuti leggendo tra le righe nei paragrafi seguenti.
Leggere vs Interpretare vs Eseguire
Fermi, dove scappate... non è mica ancora finito l'articolo! Prima di tornare al menu di navigazione con link in JavaScript è importante essere a conoscenza della sottile differenza tra leggere, interpretare ed eseguire. Questi tre verbi potrebbero sembrare sinonimi, ma non è così.
I crawler normalmente leggono i file JavaScript e CSS ma, come scrissi un anno fa nell'articolo Cosa gli spider dei motori di ricerca non sanno fare, questo non significa necessariamente che intendano eseguirlo.
In altre parole. I crawler scaricano il contenuto dei file, i sorgenti all'interno vengono normalmente interpretati (soprattutto nel caso di JavaScript) ma quasi mai eseguiti. Questo significa, ad esempio, che un crawler può facilmente scoprire il significato della funzione seguente ma non vuol dire che il dominio paradise.god sarà indicizzato.
function redirect_me_to_paradise {
document.location.href = 'http://paradise.god';
}
Per questo motivo spesso si tende ad affermare, in modo improprio, che i crawler non leggono JavaScript o CSS indicando che il loro contenuto non viene eseguito come ci si potrebbe aspettare e come avviene invece con un normale browser.
Perché i motori di ricerca leggono i file JavaScript e CSS?
L'esempio precedente dovrebbe cominciare a chiarire alcune delle motivazioni per le quali i motori di ricerca hanno cominciato a leggere ed interpretare il contenuto di file JavaScript e CSS. In passato entrambi i linguaggi sono stati largamente utilizzati per nascondere agli occhi degli utenti contenuti realizzati esclusivamente per i motori di ricerca, all'unico scopo di sfruttarne il posizionamento a favore di terze pagine. Per approfondimenti sul tema vi consiglio l'articolo Testo Nascosto, scritto da Vincenzo.
Tecniche come redirect in javascript, doorway page, blocchi di testo nascosto sono oggi nel mirino dei filtri antispam di quasi i motori di ricerca. Per individuarle è necessario analizzare ed interpretare il contenuto di questi file, spesso inseriti esterni alla pagina nella (vana) speranza di eludere il crawler del motore di ricerca.
Per calcare ulteriormente la mano su questo punto vi consiglio alcune letture direttamente dal blog di Matt Cutts:
- SEO Mistakes: sneaky JavaScript
- SEO Mistakes: software mistakes
- SEO Mistakes: crappy doorway pages
- SEO Mistakes: Spam in other languages
- Ramping up on international webspam
- SEO Advice: clean house before press releases
- "Undetectable" spam
In conclusione
Webmaster, SEO, spammer ed utenti siete avvisati! Qualunque sia il vostro scopo finale, siate consapevoli del fatto che i motori di ricerca leggono JavaScript e CSS, normalmente li interpretano, raramente li eseguono. Ovviamente non è escluso che il comportamento possa variare in futuro.
Simone,
permettimi di dissentire su quanto hai scritto. Premetto che sto uscendo di corsa e quindi rispondo solo in funzione del titolo.
Non è detto che i motori sappiano leggere il css o il js (o ecma) ma questo non significa che non lo scarichino.
E' intrinseco, infatti, ad ogni piattaforma di log riportare ogni singola hit compiuta da chiunque navighi sul tuo sito.
Questo significa che se chiami la pagina a.htm e questa dentro ha diverse risorse embedded (video, js, css) tu ti ritroverai nel tuo log la tua pagina e in automatico tutte quelle risorse in essa linkate, perchè la cosa è pressochè automatica.
Il motore, infatti, non può discriminare a priori un file solo perchè ha estenzione css o js, ma lo farà solo dopo averne letto la sua intestazione. Quindi quantomeno la hit te la ritrovi.
Ciao Andrea,
questo non è corretto. Così funzionano i browser ma solo perché sono stati istruiti per farlo.
Un crawler è un client molto più semplice e ragiona per singole richieste. Quando viene richiesta di scaricare la risorsa A, anche se essa contiene risorse embeddate questo non vuol dire che vengano scaricate anch'esse.
Un esempio? Prova a scaricare una pagina con wget
$ wget http://www.simonecarletti.com/
e guarda i log. Noterai solo una hits, quella della pagina.
Infatti questo è proprio uno dei comportamenti classici per distinguere un rich client (browser) da un crawler.
Non per ultimo, lo puoi vedere tu stesso. Filtra i log per vedere solo le richieste di Googlebot. Noterai come ad ogni chiamata di pagina non corrisponde una chiamata dei file inclusi.
Se li chiama è perché lo fa di proposito. ;)
Ciao
non ho wget installato, quindi non avrei di che provare. Però per quanto posso vedere dai miei log (tutte macchine windows) noto sempre questa corrispondenza secca, da qui la mia affermazione.
Del resto, se fosse il contrario, si direbbe proprio che faccia discriminazione solo basandosi sulla lettura di una estenzione. Mi pare un pò strano.
Voglio approfondire. Ma adesso fammi veramente uscire.
Ok, ho scaricato, compilato e installato wget. Quello alla fine è un semplice download manager, quindi mi pare logico che se gli dici scarica a.html ti scarica solo quello e basta.
Nel mentre ho provato a sbirciare meglio nei log, e trovo entrambe le situazioni, quindi solo file.html, tutto il pacchetto (html e risorse varie).
Mi viene a questo punto da azzardare l'ipotesi che fatta eccezione per la prima volta in cui il motore scarica tutto di tutti, le volte dopo si preoccupa solo di verificare l'htmlp er aggiornare la sua copia cache e solo di rado ti verifica anche gli altri file.
PS. Che software è quello che usi per l'analisi dei log? Tu mi pare lavori su mac, se non erro, giusto?
No, wget non è un vero e proprio download manager. E' più propriamente un http client. ;)
E cos'è un crawler se non un http client più evoluto?
Se hai mai avuto modo di sviluppare un crawler ti sarai senz'altro accorto che se tu chiedi l'URI A lui scarica solo A. Anche perché scaricare una pagina non vuol dire per forza voler elaborarne il contenuto.
Per chiarire il funzionamento di un crawler e come avviene la gestione della coda delle richieste ti consiglio di vedere qualche progetto open source, come ad esempio http://lucene.apache.org/nutch/
Non è Googlebot o Yahoo, ma è un ottimo case study. :)
Ad esempio, immagina un bot scritto in Ruby. Il core sarebbe probabilmnte una cosa tipo
require 'net/http'
response = Net::HTTP.get_response(URI.parse('http://www.simonecarletti.com/'))
Se provi ad avviare questo script vedrai che si tratta di una sola e singola hit.
Osserva il comportamento a confronto di due bot e del tuo browser (ovvero di un utente reale) per 1 singola richiesta.
http://www.simonecarletti.com/blog/public/2008/10/miti-e-leggende-seo-3/client-activity.txt
http://www.simonecarletti.com/blog/public/2008/10/miti-e-leggende-seo-3/googlebot-activity.txt
http://www.simonecarletti.com/blog/public/2008/10/miti-e-leggende-seo-3/yahoobot-activity.txt
Per quanto riguarda i software nessuno di particolare.
Tutte queste analisi sono fatte ad occhio nudo sfruttando le utility di sistema di Mac/Linux come grep, egrep, cat, less etc.
Per le analisi complesse ho dei parser più evoluti, come http://code.simonecarletti.com/projects/show/apachelogregex :)
wget è si un http client, ma è ottimo come download manager anche. te lo assicuro :)
La funzione di resume è eccezionale.
Ma senza passare fuori campo. Entrambi stiamo dicendo cose di senso compiuto.
Per quanto mi riguarda, nei corsi di posizionamento mi trovo sempre quello che mi dice - "ma tanto i motori non sono in grado di capire JS e CSS" - ed ogni volta mi tocca spiegare quello che hai scritto e sul quale concordo.
Perfetto.
Da oggi mi eviterò la spiegazione e passerò la URL di questo post :D
L'articolo mi sembra tutto pignolino e vuole dire che altra genti usa il linguaggio in modo improprio, ma meso tutto insieme è un po vuoto
Gli spider scaricano Javascript e CSS? Certo che si, chi fa questo lavoro da più di qualche mese lo sa.
Legono i Javascript? Si e no.
Li legono e cercano anche di interpetarli attraverso interpreti js embedded, ma non è detto che capiscano tutto.
Lo spam fatto attraverso l'uso di tecniche javascript (o css) è "detectable"? Si e no.
Dipende da quanto è complicato il codice, se utilizza obfuscatore e così via.
Funzionano tecniche Spam che utilizzano Javascript? Quelle non ingenue si, ma prima o poi passerà una quality rater e quindi bisogna fare troppa attenzione.
In ogni caso usare un file javascript esterno per nascondere del testo è modo sicuro per far vedere agli spider quello che vogliamo, è non è detto che uno lo fa solo per fare spam.
Visto? In poche righe detto tutto, senza dire che gli altri usano il linguaggio in modo improprio.
Quindi quando un SEO dice per brevit "Che gli spider non legono Javascript" non sta seguendo un mito, solo non ha voglia di scrivere un articolo luuuuuuuuuuuuuuuuungo e vuoto.
Soloseo, nel tuo commento vedo solo frasi del tipo "potrebbe essere ma anche no", senza né prove né documentazione. Questo è proprio il tipo di abitudini che portano ad alimentare miti e leggende... o flame?
Di affermazioni senza uno straccio di prova, di test o di documentazione alla base né è pieno il web.
Personalmente preferisco spendere un po' più di tempo quando scrivo qualcosa e fare in modo che quanto affermo possa essere documentato.
Simone, no flame by me, forse il tuo post è in potenza un "flame" inutile contro chi dice "spider non leggono js e css".
Cosa hai documentato? Che gli spider legg...pardon, "scaricano", CSS e JS?
Roba di due anni fa e bastava un Awstats (vero però che legere diretamente i log con grep è più cool :D).
Quello che io dico posso documentarlo, ma non c'è bisogno già lo sa chi fa il nostro lavoro, o forse sotovaluti i tuoi followers?
Segnalo anche http://mechanize.rubyforge.org/mechanize/ per giocare a fare gli spider.
Su questo spider si può dire con certezza, almeno per ora, che non interpreti i javascript però può salvare i cookie, compilare form, seguire link etc.
Hai ragione Andrea, WWW::Mechanize è una libreria straordinaria.
Altrettanto straordinaria è Hpricot, il parser HTML alla base. Per fare scraping è la migliore libreria che abbia mai visto. :)
Ottima segnalazione, grazie!
PS. E' bello scoprire altri Rubysti in Italia! :D
E quando Google si imbatte in funzioni che ricorrono a framework come Mootools, Prototype o ExtJs che generano animazioni a tempo e/o al passaggio del mouse come ragiona?
Non credo sia fattibile per un motore capire se un div è momentaneamente nascosto perchè fa parte di una classe che genera un effetto carousel per esempio...
Non quanto credi. ;)
Dimentichi, ad esempio, che meno di un mese fa Google ha lanciato Chrome. Non per ultimo, alla base di Chrome c'è un progetto molto interessante chiamato V8, un innovativo motore per l'interpretazione di JavaScript.
http://code.google.com/p/v8/
Dulcis in fundo, c'è un particolare dello sviluppo di Chrome (quello che Matt Cutts ha chiamato Chromebot) molto interessante che potrebbe aprire ad ulteriori considerazioni:
Attenzione però a ciò che ho scritto: ho detto "momentaneamente".
Il senso che dà questa parola al mio periodo è molto più complesso.
Può un motore capire se un utente, mentre sfoglia la pagina web, ha la possibilità di vedere quel div magari fra qualche secondo oppure passando con il mouse sopra a qualche elemento a cui il framework ha prontamente assegnato la funzione di renderlo maggiormente visibile.
Cioè: ha senso per un motore sprecare tutte queste risorse di calcolo per definire qualcosa che è grafica di un layout dinamico?
Può un motore capire qual'è il limite dello spam grafico?
Questa cosa può portare benefici alle serp?
Secondo me, la guerra ai feticisti del testo nascosto e simili è già stata vinta anni fa e probabilmente Google neanche la combatte più...
Se cerchi di ingannarlo stupidamente se ne accorge, ma la potenza del nuovo modo di concepire siti esula, a mio avviso, da volerlo ingannare.