S’abonner à RankUp sur Spotify | Podcasts Apple | Podcasts Google | RSS
Gerry White de Rise At Seven nous a rejoint pour l’épisode 18 du podcast RankUp pour parler de son expérience de travail sur le référencement technique pour les sites Web d’entreprise.
La conversation a porté sur la manière de s’assurer que les équipes avec lesquelles vous travaillez accomplissent réellement les tâches, avec des conseils pour parler à la fois aux développeurs et aux parties prenantes de haut niveau.
Écoutez l’interview complète ici ou sur l’application de votre choix, ou continuez à lire pour découvrir certains des moments forts de l’interview.
Présentation de Gerry
Ben: Comment avez vous obtenu où vous êtes aujourd’hui? Quelle est votre histoire en SEO?
Gerry: Je suis dans le monde numérique depuis environ 20 ans. J’ai fait des allers-retours – je suis en fait allé aux ventes, au recrutement, à divers autres éléments. J’ai essayé de créer des pages Web, j’ai fait du développement Web, mais il s’est avéré que les gens avec qui je travaillais étaient meilleurs dans ce domaine.
J’ai trouvé que je pouvais me débrouiller avec des éléments tels que l’analyse et le référencement. Une connaissance approfondie du numérique, combinée à une bonne connaissance du fonctionnement d’Internet, s’est avérée très utile dans ma carrière.
Ben: En quoi consiste votre rôle actuel en tant que directeur du référencement chez Rise At Seven?
Gerry: Cela dépend vraiment! Je ne peux pas vous donner une réponse sur ce que je ferais au jour le jour, mais une grande partie consiste essentiellement à parler par l’intermédiaire de nos clients et à essayer de faire avancer les choses d’une manière ou d’une autre avec différents clients.
Défis courants du référencement en entreprise
Ben: Quels problèmes courants rencontrez-vous lorsque vous travaillez sur des sites d’entreprise?
Gerry: Je pense que le plus gros problème est GSD – faire «des choses». Par exemple, obtenir une approbation pour la réparation des systèmes hérités. Avec les sites Web d’entreprise, vous découvrez souvent qu’il existe un composant de base qui alimente une partie du site, qui aura entre 10 et 15 ans.
Un bon exemple est le Premier Inn. Par exemple, lorsqu’ils ont effectué une migration de site, il s’est avéré que l’un des processus alimentant le site était en fait plus ancien qu’Internet car il s’agissait du système de réservation de salle!
La recherche de la BBC, qui a été alimentée par une grande partie de la BBC elle-même, était tellement héritée et personne ne savait vraiment exactement ce qui en était alimenté. Donc, si nous le désactivons, quelle partie du site Web se cassera? Parce que le site Web était juste un peu plus ancien que quiconque y travaillait.
Un autre bon exemple est quelque chose d’aussi simple qu’un plan de site XML, lorsqu’il est construit à partir d’une demi-douzaine de composants différents et que la structure de l’URL n’est en fait mappée nulle part. L’une des étranges objections que j’ai vues est le fait qu’une équipe infosec, par exemple, ne veut pas que le site Web soit gratté par des concurrents. Ils ne veulent pas vraiment d’un plan de site XML qui expose toutes les listes de produits, qui peuvent ensuite être récupérées par l’éditeur.
Lorsque je travaille avec des entreprises clientes, je dois m’assurer de bien réfléchir à ces objections et leur dire: “Écoutez, nous pouvons nous assurer que les concurrents ne le trouvent pas, nous le transmettons simplement à Google.” Nous devons nous assurer que les choses sont suffisamment rapides, suffisamment évolutives et qu’il n’y aura pas une charge énorme sur une API si quelque chose est transmis à la page d’accueil.
Communiquer avec les principaux intervenants
Ben: Avez-vous des conseils, des conseils ou quoi que ce soit sur la façon de modifier ce que vous dites pour l’adapter aux personnes à qui vous parlez, pour vous assurer que les choses sont validées de la bonne manière?
Gerry: Je trouve cela beaucoup mieux à parler aux gens du produit et de la technologie que je ne le suis avec la haute direction. Ils ne se soucient pas vraiment du fonctionnement d’un plan de site XML, ils ne se soucient pas des valeurs que vous y mettez. Ils se soucient de ce dont ils ont besoin et des avantages commerciaux.
Si vous pouvez vous adapter [your proposal] en une seule page, ils sont beaucoup plus heureux. D’une manière générale, un jeu de diapositives pour quelque chose comme celui-ci devrait être long de trois diapositives. Il doit indiquer ce dont vous avez besoin et comment y parvenir.
Il ne vous donne pas de code, il ne vous donne aucun détail sur le système backend, il ne vous donne aucune implication au-delà de cela, il dit simplement ce dont vous avez besoin, quels sont les avantages, ou alternativement, quel est le risque est, si vous ne le faites pas.
Je trouve souvent que nos clients veulent connaître le retour sur investissement d’une action. Je trouve que j’essaie parfois de leur expliquer qu’il y a un retour sur investissement négatif s’ils ne le font pas – c’est ce que vous allez perdre. Si vous ne l’implémentez pas, ou si vos concurrents font quelque chose, ils vont vous voler le trafic.
Communiquer avec les développeurs
Ben: Quels sont vos conseils pour parler aux développeurs au niveau de l’entreprise?
Gerry: En termes simples, assurez-vous de leur parler de la bonne manière. Ils utilisent généralement quelque chose comme Jira – un processus de billetterie ou des user stories. Assurez-vous donc que les billets sont écrits de la bonne manière. Nous disons souvent aux développeurs: “Regardez, montrez-nous simplement ce que vous faites réellement.”
Par exemple, s’il y a un champ particulier que nous devons entrer, nous nous assurons qu’il y est écrit à l’avance, afin que nous n’ayons pas à travailler avec eux pour l’ajouter ultérieurement. Vos critères d’acceptation sont souvent les plus importants. Si vous avez quelque chose dans leur système qui dit que vous devez mettre des critères d’acceptation de l’utilisateur, nous le remettons à l’équipe de référencement et nous écrivons le problème. Cela peut être quelque chose d’aussi simple que si vous accédez à cette URL, il existe un plan de site XML qui ressemble à ceci. Nous essayons d’utiliser le format correct et d’être suffisamment complet pour que cela fonctionne avec leur fonctionnement. Et je pense que c’est essentiel.
Beaucoup veulent aussi des références. Ainsi, par exemple, si vous parlez de la façon dont une redirection devrait fonctionner, ils veulent une sorte de référence sur ce qu’est une redirection, quels sont les en-têtes, à quoi elle devrait ressembler.
Mais l’une des choses que je recommande est de ne pas leur donner trop de code. Ainsi, par exemple, si vous leur dites qu’ils doivent créer quelque chose dans leur back-end, vous ne leur donnez pas le code que vous avez recherché sur Internet. La raison pour laquelle ce n’est pas le cas est souvent que cela ne fonctionne tout simplement pas avec notre système. C’est la mauvaise version de .net, .php ou quelque chose de similaire. Ils ressentiront ce sentiment que vous les conduisez presque avec condescendance. Quand j’étais chez Just Eat, nous avions une agence qui nous donnait des redirections pour les fichiers htaccess. J’essaye alors de leur expliquer que nous n’avons pas de fichier htaccess. C’est le mauvais type de serveur. Si cela arrivait aux développeurs, ils auraient perdu confiance en moi.
En savoir plus
Vous pouvez voir plus de Gerry sur Twitter, ou en savoir plus sur son travail avec Rise At Seven et Take It Offline. N’oubliez pas de consulter l’intégralité de l’interview sur une application de podcast de votre choix.
Edd et moi serons bientôt de retour avec une nouvelle interview pour le podcast RankUp. En attendant, vous pouvez nous retrouver tous les deux sur Twitter, @BenJGarry et @EddJTW.
Si vous souhaitez être invité à l’émission, veuillez nous contacter sur Twitter ou par e-mail.