Configurations d’URL avancées

REMARQUE

L’optimisation pour les moteurs de recherche est devenue une préoccupation essentielle pour de nombreux spécialistes du marketing. Par conséquent, l’optimisation pour les moteurs de recherche doit être prise en compte dans de nombreux projets Adobe Experience Manager (AEM) as a Cloud Service. Consultez les Bonnes pratiques de gestion des URL et de l’optimisation pour les moteurs de recherche pour plus d’informations.

Les composants principaux AEM CIF offrent des configurations avancées pour personnaliser les URL des pages de produits et de catégories. De nombreuses mises en œuvre personnalisent ces URL à des fins d’optimisation pour les moteurs de recherche (SEO). La vidéo suivante explique comment configurer le UrlProvider service et les fonctionnalités du mappage Sling pour personnaliser les URL des pages de produits et de catégories.

Configuration

Pour configurer le service UrlProvider en fonction des exigences et des besoins de SEO, un projet doit fournir une configuration OSGI pour la configuration du fournisseur d’URL CIF.

REMARQUE

Depuis la version 2.0.0 des composants principaux CIF d’AEM, la configuration du fournisseur d’URL fournit uniquement des formats d’URL prédéfinis, au lieu des formats configurables en texte libre connus des versions 1.x. De plus, l’utilisation de sélecteurs pour transmettre des données dans des URL a été remplacée par des suffixes.

Format d’URL de page de produits

Celui-ci configure les URL des pages de produits et prend en charge les options suivantes :

  • {{page}}.html/{{sku}}.html#{{variant_sku}} (par défaut)
  • {{page}}.html/{{sku}}/{{url_key}}.html#{{variant_sku}}
  • {{page}}.html/{{sku}}/{{category}}/{{url_key}}.html#{{variant_sku}}
  • {{page}}.html/{{sku}}/{{url_path}}.html#{{variant_sku}}
  • {{page}}.html/{{url_key}}.html#{{variant_sku}}
  • {{page}}.html/{{category}}/{{url_key}}.html#{{variant_sku}}
  • {{page}}.html/{{url_path}}.html#{{variant_sku}}

Dans le cas du magasin de référence Venia :

  • {{page}} sera remplacé par /content/venia/us/en/products/product-page
  • {{sku}} sera remplacé par le SKU du produit, par exemple VP09
  • {{url_key}} sera remplacé par la propriété url_key du produit, par exemple lenora-crochet-shorts
  • {{url_path}} sera remplacé par le url_path du produit, par exemple venia-bottoms/venia-pants/lenora-crochet-shorts
  • {{variant_sku}} sera remplacé par la variante actuellement sélectionnée, par exemple VP09-KH-S

Depuis que url_path a été déprécié, les formats d’URL de produit prédéfinis utilisent les url_rewrites d’un produit et choisissent celui qui contient le plus de segments de chemin comme alternative si url_path n’est pas disponible.

Avec les données d’exemple ci-dessus, une URL de variante de produit formatée à l’aide du format d’URL par défaut ressemblera à /content/venia/us/en/products/product-page.html/VP09.html#VP09-KH-S.

Format d’URL de page de catégorie

Celui-ci configure les URL des pages de listes de catégories ou de produits et prend en charge les options suivantes :

  • {{page}}.html/{{url_path}}.html (par défaut)
  • {{page}}.html/{{url_key}}.html

Dans le cas du magasin de référence Venia :

  • {{page}} sera remplacé par /content/venia/us/en/products/category-page
  • {{url_key}} sera remplacé par la propriété url_key de la catégorie.
  • {{url_path}} sera remplacé par le url_path de la catégorie

Avec les données d’exemple ci-dessus, une URL de page de catégorie formatée à l’aide du format d’URL par défaut ressemblera à /content/venia/us/en/products/category-page.html/venia-bottoms/venia-pants.html.

REMARQUE

L’url_path est une concaténation des url_keys, des ancêtres d’un produit ou d’une catégorie et de l’url_key du produit ou de la catégorie, séparés par une barre oblique /. Chaque url_key est considéré comme unique dans un magasin donné.

Configuration spécifique au magasin

Les formats d’URL de catégories et de pages de produits définis par la configuration du fournisseur d’URL CIF peuvent être modifiés pour chaque magasin.

Dans la configuration du CIF, un éditeur peut sélectionner un autre format d’URL de page de catégorie ou de produit. Si rien n’est sélectionné à cet endroit, l’implémentation revient à la configuration de l'ensemble du système.

La modification du format de l’URL d’un site Web actif peut avoir un impact négatif sur le trafic organique de votre site. Veuillez vous référer aux Bonnes pratiques ci-dessous et planifier soigneusement le changement du format de l'URL à l'avance.

Formats d’URL dans la configuration CIF

REMARQUE

La configuration spécifique des formats d’URL pour les magasins nécessite les composants principaux CIF 2.6.0 et la dernière version du module complémentaire Adobe Experience Manager de contenu et Commerce.

URL de page de produits prenant en compte les catégories

Comme il est possible d’encoder des informations sur les catégories dans l’URL d’un produit, les produits appartenant à plusieurs catégories peuvent également être adressés avec plusieurs URL de produit.

Les formats d’URL par défaut sélectionnent l’une des alternatives possibles à l’aide du schéma suivant :

  • si l’url_path est défini par le serveur principal de commerce électronique, utilisez-le (obsolète).
  • à partir des url_rewrites utilisez les URL qui se terminent par l’url_key comme alternatives
  • parmi ces alternatives, utilisez celle qui a le plus de segments de chemin d’accès
  • s’il y en a plusieurs, prenez la première dans l’ordre indiqué par le serveur principal de commerce électronique.

Ce schéma sélectionne la variable url_path avec la plupart des ancêtres, en partant du principe qu’une catégorie enfant est plus spécifique que sa catégorie parent. The so selected url_path is considered canonical and will always be used as the canonical link on product pages or in the product sitemap.

Cependant, lorsqu’un acheteur navigue d’une page de catégorie à une page de produit, ou d’une page de produit à une autre page de produit associée dans la même catégorie, il est utile de conserver le contexte actuel de la catégorie. Dans ce cas, la sélection url_path doit préférer les alternatives qui se trouvent dans le contexte de la catégorie actuelle à la sélection canonique décrite ci-dessus.

Cette fonctionnalité doit être intégrée dans la configuration du fournisseur d’URL CIF. Si elle est activée, la sélection donnera un score plus élevé aux alternatives, lorsque

  • elles correspondent à des parties d’une catégorie donnée url_path depuis le début (correspondance approximative des préfixes)
  • ou correspondent à une catégorie donnée url_key n’importe où (correspondance partielle exacte)

Prenons l’exemple de la réponse à une requête de produits ci-dessous. Given the user is on the "New Prodcuts / New in Summer 2022" category page and the store uses the default category page URL format, the alternative "new-products/new-in-summer-2022/gold-cirque-earrings.html" would match 2 of the context's path segments from the beginning: "new-products" and "new-in-summer-2022". If the store uses a category page URL format that only contains the category url_key, the same alternative would still be selected as it matches the context's url_key anywhere. Dans les deux cas, l’URL de la page de produits est créée pour « nouveaux-produits/nouveautes-de-lete-2022/boucles-doreilles-cirque-dor.html »url_path.

{
  "data": {
    "products": {
      "items": [
        {
          "sku": "VA18-GO-NA",
          "url_key": "gold-cirque-earrings",
          "url_rewrites": [
            {
              "url": "gold-cirque-earrings.html"
            },
            {
              "url": "venia-accessories/gold-cirque-earrings.html"
            },
            {
              "url": "venia-accessories/venia-jewelry/gold-cirque-earrings.html"
            },
            {
              "url": "new-products/gold-cirque-earrings.html"
            },
            {
              "url": "new-products/new-in-summer-2022/gold-cirque-earrings.html"
            }
          ]
        }
      ]
    }
  }
}
REMARQUE

Les URL de produits prenant en compte les catégories nécessitent les composants principaux CIF 2.6.0 ou plus récents.

Pages de catégories et de produits spécifiques

Il est possible de créer plusieurs pages de catégories et de produits pour un sous-ensemble spécifique de catégories ou de produits d’un catalogue.

Critères de sélection

La sélection d’une page de catégorie spécifique est directe, basée sur l’url_path ou l’url_key de la catégorie. La correspondance de sous-catégories n’est prise en charge que pour les formats d’URL contenant l’url_path complet de la catégorie. Sinon, seule une correspondance exacte de l’url_key est possible.

Les pages de produits spécifiques sont sélectionnées soit par le sku du produit, soit par sa catégorie. Dans ce dernier cas, certaines informations sur la catégorie doivent être encodées dans l’URL du produit. Cette option n’est disponible que pour certains des formats d’URL par défaut. Reportez-vous au tableau ci-dessous pour une comparaison des formats d’URL qui permettent de sélectionner des pages spécifiques par sku ou par catégorie.

Format d’URL par sku par catégorie
{{page}}.html/{{url_key}}.html non non
{{page}}.html/{{category}}/{{url_key}}.html non correspondance exacte uniquement
{{page}}.html/{{url_path}}.html non oui
{{page}}.html/{{sku}}.html oui non
{{page}}.html/{{sku}}/{{url_key}}.html oui non
{{page}}.html/{{sku}}/{{category}}/{{url_key}}.html oui correspondance exacte uniquement
{{page}}.html/{{sku}}/{{url_path}}.html oui oui
REMARQUE

Pour sélectionner des pages produits spécifiques en fonction de la catégorie, vous devez disposer de lʼextension CIF Core Components 2.6.0 ou version ultérieure.

Lien profond

Le UrlProvider est préconfiguré pour générer des liens profonds vers des pages de catégories et de produits spécifiques sur les instances dʼauteur. Cette fonctionnalité est utile aux rédacteurs qui parcourent un site en mode Prévisualisation, se rendent sur une page produit ou de catégorie spécifique, puis repassent en mode Édition pour modifier la page.

Dans les instances de publication, en revanche, les adresses URL des pages de catalogue doivent rester stables pour ne pas perdre les gains de classement dans les moteurs de recherche, par exemple. Pour cette raison, les instances de publication ne généreront pas de liens profonds vers des pages de catalogue spécifiques par défaut. Pour modifier ce comportement, la Stratégie de page spécifique du fournisseur d’URL CIF peut être configurée pour toujours générer des adresses URL de page spécifiques.

Personnalisations

Formats d’URL personnalisés

Pour fournir un format dʼURL personnalisé, un projet peut implémenter soit lʼinterface de service ProductUrlFormat ou CategoryUrlFormat et enregistrer lʼimplémentation en tant que service OSGI. Ces implémentations, si elles sont disponibles, remplaceront le format configuré et prédéfini. S’il existe plusieurs implémentations enregistrées, celle qui a le rang de service supérieur remplace celle ou ceux qui ont le rang de service inférieur.

Les implémentations de format dʼURL personnalisé doivent implémenter une paire de méthodes pour créer une adresse URL à partir de paramètres donnés, et pour analyser une URL afin de renvoyer les mêmes paramètres, respectivement.

Combinaison avec des mappages Sling

En plus du UrlProvider, il est également possible de configurer des mappages Sling afin de réécrire et de traiter les URL. Le projet AEM Archetype fournit également un exemple de configuration afin de configurer des mappages Sling pour le port 4503 (publication) et 80 (Dispatcher).

Combinaison avec AEM Dispatcher

Les réécritures d’URL peuvent également être obtenues en utilisant le serveur HTTP AEM Dispatcher avec le module mod_rewrite. L’archétype de projet AEM fournit une configuration de Dispatcher AEM de référence qui inclut déjà des règles de réécriture de base pour la taille générée.

Bonnes pratiques

Choisir le meilleur format d’URL

Comme mentionné avant de sélectionner l’un des formats par défaut disponibles, ou même d’implémenter un format personnalisé, cela dépend fortement des besoins et des exigences d’un magasin. Les suggestions suivantes peuvent vous aider à prendre une décision éclairée.

Utilisez un format d’URL de page produit qui contient le code SKU.

Le code SKU est utilisé comme identifiant principal dans tous les composants de lʼextension CIF Core Components. If the product page URL format does not contain the sku, a GraphQL query is necessary to resolve it. This may impact the time-to-first-byte. Also, it may be desired, that shoppers can find products by sku using search enignes.

Utilisez un format dʼURL de page produit qui contient le contexte de la catégorie.

Certaines fonctionnalités du fournisseur d’URL CIF ne sont disponibles que lors de l’utilisation de formats d’URL de produit, qui encodent le contexte de catégorie, comme la catégorie url_key ou la catégorie url_path. Même si ces fonctionnalités ne sont pas nécessaires pour un nouveau magasin, l’utilisation de l’un de ces formats d’URL au début contribue à réduire les efforts de migration à l’avenir.

Compromis entre la longueur de lʼURL et les informations codées.

En fonction de la taille du catalogue, en particulier de la taille et de la profondeur de lʼarbre des catégories, il peut ne pas être raisonnable dʼencoder lʼurl_path complet des catégories dans lʼadresse URL. Dans ce cas, la longueur de l’URL peut être réduite en incluant uniquement le url_key au lieu de . Cela prend en charge la plupart des fonctionnalités disponibles lors de l’utilisation de la catégorie url_path.

En outre, utilisez les Mappages Sling afin de combiner le code SKU avec lʼurl_key du produit. Dans la plupart des systèmes d’e-commerce, le SKU suit un format particulier et sépare le SKU de la variable url_key pour les requêtes entrantes doivent être facilement possibles. Dans cette optique, il devrait être possible de réécrire lʼadresse URL dʼune page produit en /p/{{category}}/{{sku}}-{{url_key}}.html, et lʼURL dʼune catégorie en /c/{{url_key}}.html, respectivement. Les préfixes /p et /c sont toujours nécessaires pour distinguer les pages produit et de catégories des autres pages de contenu.

Migration vers un nouveau format d’URL

De nombreux formats d’URL par défaut sont d’une manière ou d’une autre compatibles entre eux, ce qui signifie que les URL formatées par l’un peuvent être analysées par un autre. Cela permet la migration entre les formats d’URL.

D’un autre côté, les moteurs de recherche auront besoin d’un certain temps pour analyser à nouveau toutes les pages du catalogue avec le nouveau format d’URL. Pour prendre en charge ce processus et améliorer l’expérience de l’utilisateur final, il est recommandé de fournir des redirections qui redirigent l’utilisateur des anciennes URL vers les nouvelles.

Une approche pour cela pourrait être de connecter un environnement intermédiaire au serveur principal de commerce électronique de production et de le configurer pour utiliser le nouveau format d’URL. Afterwards obtain the product sitemap generated by CIF products sitemap generator for both the stage and the production environment, and use them to create an Apache httpd rewrite map. Cette carte de réécriture peut ensuite être déployée sur le Dispatcher en même temps que le déploiement du nouveau format d’URL.

Exemple

Le projet de magasin de référence Venia comprend des exemples de configuration afin de démontrer l’utilisation d’URL personnalisées pour les pages de produits et de catégories. Cela permet à chaque projet de configurer des modèles d’URL individuels pour les pages de produits et de catégories en fonction de leurs besoins d’optimisation de moteur de recherche. Une combinaison de mappages UrlProvider et Sling CIF telle que décrite ci-dessus est utilisée.

REMARQUE

Cette configuration doit être ajustée avec le domaine externe utilisé par le projet. Les mappages Sling fonctionnent en fonction du nom d’hôte et du domaine. Par conséquent, cette configuration est désactivée par défaut et doit être activée avant le déploiement. Pour ce faire, renommez le dossier hostname.adobeaemcloud.com de mappage Sling dans ui.content/src/main/content/jcr_root/etc/map.publish/https en fonction du nom de domaine utilisé et activez cette configuration en ajoutant resource.resolver.map.location="/etc/map.publish" à la configuration JcrResourceResolver du projet.

Ressources supplémentaires

Sur cette page