Table des matières

Abonnez-vous à RankUp sur Spotify Podcasts Apple Google Podcasts 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 était centrée sur la façon 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 quelques-uns des moments forts de l’interview.

Présentation de Gerry

Ben: Comment êtes-vous arrivé là où vous en ê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 complète 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: Qu’est-ce que votre rôle actuel en tant que SEO Directeur chez Rise At Seven impliquer?

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 à travers nos clients et à essayer de faire avancer les choses d’une manière ou d’une autre avec différents clients.

< h2> Défis courants du référencement en entreprise

Ben: Quels sont les problèmes courants que vous rencontrez 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 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 c’était le 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 réfléchir à ces objections et leur dire: «Écoutez, nous pouvons nous assurer que les concurrents ne les trouvent pas, nous sommes juste le donner à Google. ” Nous devons nous assurer que les choses sont assez rapides, suffisamment évolutives, et 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 ou quoi que ce soit sur la façon de modifier ce que vous dites pour l’adapter aux personnes à qui vous parlez, à faire Vous êtes sûr que les choses sont bien validées?

Gerry: Je trouve cela beaucoup mieux à parler aux produits et aux techniciens 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 insérer [votre proposition] sur 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 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 encore, quel est le risque 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 mettez pas en œuvre cela, 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 plus tard. 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 des utilisateurs, 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 d’entre eux 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 fonctionnera 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 en savoir plus sur Gerry sur Twitter , ou en savoir plus sur son travail avec Rise At Seven < / a> et Mettez-le hors ligne . N’oubliez pas de consulter l’intégralité de l’interview sur une application de podcast de votre choix.

Edd et moi reviendrons bientôt avec une nouvelle interview pour le podcast RankUp. En attendant, vous pouvez nous trouver à la fois sur Twitter, @BenJGarry et @EddJTW .

Si vous souhaitez être invité à l’émission, veuillez nous contacter sur Twitter ou par e-mail. < / p>

 

traduit de https://www.impression.co.uk/blog/enterprise-level-technical-seo-gerry-white/