En quoi les cibles des redirections manuelles et dynamiques de BigCommerce diffèrent-elles ?

Définition : Dans l’API GraphQL Storefront de BigCommerce, une redirection manuelle pointe vers une URL de destination fixe. Une redirection dynamique identifie une ressource existante de la boutique par un type de ressource et un identifiant d’entité, ce qui permet à la requête route de renvoyer directement l’entité cible.

Points clés

• La documentation du nœud route de BigCommerce indique que le chemin fourni en entrée peut correspondre à une entité, à une redirection ou à aucun résultat.
• Une redirection manuelle renvoie une URL de destination fixe et nécessite une nouvelle requête route pour récupérer le contenu à cette URL.
• Une redirection dynamique renvoie un type d’entité et un identifiant d’entité. Les types GraphQL documentés sont ProductRedirect, BrandRedirect, BlogPostRedirect, CategoryRedirect et PageRedirect.
• Avec FOLLOW, une redirection dynamique peut renvoyer son entité cible dans node ; une redirection manuelle laisse node à null et expose les détails de la redirection.
• La référence de l’opération upsert des redirections de BigCommerce modélise to avec un type, un identifiant d’entité ou une URL.

Quel élément reste fixe dans la cible d’une redirection manuelle ?

La réponse GraphQL de route représente une cible manuelle sous la forme d’une URL. La documentation des routes indique que l’URL de destination peut elle-même correspondre à une autre redirection, ce qui peut créer une chaîne nécessitant plusieurs requêtes. Le fragment ManualRedirect de la requête documentée demande le champ URL :

redirect {
  toUrl
  to {
    ...on ManualRedirect {
      url
    }
  }
}

L’URL est donc la valeur cible que l’application de vitrine suit ou interroge ensuite. Elle ne contient ni type de ressource ni identifiant d’entité que la requête route puisse résoudre directement.

Comment une redirection dynamique identifie-t-elle sa cible ?

La même documentation de BigCommerce décrit une redirection dynamique comme l’association d’un type d’entité et de l’identifiant d’entité d’une ressource existante de la boutique. Elle nomme cinq types de cibles GraphQL et indique que la cible peut être récupérée directement dans la réponse de route. Le modèle REST des redirections utilise des valeurs de ressource en minuscules dans son objet RedirectTo. Les valeurs autorisées sont product, brand, category, page, post et url, avec entity_id et url comme champs disponibles.

L’exemple de réponse REST représente une cible produit par un type de ressource, un identifiant d’entité et un chemin :

"to": {
  "type": "product",
  "entity_id": 1,
  "url": "/new-url/"
}

Ce modèle permet à une intégration de conserver l’identité de la ressource séparément de l’URL de destination renvoyée dans la réponse.

Que change redirectBehavior ?

Le nœud route accepte le paramètre redirectBehavior, dont la valeur par défaut est IGNORE et l’autre valeur documentée est FOLLOW. IGNORE donne la priorité à la recherche directe d’entités à partir d’URL personnalisées. Si une redirection et une URL d’entité partagent un chemin, redirect et node peuvent tous deux être non nuls avec ce comportement.

Avec FOLLOW, node contient l’entité cible lorsque la redirection est dynamique. Pour une redirection manuelle, la documentation précise que node est null, car l’URL n’a pas d’entité associée, tandis que redirect contient les détails de la redirection. Une requête peut demander à la fois les champs de redirection et l’éventuel nœud produit :

query {
  site {
    route(path: "/mug" redirectBehavior: FOLLOW) {
      redirect { __typename to { __typename ...on ProductRedirect { entityId path } } toUrl }
      node {
        id
        ... on Product { name }
      }
    }
  }
}

Quels champs identifient une redirection dans l’API REST ?

Le point de terminaison upsert accepte une liste d’objets 301RedirectUpsert. BigCommerce indique que from_path et site_id sont obligatoires et que to est facultatif. La référence précise qu’un conflit sur la paire from_path et site_id remplace les données de la redirection par les nouvelles données. Pour une destination fixe, l’objet RedirectTo utilise le champ url. Pour une cible de type ressource, il utilise type et peut inclure entity_id.

Termes associés

• Comment une vitrine découplée (headless) BigCommerce retrouve-t-elle une page à partir d’un chemin d’URL ?
• Que renvoie FOLLOW pour une redirection de route GraphQL BigCommerce ?
• Comment enregistrer des redirections BigCommerce pour un site vitrine précis ?
• Comment inclure les URL cibles résolues des redirections dynamiques dans un export BigCommerce ?

FAQ

Une redirection manuelle inclut-elle un identifiant d’entité ?

La cible GraphQL manuelle est une URL fixe. La requête ManualRedirect documentée demande url, tandis que les fragments de redirection dynamique demandent un identifiant d’entité.

Une redirection dynamique peut-elle renvoyer le produit cible en une seule requête route ?

Oui. Avec redirectBehavior: FOLLOW, BigCommerce indique que node renvoie l’entité cible d’une redirection dynamique. L’exemple demande un identifiant d’entité ProductRedirect et le champ name d’un produit.

Quel est le comportement de redirection par défaut ?

La valeur par défaut est IGNORE. Avec ce comportement, l’API donne la priorité à la recherche directe d’entités à partir d’URL personnalisées et peut renvoyer à la fois redirect et node lorsque le même chemin correspond aux deux.

Sources

1. BigCommerce, « Storefront Routes with the GraphQL Storefront API », sans date
2. BigCommerce, « Upsert Redirects », sans date

---

Vérifiez comment une page se lit pour les moteurs de réponse. Ouvrir l’analyseur de score GEO