Une refonte de site est en cours pour vous? Félicitations d'avoir trouvé cet article. Les informations suivantes pourraient être une contribution décisive pour vous permettre de réussir votre refonte et d'obtenir un résultat fabuleux. Car ce n'est pas toujours le cas. Je suis propriétaire d'une agence et je vais vous révéler exactement ce qui vous permettra de forcer des gens comme moi à faire un travail exceptionnel et à éviter les erreurs typiques lors des refontes. Mais commençons du tout début.
Table des matières
Une refonte de site web est la rénovation et la révision d'un site web existant. Cela peut concerner à la fois la conception, le contenu et la technologie. L'objectif d'une refonte de site web est d'améliorer le site et de l'adapter aux exigences actuelles.
Certaines forces externes poussent les entreprises à déclarer l'objectif de "refonte" : le nouvel employé apporte de bonnes idées, un nouveau chef arrive et veut remuer le monde digital, la concurrence a un nouveau site web ou le chiffre d'affaires diminue. Peut-être que l'épouse du patron n'aime pas non plus l'ancien site ou que la génération Z trouve le site pas assez "cool". Vous connaissez peut-être cela. Le fait qu'il soit de nouveau temps pour un nouveau site web, tout comme les opinions personnelles, ne sont pas une raison valable pour une refonte.
Cependant, il existe certains motifs plus convaincants pour lesquels les entreprises ou organisations souhaitent réaliser une refonte de site web. Les plus importants sont les suivants :
- Conception obsolète et/ou rebranding : Un site web dépassé peut donner l'impression que l'entreprise ne suit pas son époque ou n'est plus active. Un design frais et moderne doit donc améliorer l'image. Même en cas de changement de l'image de marque ou de l'identité de l'entreprise, une refonte du site web est souvent souhaitée pour refléter le nouveau message de la marque.
- Meilleure expérience utilisateur : Si l'ergonomie d'un site web est médiocre, cela peut entraîner un taux de rebond élevé. Une refonte peut servir à améliorer l'expérience utilisateur et à rendre le site plus facile à naviguer.
- Optimisation mobile : Comme de plus en plus de personnes accèdent aux sites web via des appareils mobiles, il est essentiel de garantir que le site fonctionne bien sur des tailles d'écran et des appareils différents.
- Optimisation pour les moteurs de recherche (SEO) : Un site web obsolète peut rencontrer des problèmes de performance en matière de SEO. Une refonte offre l'opportunité de faire des changements favorables au SEO pour améliorer la visibilité sur les moteurs de recherche.
- Mise à jour du contenu : Lorsque les informations, les services ou les produits d'une entreprise changent, le site web doit être mis à jour pour refléter ces changements.
- Améliorations de sécurité : Les anciens sites web sont souvent plus exposés aux risques de sécurité. Une refonte peut servir à améliorer la sécurité du site et le protéger contre les cyberattaques.
- Mise à jour technologique : L'utilisation de technologies obsolètes peut affecter les performances d'un site web. Une refonte peut offrir l'occasion de passer à des technologies web et plates-formes actuelles.
- Accessibilité : L'amélioration de l'accessibilité est une préoccupation importante pour de nombreux sites web, afin de s'assurer qu'ils sont accessibles aux personnes handicapées.
- Compétitivité : Pour rester concurrentiel, il est important d'avoir un site web moderne et performant. Une refonte peut contribuer à maintenir ou à améliorer la compétitivité.
- Améliorations analytiques: En mettant en place de meilleurs outils d'analyse et en collectant des données, les entreprises peuvent mieux comprendre et optimiser les performances de leur site web.
- Conformité aux exigences légales: Les lois et réglementations en matière de protection des données, d'accessibilité et de sécurité évoluent régulièrement. Une refonte peut être nécessaire pour s'assurer que le site web est conforme à ces exigences.
Ces raisons peuvent se manifester individuellement ou en combinaison, et varient en fonction des objectifs et des besoins de l'entreprise. Une refonte de site web est souvent une décision stratégique visant à améliorer la présence en ligne et à atteindre les objectifs de l'entreprise. Si vous examinez chaque point individuellement ci-dessus, il est évident que la plupart des raisons peuvent être mises en œuvre avec des petits sprint et ne nécessitent pas forcément une grande refonte.
Il est donc important de distinguer ce qu'est une refonte et ce qu'elle n'est pas : Un nouveau design avec une base technique existante est plutôt un ravalement de façade. La refonte n'est justifiée que si l'objectif de la refonte implique un véritable changement dans l'expérience utilisateur, le fonctionnement et la base technique.
Une refonte doit toujours être justifiée par des faits (par exemple, la technologie est dans une impasse et n'est plus mise à jour), des données chiffrées, ainsi que des données de mesure et de comparaison.
Ceci est ma première recommandation à ce stade : Évolution avant révolution ! Évitez une refonte aussi longtemps que possible et essayez de mettre en œuvre individuellement ou de manière incrémentielle tous les points qui ont été avancés jusqu'à présent pour une refonte. Améliorez une chose, mettez-la en ligne, évaluez ce qui se passe, adaptez à nouveau ou passez au point suivant. Le meilleur exemple est Amazon, qui se modifie et s'améliore très peu et qui évite depuis de nombreuses années les grands changements de refonte.
Une refonte est toujours un gros risque pour votre visibilité sur Google. Tout le monde est à l'affût des améliorations, mais peu perçoivent les risques. Bien sûr, l'interface utilisateur s'améliore, l'expérience utilisateur positive augmente, et techniquement on est de nouveau à jour. Cependant : Si votre réussite entrepreneuriale repose sur une forte visibilité organique, une refonte est le dernier recours et ne doit être envisagée que lorsque votre douleur est suffisamment grande à cause d'une combinaison des raisons évoquées ci-dessus, qui ne peuvent plus être résolues lors de petits sprints individuels. Pourquoi? Regardez ce qui s'est passé avec la visibilité en ligne après les refontes de ces quatre sites :
Planifiez soigneusement votre refonte et assurez le succès de sa réalisation en utilisant une checklist. Définissez notamment les deux objectifs suivants: maintenir votre visibilité en ligne et trouver des moyens de créer les bases d'une augmentation de la visibilité en ligne dans le cadre de la refonte. Cet article est justement là pour vous donner un guide de refonte, afin de limiter les risques lors de la refonte et d'obtenir un excellent résultat de travail avec le potentiel de succès SEO organique durable.
Feuille de route d'une refonte
La planification d'une refonte de site web doit être soigneusement réalisée. Il est important de prendre en compte les étapes suivantes:
- Analyse du site web existant et établissement de l'état actuel : Il est d'abord nécessaire d'analyser le site web existant pour identifier les forces et les faiblesses.
- Définition des objectifs : Les objectifs de la refonte du site web doivent être clairement définis. Cela comprend par exemple l'amélioration du taux de conversion, l'augmentation du nombre de visiteurs ou le passage à un nouveau CMS avec une meilleure gestion du contenu et une meilleure maintenabilité.
- Elaboration d'un concept: Sur la base de l'analyse et des objectifs ainsi que d'une analyse concurrentielle, un concept de refonte de site web doit être élaboré. Le concept doit inclure les aspects suivants : design, contenu, technologie et SEO/Marketing.
- Mise en œuvre: Le concept est ensuite mis en œuvre. Cela comprend le développement du design, la création/l'adaptation du contenu et la mise en place des changements techniques.
- Tests: Le nouveau site web doit être soigneusement testé avant sa publication pour s'assurer qu'il fonctionne sans erreur. Cela inclut également une liste de contrôle définie.
- Publication: Le nouveau site web est ensuite publié. Il est ensuite testé, évalué et ajusté en direct.
Définition des objectifs et de la stratégie de la refonte
Déterminez précisément les objectifs de la refonte. Les objectifs peuvent être (outre les raisons mentionnées ci-dessus) :
- Amélioration de l'expérience utilisateur
- Augmentation de la clarté
- Expansion de l'offre de contenu
- Modernisation du design
- Augmentation du chiffre d'affaires et du panier moyen
- Changement vers un autre CMS facilitant la gestion du contenu et la maintenance technique
- Extension future plus facile et préservation de la capacité de mise à jour.
Conseil : Après les premières réunions de lancement en équipe en tant qu'entreprise - avant même d'engager des agences de mise en œuvre - chaque participant au projet devrait écrire les objectifs de votre refonte sur un papier ou les saisir dans son outil de communication (par ex. Slack). Lorsque tous indiqueront en même temps leurs objectifs, vous serez surpris de constater à quel point les opinions divergent, bien que l'objectif ait déjà été discuté verbalement lors des réunions. Il est donc essentiel de fixer les objectifs par écrit. Si vous connaissez vos objectifs précisément, vous pourrez déjà vérifier lors d'une phase précoce du prototype d'interface utilisateur s'ils ont été pris en compte conceptuellement.
Un cahier des charges apporte de la clarté sur la mission de la refonte
L'agence a besoin d'un briefing de projet détaillé de la part du client pour établir une offre. Les entreprises ont généralement un document Word ou un PDF prêt, dans lequel le projet est esquissé de manière plus ou moins détaillée. Il peut y avoir des questionnaires ou des ateliers visant à mieux mettre en évidence les points de douleur du client pour pouvoir faire une offre. Pour les projets plus importants, un cahier des charges est élaboré. Plus il est détaillé, mieux c'est.
Un cahier des charges est un document essentiel lors d'une refonte de site web. Il sert à consigner par écrit les exigences, objectifs et attentes de la refonte. Un cahier des charges bien élaboré aide à s'assurer que toutes les parties prenantes - que ce soit l'équipe de développement, l'équipe de design ou le client - ont une compréhension claire de ce qui doit être réalisé lors de la refonte. Il est également la base d'une offre bien calculée et contraignante de l'agence de mise en œuvre. Voici les informations et éléments qui sont généralement inclus dans un cahier des charges pour une refonte de site web :
- Objectifs et objectif : Une description des principaux objectifs de la refonte, par exemple l'amélioration de l'expérience utilisateur, l'augmentation de la visibilité dans les moteurs de recherche ou le changement du CMS avec une mise à jour du design.
- Portée du projet : Une définition claire de ce qui est inclus et ce qui ne l'est pas dans le cadre de la refonte. Cela peut inclure le nombre de pages, l'intégration d'outils tiers ou la révision de contenus.
- Exigences de design : Informations sur la conception visuelle souhaitée du site web, y compris les mises en page et le respect des directives de design d'entreprise concernant les couleurs, les polices et les images.
- Exigences de fonctionnalité : Une ventilation des fonctionnalités et des interactions souhaitées sur le site web, telles que les formulaires de contact, les fonctions de recherche, les fonctions d'e-commerce, etc.
- Exigences techniques : Spécifications des technologies à utiliser pendant la refonte, telles que le choix d'un système de gestion de contenu (CMS) ou la mise en œuvre de certaines fonctionnalités. L'utilisation de formats d'images et de graphiques modernes (WebP, AVIF, SVG) en fait également partie.
- Sauvegardes manuelles et automatiques et révisions des modifications de contenu.
- Exigences en matière de contenu : Instructions précises sur la révision, la mise à jour ou la création de contenus, y compris textes, images, vidéos et autres médias. Gestion des métadonnées et des données structurées.
- Exigences en matière de SEO : en savoir plus dans la prochaine section du contenu.
- Calendrier et jalons : Un calendrier détaillé des dates prévues de démarrage et de fin de la refonte ainsi que des jalons clés à respecter.
- Budget : Informations sur le budget alloué à la refonte, y compris les coûts de design, de développement, d'hébergement et de services tiers éventuels.
- Assurance qualité avec outils de test : Description des tests et des procédures de contrôle qualité à effectuer pendant la refonte pour garantir le bon fonctionnement du site web.
- Exigences de maintenance et de support : Exigences en matière de maintenance continue et de support du site web après la refonte.
Un cahier des charges bien structuré est essentiel pour éviter les malentendus, gérer efficacement le projet et s'assurer que les attentes de toutes les parties prenantes sont satisfaites. Il sert de guide et de document de référence pour toute l'équipe de projet et contribue à garantir le succès du redémarrage du site Web.
Lorsque nous avons planifié le redémarrage de TutKit.com avec un changement complet de framework de CodIgniter à Laravel, notre cahier des charges comptait 220 pages - une perspective pas vraiment séduisante pour une agence à traverser.
Remarque : Les aspects de la conception, du design, des fonctionnalités et des technologies utilisées ne seront pas abordés en détail dans mon article. Le nouveau site Web sera sûrement esthétique. Le plus grand danger lors d'un redémarrage réside en réalité dans une détérioration de l'expérience utilisateur technique et de la qualité OnPage due à l'absence de redirections 301, etc., ce qui pourrait entraîner une perte de classement et de visibilité. Pour éviter cela, l'accent sera principalement mis sur la sécurisation du succès du projet du point de vue de l'expérience utilisateur et du référencement.
Définition des exigences SEO pour le nouveau site Web
Le brief côté client ou un cahier des charges plus détaillé règle déjà ce qui est souhaité du point de vue du design, du contenu, des fonctionnalités et de la technologie, et sert de base pour qu'une agence puisse établir un devis. Pour la liste de contrôle de redémarrage pour sécuriser le succès du projet, il faut examiner chaque point de vue SEO. Des exigences SEO spécifiques découlent par exemple de :
- une structure d'URL changeante (plan de redirection d'URL !) et des chemins de liens changeants
- une navigation changeante (importante en raison du maillage interne et de la hiérarchie des liens)
- des technologies changeantes (CMS, framework JavaScript, serveur, …)
- des contenus changeants (risque de perte de visibilité des pages bien classées)
Les pages sont bien classées sur Google en raison de leur pertinence en termes de contenu, c'est pourquoi il est important de se demander si les contenus existants vont changer ou être regroupés, si des contenus vont disparaître et/ou de nouveaux contenus vont être ajoutés ? La structure de contenu des catégories ou des pages va-t-elle changer ? À partir de ces points, des exigences SEO doivent être déduites et incluses dans la liste de contrôle du redémarrage.
Les métadonnées des anciens contenus seront-elles également transférées et modifiées ? Comment se fera la gestion des contenus par l'éditeur et les contenus des pages seront-ils associés à des données structurées ?
Les images existantes ou nouvelles seront-elles stockées avec des formats d'image modernes pour les sites Web (WebP/Avif) et une attention sera-t-elle portée à l'optimisation SEO des images avec des URL parlantes en minuscules, donc au lieu de 1234.jpg => hotel-ostsee-warnemuende_suite-nachtigall.avif.
Il convient également de s'assurer que les fichiers image sont associés à des données structurées (ImageObject) et des miniatures <meta> sont transmises à Google pour augmenter la probabilité d'intégration des images dans les extraits de recherche et leur classement dans Google Images.
Un changement de CMS dans le cadre d'un redémarrage entraîne généralement une structure d'URL modifiée et de nouveaux chemins de liens. Du point de vue SEO, c'est contre-productif et cela doit être bien réfléchi.
Il est également intéressant, dans ce contexte, de se demander comment améliorer les signaux des utilisateurs. Ainsi, il pourrait être possible d'intégrer des vidéos d'images, explicatives et d'aide sur les pages de contenu. Si un utilisateur venant de Google sur la page d'atterrissage clique sur la vidéo et la regarde, la durée de visite augmente (bon signal utilisateur), le taux de retour aux résultats de recherche s'améliore également (bon signal utilisateur).
Il convient également d'examiner comment intégrer des sections de contenu dans les pages qui répondent aux exigences de Google pour un contenu utile' et pour le principe E-A-T (Expertise, Authoritativeness, Trustworthiness).
Pour Google, le "Contenu utile" est du contenu pertinent et utile pour les utilisateurs. Il répond de manière complète et informative aux questions des utilisateurs, propose des solutions aux problèmes et offre une valeur ajoutée qui dépasse les simples messages publicitaires.
Voici quelques exemples de contenu utile:
- Tutoriels et guides : ces contenus aident les utilisateurs à apprendre de nouvelles tâches ou à résoudre des problèmes existants.
- Revues et comparaisons : ces contenus aident les utilisateurs à choisir le bon produit ou service.
- Actualités et mises à jour : ces contenus tiennent les utilisateurs informés des événements et tendances actuelles.
- Infographies et diagrammes : ces contenus peuvent aider à visualiser des données et informations complexes.
- Articles de blog : ces contenus offrent un aperçu approfondi d'un sujet spécifique.
Google utilise différents signaux pour reconnaître le contenu utile. Cela inclut notamment :
- Comportement des utilisateurs : Google observe comment les utilisateurs interagissent avec le contenu, par exemple combien de temps ils restent sur une page, combien de fois ils la partagent et la notent.
- Signaux de qualité : Google évalue la qualité du contenu en fonction de facteurs tels que la pertinence, la complétude et l'actualité.
- Feedback des utilisateurs : Google tient également compte des retours des utilisateurs, tels que les évaluations et les commentaires.
- En prenant en compte ces signaux, les exploitants de sites Web peuvent augmenter leurs chances que leurs contenus soient jugés utiles.
Le principe EEAT est un concept développé par Google qui évalue la qualité des sites web et des contenus en ligne. Il signifie Expertise, Experience, Autorité et Fiabilité, c'est-à-dire Expertise, Expérience, Autorité et Fiabilité.
- L'expertise se réfère aux connaissances et à l'expérience des personnes créant le contenu. Google évalue l'expertise en fonction de facteurs tels que la formation, l'expérience professionnelle et les récompenses.
- L'expérience est attestée lorsque le contenu est produit avec une certaine expérience, par exemple basée sur l'utilisation réelle d'un produit, la visite réelle d'un lieu ou la description de ce qu'une personne a vécu.
- L'autorité se rapporte à la réputation d'un site web ou d'un contenu en ligne. Google évalue l'autorité en fonction de facteurs tels que les backlinks, les activités sur les médias sociaux et les évaluations des utilisateurs.
- La fiabilité concerne la fiabilité et la crédibilité d'un site web ou d'un contenu en ligne. Google évalue la fiabilité en fonction de facteurs tels que la confidentialité, la sécurité et la transparence.
Quelles sont les exigences SEO des fonctionnalités existantes et nouvelles en termes de frontend et de backend? Il s'agit par exemple de :
- Crawlabilité (les contenus pertinents doivent être visibles et crawlables même sans JavaScript)
- Clarté de l'objectif du site web et clarté sur l'appel à l'action (le comportement souhaité du client cible sur les pages)
- Éviter le contenu en double par exemple à travers les pages de catégorie générées automatiquement ou les doublons de pages à travers des variantes d'articles
- Assurer une vitesse de chargement élevée en évitant trop de fichiers JavaScript et CSS, en utilisant des formats d'image modernes (WebP/AVIF)
Ces exigences SEO doivent figurer dans le cahier des charges du projet, mais également être contrôlées à l'aide d'une liste de contrôle liée à l'outil de test ou comparées dans le cadre de l'assurance qualité du projet et en tant que critère pour la validation des services de l'agence. Plus d'informations ci-dessous.
Définition des intervenants internes et externes du projet
Identifiez les intervenants du projet - ici du point de vue du client ou du propriétaire du site web :
- Qui est responsable de la gestion de projet et prend les décisions finales?
- Qui est responsable de la coordination et de la communication avec l'agence ou le client?
- Qui est en charge de la gestion de projet interne?
- Qui prépare les contenus en interne et les travaux préparatoires pour l'agence?
- Qui met en œuvre le design de l'expérience utilisateur?
- Qui met en œuvre le développement?
- Qui informe régulièrement le client du côté de l'agence à des intervalles prédéfinis?
- Qui prend en charge les tests et l'assurance qualité du côté de l'agence/du client?
- Est-ce qu'un consultant externe est impliqué (par exemple pour le SEO ou les exigences légales)?
- Qui approuve les tâches? Qui valide les tâches dans le système de tickets après leur traitement?
- Qui doit être informé à quel moment (employés, clients, partenaires, gestionnaires de campagnes publicitaires, ...)?
Quatre points importants dans le choix des prestataires externes de projet
- L'agence a-t-elle réalisé un ou plusieurs projets de ce type? Y a-t-il des références? Existe-t-il des témoignages de clients et la possibilité d'un entretien avec les clients de l'agence - ce qui est recommandé pour de grands développements individuels?
- Est-ce que la gamme de services proposée ainsi que la mise en œuvre technique (CMS/système de boutique/framework) répondent déjà de manière native à toutes les exigences liées à la refonte? Y a-t-il des fonctionnalités ou exigences spécifiques qui doivent encore être programmées (éventuellement via un plugin ou module)? Certains services essentiels sont-ils exclus de l'offre ou prévus pour une étape ultérieure, mais sont cruciaux pour le succès du projet? Il est important de ne pas introduire de nouveaux problèmes plus importants que la raison initiale de la refonte.
- Est-ce que l'agence ou le prestataire externe correspond aussi bien en termes de taille d'équipe que de localisation géographique et de fluctuation des employés (pouvant être déterminée grâce à des évaluations Kununu) pour assurer une gestion continue pour l'entreprise?
- Un contact direct avec l'équipe chargée du design et du développement est-il possible? Il est conseillé de rencontrer l'équipe de projet réelle du côté de l'agence. Les professionnels de la vente bien intentionnés et promettant monts et merveilles décrochent le contrat et ne sont plus impliqués plus tard. C'est pourquoi un contact direct avec l'équipe opérationnelle doit être convenu.
Quatre conseils pour votre propre sécurité dans ce contexte
- En tant que client, je ferais attention à la technologie utilisée par l'agence. Ce qui est proposé, je le rechercherais sur Google avec "CMS + inconvénients" ou "CMS + expériences". Vous devriez savoir exactement à quoi vous vous engagez. Il est judicieux de se fier à des solutions open source. Je suis conscient que ce n'est pas toujours possible. Assurez-vous plutôt qu'il y a une communauté de développeurs importante pour la technologie utilisée, afin de ne pas vous retrouver avec une solution exclusive à l'agence, que seule cette dernière peut gérer, ce qui pourrait vous imposer des contraintes futures importantes.
- Assurez-vous également d'obtenir les droits d'utilisation et de modification illimités pour les services de l'agence, afin d'avoir toujours le droit de continuer à développer le site web en interne ou externe. Une telle clause doit figurer dans le contrat de travail.
- Si votre entreprise est plus axée sur la technologie et que vous avez des administrateurs système, des développeurs de logiciels ou des personnes similaires dans l'équipe, il est judicieux de mettre en place GIT pour la gestion de version et JIRA (ou un outil similaire) pour la gestion de projet ou le système de tickets, d'abord vous-même dans un compte distinct. Ensuite, accordez à l'agence des droits d'accès complets et les travaux peuvent commencer. Plus un projet est grand, plus il peut devenir rude et pénible. Il est donc bon d'être maître des accès et des comptes décisifs. Je suis conscient que cette recommandation ne peut être suivie que par quelques clients sur le plan technique.
- Il arrive parfois que les agences proposent directement l'hébergement pour les clients. Nous ne sommes pas fans de cette approche, car d'une part, elle accroît la dépendance dans la relation client, d'autre part, nous considérons que les hébergeurs web sont les mieux placés pour l'hébergement, car c'est leur spécialité. Nous avons déjà configuré et géré nos propres serveurs et avons dépensé beaucoup de ressources humaines et temporaires. Nous avons fait machine arrière. Maintenant, nos systèmes tournent sur des serveurs Cloud d'un des grands hébergeurs web en Allemagne et nous sommes heureux. Lors de l'hébergement web, assurez-vous en tout cas que des backups côté serveur sont inclus dans le package, qui peuvent être rapidement restaurés en quelques clics.
Détermination de la période et de la date de lancement
Un relancement se fait en plusieurs étapes de projet. Selon notre expérience d'agence, celles-ci peuvent être :
- L'état actuel est enregistré (via des outils de test, mais aussi par écrit avec des impressions sur ce qui fonctionne bien du côté du client et où des améliorations sont nécessaires)
- Phase de recherche avec analyse de la concurrence et recherche de solutions/inspiration
- Conception de l'architecture de fil de fer
- Conception du design de l'interface utilisateur
- Développement frontend et backend
- Migration des données ou import de contenu (automatisé/manuel)
- Optimisations du contenu structurel et textuel & Sprint SEO
Les différentes étapes de projet se chevauchent, car de nouveaux intervenants dans le projet deviennent actifs au fil du traitement.
Il est important de définir le calendrier pour les différentes étapes du projet et de le coordonner avec les parties prenantes.
L'agence crée-t-elle pour le client un canal Slack dédié pour une communication plus rapide dans le cadre du projet, s'il est de grande envergure ?
Un conseil à ce stade : Il est bon que l'agence travaille déjà dans une phase très précoce avec des prototypes cliquables, donc déjà lors de la conception de l'architecture de fil de fer et surtout lors de la présentation et de la vérification du design de l'interface utilisateur. Ainsi, les clients ont une meilleure perception de l'expérience du site Web. Les simples fichiers JPG ou PNG comme proposition de layout ne sont plus d'actualité. Ce devraient être des prototypes cliquables, élaborés avec Sketch, Figma, Adobe XD ou un autre outil professionnel.
A ce stade précoce, les modifications sont facilement réalisables. Une fois que les fonctionnalités et sections d'un site Web sont déjà développées, les modifications sont beaucoup plus laborieuses et peuvent éventuellement entraîner des renégociations, ce qui n'est pas du tout attrayant.
Voici à quoi ressemble un tel prototype pour la conception de l'interface utilisateur mobile avec les parcours de clics en vue d'ensemble :
Il est nécessaire de clarifier à partir de quand les tests en cours côté client sont possibles. Les développeurs doivent tester leur travail localement même après la fusion dans le système de scène. Cela peut sembler banal, mais tout collaborateur avec des développeurs comprend immédiatement ce que je veux dire. Ensuite, la personne responsable du contrôle qualité côté agence devrait tester le ticket ou la fonction. Ce n'est qu'à ce moment-là que le ticket est libéré pour le test client. Le client ne devrait jamais se sentir comme un testeur alpha, mais devrait trouver un système déjà testé à quatre yeux. L'agence est le testeur alpha, le client est le testeur bêta ! Existe-t-il même un accès au système de tickets de l'agence ?
Il convient également de définir par écrit que les rapports côté agence au client doivent être transmis à une fréquence spécifique. Par exemple, un rapport par e-mail sur l'avancement des travaux, les boucles de rétroaction nécessaires ou les demandes de travail chaque vendredi. C'est également un conseil tiré de notre expérience en agence : Il est bon de ne pas laisser le client dans l'incertitude avant le week-end. Il pourrait avoir de mauvaises idées. Il vaut mieux bien informer sur ce qui s'est passé et ce qui est prévu la semaine suivante. La transparence aide à maintenir l'intérêt de chacun dans le projet.
La date de lancement doit également être fixée. Selon la loi de Parkinson, le travail s'étend pour occuper tout le temps disponible pour son achèvement. En d'autres termes, plus de temps est disponible pour accomplir une tâche, plus de temps sera pris pour cela, quelle que soit la complexité réelle ou la charge de travail. La date de fin prévue doit également figurer dans le contrat. Manquer la date butoir pourrait même être assorti d'une pénalité contractuelle. En règle générale, les pénalités contractuelles de 0,2 % du montant de la commande par jour de retard et au maximum de 5 % du montant de la commande sont effectives. La pénalité contractuelle n'a pas nécessairement à être réclamée du côté du client, mais vous donne la possibilité d'obtenir quelques demandes spéciales supplémentaires de l'agence en compensation.
Important : Pas de lancement le vendredi. Pas non plus entre les jours fériés ou pendant les heures de pointe de l'entreprise. Nous recommandons effectivement, pour les grands relancements, les heures nocturnes du dimanche au lundi, surtout lorsque l'adresse IP change, de sorte que les paramètres DNS sont généralement de nouveau actualisés le lundi, ce qui est souvent déjà fait en fin de matinée si l'entrée DNS a été ajustée la nuit précédente. Cela laisse en fait encore 4,5 jours ouvrables pour les tests en direct et les corrections de bogues en cas d'erreurs survenant.
Protocole de l'état actuel de votre site Web
L'état actuel doit être enregistré avant le début des travaux. L'état actuel enregistre les résultats des mesures techniques pour les paramètres. Vous pouvez entrer les valeurs cibles à côté :
Quoi ? | Description brève | Outil de test | Actuel (Valeur actuelle) | Cible (Valeur cible) |
Technique & Meta | Titre de la page, en-têtes, métadonnées, texte alternatif, ... | Seobility | ||
Structure | Redirections, liens défectueux, sitemaps, ... | Seobility | ||
Contenu | Vérification des mots-clés, fautes de frappe, manque de texte, ... | Seobility | ||
Images SEO | URLs parlantes, formats Web modernes (WebP/AVIF), vignettes <meta> | Sans | ||
Implémentation de données OG | Données Open Graph pour les médias sociaux | Open Graph Checker | ||
Données structurées (Schéma de balisage) | Marquage de schéma / données structurées | Schema.org | ||
PageSpeed Page d'accueil | PageSpeed pour mobile/desktop | PageSpeed Insights | ||
PageSpeed Page d'atterrissage | PageSpeed pour mobile/desktop | PageSpeed Insights | ||
PageSpeed Page de catégorie | PageSpeed pour mobile/desktop | PageSpeed Insights | ||
PageSpeed Page de produit | PageSpeed pour mobile/desktop | PageSpeed Insights | ||
PageSpeed Page de blog | PageSpeed pour mobile/desktop | PageSpeed Insights | ||
Accessibilité par type de page | Assurer l'accessibilité aux groupes d'utilisateurs handicapés | Accessibility Checker et/ou wave.webaim.org | ||
Vérifier Hreflang | Pour les sites Web multilingues | Hreflang Validator | ||
En-têtes de sécurité | Confiance & sécurité | SecurityHeaders.com | ||
Vérification de la santé | Confiance & sécurité | Security Audit (Astra) | ||
Test de navigateur & d'appareil | Edge, Firefox, Safari, Chrome bureau & mobile, iOs & Android | Outils pour développeurs / Lambdatest | ||
Politique de cookies & RGPD | Politique de consentement-cookie & Conformité RGPD | Cookie Metrix | ||
Crawling : Statut de l'hôte | Extraction robots.txt, Résolution DNS, Connexion au serveur | Google Search Console | ||
Statistiques de crawling | Requêtes, Taille de téléchargement, Temps de réponse moyen | Google Search Console | ||
Clics dans les SERP | Mesuré sur une période déterminée (mensuelle/90 jours, ...) | Google Search Console | ||
Impressions dans les SERP | Mesuré sur une période déterminée (mensuelle/90 jours, ...) | Google Search Console | ||
Taux de clic moyen dans les SERP | Mesuré sur une période déterminée (mensuelle/90 jours, ...) | Google Search Console | ||
Position moyenne dans les SERP | Mesuré sur une période déterminée (mensuelle/90 jours, ...) | Google Search Console | ||
Conformité aux Core Web Vitals | Facteur de classement pour l'expérience utilisateur (PageSpeed, optimisation mobile, ...) | Google Search Console | ||
Analyser les données GA4 | Durée de séjour, Pages/Visiteur, ... | Google Analytics 4 | ||
Taux de conversion | Pour les sites de réservation ou les boutiques en ligne | Métriques personnalisées | ||
Panier moyen | Pour les boutiques en ligne | Métriques personnalisées | ||
Achats/Revenus par jour | Pour les boutiques en ligne | Métriques personnalisées | ||
Inscriptions à la newsletter | En fonction des besoins | Service de newsletter | ||
Demandes de contact | En fonction des besoins | Métriques personnalisées | ||
Téléchargements | En fonction des besoins | Métriques personnalisées | ||
Vues de vidéos | En fonction des besoins | Métriques personnalisées | ||
Ajouter d'autres éléments selon les besoins | ||||
Ajouter d'autres éléments selon les besoins |
Dans la liste, vous trouverez comme outil SEO le Seobility que nous utilisons avec plaisir pour vérifier les facteurs OnPage, pour lesquels j'ai également publié une formation SEO. Il existe de nombreux équivalents tels que Sistrix, Semrush, Ryte, SE Ranking, Screamingfrog, etc. L'objectif de l'outil SEO est principalement d'identifier et de corriger les erreurs typiques OnPage. Ici, les trois domaines clés sont la technologie et la méta, la structure et le contenu, tels que Seobility établit les évaluations. Vous les retrouverez de manière similaire dans les autres outils SEO. Il est important, d'une part, que l'ensemble du site soit vérifié, c'est-à-dire que TOUS les pages soient explorées et pas seulement la page d'accueil, et, d'autre part, que vous attribuiez une note ou une valeur d'erreur pour l'état actuel à atteindre et à viser après l'optimisation. Avec Seobility, une valeur de 90 ou plus est souhaitable. Vous trouverez également des outils alternatifs pour d'autres finalités. Il est crucial d'utiliser au moins un outil pour garantir des données exceptionnelles.
Voici par exemple notre valeur actuelle pour la qualité OnPage :
Les signaux d'utilisateur peuvent être mesurés statistiquement à l'aide de mesures de Google Analytics 4 telles que le taux de rebond, les pages/visiteur, le temps passé, etc. Si Google Analytics ou un autre outil d'analyse est utilisé de manière conforme aux réglementations, ces données doivent également être prises en compte lors de la documentation de l'état actuel.
Une liste de backlinks doit également être créée, qui peut être générée gratuitement ici, par exemple : https://www.seobility.net/de/backlinkcheck/
De plus, la ancienne sitemap.xml doit être sauvegardée, tout comme une sauvegarde complète du site. Toutes les pages pertinentes doivent également être transférées sous forme de liste dans une feuille Google Sheets, qui servira de base pour la URL-Redirect-Map. Il est facile d'exporter une telle liste CSV via un outil SEO comme Seobility. La URL-Redirect-Map inclut toutes les pages pertinentes et liées via des backlinks externes (voir liste de backlinks) qui devront être redirigées ultérieurement en raison de changements dans les URL des pages. Les URLs supprimées doivent être redirigées vers les nouvelles URLs correspondantes aux anciennes. Il est important de éviter les chaînes de redirection! Les anciennes redirections encore existantes doivent rediriger directement vers la nouvelle URL finale. Il convient également de penser aux fichiers PDF et images auxquels des liens sont liés, afin de les rediriger correctement et d'éviter les liens 404.
Les redirections sont mises en place en tant que redirections 301 basées sur la URL-Redirect-Map dans le fichier .htaccess, via des Redirect-Maps via une configuration Vhost ou une solution de base de données. Le client devrait pouvoir les entretenir lui-même. Il est également important de garantir que les redirections sont permanentes.
Il est également recommandé de sauvegarder chaque type de page avec une capture d'écran de la page complète. Cela garantit une sauvegarde du contenu existant en cas de questions après la mise en ligne, concernant par exemple les types de contenu qui n'ont pas été transférés, etc.
En se basant sur les pages existantes, les fonctionnalités et les contenus, et en se basant sur les résultats des mesures, ce qui fonctionne déjà bien peut être identifié, ainsi que les domaines où des améliorations pourraient être apportées, et ce qui doit être amélioré lors du relancement.
Liste de contrôle : Avant le relancement
Une fois que la conception de l'interface utilisateur est confirmée et que l'agence est en phase de développement, la liste de contrôle suivante devient pertinente, listant chronologiquement jusqu'au jour du relancement les points essentiels :
- L'environnement de développement avec un accès pour tous les intervenants est disponible pour les tests
- L'environnement de développement est défini sur noindex
- L'accessibilité pour les outils de test sur l'environnement de développement (autorisation d'IP ou connexion http) est configurée
- La configuration de l'environnement de développement correspond autant que possible à celle du système en production
- La structure des pages de l'environnement de développement correspond à celle du site en production final
- La migration des données anciennes a été effectuée
- Les ajustements de contenu ont été effectués
- L'optimisation des images pour le SEO a été effectuée
- Les redirections 301 basées sur la URL-Redirect-Map sont en place
- Le contrôle OnPage avec Seobility a été effectué, les erreurs ont été corrigées, les objectifs ont été atteints
- Les données Open-Graph sont valides
- Les données structurées sont valides
- Les tests de Pagespeed pour tous les types de pages ont été effectués, les objectifs ont été atteints
- La politique de cookies pour le contenu est fonctionnelle
- Les en-têtes de sécurité ont été configurés
- L'accessibilité est assurée, les objectifs ont été atteints
- Les balises hreflang sont valides (pour les sites multilingues)
- Les mentions légales (CGU, mentions légales, clause de rétractation, politique de confidentialité) ont été mises à jour, la conformité RGPD est assurée
- La mise à jour du CMS, des frameworks, des plugins et modules utilisés vers la dernière version a été effectuée
- Le test final des fonctionnalités sur tous les navigateurs et dispositifs n'a révélé aucune erreur
- Le statut final et la date de lancement sont communiqués
- Une sauvegarde complète a été effectuée
L'utilisation de données structurées (balisage Schema) - voir points 12 de la liste - est toujours trop peu prise en compte aujourd'hui. Familiarisez-vous avec le sujet et lisez ce que Google dit sur le balisage des données structurées dans la recherche Google. Google accorde de plus en plus d'importance aux données valides dans le cadre des SERP, c'est-à-dire les résultats de recherche créés par l'IA. De plus, la mise à jour du contenu utile de Google implique que les contenus soient beaucoup plus validés par l'expertise, l'expérience, l'autorité et la crédibilité. Les données structurées font partie de la solution pour simplifier cette validation pour Google. Après l'intégration des données structurées, utilisez le validateur Schema-Markup, mais vérifiez également vos pages avec le Lint Structured Data, également recommandé et lié par Google dans les PageSpeed Insights. Vous y trouverez des informations approfondies sur les erreurs de code liées à votre utilisation de données structurées.
L'utilisation de données structurées sur les sites Web n'est plus une option, mais une condition. Google exige de vous des contenus valides et crédibles. Si vous ne voulez pas être à la traîne dans les résultats de recherche basés sur l'IA, veillez à intégrer des balises Schema dans vos pages !
Au point 16, la Accessibilité apparaît pour la première fois dans cet article. Déjà lors des analyses de vitesse de page, l'accessibilité a sa propre section et des chiffres verts y sont souhaitables. Le test de l'accessibilité d'une page devrait être effectué en plus des analyses de vitesse de page, également via https://www.accessibilitychecker.org et/ou https://wave.webaim.org. Surtout lorsque se profile une refonte, ce point devrait être obligatoirement pris en compte, car l'accessibilité des sites Web sera un problème actuel à partir de 2025 avec la loi renforçant l'accessibilité. Vérifiez avec un tel outil non seulement la page d'accueil, mais chaque type de page - de même pour les analyses de vitesse de page !
Dans le cadre d'une refonte, des ajustements et mises à jour des mentions légales sont souvent nécessaires. Il est important de penser tôt à cela, que les textes soient éventuellement fournis par un avocat spécialisé ou via des générateurs de mentions légales. Il est également nécessaire de penser aux contrats de traitement des données si, par exemple, un nouvel hébergeur Web est utilisé ou si le service de newsletter change.
Le point 18 avec la mise à jour du CMS, des bibliothèques JavaScript utilisées, des modules et plugins installés est tout aussi sous-estimé qu'important. Une refonte peut s'étendre sur plusieurs mois voire plus. Avec le système WordPress, il est facile de voir s'il y a déjà de nombreuses mises à jour disponibles avant la date de lancement de la refonte. Les clients doivent s'assurer que les dernières versions sont utilisées lors du lancement.
Avec les services externes changeants, d'autres tâches s'ajoutent, qui devraient alors être mentionnées dans la liste de contrôle, comme c'est le cas lors du changement du service de newsletter:
- Importation des données de contact du newsletter vers le nouveau service de NL
- Intégration du service de newsletter sur le site Web lors du formulaire d'inscription
- Contrat de traitement des données (AV)
- Création de nouveaux modèles d'envoi
- et ainsi de suite
Tout au long de la phase de développement, des tests continus des fonctionnalités, etc. sont bien entendu effectués. Il est judicieux d'établir une liste de contrôle extrêmement détaillée pour ces tests, afin de ne rien oublier. Il ne suffit pas, tant pour l'agence de mise en œuvre que pour le client, de cliquer à droite et à gauche. Après la refonte de TutKit.com, notre liste de vérification d'acceptation comptait certainement 1 000 lignes. Et c'est ainsi que nous procédons toujours : après des mises à jour majeures importantes, nous vérifions environ 70 interactions via une liste de contrôle pour Chrome, Safari et Android.
Liste de contrôle : le jour de la refonte et les jours suivants
Le jour de la refonte est arrivé et ce n'est ni un vendredi ni un jour entre les jours fériés. Le nouveau site Web est en ligne, les paramètres DNS sont ajustés. Il est maintenant temps de tout re-vérifier et d'évaluer à nouveau. Vérifiez les éléments suivants :
- Vérifier le fichier robots.txt pour vérifier que les robots ne sont pas bloqués
- L'environnement live est en index, follow.
- Les balises canoniques sont correctement définies
- Vérifier le code source des pages à la recherche des chemins absolus (chemins liés de l'environnement de test sur la page en direct)
- La redirection de http vers https avec/ sans www vers la page cible, sur la page d'accueil et les sous-pages, fonctionne
- Tester les redirections via la carte de redirection d'URL, ainsi que pour vérifier leur existence dans les chaînes de redirection
- Vérification OnPage de la page en direct avec Seobility pour la technologie & les métadonnées, la structure et le contenu ... en particulier vérifier les pages noindex fournies par Seobility
- Les données Open Graph sont valides
- Les données structurées sont valides
- Vérification de la vitesse de la page pour tous les types de pages est effectuée, les objectifs sont atteints
- La politique en matière de cookies avec l'outil Consent Cookie fonctionne comme il se doit
- Les en-têtes de sécurité sont configurés
- L'accessibilité est assurée
- Vérification des balises hreflang sur les sites Web multilingues (https://app.sistrix.com/de/hreflang-validator)
- Test final de la fonctionnalité sur différents navigateurs et appareils n'a révélé aucune erreur
- Soumettre la nouvelle sitemap.xml à la Google Search Console
- Mettre à jour les nouvelles pages cibles dans les campagnes Google Ads
- Penser aux liens sur les réseaux sociaux, les signatures d'e-mails, etc. en cas de changements de domaine spécifiques
Nous utilisons dans notre environnement de développement Mailhog pour tester les e-mails localement. Dans de tels cas, il est important de veiller à ce que les bonnes données SMTP pour la réception de e-mails dans le système live soient configurées, de sorte que les e-mails atteignent leur destination correcte.
Il est également important de s'assurer que les fournisseurs de paiement tels que Paypal ont le mode Sandbox implémenté dans le système de développement, tandis que dans le système live, la connexion correcte doit être établie.
Les jours suivants, il est important de surveiller particulièrement la Google Search Console. Ce qui est particulièrement intéressant, c'est l'évolution de vos classements. Concentrez-vous particulièrement sur les changements inattendus et les messages d'erreur :
- Crawling: État de l'hôte ... Récupération du robots.txt, Résolution DNS, Connexion au serveur
- Statistiques de crawl ... Demandes, Taille du téléchargement, Temps de réponse moyen
- Clics dans les SERP
- Impressions dans les SERP
- CTR moyen dans les SERP
- Position SERP moyenne
- Réussite des Core Web Vitals
En particulier, la Google Search Console vous signale les erreurs telles que par exemple les erreurs d'URL, les erreurs Href-Lang, l'indexation des pages avec indexation/désindexation étalée. S'il y a des pages non indexées, il doit y avoir une raison (redirection, noindex)…). Vous y verrez également du contenu en double ou d'autres problèmes. Si la Search Console signale des problèmes avec les données structurées ou les Core Web Vitals, cherchez-en la cause. Ce n'est qu'avec les données en direct que vous découvrirez par exemple que malgré un bon PageSpeed, certaines de vos pages ont des problèmes avec les Core Web Vitals en raison d'erreurs CLS. Cela montre bien quel type de changements sont possibles sur le site web :
Vous pouvez directement afficher les URL mauvaises ou à optimiser. Prenez une URL et effectuez un test de PageSpeed avec PageSpeed Insights. Vous y trouverez les raisons pour lesquelles les Core Web Vitals ne sont pas atteints et ce que vous pouvez faire pour corriger les erreurs. Développez la flèche vers le bas pour obtenir des informations plus détaillées. En général, seuls les développeurs peuvent mettre en œuvre ces recommandations. Cependant, il est important que vous soyez capable d'identifier les problèmes pour pouvoir les aborder avec votre agence.
De même, analysez vos données avec vos outils d'analyse, comme par exemple Google Analytics 4. Gardez un œil sur les indicateurs que vous pouvez collecter au niveau du système, comme les réservations, le taux de conversion, le montant du panier, les achats/chiffre d'affaires par jour, les inscriptions à la newsletter, les demandes de contact, les téléchargements de contenus spécifiques ou les vues de vidéos.
Les statistiques de crawl dans la Google Search Console sont essentielles pour les vérifications des jours suivants. Vous les trouverez via les paramètres dans le menu de gauche. Une activité de crawl plus importante devrait directement apparaître. Sinon, y a-t-il des erreurs de crawl ?
L'état de l'hôte vous montre directement les erreurs, comme on peut le voir ici après un relancement, lorsque les requêtes de crawl ont échoué sur le robots.txt et que la connexion au serveur a également été interrompue à plusieurs reprises :
Les statistiques de crawl sont également intéressantes. Après un relancement, il y a généralement une augmentation de l'activité de crawl. Vous pouvez également voir si des pages 404 sont toujours crawlées. Si certaines semblent hors sujet, discutez-en avec les développeurs.
Vous saurez si votre serveur, votre PageSpeed et votre code sont relativement bons si le temps de réponse de vos pages est inférieur à 400. Plus il se rapproche de 1000 ms, plus il est recommandé d'optimiser le PageSpeed, par exemple en réduisant les requêtes à la base de données et en renforçant la puissance du serveur (par exemple, en augmentant la puissance de calcul, en mettant à jour vers le logiciel serveur le plus récent, en passant à HTTP2 ou HTTP3 (avec Nginx)).
À terme, le budget de crawl pour les sites web individuels sera probablement de plus en plus limité en raison de la présence croissante de contenu (IA) sur les sites web, c'est pourquoi un bon temps de réponse des pages devrait être visé pour que les robots puissent crawler autant que possible vos pages dans le temps imparti.
Checklist de relancement à télécharger
Les checklists pour le relancement intégrées ci-dessus sont également disponibles sous forme de fichier PDF à télécharger. Téléchargez-les et assurez le succès de votre projet !
Aveux d'un propriétaire d'agence
Les exigences en matière de SEO dans la checklist pourraient également recevoir des instructions détaillées telles que l'attention portée à la structure des titres de H1 à H6, et ainsi de suite. La définition d'objectifs dans les outils de test raccourcit heureusement le contenu global de la checklist de relancement, car l'atteinte des meilleurs résultats des outils de test mentionnés dans la checklist ne peut être réalisée que grâce au respect d'un code propre, à l'utilisation de technologies modernes, à l'attention portée aux facteurs SEO OnPage, etc. Sinon, il faudrait formuler de manière extrêmement détaillée les dernières normes web et les exigences techniques et SEO, ce que les clients ne sont généralement pas capables de faire uniquement du point de vue technique. Si les agences doivent atteindre des valeurs élevées dans les outils de test, elles n'ont d'autre choix que de travailler selon les meilleures pratiques - une expérience nouvelle même pour les agences :-)
Il est temps de se confesser. La définition des exigences SEO ainsi que l'approche en forme de checklist avec la sécurisation et l'atteinte contraignante d'objectifs dans différents outils de test représentent un idéal rarement atteint dans la réalité. Cela dépend de :
- des limitations budgétaires du côté du client
- des intérêts d'optimisation des bénéfices du côté de l'agence
- des limitations liées aux technologies utilisées
- et malheureusement aussi : l'ignorance et l'incompétence des deux côtés
Je ne peux pas vraiment reprocher aux clients. Ils cherchent justement de l'aide professionnelle et presque toutes les agences digitales mentionnent sur leur site web et dans leurs documents techniques que l'optimisation pour les moteurs de recherche est l'une de leurs compétences clés. Il y a toujours des références qui prouvent qu'après le relooking, la visibilité en ligne a augmenté de facteurs 3, 5 ou 10. Le fait qu'après, au lieu de 10 visiteurs, 100 visiteurs par jour viennent, est certes une augmentation de 1000%, mais ce n'est pas encore un succès pour autant. De nombreux succès en matière de référencement dépendent du fait que les concurrents sont encore beaucoup plus faibles numériquement. Les agences continuent de faire du travail moyen avec des méthodes obsolètes, car jusqu'à aujourd'hui, elles n'utilisent toujours pas des outils modernes pour l'assurance qualité, même si dans les publications, références, meilleures pratiques, etc., il est dit que la compétence en référencement est présente. Peut-être que de telles agences sont des géants du savoir, mais aussi des nains en matière d'exécution. Cela semble dur, mais c'est simplement la norme. Honnêtement. Regardez de plus près! Prenez la liste de contrôle ci-dessus et saisissez la meilleure agence de la région d'où vous venez, avec son URL dans les outils mentionnés ci-dessus. Puis prenez la dernière référence de site Web que vous trouvez de l'agence et recommencez. Quels résultats allez-vous voir? Exactement ceux auxquels vous pouvez vous attendre dans une collaboration. Vous pouvez également vérifier nos propres références de cette manière et constater que nous n'atteignons pas toujours les meilleurs résultats pour tous nos projets clients. Ce processus avec une approche de l'assurance qualité basée sur les données a également évolué de projet en projet chez nous et s'est surtout établi grâce à nos travaux sur TutKit.com.
Vous pouvez faire de telles vérifications avec presque n'importe quelle agence, car peu d'entre elles travaillent vraiment de manière axée sur les données en matière d'assurance qualité, car aucune d'entre elles ne reste sur le marché avec ses propres projets pendant des années et ne se mesure dans la dure concurrence pour la visibilité en ligne aux grands acteurs internationaux, et car il est presque égal aux agences que le projet réussisse ou non, tant que la facture de l'agence est payée et que les clients peuvent célébrer de beaux (mais moyennement qualitatifs) sites Web dans leurs publications et avec des prix. L'ironie particulière est que d'après les outils de test mentionnés ci-dessus, ce sont souvent précisément les agences de référencement qui obtiennent les moins bons résultats avec leurs propres sites Web, car elles n'ont souvent qu'une seule méthode en main comme un cheval de Troie ... un pack de contenu développé sur les mots-clés du client pour le site Web. Pour les autres exigences techniques, il manque souvent tout simplement des développeurs compétents.
Un avantage est également de choisir une agence ailleurs et de ne pas croiser le client en train de faire des achats au magasin de bricolage en tant que responsable de l'agence ayant simplement à justifier une baisse de visibilité à deux chiffres après un relooking. Mais de toute façon, les clients vérifient à peine cette perte de visibilité, car bien que tout le monde ait une bannière de consentement aux cookies, peu analysent réellement les chiffres et en tirent des actions à entreprendre. En cas de doute, il suffit d'augmenter les dépenses publicitaires. Le fait que le classement organique dépende aujourd'hui d'une surabondance de sites Web techniquement bien placés sur le contenu et des signaux utilisateur et (toujours) des backlinks, les clients ne le savent heureusement pas non plus. Et avec les outils de rédaction AI, les sites Web se renforceront en contenu d'une manière inédite en quantité et qualité, et nous pourrons bientôt accueillir de nombreux nouveaux sites Web de l'étranger dans notre langue dans les SERP, car les outils de traduction AI rendent de plus en plus facile de traduire des boutiques en ligne, des portails, des SAAS et d'autres sites Web pour attaquer le marché intérieur numérique. Nous devons nous préparer à une concurrence féroce. Cela ne fait que commencer ...
Conclusion sur la liste de contrôle basée sur les données pour le relooking de site Web
Une telle liste de contrôle basée sur les données est l'une des rares façons efficaces de contraindre les agences à faire du bon travail. Il est même recommandé de rendre l'atteinte de certains indicateurs dans les outils de test comme critère d'acceptation. Il devrait être spécifié contractuellement qu'une partie du paiement ne peut être facturée qu'après quatre semaines suivant le relooking, lorsque toutes les données importantes sont disponibles et que l'atteinte des meilleures valeurs est confirmée (comme les Core Web Vitals et les extraits de produits validés selon le balisage de schéma dans la Search Console). Grâce à ce flux de travail - comme décrit dans cet article - votre perte de visibilité après une refonte avec des changements inopérants, structurels et techniques sera limitée et vous créerez la base pour que Google classe bientôt votre site Web ou votre boutique en ligne plus haut.
Si l'article vous a intéressé, consultez également d'autres contenus de notre part :