SEO d'entreprise : pourquoi les « meilleures pratiques » ne suffiront pas et que faire à la place

De nombreux professionnels du référencement s'appuient sur les «meilleures pratiques» dans leurs efforts de référencement.

Mais lors de l'optimisation des sites Web d'entreprise basés sur JavaScript pour la vitesse du site, vous avez besoin de plus que des "meilleures pratiques".

Voici pourquoi les solutions standard ne s'appliquent pas toujours aux sites d'entreprise et ce que vous pouvez faire à la place.

Améliorer la vitesse du site : migrer vers le rendu côté serveur n'est pas toujours la bonne réponse

Imaginez que vous alliez voir le PDG (ou n'importe qui dans la haute direction) et lui conseilliez : « Nous devons changer notre site Web pour le rendu côté serveur (SSR) ».

Ils vous demandent : "Pourquoi ?" et la seule réponse que vous pouvez leur donner est : "Parce qu'il est préférable d'améliorer la vitesse du site". Vous seriez probablement littéralement ri hors de la pièce.

Les implications commerciales et les coûts associés à la migration SSR ne valent pas les efforts considérables et le faible impact.

À moins qu'un site Web d'entreprise ne soit conçu à partir de zéro pour être rendu côté serveur ou qu'il ne soit déjà en cours de migration de site Web, il y a rarement une raison de migrer vers SSR.

Pensez à certains des coûts indirects et indirects qui en découleraient :

• Examen de tous les systèmes et API pour confirmer la compatibilité, qui n'est probablement pas entièrement documentée (probablement par centaines, voire par milliers).
• Des milliers d'heures de travail pour refactoriser, AQ et réviser l'accessibilité pour l'ensemble du site Web.
• Former le personnel existant sur le nouveau cadre (des dizaines, voire des centaines de personnes dans toute l'organisation).
• Embaucher ou licencier des développeurs et des ingénieurs qui ne veulent pas ou ne sont pas à la hauteur des spécifications du nouveau framework.
• Plus d'argent dépensé en frais de serveur.

Plutôt que de subir un processus aussi long et gourmand en ressources, il existe d'autres moyens plus efficaces d'améliorer la vitesse des sites Web d'entreprise.

Dans un précédent rôle en entreprise, j'ai discuté de ce scénario avec l'un de nos ingénieurs système seniors pour le plaisir.

Nous avons estimé qu'il faudrait à l'entreprise un an et demi, une tribu agile dédiée (généralement environ 70 personnes) et au moins 2 millions de dollars (AUD) pour le faire. Et c'était probablement une estimation prudente.

Alors que fait-on à la place pour avancer ?

Apprenez à connaître vos autres équipes et aidez-les

Au niveau de l'entreprise, le référencement doit être un caméléon, car vous comptez sur d'autres équipes pour établir des priorités et faire votre travail à votre place.

Il y a une bonne raison pour laquelle vous n'avez pas les clés du royaume pour apporter des modifications sur le site Web en direct. Le référencement n'est donc pas que du référencement.

Le référencement est "cela améliorera la vitesse de notre site / nous aidera à répondre aux exigences d'accessibilité / etc." Le référencement est tout mais le référencement.

Tom Critchlow l'a dit dans son cours SEO MBA et sur mon podcast, Engage: On Enterprise SEO.

Il résume très bien la vie d'un SEO d'entreprise.

Vous devez passer beaucoup de temps à écouter et à prêter attention à ce que font les autres, puis leur montrer comment ce qu'ils font a amélioré la visibilité organique du site Web.

Créez des défenseurs, et ces personnes reviendront vers vous avec un rapport régulier de ce qu'elles font et changent sur le site Web. C'est la moitié de la bataille là-bas.

La seconde moitié consiste à travailler avec des développeurs, des concepteurs et des analystes pour faire avancer les choses. C'est généralement beaucoup plus fluide lorsque vous réalisez que les gens sont des gens avec leurs propres pensées, sentiments et objectifs.

Être une personne curieuse qui veut les aider à se faciliter la vie est beaucoup plus attrayant que de travailler avec un taureau dans un magasin de porcelaine qui entre dans leur vie toutes les quelques semaines et fait des demandes sans compromis.

Travailler avec les développeurs et les producteurs

Dans de nombreuses entreprises de nos jours, la vitesse du site est un facteur connu qui aide (ou entrave) les taux de conversion.

De nombreuses équipes de développement internes ont probablement la vitesse du site comme KPI. Puisez dans cela.

Vous recherchez tous les deux la même chose et vos développeurs connaîtront mieux la base de code que vous. Et si c'est bien fait, vous pouvez tous les deux en sortir avec un bonus.

Certaines des opportunités courantes de vitesse de site que j'ai trouvées et que les développeurs peuvent vous aider incluent :

Taille/poids du code

Si vos équipes ont des sprints ou des allocations de dette technologique, le fait de savoir quand elles font généralement ce travail peut vous aider à comprendre les impacts de leur refactorisation.

Réfléchissez-leur et reconnaissez leur travail acharné.

Chargement d'image et décalage de mise en page cumulatif (CLS)

CLS peut être un facteur important dans le temps de chargement perçu des grands sites Web d'entreprise basés sur JS. Selon la façon dont cela est implémenté, l'utilisation d'une bibliothèque JS d'espace réservé pour "maintenir" efficacement la position des images peut réduire le temps de chargement perçu de la page en ne déplaçant pas la page lorsque les images sont chargées.

Gestion des redirections

Ce n'était pas quelque chose sur lequel je pouvais m'appuyer car notre gestion des redirections était massivement fragmentée.

Si votre système est un peu plus centralisé, la gestion des redirections, la suppression des sauts, la consolidation des règles en regex et l'amélioration de cette dette technique pourraient aider un peu.

Avec certains déploiements de serveur, chaque règle de redirection doit être lue avant le chargement de la page, ce qui peut ajouter un temps décent (plus de millisecondes) au temps de chargement initial.

<bouton> à la place de <a href>

Celui-ci est un peu plus nuancé, mais j'ai souvent constaté que les développeurs JS incluaient par défaut des liens ahref sous forme de boutons.

C'est généralement parce qu'ils manquent de temps, et c'est un défaut natif du framework dans lequel ils travaillent.

Lorsque j'évaluais de nouveaux modèles de page, je le signalais souvent pour être mis à jour vers <a href>.

Recevez la newsletter quotidienne sur laquelle les spécialistes du marketing de recherche comptent.

Traitement… Veuillez patienter.

S'ABONNER

Voir conditions.

Travailler avec des designers

L'une des plus grandes opportunités de vitesse de site sur les sites Web d'entreprise est la taille et le poids de l'image.

Les normes internes peuvent être mal traduites ou perdues au fil du temps, en particulier lorsque les équipes sont agiles et quelque peu décentralisées.

Lorsque j'ai commencé côté entreprise, je me souviens avoir vu des images de 10 Mo sur les pages produits de certains de nos produits phares. Cela m'a bouleversé.

Aucune image n'a besoin de 10 Mo sur le Web. Arrêt complet.

J'ai donc eu des conversations délicates avec nos designers et j'ai travaillé avec eux pour réduire la taille de nos images sur une période d'environ 8 mois.

100 Ko n'était pas une colline sur laquelle j'étais prêt à mourir, donc si je disais à un designer 100 Ko pour une bannière d'en-tête ou un a-frame, et qu'il l'obtenait à 300 Ko, c'est toujours une amélioration.

Le référencement d'entreprise concerne souvent les gains incrémentiels.

Travailler avec des analystes

Les analystes entrent dans la conversation car ils géreront probablement vos systèmes de balisage et toutes les balises tierces sur votre site Web.

Ils sont le point d'entrée pour avoir des conversations avec les propriétaires de balises pour savoir si cette balise particulière est critique ou non ou s'il existe une alternative.

Parce que, mon garçon, les scripts tiers peuvent causer un gonflement massif sur le site Web.

Ainsi, pendant que vous discutez des plus de 250 scripts publicitaires sur le site et si nous en avons tous besoin, vous pourrez peut-être trouver des compromis à court terme, comme :

• Lancer uniquement HotJar, Fullstory ou un autre script de surveillance de l'expérience utilisateur sur les pages activement cartographiées ou suivies.
• Auditer vos implémentations pour les doublons (cela se produit plus que vous ne l'imaginez).
• Voir quels chatbots ou balises de service client peuvent être lancés en un clic plutôt qu'au chargement de la page.

Travailler avec l'équipe QA

Ce partenariat pourrait très bien être une arme secrète pour vous. Le référencement en général, mais aussi le référencement JavaScript, ont beaucoup d'exigences binaires oui/non ou de bonnes pratiques, comme :

• Les métadonnées doivent être les mêmes entre la source de la page et la page rendue côté client
• Canonical doit être présent sur la page rendue côté client
• Les liens doivent être formatés en tant que <a href=""> plutôt que <button>
• Précharger les polices
• Pré-connexion à de grandes ressources

Entrez dans les bons livres avec votre équipe d'assurance qualité et travaillez avec eux (y compris la formation) pour les inclure dans leur processus d'assurance qualité général et quotidien. Vous aurez des yeux partout et un réseau potentiellement massif de micro-avocats.

Bien qu'il existe de nombreuses autres équipes avec lesquelles vous pourriez travailler pour améliorer le référencement global de votre site Web, ce sont probablement celles avec lesquelles vous travaillerez le plus en ce qui concerne le côté plus technique de la mise en œuvre.

Défendre les autres équipes avec lesquelles vous travaillez

Rappelez-vous ce que j'ai dit plus tôt sur la façon dont le travail avec les gens se passe quand vous vous souvenez que ce sont des gens ? Vous voulez mettre cela en action.

Il existe deux façons très efficaces de le faire au niveau de l'entreprise.

Respectez leur temps

Disons que vous avez une grande idée, comme "nous devrions migrer vers le rendu côté serveur".

Dans ce cas, plutôt que d'aller au bon de commande et de dire : "Hé, pouvons-nous faire tout cela ?", travaillez avec eux pour créer une preuve de concept qu'ils ont validé les chutes dans le seau "facile" et suivre son impact. .

Si cela ne fonctionne pas, ils n'ont pas essentiellement perdu 20 sprints pour mener à bien cet énorme projet.

Si cela fonctionne, vous avez une analyse de rentabilisation à présenter à l'équipe des finances pour financer et hiérarchiser le reste du projet afin de le faire passer sur l'ensemble du site Web et d'obtenir cette tribu dédiée, 2 millions de dollars et un an et demi pour le faire .

Amplifier leur effort

Quelque chose pour lequel les référenceurs sont notoirement mauvais est la communication et le partage du succès.

Ce sera peut-être un peu plus facile si, plutôt que de dire « hé, regarde cette chose fabuleuse que j'ai faite », vous la positionnez comme suit : « hé, regarde cette chose incroyable que cette autre équipe avec qui j'ai travaillé en étroite collaboration a faite et c'est ainsi que cela a beaucoup amélioré l'expérience de notre site.

Vous, le SEO, n'êtes plus le centre d'attention. L'équipe qui a fait le travail réel est.

Collaboration, plaidoyer et gains supplémentaires

Vous remarquerez peut-être que je n'ai pas trop parlé de la nuance de JavaScript et de la vitesse du site dans cet article.

C'est parce que, dans les entreprises, vous aurez probablement des personnes très intelligentes qui travaillent avec vous à qui vous pouvez vous adresser pour un problème et la forme de la solution.

Ils peuvent vous aider à y parvenir mieux qu'un article dans une publication SEO ne le pourrait.

Faire avancer les choses au niveau de l'entreprise concerne moins le « quoi » que le « comment ».

Utilisez donc ces directives pour obtenir votre "comment" pour améliorer la vitesse de votre site Web basé sur JavaScript, et le "quoi" viendra beaucoup plus facilement.