Développement Web pour le référencement : un autre va presque vers le sud

Dernière mise à jour le 14 septembre 2018

C'est pourquoi vous avez une société de référencement, comme ça ! Entreprise, pour détecter et corriger ce qui ne va pas avec la refonte d'un site Web existant. Comme le savent tous ceux qui travaillent dans l'industrie du marketing Internet et qui ont traversé la reconstruction d'un site Web fonctionnel, une myriade de choses peuvent mal tourner. Récemment, un client PPC (paiement par clic) et SEO (optimisation pour les moteurs de recherche) vient de terminer la reconstruction de son site Web et l'a lancé sans permettre l'examen. Cette dernière reconstruction du site de ce client s'est horriblement mal déroulée au lancement, je vais donc aborder certaines des choses attendues et inattendues qui peuvent et peuvent aller mal.

Le besoin

Ce client a acheté une entreprise existante qui avait un site Web de commerce électronique et d'information existant et qui était un chef de file dans son secteur. Le développeur Web n'est pas venu avec l'achat. Pour une raison qui ne m'a jamais été révélée, le client n'a pu mettre à jour aucune page en dehors du panier. Le panier d'achat n'était pas adapté aux mobiles et nous pouvions voir la différence dans leurs conversions entre ordinateur et mobile. Les conversions mobiles étaient pratiquement inexistantes. L'écrasante majorité de leurs ventes en ligne étaient générées par la recherche organique sur ordinateur, le PPC, les visites directes et de référence.

De nombreux éléments nécessaires pour améliorer leur référencement n'étaient tout simplement pas là. Aucune possibilité de modifier les métadonnées, les balises h1, les balises alt/title, etc. La plupart de ces données étaient générées par programme ; ainsi que les menus et la structure de navigation. Ce nouveau site devrait également être sécurisé. En bref, ils avaient besoin d'un nouveau site Web et d'un panier d'achat sécurisés et adaptés aux mobiles avec un connecteur pour fonctionner avec leur suite logicielle de planification des ressources d'entreprise (ERP) existante.

La mission

Ce client avait 3 766 mots-clés avec des résultats de classement dans les cent premiers SERP de Google. Cinq cent trente huit (538) mots clés avec des résultats de page 1, portant un volume de recherche mensuel moyen de 65 790 et 43 mots clés se classant en première position dans les SERP de Google qui avaient un volume de recherche mensuel moyen de 6 110. Mon travail consistait à les guider à travers les exigences qu'un nouveau système d'administration devrait fournir pour pouvoir mettre en œuvre le référencement à l'avenir. Cela comprenait également la protection de leurs résultats de classement existants aussi bien que possible.

La sélection

Le client a finalement choisi un fournisseur offshore qui pourrait fournir l'intégration entre son logiciel ERP existant et une nouvelle solution de panier d'achat et un site Web sécurisés et adaptés aux mobiles. Ne connaissant pas ce fournisseur offshore, le client m'a fourni une démo de produit enregistrée pour confirmer que le système d'administration fournirait ce dont nous avions besoin pour mettre en œuvre le référencement. Après examen de la démo, j'ai conclu que nous avions les éléments nécessaires pour aider le client à améliorer son référencement. Nous pourrions créer nos propres titres de page, méta descriptions et balises h1. Nous avons pu mettre à jour le code Google Analytics (GA), dont ils exécutaient un ancien code GA obsolète et aucun compte Search Console. Nous avons eu accès aux images afin d'ajouter un texte alt/title correctement formaté. Comme nous l'avons découvert plus tard, et bien trop tard, il était même possible d'appliquer la redirection 301 directement sur chaque page. Mais ce n'est qu'une partie de l'histoire.

Le résultat

Il s'avère que le développeur a fourni un modèle, un panier d'achat et une intégration ERP. Le client a été chargé de déplacer le contenu (copier le contenu de l'ancien site et le coller dans une nouvelle page du système d'administration), y compris les métadonnées existantes. Ils ont également été chargés d'entrer les URL de l'ancien site dans les données de la nouvelle page, page par page. Il s'est avéré que cela était compliqué par le fait que le client ne pouvait pas copier et coller les URL de l'ancien site intactes. Le client a considéré cela comme une procédure opérationnelle standard et n'en a informé personne. Nous avions initialement recommandé au développeur de créer un fichier de redirection 301 approprié. Le calendrier de déploiement n'a pas permis au client de nous laisser examiner le bon fonctionnement. Ils viennent de le lancer et c'est là que tout a mal tourné.

Dès que nous avons été informés que le site reconstruit avait été lancé, nous avons commencé à tester manuellement les résultats de classement des mots clés d'origine par rapport aux résultats de classement actuels. Juste pour voir à quoi ressemblait le nouveau site et que toutes les données ont été transférées. Tous les résultats de classement dans les SERP de Google qui étaient encore en place ont donné lieu à un code de réponse 404, à l'exception de la page d'accueil. Il s'avère que les URL de l'ancien site ont été créées avec des extensions .html et que les nouvelles URL ne l'étaient pas. Le système d'administration ne permettait tout simplement pas de coller l'ancienne URL dans le champ de redirection 301 fourni, de sorte que le client a collé l'ancienne URL sans l'extension .html. Le client avait supposé qu'il s'agissait d'une procédure d'exploitation standard.

Après de nombreuses discussions internes, nous avons découvert que si vous supprimiez l'extension .html, les pages seraient correctement redirigées vers la version sécurisée de la nouvelle URL, dans la plupart des cas. Cependant, dans certains cas, l'ancienne URL, sans l'extension .html, redirigerait vers une nouvelle URL très peu conviviale pour les moteurs de recherche contenant une chaîne de requête que nous n'avions jamais vue auparavant. Lors d'un examen plus approfondi, nous avons constaté que cette nouvelle URL inconnue était générée par la navigation dans le menu principal. Nous avons donc eu une redirection un à un, dans la plupart des cas, de l'ancienne URL, extension .html supprimée, vers la nouvelle URL conviviale pour les moteurs de recherche sécurisés et nous avons pu naviguer vers le même contenu à partir de la navigation principale qui a généré le nouveau non - URL conviviale.

Contenu dupliqué ? Eh bien, la balise canonique rel= a-t-elle été placée, vous pouvez demander ? Correctement? Non. La balise rel=canonical sur l'URL redirigée conviviale pour les moteurs de recherche a été définie pour pointer vers la nouvelle URL non conviviale pour les moteurs de recherche contenant la chaîne de requête. Lors de l'examen de la balise rel=canonical de la page non conviviale, nous avons découvert que cette balise faisait référence à une URL entièrement différente. Un contenant la catégorie et non la chaîne de requête. Ainsi, un élément de contenu était affiché pour trois URL différentes, avec des balises rel=canonical mal définies.

Ensuite, nous avons constaté que tous les bots avaient été interdits dans le fichier robots.txt. Ensuite, nous avons vérifié l'activité dans GA. Le client recevait toujours des visites de toutes les sources, mais n'enregistrait aucune conversion. De plus, le client souhaitait que nous poussions le crawl et l'indexation qui nécessitent la Search Console de Google. Le problème ici est que le code GA existant était ancien et qu'aucun code de vérification de la Search Console n'a été placé sur le site. C'est l'un de ces éléments que le client ne pouvait pas changer pour des raisons jamais divulguées.

Heureusement, le client avait suivi notre recommandation de mettre à jour son code GA vers la dernière version. De leur propre chef, ils ont également ajouté le gestionnaire de balises de Google. Oops! Peut-être un double tir du code GA ? Avec Google Tag Manager et le code GA asynchrone mis à jour en place, nous avons pu créer un nouveau compte Search Console sécurisé (https ou http) pour le client, puis nous avons découvert qu'il n'y avait pas de sitemap .xml à soumettre pour une exploration demandée. .

Dès notification, le client a communiqué avec le développeur et a reçu deux URL de plan de site .xml. Un a fonctionné. Un ne l'a pas fait. Celui qui fonctionnait avait une entrée qui pointait vers le sitemap .xml qui ne fonctionnait pas. Le plan du site .xml qui ne fonctionnait pas n'avait pas le bon formatage lorsqu'il était affiché dans un navigateur. Nous n'avons donc pas soumis le sitemap .xml fourni à l'époque.

Le résultat final

Nous avons informé le client, par le biais d'e-mails organisés, de ce que nous trouvions. Tout d'abord, le problème des redirections défaillantes et que nous avons constaté que si nous supprimions l'extension .html, elles étaient correctement redirigées. Le client a informé le développeur et le développeur a répondu que vous ne pouviez pas mettre l'extension .html dans l'outil de redirection 301 fourni. Une découverte plus approfondie a révélé que le client avait découvert cela et pensait qu'il s'agissait d'une procédure d'exploitation standard.

Pour une raison quelconque, le site Web d'origine a été supprimé (gros oopsy ici, ayez toujours une version de travail prête à se replier) afin que nous ne puissions extraire aucune des anciennes URL pour créer une nouvelle redirection 301 permanente via le fichier .htaccess. La résolution consistait à créer une nouvelle correspondance un à un, l'ancienne URL par rapport à la nouvelle URL, une feuille de calcul, en extrayant les données de la page de destination de GA pour l'année écoulée, pour que le développeur crée une redirection fonctionnant correctement en remplaçant la redirection 301 dans le système d'administration qui a été confié au client.

Problème résolu à un coût supplémentaire pour le client par le développeur. Tous les anciens résultats de classement existants avec une extension .html ont commencé à être redirigés correctement et dans les 14 jours, les résultats de classement ont été remplacés par les nouvelles URL sécurisées et, pour la plupart, très proches du résultat de classement préexistant. Le problème de balise rel=canonical a été résolu lors d'une réunion en ligne avec l'agent commercial du développeur Web et s'est soldé par une erreur de saisie de l'utilisateur. Il y avait plusieurs champs où les données pouvaient être saisies ou sélectionnées à partir d'un choix existant et la solution nécessitait de réinitialiser ces champs et de vider le cache.

Les deux versions supplémentaires de l'URL conviviale et sécurisée ont rapidement disparu. Concernant le bot /disallow dans le robots.txt, sur notification, le développeur a rapidement résolu ce problème.

Il a été constaté que le problème avec les données de conversion GA semble être limité au fournisseur de services marchands du client ; qui était nouveau et différent de l'ancien fournisseur. Personne n'a pensé à informer le fournisseur de services marchands que nous avions besoin d'un code GA sur sa page de paiement afin de fournir les données de commerce électronique nécessaires dont le client a besoin pour prendre des décisions commerciales éclairées concernant ses efforts de marketing. Nous n'avons pas été informés de l'existence d'un nouveau prestataire de services marchands.

Enfin, nous avions créé manuellement un fichier de plan de site .xml que nous voulions télécharger sur le serveur et demandé au développeur de désactiver tout ce qui créait son plan de site .xml qui ne fonctionnait pas. Lors d'une discussion plus approfondie avec l'agent commercial du développeur, on nous a dit que nous ne pouvions pas télécharger un autre sitemap .xml sur le serveur.

Après avoir montré les résultats à l'agent commercial du développeur, il a déclaré qu'il se pencherait dessus, cependant, il a suggéré que nous visionnions le code source. Lors de l'affichage dans le code source, le document .xml était correctement formaté. En voyant ce résultat, nous avons informé Google, via la Search Console, que nous avions en fait un sitemap .xml fonctionnel. Enfin, au cours de plusieurs jours, Google a finalement enregistré que nous avions un sitemap .xml fonctionnel et a commencé à afficher les URL indexées. Cependant, comme indiqué précédemment, le plan de site .xml correctement formaté n'avait qu'une seule entrée pointant vers le plan de site .xml supplémentaire qui ne se résoudrait pas dans un navigateur, mais s'afficherait correctement dans le code source.

Eh bien, ce problème est devenu un problème plus important car le sitemap .xml supplémentaire a généré un code de réponse 500, il y a donc un problème avec l'agent Google accédant à cette zone du site. Et, à ce jour, les deux sitemaps .xml génèrent 500 codes de réponse. La semaine précédente, nous avions déclenché une exploration à l'aide de l'outil d'extraction, de rendu et de soumission à notre disposition dans la console de recherche Google, ce qui, selon nous, a causé l'exploration et l'indexation du nouveau site.

Donc, en terminant, si cela peut mal tourner, ce sera le cas lors de la reconstruction de votre site Web et, espérons-le, vous pourrez éviter certaines de ces erreurs. Le blocage des bots dans le fichier robots.txt et la redirection incorrecte peuvent vous mettre en faillite en ligne ou, du moins, en danger. Si les robots ne peuvent pas explorer votre site, vous finirez par quitter l'index et lorsque vous quittez l'index, à moins qu'ils ne proviennent de sources de référence, directes ou d'autres sources non organiques, la plupart des visites de recherche organique deviendront inexistantes.

Si les résultats ne redirigent pas correctement, les visiteurs organiques peuvent considérer votre site comme non digne de confiance. Les clients existants qui ont enregistré votre site en tant que signet peuvent être frustrés lorsque leur signet ne redirige pas correctement. Sans oublier que nous avons dû arrêter leur campagne PPC entre-temps. Cliquer sur une annonce payante et obtenir une réponse 404 page introuvable n'est pas seulement frustrant pour vos visiteurs, cela coûte cher ! Le clic vous coûte de l'argent et vous n'obtenez aucun retour sur votre investissement. Et c'est pourquoi vous nous avez.

– Mark Gray, responsable principal du référencement