Création et optimisation d’un site complexe avec WordPress

Dans cette série d’articles, je vais vous partager mes galères et mes solutions dans la création d’un site complexe, celui de La Marmite Vagabonde.

Complexe, cela veut dire :

• une optimisation poussée, en particulier pour faire des archives de taxonomies de véritables contenus
• l’utilisation de nombreux métas (posts et taxonomies), générés via ACF
• l’utilisation d’un plugin de recettes, WP Recipe Maker, qui est un des (le ?) meilleur plugin de recettes, mais un peu sensible pour un site multilingue
• car, cerise sur le gâteau, le site doit être bilingue, Français-Anglais, avec WPML
• et, à terme, la mise en place d’une boutique

La couche WPML introduit beaucoup de complexité supplémentaire. Le plugin a fait de gros progrès depuis la dernière fois que j’avais fait un site multilingue, il y a trois ans, mais il reste complexe à gérer. Il y a un bon ordre pour faire les choses, une bonne façon de paramétrer, et il faut s’y tenir pour s’éviter de refaire les choses plusieurs fois ou, pire, de faire indexer des contenus par Google dont on voudra ensuite changer les urls.

Pour le SEO, suite à vos conseils, je suis partie sur RankMath SEO. Je suis en effet fâchée depuis longtemps avec Yoast, et depuis mon “retour” avec All In One SEO qui a bien changé.

Néanmoins, j’utilise uniquement les fonctions basiques, donc ce que je fais peut se faire avec n’importe quel plugin fournissant une API pour modifier ses valeurs de bases.

Un site complexe, ça se planifie avec soin

Lumière de Lune est un site simple : articles, pages, catégories, étiquettes, et puis voilà.

Mais quand on commence à faire dans le compliqué, il faut prendre une feuille de papier et se faire un mini cahier des charges, surtout quand, comme moi, on a un peu tendance à partir en mode code sans trop réfléchir.

Et quand on met WPML, c’est indispensable, parce que revenir sur des configurations erronées de WPML, c’est galère !

Les questions que je me suis posées :

1. De quoi ça parle ?

   de cuisine bien sûr, mais pas seulement. En plus des recettes, il y aura des articles sur les techniques (c’est “presque” une recette), les ingrédients et les substitutions d’ingrédients (dans mon cas, essentiel), où acheter, comment faire maison… Sans doute à moyen terme un annuaire. Une partie “magazine” avec des actualités, des livres, des émissions, une partie “histoire culinaire” parce que ça me passionne, et une partie “diététique santé”, parce que ce site est né de mon besoin de mieux manger.

2. Comment je qualifie tout ça ?
   

   Il y a des incontournables, comme les ingrédients, les types de cuisine, les types de plats, les “régimes”, la difficulté, le coût, les matériels utilisés dans la recette. Tout ça est fourni en standard dans WP Recipe Maker. Mais dans mon cas, il y a sûrement des pays, des lieux (qu’on parle d’AOP ou de pays d’origine), des chefs, des critiques, des saisons. Et puisqu’on parle de saisons, il y a aussi les “occasions”, les fêtes par exemple.
   Les cuisines, les ingrédients (comme le safran) peuvent aussi être utilisées pour les articles, comme presque toutes les taxonomies. Certaines seront aussi utiles pour l’éventuelle boutique ou le tout aussi éventuel annuaire.
   Il va donc falloir coder une surcouche à WP Recipe Maker pour pouvoir utiliser ses taxonomies dans les autres contenus, au lieu de les dupliquer. (un de mes grands dadas). Et plus tard, la même chose pour WooCommerce.

3. Site multilingue, qu’est-ce que je traduis, ou pas ? Et surtout “comment” ?
   

   Certains de mes contenus dans une langue risquent de ne pas être très pertinents dans une autre (par exemple des articles sur Top Chef, qui n’a pas du tout la même renommée en anglais). Le site sera sur deux noms de domaines différents, car son nom, “La Marmite Vagabonde” n’est pas explicite en anglais. Faut-il aller jusqu’à faire deux versions des images avec un watermark différent ? (réponse, non…). Pour chaque champs personnalisé (et il y en a beaucoup), il faut choisir si on l’ignore, si on le copie, si on le traduit.
   Le paramétrage de WPML, c’est facilement une journée.
   Et comme WP Recipe Maker n’est pas “compatible WPML” (en clair ça gonfle le créateur du plugin, il a des trucs plus importants à faire), j’ai développé une autre surcouche pour pouvoir facilement gérer la traduction des recettes.

4. Le thème permet-il de faire ce qu’on veut ?

   J’utilise depuis longtemps SmartMag, qui utilise Elementor. Là aussi, quelques petites surprises. Je sais que je vais devoir faire un thème enfant pour intégrer toutes mes optimisations SEO (c’est en fait une montée de version du thème que j’ai fait sur mon site sur l’expatriation au Maroc).

5. Vérifier que tous les plugins sont compatibles avec WPML.

   J’ai eu quelques surprises désagréables, des fonctionnalités que j’ai du abandonner. Heureusement, comme j’ai fait “avant tout” le paramétrage de base de WPML, j’ai identifié les bugs dès le début et j’ai pu changer de route sans avoir trop à reconstruire / rediriger.

On peut commencer avant d’avoir tout fait

Une fois qu’on a fait ça, on a une vision relativement claire de ce que sera le site, comment il sera structuré pour l’optimisation sémantique (cocon or not cocon, je n’en sais rien… mais ça marche) et on peut se lancer pour faire du contenu sans que tout soit totalement prêt. En informatique, il y a le “nice to have” et le “show stopper”.

L’optimisation SEO de mes archives de taxonomie, par exemple, sur un site avec peu de contenu, c’est un “nice to have”, parce que de toute façon, pour l’instant, elles sont en no-index et “no-sitemap” . Une structure d’url qui ne fonctionne pas avec WPML, c’est un “show stopper”.

Pendant la création des contenus, se poser encore des questions

Un des gros problèmes des sites de contenus, surtout quand ils ont quelques années, c’est l’incohérence des termes de taxonomies : on arrive régulièrement à des redondances, à des termes qui n’ont qu’un ou deux articles.

A l’étape précédente, en travaillant sur les qualifications, j’avais défini les termes pour un certain nombre de taxonomies, par exemple les types de plats. Au bout d’une dizaine de recettes, je me suis rendue compte que c’était trop détaillé. Par exemple, la distinction entre “plat principal”, “plat unique” et “plat” n’avait pas d’importance. Heureusement, WP Recipe Maker a une jolie fonction pour fusionner des termes, qui facilite ce genre de corrections. J’ai aussi décidé de passer d’une échelle de 5 à 3 pour les “difficultés” et “niveaux de prix”.

J’ai aussi identifié un “quelque chose” qui sera sans doute une taxonomie, qui doit me permettre de parler des blogs que je préfère. Pourquoi une taxonomie ? Parce que ces blogs sont aussi des “sources” qui devraient taguer un article ou une recette. C’est possible à faire avec un type de post, mais la gestion de la traduction est trop complexe. Ce sera donc une taxonomie, j’hésite simplement à savoir si je fais une taxo différente de celle que j’utilise pour les personnes : beaucoup de blogueurs sont des gens, mais un site peut aussi être édité par une société. (Et derrière ces questions apparemment capillotractées, il y a un point très concret, qui est l’optimisation des pages d’archives de taxonomie, avec des marquages de schema.org).