WordPress: Migliorare SEO e ottimizzare Performance


Il SEO è un argomento inflazionato, esistono milioni di guide più o meno utili e le leggende metropolitane di ogni tipo. WordPress è un ottimo strumento per muovere i primi passi e capirne alcuni criteri base.

Design, in breve

Il design del sito deve essere semplice ma efficace. Sembra ovvio ma spesso i siti sono fatti per essere glamour ma poco usabili… ma ancor peggio: incomprensibili ai motori di ricerca.
Durante un recente redesign di questo sito, ho usato il Framework Twitter Bootstrap, per creare questo template personalizzato per WordPress, che preferisco tra altri Framework per la scelta della struttura e dei componenti: leggera, flessibile e il più “open” possibile (senza oscuri linguaggi semi-proprietari di dubbia compatibilità cross-browser – con altri browser).

Non avendo quindi usato un template già fatto (siamo in pochi a non usarne uno!), tutto quello che fa il sito, tutto quello che c’è e tutte le funzionalità che ci facilitano il lavoro di tutti i giorni, delle quali il visitatore non si accorge, e che migliorano la performance di WordPress stesso e quindi del sito, sono volute e create ad hoc.

Questioni di URL

Usiamo un nostro “url shortener”, o meglio un abbreviatore di url tipo bit.ly, t.co (di Twitter), youtu.be (di Google YouTube), che in assenza di domini assurdi da comprare a prezzi folli, è semplicemente url.shambix.com/abc, dove abc è l’abbreviazione della pagina o articolo che ci interessa.
Questo non influenza niente di per sé, ma i motivi del suo utilizzo sono 2 : è un modo per risparmiare spazio su Twitter e poter scrivere più testo e poi, poiché il sito è in doppia lingua, se un post prima veniva condiviso in una lingua e poi nella sua traduzione, le statistiche erano sdoppiate, mentre a noi interessava avere un numero unico aggregato e questo è reso possibile dall’identificazione dello stesso articolo condiviso in più lingue, in un unico url (quello corto appunto).

Media Temple Hosting

W il SEO

Come dicevo all’inizio, il SEO non è solo un fatto di indicizzazione o quante pagine del mio sito sono su Google, il SEO deve essere prima di tutto il modo in cui viene scritto il template e quindi come viene poi letto appunto dai motori di ricerca.
In altre parole, pensate ad un libro senza punteggiatura, senza titoli o paragrafi. Un libro che a vederlo sembra una frase intera.
Ecco, se il template, quindi la struttura che rende possibile quello che vedete adesso, è scritto senza l’adeguata “punteggiatura”, risulterà a Google&co. esattamente come per noi l’esempio di cui sopra.
Questo significa che tutto (e quindi niente) avrà la stessa importanza nel nostro sito, per il motore di ricerca (che non è umano e non vede con gli occhi, ma solo grazie alla “punteggiatura” appunto).

E’ importantissimo quindi che il codice sia scritto avendo ben presente il tipo di contenuti che andranno a far parte del sito e la loro posizione nello “spazio” del sito (il layout).
Una volta che il codice è pronto per ospitare il contenuto, è evidente che l’importanza si focalizzi proprio su quello.
Non mi dilungo in questo post sul “come” scrivere i contenuti di un sito, perché la questione diventa lunga (sono comunque disponibile per parlarne in separata sede ed affiancarvi uno specialista di comunicazione ed Inbound Marketing, nel caso), ma andrò direttamente ad aspetti tecnici specifici.

All in One SEO

Questo plugin di WordPress automatizza e rende possibile tutta una serie di miglioramenti e dà la possibilità (che francamente dovrebbe essere built-in in WordPress…) di assegnare descrizione e keyword ad hoc per ogni post, se non si vuole – e non si dovrebbe – usare sempre il riassunto (excerpt) del post editor. Tra l’altro funziona anche con il plugin multilingua qTranslate con alcuni accorgimenti, in modo da avere descrizioni (quelle che poi appaiono come testo nel risultato di ricerca sui motori), multilingua, oltre che parole chiave.

Il plugin tuttavia, in assenza di questi accorgimenti contenutistici, provvede ad inserire in modo automatico, prendendole da categoria e tag, le parole chiave e dal riassunto la descrizione.
Spulciando nel codice, sarà poi possibile sfruttare alcune funzioni PHP per ottimizzare a dovere anche la condivisione su Facebook (che non sempre è ottimale, di default).

A proposito di plugin: una lista di plugin utili per WordPress, la puoi trovare qui!

Media Temple Hosting

WordPress SEO + Social

Ci sono svariati plugin che automatizzano e tentano di migliorare i vari tag che rendono la condivisione di un contenuto ottimale, ma sinceramente, a me non me ne è mai piaciuto uno. Fanno casino, inseriscono codice anche dove non devono, si incartano con altri plugin (tipo quello dei pulsanti social di Jetpack), ma anche solo con lo script standard che dà Facebook e che molti inseriscono poi a mano nel single.php (file del template che visualizza un articolo singolo).

Tra l’altro per chi, come noi, ha custom post types e custom taxonomies (tipi di contenuto diversi dal “post” o “pagina”, ad es. “portfolio” o “servizio”), i plugin esistenti per questo scopo sono davvero scarsi e difficili da personalizzare al meglio.
Insomma chi fa da sé, e sa fare, fa meglio.
Per capirci, questo è il codice, nel sito di Shambix che ottimizza tutte le pagine, categorie e post, per Facebook:

Questo codice dice a Facebook cosa pubblicare con esattezza, quando e come, utilizzando sia codice di All in One SEO, sia codice nostro custom, sia funzioni di qTranslate per il multilingua, sia istruzioni per WordPress.

Vale la pena far notare che ogni link, specialmente nelle circa 5 pagine più importanti del sito, ci sono (e dove non ci sono ancora, ci saranno) anchor titles nei link che portano a pagine interne relative alle parole a cui è assegnato il link, 3 elementi molto importanti per il SEO, per dare forza alle parole ed argomenti sui quali il sito converge e che servono a rafforzarne il significato (e quindi l’importanza e rilevanza) per i motori di ricerca.

Infine, ad ogni link a pagine esterne, sia testuale che di immagini (ma quelle anche interne), sono sempre assegnati un attributo rel=nofollow, poiché non è nel nostro interesse dire al motore di ricerca di trovare una via d’uscita, fuori dal sito, tramite quel link.
Questo si fa comodamente in modo automatico piazzando nel footer:

Il codice dice al motore di ricerca, che se il link è segnato con un target=”_blank”, che si vuole quindi far aprire quel link su una nuova pagina, è per forza di cose, un link esterno…. questo perché non si dovrebbe mai far aprire in una nuova pagina un link interno (semplicemente non ha senso, se non in rarissimi casi).

Infine, ho provveduto a ricostruire completamente la struttura “principale” del sito, secondo un criterio di importanza (per noi ovviamente, non in generale). Tutto questo dando priorità specifiche a determinate pagine e declassandone altre, generando così una sitemap interna che Google segue alla lettera, sapendo quindi cosa per me è importante e dov’è il contenuto che per me deve avere più rilevanza, per il mio sito.

E’ bene ricordare che non importa che TUTTE le pagine o articoli di un sito siano sulla sitemap, Google arriva sul nostro sito comunque ed indicizzerà piano piano tutto in ogni caso, la sitemap interna serve appunto a noi, in via diciamo “privata”, per comunicare a Google dove far più attenzione e cosa andare a controllare più spesso.

Nel nostro caso ad esempio, le pagine indicizzate da Google sono oltre 700, ma quelle che interessano a noi in particolar modo sono meno di 10, e per migliorarne la conversione è cruciale dedicare loro la massima attenzione.

Tralascio quindi tutta una questione di analisi sulle query e come ho lentamente cambiato il modo in cui gli utenti/visitatori trovano determinate pagine del nostro sito, ma è comunque un procedimento lungo ma che porta indubbiamente i suoi frutti, verificabili tramite appositi strumenti.

Infine per le immagini, noi utilizziamo anche fancybox, quindi combinando le due necessità, avremo:

In questo modo le immagini, che siano nostre o di altri siti, non saranno comunque seguite dai motori, anche perché purtroppo WordPress assegna un vero e proprio status di “contenuto” alle immagini, che diventano quindi vere e proprie pagine, se non si fa attenzione, rischiano di disperdere le energie ed il tempo dei motori di ricerca).

Visto che c’è ancora chi lo fa (LOL!), volevo far presente che inserire 389743948 “parole chiave” nel footer, o nascoste in posti improbabili, non porta NESSUN beneficio al SEO, anzi, rischiate di essere penalizzati e/o rimossi da Google ed altri motori di ricerca. Una parola è “chiave” per una serie di fattori concatenati, e non in quanto “tale”! Sì, si usava questa pratica…. circa 10 anni fa, quando gli algoritmi delle SERP erano ancora ad uno stadio “inesperto”.

Validazione?

Onestamente, la validazione è una questione che nel tempo mi ha interessata in misura sempre inferiore.
Ho scritto più volte in merito (l’ultima pochi giorni fa, in inglese) e quindi non approfondirò la questione, tuttavia è importante far notare che un codice che non si valida, NON influisce sul posizionamento nei motori di ricerca, a meno che non ci siano veri e propri errori nel codice HTML o CSS. Errori di quel tipo sono facilmente individuabili anche senza dover ricorrere alla validazione, perché solitamente piuttosto evidenti dal browser stesso (o dal sorgente della pagina).

La validazione era uno strumento utile ai tempi delle prime versioni di CSS e per l’XHTML e HTML4 (primi anni 2000), quando molti browser erano ancora incompleti e facevano fatica a visualizzare correttamente i siti.
Oggi, il codice è molto più avanti degli strumenti di validazione stessi, rendendoli quindi obsoleti. Se si pensa che i codici stessi che dà Google per determinate operazioni (es. analisi o pubblicità), non sono validabili, si capisce quanta poca importanza si dà ormai a questi strumenti. Infine, se un sito non si valida, non vuol dire assolutamente che sia fatto male o che non venga visualizzato perfettamente, ripeto, gli strumenti non sono più idonei allo scopo e devono essere quindi, ignorati.
Può essere un’opinione personale, ma è comunque condivisa dalla maggior parte dei web designer.

4. Performance

La Performance di un sito, ovvero il suo tempo di caricamento, il modo in cui “serve” le pagine ed i contenuti statici (script, css, immagini, html, font..ecc), il modo in cui il tutto è cachato e cachabile dal browser (salvabile per le prossime visite), ed altri parametri, sta diventanto sempre di più uno dei criteri di posizionamento nei motori di ricerca.
Per giusta o no che sia, la questione ha un suo senso: se un sito è veloce, l’utente avrà una migliore esperienza (da qui l’attenzione crescente degli ultimi anni alla UX – User Experience).
E qui iniziano tutta una serie di simpatiche problematiche perché andiamo inevitabilmente incontro a limitazioni più o meno problematiche, del server dove risiede il nostro sito.
Normalmente, un buon server, non darà problemi in questo senso, a patto che permetta all’.htaccess di dettar legge sugli aspetti che ci interessano di più: compressione e caching.
Ci sono tutta una serie di strumenti con i quali verificare la performance del nostro sito, i due più famosi sono sicuramente PageSpeed di Google e Yslow di Yahoo, entrambi con una serie di criteri simili, ma con pesi leggermente diversi (per cui si avranno quasi sempre risultati diversi, in alcuni casi e per alcuni siti, anche molto divergenti).

Una questione a parte, è la presenza di problemi nel sito (back o frontend).
Sebbene alcuni non sembrino influenzare il funzionamento generale del sito, è importante far notare che possono avere un peso, sia per quanto riguarda il SEO, che per quanto riguarda la performance del sito. Nel caso notiate un cambiamento delle prestazioni, o problemi evidenti, iniziate da questa guida per capire come risolvere.

Prima di iniziare con le operazioni del caso ho fatto un test veloce, con le impostazioni standard (per YSlow in realtà si dovrebbe usare il tool per sviluppatori ad hoc, e non quello standard che è fatto per siti molto diversi da questo), e qui sotto potete vederne in alto il risultato iniziale, ed in basso il risultato alla fine del mio lavoro.

shambix_performance

La differenza mi pare ovvia, come anche il fatto che il risultato finale non raggiunga il 100% pieno.
Il motivo è banale e non desta preoccupazione: per alcuni file che vengono caricati nel sito non è possibile fare assolutamente niente (o meglio per un paio si potrebbe ma i metodi sono macchinosi e per il nostro tipo di sito, completamente inutili ed ininfluenti). Volete sapere quali sono questi file? Gli script di condivisione di Facebook e Twitter, lo script di Google Analytics, lo script di statistiche di WordPress (Jetpack) ed un paio di altri script necessari ed esterni ai nostri file.
Facendo il test di YSlow a parte, impostandolo con i criteri appropriati per questo sito, il risultato è 94%.
Ho raggiunto quindi il massimo risultato ottenibile per il nostro sito. Missione compiuta!

wp_enqueue_scripts

Già che ero alle prese con tutta una serie di miglioramenti, ho deciso di mettere mano al modo in cui WordPress carica i file css e javascript del mio template.
Semplicemente, invece di metterli in header.php e footer.php (erano ancora lì per comodità dopo aver convertito il design in codice all’inizio), li ho messi nel functions.php in questo modo:

Ho quindi detto a WordPress di caricare i miei fogli di stile nell’header al momento della chiamata a wp_head(), e se presente un plugin ad hoc, in questo modo possono essere intercettati e “minificati”.

Per quanto riguarda jQuery, preferisco avere la versione più recente se possibile (quella non lo è, ma va bene così al momento) e non sempre quella standard di WordPress fa al caso mio, quindi l’ho sostituita con quella disponibile sulla repo pubblica di Google ed ho fatto in modo che venisse caricata nell’header (ma solo quella!).
Inoltre l’enqueue è utile nel momento in cui più plugin utilizzano la stessa libreria javascript (jQuery di solito), perchè in questo modo (se sono sviluppati bene), invece che caricarla di nuovo tutti, useranno quella eventualmente già caricata, quindi una volta sola (questo aiuta quindi anche ad eliminare la possibilità di conflitti con versioni diverse).

Gli altri js sono stati caricati nel footer, come dovrebbe sempre essere, per velocizzare il caricamento della pagina.
In particolare uno viene caricato solo nel caso in cui si tratti della home, perché quando possibile è sempre bene limitare al minimo il caricamento di script dove non necessario (sempre per motivi di performance, oltre che per eventuali conflitti).
Ho evitato di versionare i file in modo che siano più facilmente cachabili e poi perchè a parte lo style.css, gli altri non vedo perchè dovrebbero comunque cambiare.

Better WordPress Minify

Questo è un plugin per WordPress, che permette di “minificare” i vari file javascript e css in un unico file.
Altri plugin fanno la stessa cosa, a volte includendo questa funzionalità in un più ampio plugin di caching, tuttavia questo fa quello che deve fare senza troppi problemi.
In pratica il plugin prende tutti i css e i js, enqueued a dovere, e li concatena in un unico striminzito file, eliminando spazi e commenti (che aumentano la grandezza dei file).

WP Smush.it

Questo plugin aiuta nelle operazioni di ottimizzazione performance, perché permette una compressione automatica, senza perdita di qualità, delle immagini del sito (quelle nei post), che vengono quindi caricate molto più velocemente.
Per le altre immagini (non post), consiglio di andare ad effettuare “manualmente” la compressione utilizzando direttamente Smush.it (di Yahoo) oppure da software con PNGGauntlet per Windows (per Mac basta fare una ricerchina), andando quindi a rimpiazzare le immagini attuali.
Il tutto sarà molto apprezzato dagli strumenti di analisi performance.

.htaccess mon amour

Benché abbia un linguaggio tutto suo ed il suo funzionamento sia spesso oscuro ai più, l’.htaccess può fare magie, sia rendendo i nostri url più “carini” (senza ? .html o altri simboli orridi e decisamente pessimi per il SEO), sia istruendo il browser ed il server ad effettuare certe operazioni “invisibili” ma importantissime, come il caching.
Senza addentrarmi troppo nei dettagli, consiglio a tutti i web designer di utilizzare l’ottimo .htaccess già ottimizzato per la maggior parte dei siti e degli usi, su GitHub.
All’occorrenza potrebbe comunque essere necessario qualche tweak ad hoc per il vostro sito, ma lasciatelo fare ad un professionista WordPress, perché un .htaccess con un singolo errore può rendere il sito completamente inaccessibile.

Concludo qui questa guida agli accorgimenti importanti in campo SEO e Performance, soprattutto per WordPress, che a volte ha bisogno di un aiutino speciale ^_^

Sono Consulente Digitale, WordPress Specialist e Web Designer, creo siti da 17 anni.
Abitualmente uso PHP/MySQL, HTML5/CSS3/Javascript, Twitter Bootstrap e WordPress, ma non solo.
Aiuto aziende, professionisti e startup ad utilizzare la tecnologia per crescere, creando Team di designer & sviluppatori, pianificando progetti e strategie, sviluppando soluzioni complesse.