Ogni giorno ho la conferma di quanto l’ottimizzazione dei contenuti e della struttura di un sito web in chiave SEO sia un processo che necessita di un bagaglio di skill tecnici molto più ampio di quanto comunemente si pensi. Non basta più scegliere bene il contenuto dei tag title, e disporre ad arte le keyword negli heading, ma serve una buona base statistico/matematica oltre che ad una padronanza tecnica degli aspetti di sistema che stanno dietro ad una pagina web, primo fra tutti il controllo del web server (o dell’application server) e dei moduli per le operazioni di rewrite, proxying etc.

Il recente aggiornamento Google Panda, ha come scopo dichiarato la lotta alle directory ed a tutti quei siti il cui contenuto si presenta come di scarso valore per il visitatore ad esempio perché duplicato, o difficilmente fruibile perché mal strutturato o immerso in annunci pubblicitari o simili. Già prima del lancio della versione Italiana dell’aggiornamento Panda mi ero chiesto, oltre alla prevedibile assenza/presenza di contenuto duplicato, quali altre metriche sarebbero diventate prioritarie per il posizionamento nelle SERP.

Se la presenza di contenuto duplicato infatti è un buon modo per eliminare dalle SERP le cosiddette content farm (a parte l’intrinseca difficoltà nello stabilire quale sito è il legittimo proprietario del testo, visto che in caso di crawling frequency diversa non è detto che l’ordine cronologico di rilevamento da parte del bot sia lo stesso di pubblicazione) lo stesso non vale per il secondo obiettivo dichiarato, ovvero quello di penalizzare i contenuti poco fruibili.

A questo scopo il Google Panda Update ha portato alla ribalta due nuove metriche che personalmente ritengo importanti (anche nessuno sa esattamente quanto fra gli oltre 200 parametri che influenzano l’algoritmo di calcolo delle SERP) ovvero:

• Keyword Density
• il fattore HTML to TEXT ratio

Keyword Density

La keyword density KD è banalmente il valore percentuale che indica quanto una parola chiave (intesa come singola parola o espressione formata da più parole contigue) è presente nel testo di una pagina. Si calcola dividendo il numero di occorrenze della parola chiave per il numero totale di parole che compongono il contenuto testuale della pagina (quindi sono esclusi codice HTML, eventuali Javascript o CSS). La KD viene valutata sia globalmente KDG, che con focus ristretto ai soli headings (i vari tag <h1>, <h2>, etc) KDH.

A questo punto nella mente di chi sviluppa siti web viene spontaneo farsi la classica domanda che, quando si parla di Google, non ha risposta: “Qual è il valore ottimale di densità delle parole chiave in una pagina?”. Quando anche io ho iniziato a farmi questa domanda, ho cercato un po’ sul web trovando di tutto e di più, quindi ho deciso di fare un po’ di reverse engineering per alcune query che mi stavano particolarmente a cuore.

Operativamente ho fatto le ricerche (solamente 3) in modo tradizionale e mi son segnato i link che apparivano nelle prime 10 posizioni delle SERP. Ho poi utilizzato un keyword density checker reperito online (ce ne sono decine). Il risultato è abbastanza preciso:

• in caso di query di ricerca mono-parola nessuno dei siti nelle SERP era sotto l’1,5% come KDG, e sotto il 2,2% come KDH, mentre il limite superiore per KDG è stato del 5,76% mentre per KDH del 4,4%;
• in caso di ricerche con query composte da più parole la situazione si complica un po’. Per semplificare ho deciso di utilizzare un ulteriore indicatore sintetico, ovvero la media delle KD delle singole parole che compongono la query. In questo caso la forbice è un po’ più spostata verso il basso, con limiti inferiori di 0,96% per KDGMedio e di 1,12% per KDHMedio, mentre i limiti superiori si posizionano rispettivamente su 3,4% e 3,5%.

Questa analisi non ha la pretesa di essere esaustiva, ma è un’indicazione di come si sta muovendo Google contro i siti come Wikio, Liquida, eHow, che presentavano KDG e KDH più alti e sproporzionati rispetto alla lunghezza del testo. Ci vorrebbe un tool automatizzato per dare un senso a questa analisi di reverse engineering (con molti più campioni a disposizione quindi) e per vedere come la forchetta dei valori si posiziona, anche in relazione alla nicchia di mercato ed ai competitors presenti.

Per ora mi accontento così, anche perché ho scoperto che qualche pagina di siti che stiamo curando ad ELBuild non rientra nella forchetta (e nemmeno nelle SERP) per un paio di query abbastanza importanti. La stessa pagina è ai primi posti invece per altre query, che sottostanno anche ai limiti empirici visti sopra….ho materiale per testare quindi.

HTML to TEXT ratio

L’HTML to TEXT ratio, o rapporto codice su testo, è calcolato come la percentuale di byte che costituiscono contenuto testuale per l’utente, rispetto al contenuto totale della pagina. E’ un indice che  valuta la “pulizia” di una pagina, cercando di valorizzare quelle pagine strutturate in modo pulito (nel codice) e quindi in modo più chiaro (per l’utente).

Come contenuto testuale si intende:

• testo, tipicamente incluso nei tag <p>, <span> o libero nella pagina
• alt delle immagini
• anchor
• content dei meta tag title, keyword e description
• contenuto dell’attributo title di alcuni tag (che viene usato come tooltip)

Come codice si intende….tutto il resto, ovvero tag HTML, inline Javascript, inline CSS etc.

E’ facilmente intuibile che questo rapporto non è del tutto controllabile dallo sviluppatore, a meno che non stia sviluppando un sito completamente “a mano”, senza l’aiuto di CMS, o tag-library (ad esempio le varie RichFaces, OpenFaces, PrimeFaces che utilizziamo quotidianamente ad ELbuild).

Anche in questo caso ho cercato di operare un piccolo tentativo di reverse engineering, utilizzando le stesse tre query viste in precedenza. Il risultato è meno netto per i limiti superiori, ma certifica che c’è una soglia sotto la quale non si dovrebbe mai scendere, ovvero quella di un 10-12 % di rapporto fra contenuto testuale e codice HTML. Solo in un caso ho trovato un risultato nelle SERP sotto il 10% (di poco sotto l’8%), ma era una pagina di un sito con PR altissimo, migliaia di link entranti, e con dominio particolarmente attinente alla query di ricerca.

Personalmente penso che rispettare la soglia del 10% sia semplice, tenendo a mente alcune semplici accortezze:

• definire le risorse Javascript in uno o più file esterni e includerli piuttosto che metterli inline
• evitare spezzoni di inline CSS
• controllare che il DOM sia pulito e che non ci siano troppe incongruenze con le specifiche W3C
• utilizzare i tag, alt e title

Conclusioni

Mi rendo conto di quanto questa analisi sia parziale, con il supporto di qualche tool sarebbe possibile automatizzare il processo di calcolo della forchetta dei valori “buoni” per capire per lo meno in che range posizionare le proprie pagine.

In definitiva si aprono scenari per lo sviluppo di semplici software di text analysis che, appoggiandosi su librerie di DOM parsing, coadiuvino lo sviluppatore nell’ottimizzazione del contenuto, magari con un occhio all’evitare la duplicazione dei contenuti con l’aiuto di dizionari studiati ad hoc….ma per questo ci sarà un altro post 🙂