Una delle preoccupazioni di chi fa indicizzazione nei motori di ricerca è quella di "sapere" se c'è qualcosa che non va nei siti sottomessi a Google.

Da ieri, questo problema è stato radicalmente risolto, in quanto i ragazzi di Google hanno attivato un message center nel quale riportano messaggi e comunicazioni circa i siti sottoposti mediante i Webmaster Tools.

A dire il vero questa funzionalità era stata avviata già ad Ottobre 2005, ma rimossa nell'Aprile 2006 a causa di falsi positivi e altri messaggi che arrivavano un pò a caso. Sembrerebbe quindi, che l'aver riabilitato la funzione sia sinonimo di "abbiamo sistemato le cose".

La cosa interessante di questo sistema è che è stato - a dir di Google - localizzato in diverse lingua, tra cui anche la "lingua dei maccheroni" (in italiano - ndr).

Che messaggi si potranno trovare? Verranno notificati probemi di "testo nascosto", "cloacking" (travestimento delle pagine, mostri il contenuto A all'utente e il contenuto B al motore di ricerca - ndr), "keyword stuffing" (aggiunta irregolare delle parole chiave nascoste, ndr), e lo "Sneaky redirects" (che a tradurlo in italiano potrebbe venire qualcosa tipo "redizionamento a serpente", cioè quando alla stessa url, una volta immessa nella barra di navigazione, vengono associate diverse pagine con contenuti diversi.

Sempre in tema di contatti, se scoprite un bug in Google, esiste ora un sistema leggermente più veloce per essere segnalato; Matt Cutts, nel suo blog, ha aperto una apposita sezione nella quale poter inviare "le prove" di un Google "scriteriato" che restituisce risultati illogici.
Ovviamente chiede di dare prove concrete, tipo l'esatto criterio di ricerca, mostrare la SERP restituita (magari con delle screenshoot), ecc.
Non quindi segnalare ... "c'è un problema".

Il link per le segnalazioni sul blog è questo.

Uno dei principali problemi a cui spesso si assiste oggi quando si fa una ricerca tramite i motori di ricerca, è quello dei contenuti duplicati. Decine se non centinaia di pagine che offrono volgarmente lo stesso contenuto. Chi lo offre ribrandizzando il contenuto sotto diverso sito, chi carica il contenuto tramite web-service, chi usa frame nascosti ... Insomma, sembra che la creatività sia morta.

In realtà una spiegazione logica è riconducibile al fatto che un buon contenuto attira visitatori, e da qua la logica conseguenza che più traffico significa più pagine viste e per quei siti dove si fa uso di campagne pubblicitarie a banner, più pagine significa più impressione e quindi più soldini.

Personalmente è una cosa che proprio non digerisco. Non sò quante volte alla ricerca di risposte, utilizzando Google mi sarò imbattuto in post pubblicati sul medesimo forum e risposti da n siti, oppure articoli di blog presi e copiati di sana pianta.

Purtroppo sembra un fenomeno al quale - almeno per il momento - non si possa dare una smussatina. Credo che il maggior compito in questo frangente venga dai motori di ricerca stessi, che dovrebbero - a mio avviso - implementare un algoritmo migliore di quello che un pò tutti oggi adottano e verificare la dupliclicità dei contenuti fra i vari siti, scaraventando quelle pagine doppione (dalla prima all'ultima) nei cosìdetti "risultati supplementari" che in prima battuta non vengono presi in considerazione (non da Google per lo meno).

Un pò quello che succede con questo particolare motore di ricerca chiamato CopyScape, che mostra quali pagine - a partire da un url - contengono del materiale duplicato.

Non ho bene idea su quale sia la percentuale di contenuto duplicato tenuta in considerazione dal motore, ma trovo l'idea estremamente utile, specie se poi si vogliono far valere i propri diritti.
Comunque, per conoscere la percentuale di cui parlavo sopra, si può utilizzare quest'altro strumento, utile anche per confrontare le pagine del proprio sito.
Eh, già perchè anche il proprio sito, nel bene o nel male, potrebbe cadere nella stessa trappola del contenuto doppio.

A mio modesto parere, una pagina non dovrebbe mai superare il 32-35% di contenuto duplicato, altrimenti si inizia a parlare di vero e proprio SPAM.
Questo valore, ovviamente, si riferisce alla sola parte del mero contenuto, non quindi a quelle sezioni o quelle parti dell'html identiche che spesso corrispondono al menù, piuttosto che al footer.

Copia tu ... che copio io. Da oggi anche Yahoo renderà disponibile a breve la sua funzione di suggerimento durante la fase di digitazione nella casella di testo.

Nulla di eclatante, ma fa pur sempre notizia.

Google ha fatto sapere attraversi canali di settore che presto saranno disponibili nuove modifiche. Alcune che trovo estremamente interessanti sono:

1. Il tag "unavailable_after", che messo tra i META della pagina, comunicherà al motore che quella è una pagina a validità temporanea (es. offerta promozionale) e che di conseguenza dopo la data di scadenza può tranquillamente essere rimossa dall'indice di Google.
   L'intento è sicuramente buono, tuttavia, mi viene il sospetto che saranno pochi i webmaster accorti che useranno questo tag.
   Farlo significa aderire agli standard di Google, non farlo equivarrà prima o poi a trovarsi quella pagina nei "Supplemental Results" (Ricerche supplementari).
   Un esempio lo abbiamo già improntato per questa pagina con un'offerta promozionale dove regaliamo un buono vacanze per chi realizza un sito internet.
   Altri tag interessanti sono il "nosnippet" e il "noarchive" che sono abbastanza eloquenti.
2. A proposito di "Ricerche supplementari" o database secondari di google, è stato detto che quanto prima la differenza tra i due indici verrà piano piano rimossa con una frequenza maggiore di scansione del db secondario.
   In questo caso sono peggio di S. Tommaso, finchè non vedo non credo.
3. Infine il NO definitivo a contenuti in Flash, ovvero a tutte quelle pagine che si propongono solo animate e per giunta con nessuna riga di codice html se non quella del plug-in. Su questo si è ribadito ancora una volta come l'utilità di queste pagina - seppure accattivanti - sia privo di senso per il motore di ricerca e di conseguenza inutili a tal punto che queste pagine prima o poi non verranno nemmeno più indicizzate (Era ora!!!).

La prima risposta di getto che probabilmente viene da dare è "Che ci vuole? Crei una nuova cartella e sposti il file li dentro o rinomini il file!".

Vero! Ma proviamo ad analizzare la cosa da un punto di vista dei motori di ricerca. Questi enormi indici, per quanto quotidianamente scandagliano milioni di siti web, continueranno a non conoscere le vostre modifiche fintanto che non ripasseranno sul vostro sito per reindicizzarne il contenuto.

Supponete ora che avete un sito web scarsamente aggiornato, e che questa scansione avvenga una volta al mese, e proprio ieri i motori di ricerca sono passati per il loro "giro". Cosa succederebbe per un mese? Che n visite che arrivano al vostro sito da quel link contenuto nella pagina del motore di ricerca andrebbero perse perchè la pagina richiesta non esiste più (Errore 404 Pagina non trovata).

Se avete implementato un sistema per restituire una pagina di errore amichevole, poco male. Il vostro utente capirà "nel bene o nel male" che il contenuto non esiste più. Ma Google o gli altri motori di ricerca? A seconda del codice di errore restituito (200 o 404, per maggiori informazioni leggete qui) i motori di ricerca potrebbero non accorgersi immediatamente (o magari non farlo per niente) di quello che è successo.

La cosa migliore a questo punto è quella di impostare una politica corretta di redirect fatta lato server, in modo da restituire un codice stato corretto ed informare il motore di ricerca del cambiamenteo attraverso il codice 301 - Pagina trasferita definitivamente.

In ambiente Microsoft, sotto IIS6, questo cambiamento è possibile effettuarlo nel seguente modo:

1. Aprire la console IIS, e quindi il sito web di interesse
2. Selezionare la risorsa (file o cartella) quindi fare tasto destro e proprietà
3. Nella sezione file, selezionare l'opzione su "A rederiction to a URL"
4. Marcare la casella "A permanent redirection on this resource"
5. Premere ok per uscire

Il punto 4 è fondamentale e fa la differenza nella restituzione del codice di errore tra il 301 (Moved permanently, accettato di buon grado dai motori di ricerca) e il 302 (Documento trovato, ma semplicemente mosso temporaneamente).

Il codice 301 viene visto dal motore di ricerca come un cambiamento, e di conseguenza senza altre variazioni da parte nostra, possiamo aspettarci che nel breve periodo il motore prima o poi aggiorni l'indice in automatico.

Ovviamente, per chi sta facendo attività di SEOing, è bene aggiornare la sitemap.xml (e sottometterla di nuovo nel caso di Google tramite i webmaster tools) e magari anche il robots.txt assicurandosi tempi più brevi e minori problemi.

Analogo discorso si potrebbe fare per lo spostamento dei domini, ma in questo caso ho avuto modo di notare e comunque di leggere anche di esperienze di "latenza" a livelli paurosi.

Una ventata di novità sta per abbattersi sul sistema di advertising di Google. Vero siamo ancora in beta, ma non oso immagginare cosa potrà succedere quando il sistema divernterà definitivo.

Che il Pay-Per-Click stesse diventando obsoleto, nell'ambiente già si sapeva; che stesso portando problemi (Click-Fraud) anche. Che ci fosse bisogno di una risposta pure, ma questa della Pay-Per-Action non è che mi convinca molto.

In pratica cosa succede. Oggi con il pay-per-click si paga per essere visibili nei collegamenti sponsorizzati in ragione di ogni click ricevuto. Al click corrisponde un pari valore impostato nel pannello di controllo delle AdWords, con il quale google ti fa amministrare l'account (tralasciamo le varie discussioni su rettifiche di prezzo et simili).

Con questo sistema, per quanto "poco efficace" si ha comunque un certo margine di "concorrenzialità" con gli altri competitor.

Quando entrerà in vigore il nuovo sistema, secondo me sarà lo sfacelo e gli AdWords inizieranno ad essere uno strumento che pochi useranno. Perchè?

Il principio di funzionamento del Pay-Per-Action è "mi paghi se vendi" o "mi paghi se hai una prenotazione" o (peggio) "mi paghi se hai un contatto". Ho tanto da obiettare su questa cosa. Ti pago? Si, ma quanto? Primo dubbio da sciogliere; non saranno più i pochi centesimi ai quali siamo abituati.

Se vendo? Ok, ma per vendere, se io faccio pubblicità per attirare clienti ... significa che credo nella pubblicità, e di conseguenza ci crede anche Google che a questo punto si sentirà motivata dal mostrare in primi i link e i collegamenti dei siti che in un certo periodo avranno venduto di più.

E gli altri poveri siti che invece? Quelli che nella loro totale ignoranza si rifanno solo sulle Adwords e nonostante tutto non riescono a vendere come vorrebbero, cosa succederà a loro? Le ultime posizioni degli Adwords alla 2 - 4 pagina?

Se questo vuol dire maggior lavoro per i SEOer ... venghino signori e signore ... ma nonostante tutto penso che Google non stia andando nella direzione giusta (a parte quella commerciale dove sicuramente si sarà già fatta tutti i suoi bei tornaconti).

Maggiori informazioni direttamente sul sito di Google a questo indirizzo.

A seguito del post "Errore 404 – La pagina richiesta non è stata trovata", è bene fare una precisazione. Utilizzare le "pagine di errore personalizzate" per restituire, in caso di pagina non trovata, una pagina alternativa (perfettamente valida e funzionante e soprattutto significativa per l'utente finale), significa anche alterare il normale corso della vita della pagina.

Internamente, infatti, il server web (qualunque esso sia), dopo essersi accorto che la risorsa richiesta non esiste, genera l'errore, quindi l'handler in carico di gestire questi errori verifica nella sua "tabella" cosa fare.

Se tramite le impostazioni del pannello di controllo si specifica di "mostrare" una nuova pagina, succede che automaticamente il codice di errore passa da 404 (pagina non trovata) a 200 (OK), perchè effettivamente la nuova risorsa richiesta esiste.

Ai fini dell'utente finale, questo poco conta, perchè a quest'ultimo poco interessa del codice di errore restituito. Diverso è per i motori di ricerca che, nel lungo periodo, potrebbero fraintendere una serie di richieste a questa pagina e immagazzinarle come "contenuto duplicato" dando origine a tutta un'altra fitta serie di problemi che non sto qui ad elencare.

La soluzione allora è quella di avvalersi di un linguaggio di scripting (in funzione del server web dove il vostro sito lavora) e agire di conseguenza per ritornare uno status code corretto, il 404 per l'appunto. Questo dirà al motore di ricerca che effettivamente la pagina richiesta non è stata trovata, ma mostrerà al "malcapitato" utente un modo per continuare la sua navigazione.

Ottenere questo risultato senza un linguaggio di scripting direi che è impossibile, e per questo stesso motivo, attenzione a non mettere mai la index page come la pagina d'errore predefinita. Rischiereste entro breve tempo di provocare più danni che benefici.

Per sapere quale codice d'errore ritorna la vostra pagina, potete utilizzare questi tool on-line: HTTP Status Code Checker

Se stai cercando una risposta al perchè il settaggio della proprietà DataFormatString non viene preso in considerazione da un BoundField, la risposta più corretta è "questo è un bug". Un bug che per il quale nessuno alla Microsoft vuole prendersi la responsabilità.

In poche parole, se si ha un BoundField di tipo DateTime (o in generale un BoundField che necessita di essere formattato secondo una particolare forma) si deve utilizzare la proprietà DataFormatString in questo modo:

<asp:boundfield datafield="DateOfBirth"</asp:boundfield" dataformatstring=""{0:MM/dd/yyyy}""></asp:boundfield>

Ma, sfortunatamente, quando si esegue l'applicazione, l'output invece di essere una stringa di tipo data formattata come richiesto (MM/dd/yyyy), sarà una stringa apparentemente dello stesso tipo che si ottiene invocando il metodo ToString():

Il problema è riconducibile allo sforzo fatto da Microsoft nel cercare di prevenire i così detti attacchi cross site scripting; per questa ragione i BoundField vengono prima dati in pasto alla funzione di econding HtmlEncode e poi passati alla DataFormatString, che però non ritrovandosi più una data valida non potrà procedere oltre con la formattazione.

La soluzione è in questo caso quella di impostare la proprietà HtmlEncode = false come nell'esempio qui sotto.

If you are looking for an answer why DataFormatString won't be applied at your BoundField, the most reasonable answer is "It's a bug". A bug for which nobody at Microsoft seems to be responsible for.

In few words, if you have a BoundField object bound to a field of type DateTime (or whatever you want) with a DataFormatString like this:

<asp:BoundField DataField="DateOfBirth" DataFormatString="{0:MM/dd/yyyy}" />

when you will run your web application, the output instead to be as everybody would expect (MM/dd/yyyy) appears to be formatted using its ToString() method like so:

07/02/2007 7:35:54 PM

The problem is reconducible to an effort of preventing cross site scripting attacks, so the field value is HtmlEncoded before the new formmating is applied. This internally changes the output that doesn't match anymore to a suitable Date format and for this reason the format requested won't apply.

The resolution is to set up the HtmlEncode to false like so:

<asp:BoundField DataField="DateOfBirth" DataFormatString="{0:MM/dd/yyyy}" HtmlEncode="false"/>