Bonnes pratiques relatives à l’optimisation du moteur de recherche (SEO) et à la gestion des URL seo-and-url-management-best-practices

L’optimisation du moteur de recherche (SEO) est devenue une préoccupation essentielle pour de nombreuses personnes spécialisées dans le marketing. En conséquence, les questions d’optimisation du moteur de recherche doivent être traitées pour de nombreux projets AEM.

Le présent document commence par décrire certaines bonnes pratiques relatives à l’optimisation du moteur de recherche et explique comment les suivre lors d’une implémentation d’AEM. Il approfondit ensuite certaines des étapes de mise en œuvre plus complexes abordées dans la première section.

Bonnes pratiques relatives à l’optimisation pour les moteurs de recherche seo-best-practices

Cette section décrit certaines bonnes pratiques générales d’optimisation pour les moteurs de recherche.

URL urls

Il existe certaines bonnes pratiques reconnues concernant les URL.

Dans votre projet AEM, lors de l’évaluation des URL, posez-vous la question suivante :

« Si une personne voit cette URL, mais aucun des éléments de contenu de la page, peut-elle décrire cette page ? »

Si la réponse est oui, alors l’URL fonctionne probablement bien pour un moteur de recherche.

Voici quelques conseils généraux sur la construction de vos URL pour l’optimisation du moteur de recherche :

Configuration du serveur server-configuration

En termes de configuration du serveur, vous pouvez accomplir les étapes suivantes pour vous assurer que seul le contenu approprié est analysé :

Configurations AEM aem-configurations

Cette section décrit les étapes d’implémentation pour configurer AEM avec les recommandations d’optimisation du moteur de recherche suivantes.

Utiliser des sélecteurs Sling using-sling-selectors

Auparavant, des paramètres de requête étaient généralement utilisés lors de la création d’une application web d’entreprise.

La tendance des dernières années a été de les supprimer afin que les URL soient plus lisibles. Sur de nombreuses plateformes, ce processus implique l’implémentation de redirections sur le serveur web ou le réseau de diffusion de contenu (CDN), mais Sling simplifie le processus. Les sélecteurs Sling :

Utilisation de sélecteurs pour les servlets using-selectors-for-servlets

AEM propose deux options d’écriture de servlets :

Les exemples suivants illustrent comment enregistrer des servlets qui suivent ces deux schémas, ainsi que l’avantage obtenu grâce à l’utilisation des servlets Sling.

Servlets bin (un niveau vers le bas) bin-servlets-one-level-down

Les servlets bin suivent le schéma issu de la programmation J2EE auquel nombre de développeurs et développeuses sont habitués. Le servlet est enregistré à un chemin spécifique qui, dans le cas d’AEM, se trouve généralement sous /bin, et vous extrayez les paramètres de requête nécessaires dans la chaîne de requête.

L’annotation SCR pour ce type de servlet doit ressembler à ce qui suit :

@SlingServlet(paths = "/bin/myApp/myServlet", extensions = "json", methods = "GET")

Vous extrayez ensuite les paramètres à partir de la chaîne de requête via l’objet SlingHttpServletRequest inclus dans la méthode doGet, par exemple :

String myParam = req.getParameter("myParam");

L’URL résultante utilisée doit ressembler à ce qui suit :

https://www.mydomain.com/bin/myApp/myServlet.json?myParam=myValue

Cette approche comporte quelques points à prendre en compte :

Servlets Sling (un niveau vers le bas) sling-servlets-one-level-down

Les servlets Sling vous permettent d’enregistrer votre servlet de la manière opposée. Au lieu d’adresser un servlet et de spécifier le contenu que le servlet doit rendre en fonction des paramètres de requête, vous pouvez adresser le contenu de votre choix. Vous spécifiez également le servlet qui doit effectuer le rendu du contenu en fonction des sélecteurs Sling.

L’annotation SCR pour ce type de servlet doit ressembler à ce qui suit :

@SlingServlet(resourceTypes = "myBrand/components/pages/myPageType", selectors = "myRenderer", extensions = "json", methods="GET")

Dans ce cas, la ressource que l’URL adresse (une instance de la ressource myPageType) est accessible dans le servlet automatiquement. Pour y accéder, vous devez appeler :

Resource myPage = req.getResource();

L’URL résultante utilisée doit ressembler à ce qui suit :

https://www.mydomain.com/content/my-brand/my-page.myRenderer.json

Les avantages de cette approche sont les suivants :

Réécriture d’URL url-rewriting

Dans AEM, toutes les pages web sont stockées sous /content/my-brand/my-content. Bien que cet emplacement soit utile du point de vue de la gestion des données du référentiel, il ne s’agit pas nécessairement de la manière dont vous souhaitez que vos clientes et clients voient votre site. En outre, cela peut entrer en conflit avec les directives d’optimisation du moteur de recherche pour conserver les URL aussi courtes que possible. En outre, vous pouvez diffuser plusieurs sites web depuis la même instance AEM et différents noms de domaines.

Cette section décrit les options disponibles dans AEM pour gérer ces URL et les présenter aux utilisateurs d’une manière plus lisible et tenant davantage compte de l’optimisation pour les moteurs de recherche.

URL de redirection vers un microsite vanity-urls

Si un auteur souhaite qu’une page soit accessible depuis un autre emplacement à des fins publicitaires, les URL de redirection vers un microsite d’AEM, définies page par page, peuvent être utiles. Afin d’ajouter une URL de redirection vers un microsite pour une page, accédez à la console Sites et modifiez les propriétés de la page. Au bas de l’onglet Basique se trouve une section dans laquelle peuvent être ajoutées les URL de redirection vers un microsite. Gardez à l’esprit que le fait que la page soit accessible via plusieurs URL réduit la valeur d’optimisation pour les moteurs de recherche de la page en question. Par conséquent, une balise d’URL canonique doit être ajoutée à la page afin d’éviter ce problème.

Noms de pages localisés localized-page-names

Vous pouvez afficher les noms de pages localisés pour les utilisateurs de contenu traduit. Par exemple :

La difficulté en matière de localisation du nom d’une page réside dans le fait que plusieurs outils de localisation disponibles sur la plateforme AEM nécessitent que les noms de cette page correspondent dans toutes les langues pour que le contenu reste synchronisé.

La propriété sling:alias permet de pallier cette difficulté. sling:alias peut être ajouté comme propriété à n’importe quelle ressource pour donner un nom d’alias à la ressource. Dans l’exemple précédent, vous auriez :

Les outils de traduction d’AEM tels que le gestionnaire multisite peuvent ainsi conserver des relations entre :

Tout en permettant aux utilisateurs finaux d’interagir avec le nom de la page dans leur langue maternelle.

/etc/map etc-map

Dans une installation AEM standard :

Les définitions de mappage peuvent être ajoutées à cet emplacement pour mapper des requêtes entrantes, réécrire des URL sur des pages dans AEM, ou les deux.

Pour créer un mappage, créez un nœud sling:Mapping à cet emplacement sous /http ou /https. En fonction des propriétés sling:match et sling:internalRedirect définies sur ce nœud, AEM redirigera tout le trafic pour l’URL correspondante vers la valeur spécifiée dans la propriété internalRedirect.

Bien qu’il s’agisse de l’approche documentée dans la documentation officielle d’AEM et de Sling, cette implémentation ne fournit qu’une prise en charge limitée des expressions régulières par rapport aux options disponibles en utilisant directement SlingResourceResolver. De plus, une telle mise en œuvre des mappages peut entraîner des problèmes d’invalidation du cache du Dispatcher.

Voici un exemple de la manière dont ce problème se produit :

Il existe plusieurs façons de configurer des règles de vidage du Dispatcher personnalisées qui mappent les URL plus courtes aux URL plus longues à des fins d’invalidation du cache.

Cependant, il existe également un moyen plus simple de gérer ce problème :

Apache HTTP Server mod_rewrite apache-http-server-mod-rewrite

Jusqu’à présent, vous avez implémenté des mappages avec la logique dans vos composants pour utiliser ces mappages lors de la génération des URL sur des pages.

La gestion de ces URL raccourcies lorsqu’elles entrent dans le Dispatcher constitue la pièce finale du puzzle ; c’est là que mod_rewrite entre en jeu. L’utilisation de mod_rewrite a pour principal avantage que les URL sont mappées vers leur forme complète avant leur envoi au module de Dispatcher. Cela signifie que le Dispatcher demande l’URL longue au serveur de publication et la met en cache en conséquence. Par conséquent, toutes les demandes de vidage du Dispatcher entrant à partir du serveur de publication invalideront correctement ce contenu.

Pour mettre en œuvre ces règles, vous pouvez ajouter des éléments RewriteRule sous votre hôte virtuel dans la configuration Apache HTTP Server. Si vous souhaitez développer les URL raccourcies de l’exemple précédent, vous pouvez mettre en œuvre une règle qui ressemble à ce qui suit :

<VirtualHost *:80>
  ServerName www.mydomain.com
  RewriteEngine on
  RewriteRule ^/(.*)$ /content/my-brand/$1 [PT,L]
  …
</VirtualHost>

Balises d’URL canoniques canonical-url-tags

Les balises d’URL canoniques sont des balises de lien placées dans l’en-tête d’un document HTML afin de clarifier la manière dont les moteurs de recherche doivent traiter une page lors de l’indexation du contenu. Elles présentent l’avantage de s’assurer qu’une page (et ses différentes versions) sera indexée comme étant la même, même si l’URL menant vers la page peut contenir des différences.

Par exemple, si un site offre une version d’une page compatible avec les imprimantes, un moteur de recherche indexerait potentiellement cette page indépendamment de la version standard de la page. La balise canonique indique au moteur de recherche qu’elles sont identiques.

Exemples :

Les deux appliqueraient la balise suivante à la tête de la page :

<link rel="canonical" href="my-brand/my-page.html"/>

href peut être relatif ou absolu. Le code doit être inclus dans le balisage de la page pour déterminer l’URL canonique de la page et générer cette balise.

Configuration du Dispatcher pour le non-respect de la casse configuring-the-dispatcher-for-case-insensitivity

La bonne pratique consiste à afficher toutes les pages en minuscules. Cependant, vous ne souhaitez pas qu’une personne obtienne une erreur 404 lorsqu’elle accède à votre site web en utilisant des lettres majuscules dans son URL. Pour cette raison, Adobe recommande d’ajouter une règle de réécriture dans la configuration Apache HTTP Server de façon à mapper toutes les URL entrantes vers une version en lettres minuscules. En outre, les créateurs de contenu doivent être formés pour créer leurs pages avec des noms en minuscules.

Pour configurer Apache afin de forcer le trafic entrant à être écrit en minuscules, ajoutez les éléments suivants à la configuration vhost :

RewriteEngine On
RewriteMap lowercase int:tolower

De plus, ajoutez le code suivant au tout début du fichier htaccess :

RewriteCond $1 [A-Z]
RewriteRule ^(.*)$ /${lowercase:$1} [R=301,L]

Mise en œuvre de robots.txt pour protéger les environnements de développement implementing-robots-txt-to-protect-development-environments

Les moteurs de recherche doivent normalement vérifier la présence d’un fichier robots.txt à la racine du site avant d’analyser votre site. Si les principaux moteurs de recherche comme Google, Yahoo ou Bing le font, d’autres ne le font pas.

La façon la plus simple de bloquer l’accès à l’ensemble de votre site consiste à placer un fichier nommé robots.txt à la racine du site avec le contenu suivant :

User-agent: *
Disallow: /

Sur un environnement de production, vous pouvez également choisir de désactiver certains chemins que vous ne voulez pas voir indexer.

Lorsque vous placez le fichier robots.txt à la racine du site, il est possible que les requêtes de purge du Dispatcher effacent ce fichier. En outre, les mappages d’URL placent probablement la racine du site à un emplacement différent du DOCROOT, comme défini dans la configuration Apache HTTP Server. Pour cette raison, il est courant de placer ce fichier sur l’instance de création à la racine du site et de le répliquer dans l’instance de publication.

Création d’un plan de site XML sur AEM building-an-xml-sitemap-on-aem

Les robots d’exploration utilisent des plans de site XML pour mieux comprendre la structure des sites web. Bien que le fait de fournir un plan de site ne garantisse pas un meilleur référencement sur les moteurs de recherche, c’est une pratique recommandée. Vous pouvez gérer manuellement un fichier XML sur le serveur web à utiliser comme plan du site. Cependant, Adobe vous recommande de générer le plan du site par programmation afin de vous assurer que, lorsque les auteurs et autrices créent du contenu, le plan du site reflète automatiquement leurs modifications.

AEM utilise le module de plan de site d’Apache Sling pour générer des plans de site XML, un module qui offre un large éventail d’options permettant aux personnes chargées du développement et de l’édition de tenir à jour un plan de site XML Sites.

Le module de plan de site Apache Sling fait la distinction entre un plan de site de niveau supérieur et un plan de site imbriqué, tous deux générés pour toute ressource dont la propriété sling:sitemapRoot est définie sur true. En règle générale, les plans de site sont rendus à l’aide de sélecteurs localisés par le chemin du plan de site de niveau supérieur de l’arborescence, qui correspond à la ressource qui n’a aucun autre ancêtre racine du plan de site. Cette racine de plan de site de niveau supérieur expose également l’index de plan de site, qui est normalement ce que le propriétaire d’un site doit configurer dans le portail de configuration du moteur de recherche ou ajouter au fichier robots.txt du site.

Prenons l’exemple d’un site qui définit une racine de plan de site de niveau supérieur à l’adresse my-page et une racine de plan de site imbriqué à l’emplacement my-page/news, afin de générer un plan de site dédié pour les pages de la sous-arborescence news. Les URL pertinentes résultantes seraient :

Dans la configuration par défaut, la boîte de dialogue Propriétés de la page permet d’identifier une page en tant que racine du plan du site et, comme décrit ci-dessus, de générer un plan du site lui-même et de ses descendants. Ce comportement est implémenté par les implémentations de l’interface SitemapGenerator et peut être étendu en ajoutant d’autres implémentations. Cependant, comme la fréquence de régénération des plans de site XML dépend des workflows et des charges de travail de création de contenu, le produit n’est livré avec aucune configuration SitemapScheduler. Par conséquent, la fonctionnalité est effectivement opt-in.

Pour activer le traitement en arrière-plan qui génère le plan de site XML, un SitemapScheduler doit être configuré. Pour ce faire, créez une configuration OSGI pour le org.apache.sling.sitemap.impl.SitemapScheduler de l’ID persistante. L’expression du planificateur 0 0 0 * * ? peut être utilisée comme point de départ pour régénérer tous les plans de site XML, une fois par jour à minuit.

Le traitement de génération du plan de site peut s’exécuter sur les instances de niveau création et publication. Généralement, il est recommandé d’exécuter la génération sur les instances de niveau publication, car les URL canoniques appropriées ne peuvent être générées qu’à ce niveau (en raison des règles de mappage des ressources Sling généralement présentes uniquement sur les instances de niveau publication). Cependant, il est possible d’intégrer en tant que plug-in une implémentation personnalisée du mécanisme d’externalisation utilisé pour générer les URL canoniques en implémentant l’interface SitemapLinkExternalizer. Si une implémentation personnalisée peut générer les URL canoniques d’un plan de site sur les instances de niveau création, le SitemapScheduler peut être configuré pour le mode d’exécution de création. De plus, la charge de travail de génération du plan de site XML peut être répartie entre les instances du cluster de services de création. Dans ce scénario, une attention particulière doit être accordée à la manipulation de contenus qui n’ont pas encore été publiés, qui ont été modifiés ou qui ne sont visibles que par un groupe restreint d’utilisateurs et utilisatrices.

AEM Sites contient une implémentation par défaut d’un SitemapGenerator qui parcourt une arborescence de pages pour générer un plan de site. Il est préconfiguré pour ne générer que les URL canoniques d’un site et des alternatives linguistiques, le cas échéant. Il peut également être configuré pour inclure la date de dernière modification d’une page, si nécessaire. Pour ce faire, activez l’option Ajouter la dernière modification de la configuration Optimisation du moteur de recherche d’Adobe AEM - Générateur de plan de site de l’arborescence de page et sélectionnez une Source de dernière modification. Lorsque les plans de site sont générés au niveau de publication, il est recommandé d’utiliser la date cq:lastModified.

Pour limiter le contenu d’un plan de site, les interfaces de service suivantes peuvent être mises en œuvre si nécessaire :

Si les implémentations par défaut ne fonctionnent pas dans un cas d’utilisation particulier ou si les points d’extension ne sont pas suffisamment flexibles, implémentez un SitemapGenerator personnalisé pour prendre le contrôle intégral du contenu d’un plan de site généré. L’exemple suivant utilise la logique de l’implémentation par défaut pour AEM Sites. Il utilise le ResourceTreeSitemapGenerator comme point de départ pour parcourir une arborescence de pages :

import java.util.Optional;

import org.apache.sling.api.resource.Resource;
import org.apache.sling.sitemap.SitemapException;
import org.apache.sling.sitemap.builder.Sitemap;
import org.apache.sling.sitemap.builder.Url;
import org.apache.sling.sitemap.spi.common.SitemapLinkExternalizer;
import org.apache.sling.sitemap.spi.generator.ResourceTreeSitemapGenerator;
import org.apache.sling.sitemap.spi.generator.SitemapGenerator;
import org.jetbrains.annotations.NotNull;
import org.osgi.service.component.annotations.Component;
import org.osgi.service.component.annotations.Reference;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import com.adobe.aem.wcm.seo.sitemap.PageTreeSitemapGenerator;
import com.day.cq.wcm.api.Page;

@Component(
    service = SitemapGenerator.class,
    property = { "service.ranking:Integer=20" }
)
public class SitemapGeneratorImpl extends ResourceTreeSitemapGenerator {

    private static final Logger LOG = LoggerFactory.getLogger(SitemapGeneratorImpl.class);

    @Reference
    private SitemapLinkExternalizer externalizer;
    @Reference
    private PageTreeSitemapGenerator defaultGenerator;

    @Override
    protected void addResource(@NotNull String name, @NotNull Sitemap sitemap, Resource resource) throws SitemapException {
        Page page = resource.adaptTo(Page.class);
        if (page == null) {
            LOG.debug("Skipping resource at {}: not a page", resource.getPath());
            return;
        }
        String location = externalizer.externalize(resource);
        Url url = sitemap.addUrl(location + ".html");
        // add any additional content to the Url like lastmod, change frequency, and so on
    }

    @Override
    protected final boolean shouldFollow(@NotNull Resource resource) {
        return super.shouldFollow(resource)
            && Optional.ofNullable(resource.adaptTo(Page.class)).map(this::shouldFollow).orElse(Boolean.TRUE);
    }

    private boolean shouldFollow(Page page) {
        // add additional conditions to stop traversing some pages
        return !defaultGenerator.isProtected(page);
    }

    @Override
    protected final boolean shouldInclude(@NotNull Resource resource) {
        return super.shouldInclude(resource)
            && Optional.ofNullable(resource.adaptTo(Page.class)).map(this::shouldInclude).orElse(Boolean.FALSE);
    }

    private boolean shouldInclude(Page page) {
        // add additional conditions to stop including some pages
        return defaultGenerator.isPublished(page)
            && !defaultGenerator.isNoIndex(page)
            && !defaultGenerator.isRedirect(page)
            && !defaultGenerator.isProtected(page);
    }
}

De plus, la fonctionnalité mise en œuvre pour les plans de site XML peut également être utilisée dans différents cas d’utilisation, par exemple pour ajouter le lien canonique ou des variantes linguistiques à l’en-tête d’une page. Voir l’interface SeoTags pour plus d’informations.

Création de redirections 301 pour les URL héritées creating-redirects-for-legacy-urls

Lors du lancement d’un site avec une nouvelle structure, la mise en œuvre et le test des redirections 301 dans Apache HTTP Server sont importants pour deux raisons :

Veillez à consulter la section Ressources supplémentaires qui suit pour obtenir des instructions sur la mise en œuvre des redirections 301, ainsi que pour en savoir plus sur un outil permettant de tester que vos redirections fonctionnent comme prévu.

Ressources supplémentaires additional-resources

Pour plus d’informations, consultez les ressources supplémentaires suivantes :