In questo post di dicembre 2008 Dave Ward ci ricorda tre buoni motivi per richimare jQuery dai server di Google, anzichè dal nostro server.
Ci sono almeno tre valide ragioni per farlo.

Innanzitutto sfruttare il Content Delivery Network di Google. Il CDN è un network di computer “che collaborano in maniera trasparente per distribuire contenuti [...] agli utenti finali al fine di ottimizzarne il processo di consegna” [wikipedia]. Tra i vantaggi di questa tecnolgia anche la possibiltà che il contenuto venga servito dal nodo del network che può soddisfare la richiesta nel minor tempo possibile.

In secondo luogo  si riducono le connessioni simultanee al server (maggiori info su questo punto potete trovarle qui) .

Terzo vantaggio, probabilmente il più importante, se l’utente ha già navigato su siti internet che includevano jQuery dai server Google, la libreria è già memorizzata nella cache del browser e non deve essere nuovamente scaricata.

Si può utilizzare il tag <script>:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js" type="text/javascript"></script>

oppure utilizzando le API di Google e il mettodo google.load

<script src="http://www.google.com/jsapi"></script>
<script type="text/javascript">

    // Load jQuery
    google.load("jquery", "1.2.6");

    google.setOnLoadCallback(function() {
        // Your code goes here.
    });
       
</script>

Nello stesso modo possono essere richiamate tutte le principali librerie javascript; se vi interessa, la documentazione è qui.

È di qualche giorno fa la notizia che Google finalmente indicizza i contenuti Flash. Una notizia che a differenza di molti, ho accolto con qualche freddezza, anche se la cosa che più mi spinge a non apprezzare flash come strumento per il web, è proprio il fatto che praticamente viene ignorato dai motori di ricerca. La diffidenza iniziale ha poi trovato conforto in articoli come questo: Flash and SEO – Compelling Reasons Why Search Engines & Flash Still Don’t Mix, pubblicato su Seomoz, e che vi consiglio di leggere se siete interessati all’argomento.

Ecco le mie prinicipali perplessità…

Innanzitutto, stando a quanto dichiarato su Webmastercentral, l’algoritmo creato da Google indicizza solo i contenuti testuali presenti all’interno dei filmati swf. Sono escluse quindi le immagini, e se i pulsanti non contengono testo non viene considerato alcun anchor text (mentre vengono seguiti i link che si trovano nell’swf, che, se testuali, ricevono lo stesso trattamento e considerazione dei link html).

Nella ricerca dei contenuti, ancora una volta Google si comporta come un umano, per il momento un umano con javascript disabilitato: dovrebbe essere in arrivo un importante update, ma per ora tutte le volte in cui il filmato flash viene caricato nella pagina con javascript (attraverso SWFobject per esempio), esso sfuggirà al motore di ricerca. Una casistica non tanto limitata, se si pensa che javascript è il modo più semplice per inserire swf nella pagina e restare crosswbroser, evitando gli errori di visualizzazioni di Internet Explorer.

Fondamentalmente, con qualche (importante) eccezione, da qualche giorno Google riesce a navigare nei contenuti flash e quindi leggere e indicizzare il testo in maniera più efficace di quanto riusciva a fare già in passato.

Prima di correre a realizzare interi siti in Flash, quindi sarà meglio considerare che uno dei maggiori limiti di questa tecnologia – la quasi impossibilità con cui i motori di ricerca riescono ad addentrarsi nei contenuti swf – non è affatto superato.

Le carenze strutturali di Flash rispetto ai motori di ricerca rimarranno fino a quando questi ultimi avranno bisogno del markup, per capire cosa è importante all’interno di una pagina; e dei link per capire quali pagine sono importanti: fare un sito interamente in flash significa praticamente rinunciare a molti link in ingresso, poichè a contenuti specifici non corrispondono url specifici.

Ma evidentemente link e markup non sono cose a cui è possibile rinunciare…

Per come la vedo io, Google fa, sempre egregiamente, il suo lavoro: e accresce le proprie capacità di sondare la rete, potenziando in qualche modo il suo bot dove naturalmente è più debole, migliorando di conseguenza il servizio.

Noi, operatori del web, dobbiamo continuare a fare il nostro: flash andrebbe usato per realizzare piccole parti animate all’interno di un sito, o pagine altamente spettacolari, talmente spettacolari che essere perfettamente indicizzati può rappresentare un’esigenza secondaria. In tutti gli altri casi, quando i nostri clienti devono assolutamente esserci sui motori di ricerca, cioè nella maggior parte dei casi, Flash è dannoso.

(E ciò non vuol dire che dobbiamo rinunciare allo spettacolo: per questo esistono jQuery, Prototype o Mootools…)

Su Google Webmaster Central, T.V. Raman offre qualche suggerimento su come realizzare siti in grado di ottenere un buon posizionamente nella accessible search, cioè la ricerca di Google che favorisce i siti internet accessibili.

• I contenuti rilevanti devono essere raggiungibili con un semplice link html. Per linkare un contenuto è sempre meglio usare il tag A, piuttosto che javascript.
• I contenuti devono essere leggibili, da tutti.
• Organizzare i contenuti in maniera logica: il lettore deve essere in grado di seguirli, attraverso i link, secondo il loro ordine logico. Questo significa evitare layout troppo complessi che possono vanificare l’efficacia dei link.
• Non aver paura della ridondanza dei contenuti, specialmente relativamente ai contenuti visuali della nostra pagina: per esempio usare sempre l’attributo ALT per le immagini, accompagnare le animazioni e le tabelle con brevi sommari testuali.

Link: Webmaster tips for creating accessible, crawlable sites

Le tecniche di image replacement sono numerose e molto diffuse tra i webdesigner. Permettono di visualizzare un’immagine all’interno di un’elemento della pagina web, mentre per quel’elemento nel codice html è scritto semplice testo.
Il vantaggio è duplice: si guadagna in estetica e non si perde niente in termini di indicizzazione da parte dei motori di ricerca.

Proprio su questa ultima considerazione è necessario fare molta attenzione, e leggere i suggerimenti di google ai webmaster a proposito di Hidden text and links.

Hiding text or links in your content can cause your site to be perceived as untrustworthy since it presents information to search engines differently than to visitors.
[...]
If your site is perceived to contain hidden text and links that are deceptive in intent, your site may be removed from the Google index, and will not appear in search results pages.

In sintesi, testo e link nascosti offrono contenuti diversi ai visitatori e ai motori di ricerca. I siti che ne fanno uso rischiano di non essere indicizzati e non comparire tra i risultati delle ricerche.
La possibilità che Google punisca una pratica diffusissima, e soprattutto standard compliant, per l’uso scorretto che se ne può fare in chiave SEO, ha ovviamente suscitato un mare di domande dubbi e obiezioni, che spesso e volentieri non hanno trovato risposta.
In questo mare nero, i webdesigner preoccupati trovano fortunatamente un paio di autorevoli appigli che fanno sperare bene: innanzitutto 456 barea street riporta un commento in cui Matt Cutts (quality group google) fa notare come i siti colpevoli non vengano individuati tramite un algoritmo; 456bs conclude che quindi la penalizzazione avviene a seguito di una valutazione umana. E quindi i quality rater, aggiungo io, non dovrebbero avere difficoltà a capire gli intenti per cui i è realizzato un Image replacement. Buone notizie quindi, soltanto un po’ datate: il post è di due anni fa, un’eternità.
La discussione si riaccende a metà dell’anno scorso in seguito all’aggiornamento delle linee guida per Webmaster da parte di Google.
In questo thread si trova la risposta che dovrebbe tranquillizzare chi usa tecniche di image replacement; proprio qui commenta infatti Susan Moskwa, (Webmaster central blog di Google):

if your intent is purely to improve the visual user experience (e.g. by replacing some text with a fancier image of that same text), you don’t need to worry

Moskwa inoltre fa un discorso più generico e rassicurante. In sintesi, solo se nel sito compaiono altre tecniche sconsigliate o vietate da google, allora l’utilizzo dell’Image replacement si aggiunge a questi elementi, e può contribuire alla penalizzazione. Quindi:

If you’re running a perfectly legitimate site, you don’t need to worry about it.

Sono considerazioni che tranquillizzano, ma se tra le nostre priorità c’è il buon posizionamento su Google, sarà meglio fare un uso moderato del replacement, visto che le linee guida lo sconsigliano esplicitamente.

Headspace2 è un valido plugin per Wordpress che permette di gestire dettagliatamente i metadati presenti nel tag HEAD del nostro blog, e di modificarli per ogni singolo post o singola pagina. L’obiettivo ovviamente è migliorare il posizionamento e l’indicizzazione sui motori di ricerca.
Oltre che per la gradevolissima interfaccia Ajax, Headspace2 si segnala per una serie di features che riguardano il sito in generale ed altre che invece si applicano ai singoli post (e pagine). Tra queste: la possibilità di inserire in maniera automatica tags e keywords a seconda del contenuto del post e la possibilità di specificare plugins e temi attivi solo per una specifica pagina.
Notevole anche la l’opzione che permette di importare i dati generati con altri plugin SEO, come per esempio SEO Title tags e All-in-one SEO.

[video]http://www.youtube.com/watch?v=T8um7a0fUfc[/video]

Se si effettua una ricerca in un blog/sito realizzato con Wordpress, utilizzando il motore di ricerca interno del blog, si vedrà come dai results vengono escluse le PAGINE, mentre sono visualizzate tutte le occorenze all’interno dei singoli post. Questo limite di Wordpress è comprensibile, visto che è e resta una piattaforma di blogging.
È un limite però grave se comunque lo utilizziamo per realizzare e gestire un sito web che non è un weblog. In questo caso non è pensabile che le pagine siano escluse dai risultati della ricerca.
La soluzione, come spesso accade è in un plugin (che ci aiuta a piegare ancora Wordpress alle nostre esigenze di webmaster…): si chiama search-unleashed ed è stato realizzato da John Godley.

Ecco le principali caratteristiche di Search-unleashed (come riportate sul sito dell’autore):

• ricerca full-text estesa a wildcards e operazioni logiche;
• ricerca su post, pagine, commenti, titoli, url, tag e metadati;
• ricerca sui dati così come vengono elaborati dagli altri plugins;
• evidenziazione delle parole nella serp;
• evidenziazione delle parole anche se la ricerca è stata effettuata su motori di ricerca come google o yahoo;
• visualizzazione delle informazioni contestuali, non solo di un estratto del post;
• registrazione delle ricerche effettuare in un log visualizzabile nel pannello di controllo;
• possibilità di escludere alcune pagine o post dai risultati della ricerca;
• compatibilità con WP-Cache;
• compatibilità da WordPress 2.0.5 a 2.3;
• nessun cambiamento richiesto al tema.

Aggiungo che si tratta di un plugin altamente configurabile, attraverso un comodo pannello di controllo, e i risultati della ricerca vengono normalmente visualizzati da Wordpress attraverso il template impostato nella pagina search.php