Aller au contenu

Frontend — SEO

Statut

CURRENT / CONTRACT pour les principes d’architecture SEO décrits ici.

Cette page documente comment le Frontend expose les informations SEO sans créer une seconde vérité métier dans le thème.

Elle ne prétend pas lister tous les champs SEO actuellement produits page par page. Lorsqu’un détail d’implémentation précis est nécessaire, vérifier le code réellement chargé par WordPress.

Principe

Le SEO public doit dériver des mêmes données canoniques que le reste du Frontend.

Domain Core / Vertical Modules
        ↓
projections stables
        ↓
Read Services / Readers
        ↓
Adapter WordPress
        ↓
HTML + métadonnées SEO

Le thème peut formater une information ; il ne doit pas réinventer sa signification.

Objectifs

L’architecture SEO doit garantir :

  • une URL canonique stable par intention publique ;
  • une page produit canonique par identité produit ;
  • des titres et métadonnées cohérents avec les projections ;
  • une navigation et un maillage cohérents avec l’architecture publique ;
  • l’absence de duplication créée par les états d’offre ;
  • une évolution SEO sans couplage aux catégories marchandes.

Une identité produit, une page canonique

Le neuf, le reconditionné et les autres états d’offre ne doivent pas créer plusieurs identités produit.

Le principe reste :

identité produit canonique
    ├── offres neuves
    ├── offres reconditionnées
    └── autres états d’offre autorisés

Le Frontend et le SEO ne doivent donc pas fabriquer plusieurs pages produit concurrentes uniquement parce que l’état d’offre diffère.

URLs publiques

La stratégie d’URL doit suivre l’architecture publique et ses contrats, pas les catégories d’un marchand.

La source canonique CURRENT pour l’architecture déclarée de navigation est :

plugins/ccx-feeds-industrial/includes/application/navigation-architecture.php

via :

ccx_navigation_architecture_registry()

Une URL ou un breadcrumb ne doit pas inventer une branche absente du contrat public.

Pour la stratégie canonique d’URL, voir également l’ADR dédiée.

Titres et descriptions

Les titres, descriptions et contenus SEO doivent partir de données déjà établies.

Exemples de sources possibles selon la page :

  • identité ou modèle produit projeté ;
  • marque canonique ;
  • attributs utiles à la restitution ;
  • catégorie publique ;
  • état réel des offres ;
  • données éditoriales explicitement séparées.

Le template peut assembler ces informations pour le rendu, mais il ne doit pas :

  • corriger localement une marque ;
  • résoudre un modèle ambigu ;
  • forcer une catégorie ;
  • transformer un statut incertain en certitude pour obtenir un meilleur titre.

Statuts de résolution

Les statuts resolved / unknown / ambiguous / conflict conservent leur sens jusqu’aux surfaces publiques.

Un besoin SEO ne justifie pas de transformer :

  • unknown en valeur devinée ;
  • ambiguous en candidat choisi arbitrairement ;
  • conflict en resolved silencieux.

Lorsque la donnée ne permet pas un titre ou une page suffisamment fiable, la bonne réponse est de traiter la cause amont ou d’adopter une restitution prudente, pas de créer une certitude dans le Frontend.

Catégories et navigation

Le SEO ne doit pas créer une arborescence parallèle.

Header, breadcrumbs, pages catégories, sitemap et maillage doivent rester alignés avec la même architecture publique.

Une feuille déclarée dans le registre mais non visible au Runtime peut rester absente des surfaces SEO si aucune donnée publique ne satisfait son contrat.

Déclaration et visibilité sont deux notions différentes.

Marchands

Les catégories marchandes peuvent fournir des signaux d’entrée au Pipeline, mais elles ne gouvernent pas directement :

  • les URLs publiques ;
  • les catégories SEO ;
  • les breadcrumbs ;
  • les titres canoniques ;
  • la navigation principale.

Ajouter un marchand ne doit donc pas créer automatiquement une nouvelle taxonomie publique.

Données structurées

Les données structurées éventuellement rendues par le Frontend doivent utiliser les mêmes faits que la page visible.

Elles ne doivent pas :

  • annoncer un prix absent du contenu public ;
  • présenter un produit comme résolu si la Platform le considère ambigu ;
  • exposer une catégorie différente de celle du breadcrumb ;
  • inventer une disponibilité ou un état d’offre.

Le markup structuré est une représentation supplémentaire, pas une source de vérité.

Canonical, redirections et legacy

Les redirections legacy sont des mécanismes de compatibilité.

Elles ne doivent jamais devenir le moyen de conserver indéfiniment plusieurs structures publiques concurrentes.

Lorsqu’une URL est remplacée :

  1. déterminer la destination canonique ;
  2. vérifier qu’elle représente la même intention ;
  3. éviter les chaînes de redirections ;
  4. mettre à jour les liens internes ;
  5. conserver la logique de redirection dans la couche adaptée, pas dans le contenu métier.

Sitemap et maillage interne

Le sitemap et les liens internes doivent dériver des surfaces réellement publiques.

Ils ne doivent pas faire apparaître artificiellement :

  • des feuilles sans données publiques suffisantes ;
  • des catégories legacy ;
  • des routes techniques ;
  • des pages générées uniquement pour un marchand ;
  • des doublons selon l’état d’offre.

Le sitemap n’est pas un moyen de forcer l’existence SEO d’une page qui n’a pas de contrat public valide.

Diagnostic d’un problème SEO

Mauvais titre produit

Vérifier :

  1. identité/projection produit ;
  2. Reader ;
  3. Adapter ;
  4. assemblage SEO dans le Frontend.

Mauvais breadcrumb

Vérifier :

  1. registre de navigation ;
  2. visibilité Runtime de la feuille ;
  3. projection/navigation Reader ;
  4. renderer breadcrumb.

Deux URLs pour le même produit

Vérifier :

  • stratégie d’URL canonique ;
  • route legacy ;
  • redirections ;
  • génération de liens internes ;
  • éventuelle confusion entre identité produit et état d’offre.

Page indexable sans donnée suffisante

Vérifier si la page est réellement soutenue par une projection publique valide avant de corriger seulement la balise SEO.

Ce que le Frontend peut faire

Le Frontend peut :

  • formater un <title> ;
  • rendre une meta description ;
  • produire un canonical ;
  • rendre des breadcrumbs ;
  • générer des données structurées à partir des données lues ;
  • construire des liens internes conformes au contrat public.

Il ne peut pas décider ce qu’est le produit ou où il appartient métierement.

Anti-patterns

Éviter :

  • catégories SEO codées en dur indépendamment du registre canonique ;
  • titres produits corrigés manuellement dans le thème ;
  • page séparée par état d’offre sans décision architecturale explicite ;
  • catégories marchandes exposées telles quelles ;
  • données structurées plus affirmatives que la page ;
  • canonical choisi par heuristique locale non documentée ;
  • sitemap construit depuis une taxonomie legacy divergente ;
  • SEO utilisé pour masquer un défaut de projection.

Intervention sûre

Avant une modification SEO :

  1. identifier l’URL et l’intention publique ;
  2. vérifier la donnée projetée ;
  3. vérifier la route et le canonical actuels ;
  4. vérifier navigation et breadcrumbs ;
  5. corriger la première couche incorrecte ;
  6. contrôler les redirections et liens internes ;
  7. vérifier le HTML final et, le cas échéant, les données structurées.

Invariants

  1. Le SEO dérive des mêmes projections que le Frontend.
  2. Le thème ne crée pas une vérité métier parallèle.
  3. Une identité produit possède une surface canonique cohérente.
  4. Les états d’offre ne redéfinissent pas l’identité produit.
  5. Les catégories marchandes ne gouvernent pas l’architecture publique.
  6. Navigation, breadcrumbs, URLs et sitemap doivent rester cohérents.
  7. Les statuts unknown / ambiguous / conflict ne sont jamais transformés en certitude pour des raisons SEO.

Voir aussi