Quiz sull’indicizzazione e cose imparate a pappagallo

Craaak! Polly vuole un biscotto!

Un argomento ricorrente nei discorsi tra colleghi e amici SEO è legato a quanta confusione vi sia sul tema dell’indicizzazione.

Il fatto stesso che il termine “indicizzazione” venga spesso usato in contesti che non hanno niente a che fare con un indice, la dice lunga sul generale stato di confusione nella cultura SEO: non essendoci una definizione unanimemente condivisa del termine, ognuno di noi lo può usare (e lo usa) come gli pare.

Magari voi penserete che le tecniche di indicizzazione siano di facile comprensione a tutti, eppure vi posso assicurare che in tanti anni ho visto moltissimi SEO, anche di grande esperienza, fallire miseramente se messi alla prova con un semplicissimo quesito.

Il quesito

“Possiedo un sito web le cui pagine sono già indicizzate da Google. Nasce l’esigenza di non far apparire più una specifica pagina nei risultati di ricerca del motore. Allora inserisco in quella pagina un meta tag ROBOTS con direttiva NOINDEX e, per sicurezza, aggiungo anche nel file robots.txt una riga DISALLOW dedicata a quella specifica pagina. Che cosa c’è di illogico (e sbagliato) in questo procedimento?”

La risposta è, ovviamente, che se desideriamo impartire un’istruzione allo spider scrivendola nel codice della pagina HTML, non dobbiamo impedire allo spider di scaricare la pagina e quindi non dobbiamo usare il disallow nel file robots.txt

Immagino che la stragrande maggioranza dei frequentatori/trici di questo blog non dovrebbero avere avuto grandi difficoltà a rispondere alla domanda, però sono certo che rimarreste sorpresi nel sapere quanti SEO, nel corso degli anni, non sono riusciti a trovare facilmente la risposta. Una risposta che dovrebbe essere immediata, per chi ha appreso l’ABC del SEO.

La domanda che mi pongo è: “Perché ho osservato tutte queste difficoltà?” e la risposta probabilmente è: “Perché spesso si apprende l’ABC meno utile.”

Memorizzare un protocollo o memorizzare tutte le possibili combinazioni?

Il fenomeno che ho osservato nel corso degli anni tra coloro che si interessano di SEO è che diverse persone sono poco propense a studiare le regole di base del funzionamento di un sistema.

Al contrario, ho notato che l’approccio di apprendimento che va per la maggiore è quello di imparare il maggior numero di combinazioni che possono scaturire dall’applicazione e dall’interazione di un insieme di diverse regole ed elementi.

E’ come se invece di capire come funziona l’operazione aritmetica dell’addizione si cercasse di imparare a memoria i risultati di tutte le possibili somme di due numeri.

Il fenomeno si presenta con maggiore evidenza proprio sul tema dell’indicizzazione, perché i motori di ricerca hanno sfornato nel corso degli anni sempre più strumenti per aiutare i webmaster a gestire al meglio l’archiviazione delle risorse. Il risultato è che ad ogni introduzione di un nuovo strumento nascono dubbi su cosa farci e in quali occasioni può essere deleterio usarlo.

Dal mio punto di vista, l’ABC SEO legato ai fenomeni di indicizzazione consiste nelle seguenti informazioni:

• le basi del protocollo HTTP
• il funzionamento del modello client/server
• il funzionamento di uno spider
• a che cosa serve un file robots.txt e il robots exclusion standard
• il diverso significato dei termini “indicizzazione”, “archiviazione” e “richiesta”

Una volte apprese le suddette basi, che rimangono pressoché immutabili nel tempo, è possibile crearsi una visione chiara del protocollo che gestisce il variopinto mondo dell’indicizzazione e dell’archiviazione.

Combinazioni esotiche tra robots.txt, intestazioni HTTP, meta tag, e attributi rel=canonical troveranno subito posto all’interno del paradigma che ci siamo costruiti e non sarà necessario imparare a pappagallo gli effetti di ogni possibile interazione tra questi ed altri elementi.

Ogni futuro strumento, inoltre, può essere inserito all’interno dello scenario per avere subito chiaro come può interagire con gli strumenti preesistenti.

Un flusso parziale

Solo per esercizio, ho creato un semplice diagramma di flusso che illustra un semplice protocollo di indicizzazione limitatamente agli elementi: direttiva noindex, robots.txt e indexer.

Il flow chart dipinge solo un processo di base e tiene conto solo di un paio di strumenti di indicizzazione, però dovrebbe fornire già qualche indicazione importante sull’interazione tra lo spider e l’indexer.

Per esempio, seguendo il flow chart dovrebbe essere possibile rispondere facilmente a domande quali “Quali testi associabili ad una risorsa non possono finire nella SERP se il robots.txt chiede di non accedervi?”, o anche “Che ruolo deve avere il file robots.txt nel caso in cui non si desideri far indicizzare una risorsa?”.

Il flusso di indicizzazione-fine-di-mondo

Un flow chart completo che mostri l’interazione di tutti gli strumenti di indicizzazione esistenti sarebbe decisamente più complesso da realizzare, ma non certo impossibile. Ma sicuramente strafigo!

Partire dalla redazione di un elenco di tutti gli strumenti sarebbe il primo passo da fare.

C’è qualcuno tra di voi che se la sente? 🙂

Se vi può servire, il software che ho utilizzato per produrre il diagramma di flusso è gratuito e si chiama yED.

Buona analisi del flusso!

Migliorare l’indicizzazione con le priorità delle sitemap

Se c’è uno strumento SEO che a mio parere viene spesso sottovalutato è quello dell’attributo priority delle sitemap XML.

In tanti anni ho osservato una gestione dei file sitemap poco interessata, forse perché è più comodo far fare tutto a qualche plugin o automatismo software che si occupa di creare i file sitemap sollevando webmaster e SEO da un’attenta progettazione.

Il problema con questo approccio è che molti file sitemap non sfruttano appieno le proprie potenzialità; ho quindi pensato di fornire qualche dritta.

L’importanza del priority

Secondo il protocollo sitemap, l’attributo priority va usato per indicare al motore di ricerca quali pagine vorremmo che finissero ben visibili in SERP.

In un certo senso, il valore contenuto nell’attributo priority di ciascun URL può essere considerato un indice di quanto l’URL è per noi importante o strategico.

Quando si parla di “importanza” la memoria va al buon caro vecchio PageRank, che ormai va di moda tacciare di inutilità generica, quando invece ne ha molta se ci si focalizza sul fenomeno dell’indicizzazione.

La relazione tra PageRank e l’attributo priority appare azzeccata perché entrambe gli elementi hanno sicuramente influenza sulle decisioni degli spider riguardanti quanti e quali URL richiedere e, conseguentemente, quanti e quali URL conservare in archivio.

Il primo contributo importante dell’attributo priority consiste dunque nell’aiutare il SEO a far archiviare un maggior numero di pagine del sito, fenomeno che è strategico sopratutto per quei siti grandi che vivono di long tail e pageview.

Sinergia col PageRank

La relazione tra attributo priority e PageRank è ulteriormente cementificata dal fatto che i due elementi possono essere sfruttati in maniera complementare, sinergica.

Quando per ragioni tecniche o di design non è possibile modificare le strutture di navigazione di un sito per conferire maggiore importanza/PageRank ad alcune sezioni o tipologie di risorse, un valore più alto nell’attributo priority di quelle risorse può venire in aiuto sopperendo a quanto non riusciamo a fare attraverso il grafo dei link del sito.

E’ vero anche il contrario: in condizioni in cui non è possibile gestire nel dettaglio i valori che andranno a finire negli attributi priority dei file sitemap, diventa più strategico sfruttare al meglio i link sul sito per assegnare importanza alle risorse che realmente ci interessano.

Per queste ragioni già da tempo io sfrutto le priorità nelle sitemap e la distribuzione del PageRank sul sito come due strumenti sinergici attraverso i quali gestire nel migliore dei modi il concetto di “importanza” da associare alle risorse.

Approccio base

In linea puramente teorica, con un sito che sfrutta i link interni per distribuire importanza alle proprie risorse in perfetta aderenza con gli obiettivi di visibilità e traffico, l’attributo priority delle sitemap XML potrebbe anche non servire.

All’atto pratico, un sito dal linking interno “perfetto” non può esistere e dunque si rendono necessarie le pratiche sopra accennate. Questa affermazione è ancora più vera per quei siti che beneficiano di contenuti generati da utenti e che sono soggetti a modifiche del grafo dei link sul sito operate dagli utenti stessi.

Un buon modo per iniziare a progettare bene dei valori di priorità adeguati consiste nel fare un elenco delle risorse più strategiche del sito e metterle in ordine di importanza.

Per i siti grandi non è ovviamente possibile produrre un elenco esaustivo ma in tal caso è sufficiente elencare in ordine di importanza le categorie in cui le risorse vengono classificate.

L’obiettivo finale è quello di operare una selezione ragionata di quanto il sito contiene e chiarirsi bene le idee su quali risorse beneficerebbero di più di una maggiore visibilità nelle SERP.

Un’obiezione che mi sento fare spesso è: “le risorse sono tutte importanti” ma sicuramente le risorse non sono tutte importanti allo stesso modo.

Il mio consiglio è, in questo contesto, di farvi guidare dal denaro: se avete un e-commerce chiedetevi quali (categorie di) prodotti avete un interesse a vendere più di altre tenendo in considerazione i volumi di ricerche sul web; se avete un sito di news che vende spazi pubblicitari chiedetevi quali temi e tipologie di contenuti vi permettono di intercettare un target ampio o che per propria natura è più propenso a fare più pageview sul sito.

Per dirla tutta, queste considerazioni di importanza dovrebbero essere fatte a monte, prima ancora della fase di progettazione del sito e dell’architettura delle informazioni, che influisce direttamente sul linking interno e quindi sull’assegnazione di importanza alle risorse. Ma questa è fantascienza.

Tornando con i piedi per terra, che ci si fa con l’elenco delle risorse più strategiche ordinate per importanza? Semplice, si usano come base per scegliere quanti e quali URL inserire nella sitemap XML e che priority attribuire loro.

Se tutto è importante, niente è importante

I valori dell’attributo priority vanno da zero a uno, che è il massimo. In mezzo ci sono tanti numeri con virgola che potete sfruttare per stabilire quanto ciascuna risorsa è importante rispetto alle altre.

Queste ultime parole ve le ripeto perché sono determinanti: “quanto ciascuna risorsa è importante rispetto alle altre“. Ho aggiunto anche il neretto, visto?

Se stresso tanto su questo punto è perché a volte ho osservato la tendenza ad attribuire il priority di una risorsa ragionando esclusivamente sulla risorsa stessa e dimenticandosi della sua importanza relativa rispetto a tutto il resto del sito.

Vi faccio un esempio pratico prendendo dei dati reali gentilmente fornitimi da un cliente, che ringrazio.

Quello che segue è un grafico della distribuzione delle priorità in una sitemap XML sottopostomi dal cliente.

Come potete notare, la stragrande maggioranza degli URL presenta una priorità molto alta e solo una piccola parte possiede una priorità bassa.

Il problema con questo tipo di struttura è che asserire “la maggioranza delle risorse ha priorità identica o simile” non consente di far emergere quelle risorse realmente strategiche rispetto alle altre.

Al mio consiglio di ottenere una curva di distribuzione più “morbida” e che mettesse in risalto un gruppo principale di risorse più importanti di altre, il cliente ha proposto una nuova distribuzione, che è decisamente migliore rispetto alla precedente e che potete osservare nel prossimo grafico.

Vi consiglio dunque di porvi sempre le domande: “quanto sono stato selettivo?” o “sto mettendo in risalto ciò che realmente è più importante?”.

Pubblicare e migliorare

Una volta abbozzate le priorità come si può essere sicuri che vadano bene? Il metodo migliore è quello di pubblicare il file sitemap XML, eventualmente segnalandolo attraverso il pannello di Google Webmaster Tools, e osservare come reagisce Google nei giorni successivi.

E’ aumentata la quantità giornaliera di pagine richieste dallo spider? Chiede sempre le stesse risorse o risorse diverse (consiglio di dare un’occhiata ai log del web server)? Vi sono modifiche alle posizioni delle pagine strategiche per le keyphrase di riferimento? E’ aumentata la quantità di pagine archiviate da Google? E’ aumentato il numero di differenti landing page dai motori di ricerca? Son salite di posizione le pagine giuste (consiglio di valutare come son cambiati gli indici di apprezzamento da parte degli utenti)?

Se c’è la percezione che qualche risorsa “arranchi” o che le nuove priorità attribuite attraverso la sitemap XML abbiano comportato effetti negativi su specifiche risorse, potrebbe essere una buona idea aumentare leggermente la loro priorità oppure svalutare ulteriormente i gruppi di risorse meno strategiche.

Al di là di questo consiglio chiave, ricordate che giocare con le priorità è nella stragrande maggioranza dei casi un’attività sicura perché, a differenza della modifica di link interni del sito, modificare le priority consente di tornare facilmente e velocemente sui propri passi o di fare test ed esperimenti sui valori che producono risultati migliori.

Benefici conseguibili

In particolare per i siti di una certa grandezza ed in grado di farsi perlustrare in lungo ed in largo da Google, ho osservato in più di un caso che accorte modifiche degli attributi priority hanno condotto ad un crawling più approfondito, ad una quantità maggiore di pagine indicizzate e a più accessi sul sito.

E anche per coloro che non hanno siti particolarmente corposi, un sano tweaking delle priorità basato su ciò che vi sta più a cuore potrebbe portare risultati gradevoli.

Come al solito, vi invito a sperimentare. 🙂

Velocizzazione dei siti: creare un fake CDN

Da un po’ di tempo mi è venuta in mente un’idea malsana per velocizzare il caricamento delle pagine web da parte dei browser, in particolare quelle che inducono il browser a scaricare tante risorse, per esempio immagini.

Alla base di tutto c’è la considerazione che i browser decidono di scaricare in parallelo solo un numero limitato di risorse ospitate sullo stesso host.

Per esempio, se una pagina web contiene molte immagini e se tutte sono ospitate sotto l’host www.nomesito.it, allora i browser decideranno di scaricarne in parallelo solo una quantità massima, iniziando a richiedere le immagini successive via via che le immagini del primo “pool” sono state ricevute.

Una tecnica per indurre i browser a mettere in parallelo più richieste, ottimizzando così l’uso della banda, consiste nell’ospitare le immagini/risorse su host diversi.

Quella che segue è la tecnica che vi propongo. Sì, so che è improprio parlare di “CDN”. Un vero CDN è tutt’altra cosa. Non mi è venuto in mente un nome migliore di “Fake CDN”. Rassegnamoci.

Attenzione, pericolo: quanto segue non è un tutorial! Io vi indico il risultato finale che bisogna ottenere, sta a voi capire in che modo ottenerlo sul vostro specifico sito o server! Fate conto che diversi CMS (es: WordPress) o pannelli di controllo (es: Plesk) possono gestire in automatico alcuni file di configurazione dei vostri server e che ciò potrebbe andare in conflitto con eventuali modifiche manuali che voi decideste di fare. Procedete solo se sapete bene dove mettere le mani.

Cosa serve

• Possibilità di gestire i DNS
• Server Apache e possibilità di aggiungere alias ai domini serviti
• Un linguaggio di programmazione lato server (PHP, ASPX, ecc.) che gestisca la produzione del codice HTML delle pagine
• Saper programmare col linguaggio di programmazione

Primo passo

Bisogna modificare il DNS e inserire un host catch-all con un wildcard, per esempio: *.cdn.nomesito.it

Come tipo di record DNS potete usare un CNAME e potete farlo puntare al dominio principale nomesito.it

In questo modo tutti gli host del tipo qualsiasicosa.cdn.nomesito.it verranno risolti, alla fine dei giochi, con l’IP associato al nome di dominio nomesito.it

Secondo passo

Bisogna dire ad Apache che gli host del tipo *.cdn.nomesito.it devono essere gestiti come se fossero alias del dominio principale.

La direttiva da usare per ottenere ciò è ServerAlias, che dovrebbe essere inserita all’interno di una sezione VirtualHost già esistente nel vostro file di configurazione del server.

Alla fine dovreste avere qualcosa di simile:

<VirtualHost *:80>
    DocumentRoot /www/dominio.it
    ServerName www.dominio.it
    ServerAlias *.cdn.dominio.it
    ...
</VirtualHost>

Terzo passo

Il CMS del vostro sito dovrebbe essere istruito per produrre dinamicamente gli URL delle immagini usati negli attributi SRC dei tag IMG nelle pagine HTML.

Per esempio, ogni volta che c’è da produrre l’URL di una delle tante foto/immagini che ingolfano la vostra bellissima home page, il CMS dovrebbe produrre URL di immagine del tipo: http://a.cdn.nomesito.it/img/foto-322.jpg

Il sistema di parallelizzazione si ottiene usando, sulla stessa pagina, URL che fanno riferimento ad host diversi, tipo:

• http://a.cdn.nomesito.it/img/foto-322.jpg
• http://b.cdn.nomesito.it/img/foto-839.jpg
• http://c.cdn.nomesito.it/img/foto-063.jpg
• ecc…

In altre parole, la cartella “img” è sempre la stessa ma grazie ai tre passi indicati i suoi contenuti possono essere raggiunti attraverso host diversi.

Che criterio va usato per produrre la parte di host che deve variare per ogni URL di immagine (“a”, “b”, “c”, ecc.)? E’ categorico che ogni immagine venga mostrata sempre sotto lo stesso host, per evitare problemi di duplicazione di contenuti negli indici dei motori.

Il metodo più semplice per ottenere ciò potrebbe essere quello di calcolare un hash del nome immagine (es: foto-275.jpg), prendere il primo carattere della stringa dell’hash ed usarlo come lettera da anteporre a cdn.nomesito.it

Se come algoritmo di hash decideste di usare un CRC32, che produce un valore in esadecimale, i caratteri pseudo-random prodotti sarebbero le lettere dell’alfabeto da “a” ad “f” e i caratteri numerici da “0” a “9”: 16 diversi caratteri/host da usare per le vostre immagini.

Vi invito tuttavia a ideare sistemi differenti e più elastici per la generazione del carattere da anteporre a “cdn”, in quanto sedici differenti host potrebbero in alcuni casi anche essere eccessivi per i nostri scopi.

Conclusioni

L’esempio presentato si riferisce solo alle immagini, ma ovviamente può essere applicato a qualsiasi tipo di risorsa.

Questo post ha solo lo scopo di illustrare l’idea, sta a voi decidere come implementarla sui vostri sistemi: le modalità possono cambiare tantissimo. Se avete poco chiaro come procedere, è un buon segno per far fare il lavoro a qualcun altro. 😛

Buono smanettamento e, se vi va, fatemi sapere come è migliorata la parallelizzazione delle vostre risorse usando WebPageTest. 🙂

Google Panda non c’entra un fico secco

Risorgo dopo qualche settimana di silenzio (e di qualche weekend all’estero) per dare un parere su un fenomeno SEO che nelle ultime settimane ho visto maturare tra gli addetti ai lavori.

Sembra che lo spauracchio di Google Panda, che al momento in cui scrivo deve ancora essere esteso a Google.it, stia alimentando una nuova forma di fobia.

La pandafobia avviene quando il timore che l’introduzione di Panda possa causare danni di visibilità ai propri siti induce il professionista SEO a temere che un qualsiasi fenomeno SEO negativo possa essere il segnale dell’introduzione del nuovo algoritmo.

A beneficio della sanità mentale di tutti faccio dunque un elenco di alcune informazioni che si possiedono al momento (21 giugno 2011) su Google Panda, assieme a qualche considerazione personale:

1. non è stato ancora applicato su Google.it
2. non è stato detto quando verrà esteso a Google.it o ad altri siti di Google in lingua diversa dall’inglese
3. la metodologia con la quale Panda è stato progettato lascia credere al sottoscritto che la sua estensione a lingue diverse dall’inglese non sia così automatica né facile
4. un brusco calo di posizioni/traffico può essere attribuito a decine di cause diverse, che i SEO conoscono bene: ha senso valutare tutte le cause potenziali più comuni prima di congetturare l’introduzione di un algoritmo nuovo
5. alla sua introduzione, attendetevi una reazione ampia da parte della comunità SEO online, non l’emergere di piccoli e pochi fenomeni isolati
6. parlare di Google Panda e inserirlo in contesti in cui non c’entra un fico secco va di moda, attrae l’attenzione e produce comunque traffico

A forza di gridare al lupo ogni cinque minuti c’è il rischio di non essere presi sul serio quando il lupo arriverà.

Keep Calm and Put the Kettle On

Dieci comandamenti su come difendersi dai “SEO”

Il presente articolo è un guest post scritto da Cesarino Morellato (DAO Daddy), che ringrazio molto per il contributo. [NdLow] 🙂

Dieci comandamenti su come difendersi dai “SEO”

Decalogo dedicato a chi in azienda deve fare la scelta del consulente SEO, o della società SEO, ma non conosce assolutamente niente della materia.

Per chi non sa cosa sia SEO, è l’acronimo di Search Engine Optimization e sta a significare quella attività che studia e aiuta la realizzazione di pagine ottimizzate per i motori di ricerca e ne consente una lettura nel migliore dei modi non solo al navigatore ma anche ai software dei motori.

Durante uno dei tanti aperitivi, con amici SEO, mi sono ricordato di aver ricevuto un’esilarante mail che promuoveva un corso “avanzatissimo” di SEO. Questa mail mi ha fatto riflettere per l’ennesima volta sulla difficoltà per un non addetto ai lavori nel distinguere la professionalità dagli imbonitori, non per evitare totalmente le fregature ma almeno per ridurle al minimo.

1 Ricerca per nome e cognome

Se non lo trovate non è un buon segno, potrebbe essere che non abbia un sito proprio, ma almeno su Linkedin, Facebook o Twitter ci deve pur essere.

Come può proporvi una cosa che egli non usa? Potrebbe essere un servizio innovativo, ma se dovete fare da cavia meglio saperlo, no? Inoltre le cavie non pagano, anzi alcune volte vengono pagate. 😉

Nel caso di un team, fatevi dare nomi e cognomi dei componenti. Troppo spesso, si spacciano “team dedicati” per poi scoprire che sono solo 2 o peggio è sempre solo una persona.

2 Referenze

Chiedetegli una referenza, un cliente da contattare, ma non un collega! Spesso il nostro è un settore autoreferenziale ed anche un collega ha difficoltà a capire esattamente le capacità e conoscenze dei colleghi, tranne nel caso in cui abbia lavorato insieme.
Un cliente, invece, sarà in grado di dirvi non solo le capacità tecniche, ma anche serietà, riservatezza e attitudine a risolvere i problemi. Un buon fornitore lo si scopre anche in caso di problemi.

3 Garanzie

La conoscenza di un SEO si basa sulla conoscenza di regole del passato, quindi chi garantisce conoscenza del futuro, in realtà fa un azzardo. Come lo staniamo? Proponete il pagamento “tutto” a risultato raggiunto, se accetta le sue garanzie sono in buona fede, se invece sono parte all’ordine e parte a risultato, potrebbe già celarsi la fregatura. Ho visto in passato, sedicenti consulenti farsi pagare il 30 % all’ordine ed il restante spalmato nel tempo a fronte di risultati. Sembrerebbe perfetto, peccato che se sono in male fede, si prendono il 30% non fanno nulla o molto poco e posso fregarmene del saldo.

4 Offerta prima di aver fatto analisi

Se vi vengono proposte delle soluzioni, prima di aver condotto un’attenta analisi, è evidente che non vi sta proponendo qualcosa utile a voi, ma tenta di vendere un suo prodotto, a prescindere da cosa vi possa servire. E’ come un venditore di aspirapolvere, non si preoccupa di capire le vostre esigenze, cerca solo di vendervi il suo prodotto. Vi serve un trapano? Ma se lui ha l’aspirapolvere, quella tenta di vendere.

5 Servizio chiavi in mano

Diffidate da chi vi vuole vendere un servizio, chiavi in mano, dove voi non dovete fare nulla. Non esistono casi dove l’attività viene data tutta in out sourcing! I contenuti del sito, per esempio, non possono essere scritti da un esterno, tranne nel caso in cui questo esterno non venga formato nel prodotto o nel servizio erogato dal sito. Inoltre l’attività del SEO non può e non deve terminare dopo un lasso di tempo, ma è un’attività che prosegue nel tempo. Ne deriva che se viene usato un servizio esterno, si dovrà pensare ad un rapporto duraturo nel tempo.

6 Servizio a numero di chiavi di ricerca

Un servizio a numero di chiavi di ricerca è da evitare, primo perché se il progetto SEO che intraprendete è agli inizi non sapete né quali né quante sono le chiavi che generano traffico o conversione, in altre parole quelle che vi saranno utili.
Secondo, perché il numero delle chiavi è relativo ai settori, vi sono settori composti da 10 chiavi altri da migliaia e questo a priori non è dato a sapersi.

7 Vuole vendervi il SEO a tutti i costi

Non è detto che il servizio SEO vada bene per tutti i progetti. Se uno vuole vendervi a tutti costi il suo servizio, potrebbe essere che la sua necessità sia di vendere il suo prodotto, non quello che serve a voi. Porre sempre la domanda, in quali casi il SEO non è conveniente? Se non risponde, o risponde in modo evasivo, dubitate!

8 Lingua italiana

Valutate anche il modo di esprimersi, se poi dovrà occuparsi anche dei contenuti del vostro sito, è fondamentale che conosca la lingua italiana. Non sottovalutate il modo di scrivere, se nella documentazione dovete rileggere in continuazione e non capite cosa scrive, pensate che quella è la sua materia e non la sa spiegare: come potrà farlo con il vostro prodotto o servizio che conosce certamente meno?

9 Trucchi e segreti

Non esistono né trucchi e segreti né maghi o guru! Chi millanta di conoscere la formuletta magica, è come un cartomante, gioca sulla suggestione o sulla vostra non conoscenza. Per raggiungere risultati, il lavoro da fare è proporzionato alla competizione del settore.

Anche per i bond argentini o Parmalat si promettevano “miracoli”, ed anche in Internet come nella realtà, le scorciatoie possono essere rischiose.

10 Lista dei motori

In Italia purtroppo, e sottolineo purtroppo, Google la fa da padrone, possiamo aggiungere Bing e Yahoo ma la lista finisce qui. A chi vi vuole vendere servizi comprendenti altri motori oltre ai sopra citati, chiedete sempre di inserirvi nel contratto i posizionamenti in Google. Se poi sarete anche su altri motori, meglio, ma non possono e non devono essere oggetto della garanzia o del contratto.
NB: questo vale per un progetto in lingua italiana in Italia, se il progetto è internazionale, fatevi dare le percentuali di share dei vari motori che vogliono vendervi.

Spero che la lista vi sia di aiuto e vi faccia evitare brutte sorprese.

Cesarino Morellato
DAO Daddy