Uno tra i miti e le leggende SEO più diffuse, soprattutto negli ambienti fai-da-te o amatoriali, è quella in cui si afferma che i motori di ricerca (in particolare Google) prediligano le pagine HTML statiche. Quest'affermazione per certi versi potrebbe avere un fondo di verità, tuttavia l'interpretazione comunemente usata è errata. Vediamo perché.
Che cosa significa che un motore di ricerca ama le pagine HTML? Rispetto a cosa? L'affermazione potrebbe essere interpretata in molti modi:
- Il motore di ricerca preferisce pagine con codice HTML, rispetto a quelle con codice PHP o ASP.
- Il motore di ricerca preferisce pagine con contenuto HTML, rispetto a contenuti immagini o Flash.
- Il motore di ricerca preferisce pagine che sembrano scritte in HTML, rispetto a pagine dinamiche.
- ... altro?
Da sola, un'affermazione con più interpretazioni è destinata a diventare un mito. Nel momento stesso in cui ci si esprime in un modo non chiaramente interpretabile, ecco che chiunque ascolterà l'intervento confezionerà l'affermazione con una sfumatura personale che non necessariamente corrisponde esattamente a quello che si intendeva dire.
Prima di proseguire nell'articolo ritengo utile una precisazione, doverosa a seguito del commento di Libero Guerra e dell'articolo Google preferisce le pagine HTML pubblicato da Jonnie come promesso.
In questo articolo utilizzerò i termini pagine HTML e pagine statiche quasi come sinonimo, in contrapposizione alle pagine dinamiche scritte con un linguaggio server side. E' indubbio che i crawler web preferiscano le pagine HTML intese come quelle servite con content type text/html, nonché a seguire eventuali derivati di content type di natura testuale rispetto a rich content type come audio, video e multimedia in genere. Diverso è il focus di questo articolo, che analizza invece l'affermazione comune che mette a confronto pagine statiche e pagine dinamiche, a parità di content type utilizzato.
Pagine dinamiche vs Pagine statiche
Comunemente, l'affermazione Google ama le pagine HTML è utilizzata per indicare una ipotetica preferenza dei motori di ricerca per le pagine statiche, scritte in puro HTML, senza l'introduzione di linguaggi server side come PHP, Ruby o ASP. L'ipotesi che i motori di ricerca preferiscano una pagina statica "classica" è figlia di un altro importante mito che vorrei discutere più avanti. Per ora, ci basti essere consapevoli che agli occhi di un crawler una pagina statica non ha particolare preferenza rispetto ad una dinamica.
Linguaggi server side vs HTML
Proseguendo sul mito client side vs server side, l'affermazione i motori di ricerca amano le pagine HTML è spesso sintomo di una scarsa conoscenza del funzionamento di interpretazione di una pagina web. E' infatti diffusa la credenza che una pagina scritta con un linguaggio server side possa in qualche modo essere meno digeribile rispetto al classico HTML.
In realtà, non vi è alcuna differenza. Ogni pagina web, sia essa scritta in qualsiasi linguaggio server side, restituisce come output codice HTML o, al massimo, markup equivalente come XML o XHTML. Le istruzioni server side sono tali poiché vengono elaborate dal server prima che la pagina sia restituita all'utente e al client arriva esclusivamente l'output dell'elaborazione.
L'uso di un linguaggio come ASP o PHP, dunque, non influisce in alcun modo sul codice HTML restituito. Semplicemente, l'utilizzo di una tecnologia server side estende la possibilità di creare pagine web ad elevata interazione, con una memoria e la capacità di reagire in modo differente a seconda della richiesta inviata.
Lo screenshot seguente dimostra come una pagina HTML ed una PHP producano esattamente lo stesso output.
Poiché, in fin dei conti, una pagina "dinamica" produce lo stesso output di una pagina "statica", sotto questo punto di vista non ha ragione di esistere alcuna preferenza.
E' possibile individuare con precisione una pagina statica?
Se ancora non foste convinti di quanto discusso nei paragrafi precedenti, cerchiamo ora di immedesimarci in un motore di ricerca e ipotizziamo di voler attribuire una preferenza ad una pagina statica. Per procedere dobbiamo innanzi tutto riconoscere una pagina statica, al fine di poterla premiare. Ma è possibile?
Con i moderni web server, la possibilità di stabilire se la pagina richiesta sia statica o dinamica è pressoché inesistente, a meno di non aver accesso fisico alla macchina e verificare con mano la presenza del file. Ci sono elementi indicatori in grado di offrirci un qualche suggerimento, ma ognuno di questi può essere falsato o invalidato.
L'estensione della pagina
Partiamo dall'estensione del file. Sebbene siamo abituati a pensare all'estensione come elemento rappresentativo del tipo e contenuto del file, l'estensione è solamente indicativa. Ci sono siti dove la condigurazione del server nasconde completamente l'estensione. Ne sono un esempio i blog PHP basati su WordPress come Edit dove il permalink di ogni post, ad esempio questo, non ha estensione.
Un altro esempio è il sito del programma ASP Stats, scritto in Ruby. Eppure, nessuna pagina ha estensione .rb.
Ci sono poi i casi in cui l'estensione c'è ma non corrisponde ad alcun linguaggio o, addirittura, ad un linguaggio differente. Proprio a causa del mito prima descritto, in passato ci sono stati migliaia di siti le cui pagine contenevano l'estensione .html pur essendo scritti in linguaggi server side come PHP.
L'estensione non è vincolante.
Header HTTP
L'analisi degli header HTTP di una pagina costituisce un altro indizio fondamentale per tentare di individuare una pagina statica ma, ancora una volta, non offrono alcuna garanzia. Alcuni header sono più "complessi" da manipolare e spesso la loro presenza indica una pagina statica, ma questo non significa che non sia possibile inserirli volutamente restituendo una pagina con un linguaggio server-side.
Prendiamo ad esempio la seguente risposta HTTP, restituita in richiesta ad una pagina statica (ne sono certo, l'ho scritta io!).
Date: Sat, 20 Sep 2008 14:37:34 GMT Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 Phusion_Passenger/2.0.3 DAV/2 SVN/1.4.2 Last-Modified: Sat, 16 Feb 2008 22:14:45 GMT Etag: "2524778-134a-d9a8ff40" Accept-Ranges: bytes Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 2025 Content-Type: text/html 200 OK
Le chiavi più significative sono quelle che ho formattato in grassetto. Per il significato di ciascun header consiglio la lettura delle specifiche del protocollo HTTP.
Content-Length e Etag sono soliti indicare un'alta probabilità che una pagina sia statica. Questo perché, di norma, in presenza di una pagina statica il web server ne conosce il peso in byte con assoluta certezza e lo può indicare: la pagina esiste, al contrario di una server side non subirà modifiche prima di essere restituita al client.
Ad ogni modo, questo non mi impedisce di calcolare il peso di una pagina server side in fase di elaborazione e falsare l'header.
In PHP è possibile catturare l'output usando un buffer e la funzione ob_start per poi scrivere l'header con header.
L'header Etag è un altro elemento indicativo. Rappresenta univocamente una determinata risorsa all'interno del sito e, anche in questo caso, è normalmente aggiunta in automatico dai web server in quanto una pagina statica è facilmente rappresentabile in modo univoco.
Rappresentare una pagina dinamica richiede la generazione di un hash univoco per il suo contenuto, ma questo non è un problema così insormontabile.
Rails, ad esempio, permette di generare l'Etag per una risposta in modo quasi banale, assegnando un oggetto di riferimento all'oggetto Response.
class ArticlesController < ApplicationController
def show
@article = Article.find(params[:id])
# Set the response headers to accurately reflect the state of the
# requested object(s)
response.last_modified = @article.published_at.utc
response.etag = @article
# .. continue
end
end
Come potete vedere, in questo esempio l'Etag è generato in automatico a partire da un array di oggetti Article. Fin tanto che quella pagina conterrà lo stesso array di elementi, il valore di Etag rimarrà inviariato.
Backlist vs Whitelist
Poichè, come dimostrato, non ci sono elementi certi (whitelist) per definire una pagina statica, in questo caso è più comune adottare il processo inverso (blacklist): possiamo isolare i comportamenti certamente non riconducibili ad una pagina statica ed ottenere con maggiore precisione una lista di pagine verosimilmente statiche.
Ancora una volta si tratta però di un'analisi empirica, particolarmente soggetta a falsi positivi.
In conclusione
Abbiamo dimostrato come l'affermazione che i motori di ricerca preferiscono le pagine HTML sia priva di fontamento per due motivi. Innanzi tutto perché ad oggi non c'è una ragione reale per un comportamento simile, in secondo luogo perché sarebbe difficile stabilire con certezza se la risorsa sia una pagina HTML statica o scritta in un linguaggio server side.
Secondo me Lei ha dimenticato un'interpretazione a mio avviso importate, che sicuramente porta ad affermare che la frase "Google ama i MDR" è VERA e non un mito.
Come ben sappiamo tutte le pagine web, da quelle dinamiche a quelle statiche sono formate da codice html.
Un buon posizionamento delle proprie pagine web è dato dal fatto che le suddette pagine siano scritte con codice html ben formato, pulito e digeribile. Per far ciò basta seguire le indicazioni del consorzio W3C.
Google non ama il Flash perchè non è scritto in puro codice html che rispetta le regole sopra citate.
Provate a scrivere la stessa pagina in due formati, una in flash e l'altra in puro html. Vedete la differenza e sicuramente arriverete alla conclusione che Google ama l'html
;-)
Ciao Simone, aspettavo con ansia questi post, lo sai che questo argomento mi entusiasma, se non ti dà fastidio ti dico quel che ne penso con un post sul mio blog :)
@ Libero
In realtà la tua affermazione non è propriamente corretta. :)
Non è possibile porre sullo stesso piano un linguaggio server side e Flash.
Infatti, mentre sia HTML sia ASP/PHP restituiscono un output testuale (uno stream di testo, sia esso un formato txt, html, xml...), Flash restituisce un formato multimediale.
La tecnologia Flash, così come le altre risorse multimediali quali video, filmati ed immagini non sono progettate per essere indicizzate da un client che si aspetta del testo dunque è ovvio che nessun crawler predisposto per contenuti testuali sia in grado di estrapolare le informazioni da un file Flash e Video.
Mentre lo stesso crawler non trova alcuna differenza in una pagina scritta in solo HTML rispetto ad una pagina realizzata con un linguaggio server side, indubbiamente non supporterà gli elementi multimediali all'interno di quella pagina.
Mi rendo conto che sia difficile da esprimere, ancora più in un commento. Forse ci vorrebbe un post.
Ad ogni modo, ti fornisco alcuni altri punti di riflessione. Ogni pagina che contiene Flash normalmente è composta da una pagina HTML che include via tag object o embed il filmato. Esattamente come avviene per una qualsiasi altra risorsa multimediale (vedi video).
Non esiste nulla di HTML in un elemento Flash. Il formato Flash è un formato proprietario. Non per ultimo non è un formato per il web e l'affermazione
> Provate a scrivere la stessa pagina in due formati, una in flash e l'altra in puro html.
non è corretta poiché paragoni due tecnologie su un piano che non può essere paragonato.
E' come paragonare il comportamento di un browser con un client email. Solo perché entrambi richiedono una connessione internet e in alcuni casi i loro ambiti di accavallano non vuol dire che siano paragonabili.
Puoi comparare le funzionalità di Firefox con Safari, ma non Firefox con Thunderbird. :)
Per concludere la risposta al tuo intervento, non è che i MdR amano l'HTML rispetto a Flash. Nel tuo caso è che i MdR pretendono dei contenuti testuali (che sia ASP/PHP/HTML/XML... possono fornire) poiché per questo sono progettati e non sono (ad oggi) in grado di estrapolarli con uguale capacità da elementi multimediali come video, flash o immagini.
@ Johnnie
Fa come se fossi a casa tua. ;)
Mah! secondo me c'è un bug nella tua affermazione caro Simone. ASP | PHP appartengono ad una categoria di linguaggio molto diversa da quella di HTML | XML... non li metterei mai nella stessa riga :(
Ho dovuto condensare la risposta ad un commento e questo ha richiesto che "saltassi qualche passaggio".
Il mio obiettivo era sottolineare come linguaggi server side come ASP/PHP/Ruby/Python/Java possano avere come output pagine XML/HTML (ed è questo quello che intendevo nel paragone) mentre Flash non è né pensato né utilizzato per produrre in output file di testo come pagine (X)HTML.
Spero di aver chiarito meglio ora. :)
grande simone, post chiarissimo.
lo riproporrò prossimamente anche su italianwebdesign ;)
OT: ummm, oggi se non ricordo male è anche il tuo compleanno! auguri!!!!!!!! :)
Quoto tutto aggiungendo un aneddoto:
Situazione: sito anziano, tipo del 97-98 con un buon successo ma scritto a pezze. Latenza e lentezza assurde.
Il tipo si è rivolto a noi e glie lo abbiamo riscritto da zero, trovando chicche del tipo:
- caricamento di una intera tabella di un db di eventi, 10.000 eventi tipo, e parsing dell'array a botte di ereg_replace per cambiare date ed apici;
- uno sleep(60*60*24) che ancora non ho capito a cosa servisse se non far bloccare la pagina per timeout e bestemmiare pesantemente il server
Abbiamo usato un sistema di caching e creato alcune pagine staticamente sul fs senza passare dal db se non una tantum.
Ovviamente il server è rinato e *magicamente* googlebot ha incominciato non più a passare ogni tanto ma si è letteralmente divorato il sito.
Il tipo alla fine ha riassunto tutto il lavoro con:
"hai visto che alla fine bastava fare il sito in html?" :)
PS: Nel caso johnnie avesse ragione, auguroni!
Complimenti Simone, concordo con te in pieno.
Non starei a fare troppi sofismi sulle differenze intrinseche tra "Server Side" e "Client Side", il concetto che hai voluto trasmettere è chiarissimo e ben sintetizzato.
Certo, è difficile accontentare tutti ;)
Hai pensato anche di trattare argomenti SEO 2.0?
Magari si potrebbe aprire un gruppo di discussione su qualche Social Network :)
Io ci stò provando su Viadeo e ci proverò anche su LinkedIn, ma cerco manforte.
@ Johnnie
Ricordi bene! ;)
Grazie anche a Massy.
@ Massy
Che bello vederti per qua ogni tanto! ;)
Grazie per il tuo contributo, non poteva essere più a tema. :)
@ Angelo
Prima di arrivare al SEO 2.0 c'è parecchio lavoro da fare sul SEO "old style" ma non mancherò di toccare qualche nuovo argomento.
Se hai proposte specifiche, sentiti libero di inviarmele qui tra i commenti o via email.
Ottimo articolo. alla prox.
Bah, io non so come funzioni Google, che tipo di algoritmi usi, ecc., ecc.. Credo che solo chi ci lavori ne sappia qualcosa, quindi per quanto mi riguarda questo post è fuffa. :)
In un primo momento ho anche pensato di scrivere quali sono, secondo me, i motivi per cui le pagine in html sono "digerite meglio" dai motori di ricerca, ma perchè dovrei? Non mi conviene mica, ed è buono per me che altri pensino che questi articoli siano davvero utili ai fini del posizionamento, perchè così continuerò a posizionare per bene i sitarelli che faccio mentre altri leggeranno questi post e staranno sempre indietro. :)
P.s. però una cosa c'è da dirla: una persona per parlare di seo, deve avere il suo sito (o blog) posizionamento bene sui motori, perchè questo da garanzia della "bravura" di chi scrive gli articoli. Se invece questi articoli non sono utili nemmeno a chi li scrive in quanto il suo sito (o blog) non lo trovi tramite i motori ma solo tramite linkaggio di altri siti, credo non valgano molto. :)
Dadan, accetto le critiche ma solo quando chi le pubblica (1) non si nasconde dietro IP anonimi e email fasulle ed ha il coraggio di assumersi la responsabilità di quanto afferma, (2) motiva ed argomenta la teoria alla base delle proprie affermazioni.
Per quanto mi riguarda, il tuo commento hon ha alcun fondamento, non per ultimo l'affermazione legata al posizionamento di questo blog che, come dimostrano accessi e statistiche, gode di ottima salute.
Ad ogni modo, apprezzo il tempo che hai speso su queste pagine e che hai dedicato nello scrivere il tuo commento.
1) Il tuo blog gode di ottima salute non perchè viene trovato su Google, ma perchè vi commentate a vicenda, tutto qui. :)
2) Ho già argomentato il motivo per cui credo sia fuffa. :)
3) E' importante il concetto e non il nome di chi lo esprime. Potrei firmarmi e linkare un sito qualunque. Cosa cambierebbe? Nulla, no? :)
Baibai.
Ciao Simone,
ottimo articolo... demitizzare è sempre un bene.
Concordo con lo spirito e le conclusioni: il MdR ha un solo strumento per leggere una pagina: il suo bot, il quale capisce solo una lingua, il testo, a prescindere dalla tecnologia con la quale è generato. Lui vede l'output e se ne sbatte delle tecniche usate per produrlo.
Le pagine "html" statiche non sono affatto digerite meglio di quelle generate con linguaggi server side e chi lo dice non sa letteralmente di cosa parla. Questa si che è pura fuffa.
Un CMS in php/asp ben progettato e veloce è indistinguibile dal punto di vista delle performance sui motori da un sito statico. Il fatto è che spesso i CMS, specie se sostenuti da db pesanti e mal querati, hanno tempi di risposta inaccettabili e, come chiunque con un po' di mestiere sa, i tempi di risposta al bot fanno una grande differenza. Lo svantaggio di un sistema server side risiede quindi sulla sua eventuale lentezza - se progettato male - ma non dipende assolutamente dalla tecnologia usata in quanto tale.
Solo una aggiunta. Quando dici che il motore non potrebbe agevolmente distinguere le pagine server side da quelle realmente statiche.... beh... un sistema abbastanza preciso ci sarebbe: controllare la data della risorsa chiamata.
Se è sempre fresca e coincidente con la chiamata ecco che siamo in presenza di pagine dinamiche, se invece è diversa si tratta con plausibilità di pagine statiche.
Esempio, usando un banale:
javascript:alert (document.lastModified) scopro che
http://www.simonecarletti.com/blog/2008/09/query-case-sensitive.php è generata nell'attimo stesso in cui la chiedo, mentre http://www.simonecarletti.com/robots.txt è del 13 maggio.
Ciao, a presto.
Io trovo che Simone abbia pienamente ragione. Unico motivo per cui google poteva preferire le classiche pagine statiche HTML era semplicemente per l'url che appariva semanticamente più corretto che di un url http://www.esempio.com/index.php?id=23, anche perchè a google piace molto che nell'url venga citata una parola che un po' descriva il contenuto della pagina. Con il mod_rewrite di apache è stato possibile ovviare al problema creando url del top http://www.esempio.com/dicono-di-noi/ o addirittura fare in modo di aggiungere l'estensione /dicono-di-noi.html (ma l'estensione non importa a google)... Google ama che nell'url appaia una parola descrittiva del contenuto della pagina. E' semplice testare la cosa caricando una pagina online e poi cercare tramite google, capita spesso che la parola chiave che google trova, la prenda proprio dall'url (TUTTO TESTATO CARI MIEI)
Google premia chi ha del contenuto valido, non importa se poi il codice è perfetto, purchè sia accessibile, purchè google lo possa leggere! Ovviamente c'è tutto sotto un algoritmo, ma la cosa che google preferisca l'html è assurda, anche perchè chiunque scriva un po' di codice php e si occupi di webserver sa che facile mostrare un contenuto simile ad una pagina html. L'output generato come ha ben detto simone, lo decidi tu da bravo programmatore PHP. Se io non genero codice html come output nella mia applicazione PHP, non vedo come possa diventare una pagina web.
e per chi ha detto che la cosa si dovrebbe provare tramite statistiche ed altro, google per nostra fortuna ci da tante statistiche a portata di mano, basta solamente saperle usare.
Adobe, Microsoft, Apple, e tanti altri siti importantissimi che non si potranno mai affidare a semplici pagine html, anche perchè le applicazioni server side semplificano la vita e ti permettono di gestire un contenuto in pochi minuti senza dover cambiare i link del menu ad ogni pagina html per ogni pagina aggiunta.
Scusate se mi sto esprimendo malissimo, ma ho così tanti validi esempi per la testa e mi rendo conto che si parla sconoscendo del tutto le tecnologie.
Ritornando al fatto di adobe ecc ecc...
provare per credere cercando su google "cache:www.adobe.com" o la medesima cosa con microsoft...
risultano indicizzate perfettamente...
perchè google le indicizza?? dovrebbe preferire il tuo sitarello fatto di pagine statiche HTML??
Ci sono così tanti fattori che determinano la qualità di una pagina che dire semplicemente che google preferisca pagine statiche anzicchè server side ci fa cadere nel ridicolo.
Tornando a flash, vi consiglio di cercare un po' su google l'argomento. Ho letto che google tempo fa si stava muovendo per imparare a leggere anche i file SWF e indicizzare il loro contenuto. (LA TECNOLOGIA SI EVOLVE).
Google si adatta sempre. Le sue uniche preferenze sono: "HO TROVATO GLI ELEMENTI CHE CERCAVO PER RIEMPIRE CORRETTAMENTE IL MIO DB?".. o addirittura: "HO IMPIEGATO TROPPO TEMPO A CAUSA DEL SERVER LENTO? (SE E' LENTO MEGLIO CHE NON SPRECO IL MIO TEMPO AD INDICIZZARE QUESTO SITO E INDICIZZO ALTRI CHE IMPIEGANO MENO TEMPO).
La cosa più bella è che lo stesso google tramite i webmaster tools ci aiuta a capire come funziona.
SIMONE il tuo articolo è chiaro e concordo con te. Unica pecca è che non si potrebbe mai ridurre il tutto ad un post, ci sarebbero così tanti motivi che si potrebbe scrivere un libro. :P Complimenti...
ottimo post
Volevo chiedervi una cosa che sta a cuore a tutti coloro che usano coppermine.per la pubblicazione di immagini.
In questo caso il motore di ricerca google è quasi inesistente
http://www.studentitorino.it/foto-torino/
grazie
@ Daniele
Un libro? Sì, ma non una guida SEO... Non avrebbe senso e non mi divertirebbe! ;)
A proposito della citazione di Google e mod_rewrite, curiosamente Google la settimana scorsa ha pubblicato un interessante documento in merito:
http://googlewebmastercentral.blogspot.com/2008/09/dynamic-urls-vs-static-urls.html
In alcuni passi Google arriva anche a suggerire di non riscrivere le URL, per evitare potenziali danni causati da regole di rewriting errate.
Ovviamente, prima di saltare a conclusioni affrettate è bene leggere attentamente il documento ed anche "tra le righe".
Quello che tu affermi è la stessa cosa che intedevo dire io.
Scrivere la stessa pagina, una realizzata in flash e l'altra in html non è impossibile come tu affermi. Io mi riferisco al layout fisico e grafico della pagina e non al codice html o flash utilizzato.
I MDR non amano il flash perchè non c'è contenuto da estrapolare come hai anche tu affermato.
Abbiamo detto la stessa cosa.
A presto