WordPress publie facilement, et chaque type de contenu, étiquette ou archive peut devenir une URL de plus. Nous décidons d'abord lesquelles doivent exister dans Google.
Un premier échange pour regarder vos types de contenu, vos extensions et vos pages prioritaires.
Archives indexées, gabarits hétérogènes, champs ignorés, extensions empilées : nous rencontrons ces situations sur les sites WordPress, et chacune a sa réponse.
Sur WordPress, chaque type de contenu, chaque taxonomie et chaque archive peut produire des adresses. Le sitemap natif liste par défaut les contenus publics, les taxonomies et les archives d’auteur.
Un site de services qui publie depuis des années compte souvent beaucoup d’articles, quelques pages qui portent une demande, et des archives que personne n’a décidé de créer.
Ce que cela coûte échappe aux tableaux de bord : le nombre d’adresses grandit, et les pages qui font venir des demandes partagent l’attention de Google avec des archives que personne ne cherche.
Nous décidons des URL avant de choisir les extensions.
Soigner le gabarit d'une archive que personne ne cherche n'apporte rien, et rediriger sans avoir cartographié les pages revient à deviner.
Un site WordPress se construit contenu après contenu, et le blog finit souvent par répondre à des recherches que les pages de services visent aussi. Google hésite alors entre deux adresses, et celle qui devrait générer des demandes n'est pas toujours celle qu'il retient. Nous partons des recherches de votre activité et décidons quel type de page doit répondre à chacune.
Nous croisons le crawl, la Search Console, l'export des types de contenu et des extensions, et le sitemap réellement servi.
Nous classons chaque action selon les pages qui portent une demande et une valeur business.
Nous appliquons les réglages et les gabarits sur une copie du site, puis en production.
Nous suivons l'indexation et les pages qui apportent des demandes, et contrôlons le site après chaque mise à jour du thème ou d'une extension.
Un état des lieux des types de contenu, de l'indexation, des gabarits et des extensions.
L'affectation de chaque recherche au type de page qui doit y répondre, avec les pages à regrouper ou à créer.
Une décision par type d'adresse : indexée, regroupée, redirigée ou retirée de l'index.
La structure prévue pour chaque type de page : titres, champs à remplir et balises.
Ce que chaque extension ajoute au site, et ce qu'il faut garder, remplacer ou retirer.
La destination de chaque ancienne adresse, prévue quand un changement de thème ou une migration fait partie du périmètre.
Les règles de publication à donner à l'équipe pour que chaque page garde la même structure.
Le suivi de l'indexation et des demandes pour chaque type de page prioritaire.
Décider des URL d'un site WordPress a de l'effet quand le site contient déjà des pages qui portent une demande. Sinon, la priorité est ailleurs.
Non, pas seuls. Ils appliquent des réglages (modèles de titres, balises, sitemap), mais ne décident pas quelles adresses doivent exister ni quelles archives garder. Nous travaillons avec les deux, et le diagnostic commence par ce que WordPress fait déjà de lui-même, comme son sitemap natif.
Seulement si elles répondent à une recherche et portent un contenu qui leur est propre. Le sitemap natif de WordPress liste par défaut les taxonomies et les archives d’auteur, sans se demander si elles ont un intérêt. Chaque cas se décide au vu des recherches, pas du réglage par défaut.
Ni l’un ni l’autre ne suffit à décider du classement. Ce qui compte, c’est le HTML que l’éditeur produit, la hiérarchie des titres et le poids des pages. Les conteneurs d’Elementor, par exemple, produisent un HTML plus léger que ses anciennes sections et colonnes, selon la version et les réglages. Un thème à blocs aide surtout par la structure et le code plus propre qu’il produit, pas par son seul statut.
Pas toujours. Avec Yoast, le contenu des champs ACF n’est pas analysé par défaut et il faut une extension de liaison ; avec Rank Math, les blocs personnalisés demandent, selon la version, un branchement à son interface d’analyse. Nous vérifions sur votre site ce que l’extension lit ou ignore, car une analyse qui laisse de côté une partie du contenu mène à de mauvaises décisions.
Avant la conception du nouveau site. C’est le moment où les adresses se décident, et où il est encore possible de garder celles qui comptent. WordPress ne redirige de lui-même que les anciens slugs d’un contenu : le reste d’un changement de structure demande ses propres redirections.
Oui. Nous décrivons chaque changement dans des tickets que votre développeur ou votre agence peut appliquer, puis nous vérifions le résultat. Si vous préférez nous confier la mise en œuvre, nous intervenons selon le périmètre, d’abord sur une copie du site.
Le périmètre dépend du nombre de types de contenu et d’adresses, des extensions installées, du multilingue et de la personne qui développe. Un site vitrine, un site de services et une boutique WooCommerce ne demandent pas le même travail, et nous intervenons sur ces trois cas. Nous définissons le périmètre après un premier échange.
Parlons de votre site : nous regardons ce que Google en retient et ce que le thème et les extensions y ont ajouté, puis nous convenons d'un ordre de travail.