Combien de temps faut-il à une page pour être indexée en utilisant différentes méthodes d’indexation ?

Il existe de nombreuses façons différentes d’indexer une page. Nous avons voulu tester le temps que prennent les différentes méthodes d’indexation. Comme il n’est pas certain que l’indexation fonctionne, la série de tests ci-dessous démontrera si l’indexation est une technique viable pour amener Google à explorer vos pages. Les méthodes suivantes ont été testées : Google URL Submit, Search Console’s Fetch and Render, Linklicious, et Publication sur le web dans un Google Doc.

Configuration du test

Il y a cinq tests dans ce test. Une fois la page publiée, elle est immédiatement soumise à chaque méthode d’indexation spécifique. La page a été testée pour voir si elle apparaissait dans les résultats de recherche et pour vérifier la date de mise en cache.

Premier test : Linklicious

L’URL cible a été soumise via le tableau de bord de Linklicious. Elle a été soumise le 20 septembre. L’URL cible a été indexée le 28 septembre.

Deuxième test : Google Doc, hyperlien

Un document Google a été créé et un lien cliquable vers la page cible figurait sur ce document. Le Google Doc a été publié sur le Web le 20 septembre. L’URL cible a été indexée le 30 septembre.

Test 3 : Search Console, Fetch et Render

L’URL cible a été soumise via Fetch and Render. Elle a été soumise le 21 septembre et indexée le 21 septembre.

Test 4 : Google URL Submit

L’URL cible a été soumise via Google URL Submit. Elle a été soumise le 21 septembre et indexée le 21 septembre.

Test 5 : Google Doc, sans hyperlien

Un Google Doc a été créé. Cette fois, le lien vers l’URL cible n’était pas cliquable. Il s’agissait simplement d’un texte. L’URL cible a été publiée le 14 septembre. Cela fait un mois et la page n’a pas été indexée.

Résultats

Le document Google Doc sans hyperlien est une pièce importante de ce test. Il démontre que les méthodes fonctionnent réellement. Les pages ne sont tout simplement pas indexées dans le temps imparti. En outre, il est important de noter que si vous utilisez la méthode Google Doc, vous devez utiliser des liens cliquables dans le document. Si vous avez des difficultés à indexer une page particulière et que vous ne souhaitez pas utiliser Search Console, nous vous recommandons d’utiliser la méthode Google Doc. Nous pensons qu’il s’agit d’une méthode d’indexation plus naturelle que celle qui consiste à envoyer des messages à Google en utilisant un indexeur de liens.

Le retour d’expérience de Clint

Dans cette vidéo, Clint discute de ce test, de son expérience avec Google Search Console, du test “Mobile Friendly” et de l’indexation.

Test numéro 66 – Combien de temps faut-il à une page pour être indexée en utilisant différentes méthodes d’indexation ?

Je pense que c’était un test de 2017-2018 et c’est certainement un test qui doit être examiné, à nouveau. Mais voici les différentes méthodes d’indexation auxquelles nous sommes habitués. La première est Linklicious, je me souviens de ce service. Je n’en étais pas un fan, mais je m’en souviens. L’ancienne méthode Google Doc – vous faites un lien vers Google Doc, la Search Console fetch and render, pas aujourd’hui, c’est URL inspect submit to indexing, Google URL submit, qui est encore une fois, la même chose. Google Doc, pas d’hyperlien et il y a les temps juste là.

La soumission d’URL était moins de 15 minutes, Fetch and Render était moins de 15 minutes, Linklicious, c’était huit jours, c’est le meilleur résultat que j’ai jamais eu avec. Google Doc hyperlien était de 10 jours, et puis Google doc non hyperlien n’était jamais.

Nous savons aujourd’hui que tout cela est complètement différent. L’URL submit a été déprécié, puis placé dans Google Search Console, dans le cadre de l’outil d’inspection des URL. Donc, l’outil d’inspection des URLs est maintenant le fetch and render. Ensuite, vous faites le test de la version live, qui récupère et rend le nouveau code par rapport à ce qui est actuellement stocké dans le système. Ensuite, vous cliquez sur le bouton Soumettre à l’index ou demander l’indexation, ce qui remplace le bouton Soumettre l’URL.

Comme vous le savez tous, si ce n’est pas le cas dernièrement, la console de recherche Google fonctionne sur une base de données différente, elle doit fonctionner sur une base de données différente de celle des résultats de recherche, car il arrive que la console de recherche dise que vos pages sont indexées, que vous alliez chercher l’URL dans les SERP pour voir si elle est indexée ou non, et qu’elle n’y soit pas, ou vice versa, que vous la trouviez dans les résultats de recherche, mais que la console de recherche vous dise qu’elle n’est pas indexée.

Cela devient de plus en plus un problème, parce qu’ils essaient de relier ces deux bases de données ensemble et ensuite de relier certaines fonctionnalités ensemble. Et en particulier, les PageSpeed Insights, ou les vitaux web de base, et l’indexation mobile ou les tests de convivialité mobile.

Ils essaient de faire en sorte que si vous utilisez la console de recherche, que vous avez le test de convivialité mobile, par exemple, et que vous l’échouez, vous serez retiré des SERPs. Je m’attendais à ce que cela se produise également pour les vitaux web de base. S’ils sont très mauvais et que votre concurrence est très bonne, vous ne serez pas retiré des SERP, mais cela peut affecter votre classement. Le mobile, c’est sûr, parce qu’ils se dirigent vers l’indexation mobile uniquement, nous allons indexer la version mobile de votre site web, n’est-ce pas ? Ils n’arrêtent pas de dire que ce basculement est repoussé parce que la plupart des gens construisent des sites Web réactifs de toute façon et tout se charge dans la version T.

À mon avis, l’indexation uniquement pour les mobiles aurait bien fonctionné lorsque vous deviez utiliser tout le .mobile et qu’il n’existait pas de conception Web réactive, il y avait deux versions de votre page Web. Et maintenant, pour moi, c’est un peu dépassé. Mais pour le mobile, ils veulent que tous les sites web soient adaptés aux mobiles et c’est vraiment une question de revenus, non ? Si vous avez un site Web adapté aux mobiles et que la majorité du trafic Internet dans le monde est adapté aux mobiles, alors ils se disent que nous allons ajuster cette plus grande base de clients en disant – hé, le site Web de tout le monde devrait être adapté aux mobiles et si vous n’êtes pas adapté aux mobiles, vous ne serez pas dans notre index, parce que nous utilisons les utilisateurs de mobiles et nous faisons notre CTR et notre CRO pour les SERPs de Google, basés sur les utilisateurs de mobiles et nous voulons seulement leur montrer des sites qu’ils peuvent ouvrir dans leur mobile. Et cela augmentera notre valeur en tant que moteur de recherche pour les utilisateurs de mobiles, par conséquent, ils cliqueront davantage sur les annonces mobiles.

Cela n’a rien à voir avec l’amélioration de l’internet. C’est entièrement lié à l’optimisation du taux de conversion de Google et des résultats de recherche. Donc, lorsqu’ils branchent un outil défectueux, comme l’outil de test de compatibilité avec les mobiles, dans la console de recherche Google, et que si vous échouez à l’outil de test de compatibilité avec les mobiles, la console de recherche Google signale la base de données SERP, et cela supprime votre classement pour tous les mots clés basés sur les données de l’outil de test de compatibilité avec les mobiles, cela ne va pas du tout aider les webmasters. C’est quelque chose que j’ai vu de plus en plus régulièrement, c’est que l’outil de test de compatibilité avec les mobiles vous montrera un échec et ensuite si vous aviez des classements sur cette page, tous ces classements disparaîtront.

La page sera toujours indexée, mais vous perdrez tous les classements et c’est à cause de la technologie. L’outil de test de compatibilité avec les mobiles n’est pas à la hauteur des normes de la technologie utilisée aujourd’hui. Il envoie ce signal à la console de recherche et la console de recherche l’envoie à la base de données SERP, ce qui perturbe les webmasters à gauche et à droite.

En fin de compte, Google n’en a rien à foutre de tout ça. Ils ne vont pas le réparer. Si un grand éditeur est impliqué dans ce problème et qu’il entretient une relation commerciale importante avec Google, il s’en occupera peut-être. Mais pour l’essentiel, les gens vont devoir se plier aux caprices et aux moyens de la quantité limitée d’outils qu’ils nous donnent, que Google nous donne, pour ce qui est d’être à jour et de fonctionner correctement pour tous les sites Web, plutôt que de réparer et de s’assurer que tout fonctionne parfaitement, bien qu’ils soient tout à fait d’accord pour que les valeurs aberrantes échouent, tant que cela fonctionne pour la plupart des gens.

Gardez donc cela à l’esprit, gardez un œil sur ce test, en particulier sur le test de compatibilité avec les mobiles. Regardez-le, si vous avez des pages qui apparaissent, vérifiez les classements si elles ont disparu. Trouvez le truc de la compatibilité mobile. D’après mon expérience, vous corrigez un problème de compatibilité avec les mobiles, et les classements reviennent, presque dans les 24 ou 48 heures. Si vous ignorez le problème de compatibilité avec les mobiles, les classements resteront perdus jusqu’à ce que vous le corrigiez. Et une fois que vous l’avez corrigé, ils reviennent. Et je l’ai vu maintes et maintes fois, il y a beaucoup de gens qui disent, je n’ai jamais vu ça. Il n’y a pas beaucoup de gens qui ont pris la peine de regarder et de vérifier ses classements.

L’indexation reste. Si vous échouez au test, ça reste dans l’index. Mais il ne sera pas classé pour quoi que ce soit.