Corriger les défauts de base pour améliorer l’optimisation

Oui, WordPress est, à la base, plutôt bien conçu pour le référencement.

Non, WordPress n’est pas, en version standard, totalement optimisé. Et cela peut être empiré par des thèmes mal construits, ou par des erreurs dans l’organisation et la structure de son blog. (On ne parlera pas ici de la performance, qui est aussi un aspect important). Commençons par les défauts de base de WordPress.

Le titre du blog en H1 sur toutes les pages

C’est quelque chose qui a évolué avec le temps, mais tous les créateurs de thème n’ont pas suivi. Au début, dans les thèmes par défaut, et la majorité des thèmes, le titre du blog qui apparait dans le header était en H1, et donc toutes les pages du blog avaient un H1 identique.

Avec, ensuite, au choix selon la structure du thème, un deuxième H1 pour le titre de la page (et donc pas de texte entre les deux, deux “sections” totalement déséquilibrées) ou bien le titre de la page en H2. Dans ce cas, il fallait passer les titres internes de l’article en H3, ce qui leur faisait perdre beaucoup de poids.

Pour corriger cela, très simple. Il suffit de remplacer le h1 qui encadre le titre par

if ( is_home() or is_front_page() ) 
{ echo '<h1' ; } else {echo '<div' }

sans rien changer d’autre (vous gardez notamment les classes et les ids, qui servent pour la mise en forme). Et bien entendu, ne pas oublier de corriger aussi la balise fermante !

La structure de permaliens avec les dates

Fortement recommandée par WordPress, mise en place sur wordpress.com, la structure de permalien incluant les années, mois et jour sous la forme aaaa/mm/jj est à mon avis à éviter à tout prix.

Notamment parce qu’elle rend impossible l’interdiction des archives par date dans le robots.txt

Or les archives par date sont, naturellement, en duplicate content avec l’index.

Sauf dans des cas exceptionnels, je ne vois vraiment pas l’intérêt de les utiliser.

L’archive “auteur”

De la même façon, dans un blog mono-auteur, l’archive d’auteur n’a aucun intérêt, et sera elle aussi en duplicate content par rapport à l’index.

Je la désactive le plus souvent possible, dans les meta, et j’ai deux petits fichiers, au contenu identique, qui s’appellent author.php et date.php et que je rajoute systématiquement dans mes dossiers de thème :

<?php
// Permanent redirection
header("HTTP/1.1 301 Moved Permanently");
header("Location: ".home_url());
exit();
?>

Les titres dans la sidebar

Par défaut, cf le codex, la fonction register_sidebar génère un marquage html avec des titre h2 pour chaque widget. Il est même précisé

This is the convention we recommend for all themes

Je trouve cela très mauvais, étant donné la faible valeur du contenu en sidebar, peu de texte, beaucoup de liens, et du contenu répétitif sur toutes les pages.

Malheureusement, pour corriger cela proprement, c’est un peu difficile. Il faut faire un thème enfant, et selon les cas, surcharger la fonction de déclaration des sidebars, ou en refaire une autre.

Pourquoi ?

Les fonctions du thème enfant sont chargées avant celle du thème parent. Si le thème parent a été correctement développé, il teste à chaque fois l’existence d’une de ses propres fonctions, avant de l’appeler.

if ( !function_exists ('register_my_sidebar') ) {
function register_my_sidebar() {
register_sidebar (

etc…

Oui mais voilà, 99% des thèmes ne font pas ce test, en tout cas pas sur la fonction de déclaration des sidebars

Vous avez donc le choix entre :

• corriger directement le thème (baaad et risqué si c’est un thème mis à jour)
• faire dans votre thème enfant une fonction qui désenregistre la sidebar du thème et qui ensuite enregistre vos propres sidebars avec un marquage html correct. Lourd, mais “propre”.

On voit qu’on a commencé à parler des défauts des thèmes, qui seront le sujet du prochain article.