Liste de contrôle de mise en production

La liste de contrôle de mise en production est un résumé des bonnes pratiques à prendre en compte lors du lancement d’un site web. Ces étapes sont généralement considérées comme des bonnes pratiques, mais présentent certains aspects spécifiques à Adobe Experience Manager.

Étapes Avant La Mise En Production

AQ de contenu et de conception

Assurez-vous que votre contenu et votre conception sont conformes aux spécifications et que vous êtes satisfait(e) du site web que vous voyez sur vos projets .aem.live domaine. Cela peut inclure des vérifications pour les exigences spécifiques d’accessibilité et d’optimisation pour les moteurs de recherche de votre projet.

Validation des performances

Chaque projet AEM doit générer un score lighthouse de 100 pour les appareils mobiles et les ordinateurs de bureau à partir des informations Pagespeed de Google sur son site .aem.live respectif.

Consultez le document Keeping it 100, Web Performance pour plus d’informations.

Validation Analytics

Assurez-vous que toute votre configuration d’analyse et le reste de votre pile SmartTech se déclenchent comme prévu et que les données du visiteur sont visibles dans vos tableaux de bord de création de rapports.
Lors du redémarrage d’un site web, l’instrumentation d’analyse change en fonction de la séquence de chargement et des performances.

Il est important de s’attendre à ce que la ligne de base de toute mesure capturée par Analytics change. Contactez les analystes correspondants pour vous assurer que l’ajustement de la ligne de base est compris et attendu.

Les mesures susceptibles de modifier leurs lignes de base telles que rapportées par Analytics peuvent inclure les pages vues, les taux de conversion, les taux de rebond, le temps passé sur la page, etc. En fonction des modifications apportées aux modèles de chargement, la ligne de base des mesures peut varier de haut en bas.
Les mesures au bas de l’entonnoir telles que le passage en caisse, les transactions ou l’envoi de formulaire capturées par les systèmes opérationnels ne sont pas affectées et doivent rester inchangées au-delà d’un lancement avec fonction de transfert.

instrumentation RUM

Afin de voir rapidement et de manière fiable l’impact sur les performances et de comparer les mesures avant et après le lancement, nous vous recommandons d’instrumenter votre site web avant le lancement avec Real Use Monitoring (RUM), idéalement le plus tôt possible. L’ajout de RUM à votre site existant est trivial et peut vous donner des informations opérationnelles importantes, même avant le lancement.

Redirections héritées

Dans la plupart des migrations, des URL héritées sont retirées. Assurez-vous qu’elles sont prises en compte dans votre feuille de calcul de redirections (redirects.xlsx dans SharePoint ou redirects dans Google), qui se trouve dans le dossier de contenu du projet. Recherchez dans la console de recherche Google les liens retour les plus performants (en termes d’optimisation du moteur de recherche) pour lesquels créer des redirections.

Voir le document Redirections pour plus d’informations.

Plan du site et robots

Pour la plupart des sites web comportant un nombre important de pages, un plan du site est souhaitable. AEM génère automatiquement des plans de site à partir de l’index de requête. Pour les sites multilingues, l’ajout de hreflang au plan du site garantit que le site web cible correctement l’audience géographique et linguistique appropriée, ce qui est essentiel pour l’optimisation du moteur de recherche (SEO) et empêche des problèmes tels que la duplication de contenu dans différentes versions linguistiques (ou cannibalisation SEO). Cela améliore également la capacité du moteur de recherche à diffuser la version appropriée du contenu aux utilisateurs appropriés.

Si vous disposez d’un plan de site généré pour votre site, assurez-vous qu’il est détectable depuis votre robots.txt. ​​Notez que robots.txt est (techniquement) sensible à la casse et qu’un bon exemple est :

User-agent: *
Allow: /

Sitemap: https://<your-domain>/sitemap.xml

Remarque : les aem.page et aem.live sont délibérément masqués aux robots d’exploration pour éviter les doublons de contenu.

Consultez les documents Indexation et Plans de site pour plus d’informations.

URL canoniques

Assurez-vous que les URL canoniques renvoient le code de statut de réponse d’HTML 2xx (et non 3xx ou 4xx) et qu’elles sont correctement implémentées, ce qui est essentiel pour éviter les problèmes de contenu en double sur le site. Une canonisation appropriée aide les moteurs de recherche à comprendre quelles versions de pages similaires indexer et afficher dans les résultats de recherche, ce qui a un impact direct sur les performances d’optimisation du moteur de recherche.

Pour plus d’informations, consultez la documentation externe suivante : Consolidation des URL en double

Favicon

L’ajout d’une favicon à votre site lui donne un aspect professionnel dans les navigateurs de votre visiteur.

Voir le document Favicon pour plus d’informations.

Authentification pour les auteurs

Par défaut, les auteurs n’ont pas besoin d’être connectés pour utiliser AEM Sidekick. Si vous décidez de contrôler qui peut prévisualiser et publier des documents, cela peut être configuré.

Consultez le document Configuration de l’authentification pour les auteurs pour plus d’informations.

Accès à SharePoint

Si votre contenu se trouve dans SharePoint, suivez ce guide pour configurer l’accès dédié que vous contrôlez.

Configuration du réseau CDN

L’une des dernières étapes d’une mise en production consiste généralement à mettre à jour votre configuration de réseau CDN pour pointer vers votre point d’entrée aem.live.

Idéalement, la configuration du réseau CDN est testée dans un environnement d’évaluation afin de s’assurer que tout fonctionne comme prévu, ce qui inclut des redirections de www vers APEX et vice versa.

Pour plus d’informations sur la configuration de votre réseau CDN autogéré, consultez la documentation de configuration du réseau CDN suivante.

Remarque : la suppression d’un site Edge Delivery supprime également les configurations de réseau CDN associées. Cette action révoque la connexion entre les domaines personnalisés et le site Edge Delivery.

Configuration de l’invalidation des notifications push

Assurez-vous que l’invalidation des notifications push est correctement configurée conformément au document Configuration de l’invalidation des notifications push pour le réseau CDN de production BYO. Testez la configuration en publiant une petite modification et en vérifiant que la modification est visible sur le domaine de production.

Mettre à jour l’hôte de production

Après avoir configuré votre réseau CDN de production, ajoutez la propriété host à la configuration du sidekick dans /tools/sidekick/config.json dans votre référentiel github, pour permettre à vos auteurs de naviguer directement depuis le domaine de production pour la modifier directement depuis le sidekick.

Consultez le document Configuration de Sidekick pour plus d’informations.

Validation de la post-activation

Validation des performances

Vérifiez que les performances atteignent toujours un score lighthouse de 100 via pagespeed insights dans l’environnement de production. L’introduction d’une couche CDN peut avoir des effets négatifs sur les performances, généralement visibles sur la couche de protocole. Les coupables courants sont l’exécution du HTTP/1.1 ou une mise en cache d’origine inefficace, ainsi que la détection des robots ou d’autres bibliothèques injectées par la configuration du réseau CDN.

Console de recherche Google

Si votre plan de site est chargé dans une console de recherche Google active, il peut s’avérer utile d’obtenir un rapport de couverture et de vous assurer que l’indexation fonctionne comme prévu. La console de recherche Google doit être surveillée pendant les semaines qui suivent une activation afin de suivre le statut d’indexation des pages nouvelles et mises à jour, en veillant à ce qu’elles soient correctement reconnues par Google. Il est essentiel de vérifier le nombre total de clics, d’impressions totales, de modifications de liens inverses et d’erreurs d’exploration, car ceux-ci peuvent avoir un impact significatif sur les performances et l’autorité du site en matière d’optimisation du moteur de recherche.

Rapport 404

Après la migration d’un site web, un ensemble de 404 éléments introuvables est généralement généré. Ceux-ci doivent être surveillés après la mise en production et redirigés vers les URL de pages populaires. Ces informations peuvent être extraites de l’analyse de votre site et du rapport de robot Slack correspondant. Il est recommandé de surveiller ce paramètre pendant les semaines qui suivent une mise en production.