Avez-vous besoin de désavouer sur [HTTPS SSL] après avoir désavoué sur [HTTP]
J'ai un client qui a désavoué quelques milliers de liens sales de son profil de site en février 2015. Récemment, le site a basculé de HTTP à HTTPS (SSL appliqué).
Google vous recommande d'ajouter toutes les variantes à la console Google (outils pour les webmasters).
Le site a un total de 4 variantes, par exemple:
http://www.example.com(précédemment préféré)http://example.comhttps://www.example.com(Maintenant préféré)https://example.com
Question:
Comme il s'agit techniquement d'une nouvelle propriété dans Google Webmaster Tools, devez-vous soumettre le même fichier de désaveu ajouté précédemment en 2015?
Il est difficile de répondre à cette question simplement parce qu'il n'y a pas de réponse directe à cette question. Voyons si nous pouvons suivre le processus.
Supposons quelques choses. Le premier est une redirection de couverture 301 d'un site, HTTP, vers un autre, HTTPS. La seconde est qu'il existe des liens vers le site HTTP et non vers le site HTTPS.
Ce que nous savons.
Les clés d'indexation Google des deux éléments de données principaux, l'URL du nom de domaine et l'URL de toute page ou ressource.
Pour n'importe quel site, le nom de domaine est l'URL complète du site, protocole compris. Si un site peut être trouvé avec HTTP et HTTPS, il s’agira de sites différents, de même que www ou non www. L'URL complète étant la clé, toute variation de l'URL apparaît dans l'index et Google sélectionne toute ressource trouvée à la suite de cette URL.
HTTP://example.com <-- HTTP://example.com/seo-guide
HTTP://www.example.com <-- HTTP://www.example.com/seo-guide
HTTP://example.com <-- HTTPS://example.com/seo-guide
HTTP://www.example.com <-- HTTPS://www.example.com/seo-guide
Pour qu'un lien existe dans l'index, il possède une URL source et une cible. Si un lien ou une page existe, Google ne supprimera pas cette URL de l'index.
HTTP://www.spamdomain.com --> HTTP://www.example.com
Dans l'index, la cible est HTTP://www.example.com.
En nous arrêtant un instant, regardons la console de recherche de Google et voyons ce que Google a à dire.
Dans: https://support.google.com/webmasters/answer/2648487?hl=fr
Remarque: lorsque vous consultez les liens vers votre site dans Search Console, vous pouvez vérifier les versions www et non www de votre domaine dans votre compte Search Console. Pour Google, ce sont des sites entièrement différents.
Dans: https://support.google.com/webmasters/answer/34592?hl=fr
Si votre site prend en charge plusieurs protocoles (http: // et https: //), vous devez les ajouter en tant que site distinct.
Lorsque vous visitez: https://www.google.com/webmasters/tools/disavow-links-main
... en supposant que vous soyez connecté, vous verrez toutes les propriétés de votre console de recherche. Vous verrez si vous les avez ajoutés, les propriétés des sites HTTP, HTTPS, www et non-www. Google vous recommande d'ajouter toutes les variantes du site. Si vous sélectionnez le bouton Désavouer les liens, vous pouvez facilement voir que la clé utilisée est l'URL du nom de domaine.
Ce que nous ne savons pas.
Nous savons que la page qui existait avant l'ajout de la redirection 301 est supprimée de l'index et que la cible de la redirection 301 est ajoutée à l'aide du nouvel emplacement. Cela est vrai si le 301 reste sur le site ou dans un nouveau domaine entièrement. Nous savons que l'ancienne URL et la nouvelle URL existent et sont associées au nom de domaine. Nous savons également que la valeur du lien est transmise du site de courrier indésirable via la redirection vers la page cible. Nous le savons.
On ne sait pas si un désaveu créé pour une propriété de la console de recherche agira en réalité comme un pare-feu.
HTTP://www.spamdomain.com --> HTTP://www.example.com --> HTTPS://www.example.com
Souvenons-nous de quelques points concernant les programmeurs et les ingénieurs de bases de données. Ils sont simples par nature et parfois paresseux. Désolé les gars. Je parle de moi Souvent, le code et les données sont canalisés. De même, si du code ou des éléments de données peuvent être réutilisés, ils le seront.
Par exemple, si j'étais programmeur et/ou administrateur de base de données, est-ce que je conserverais la relation ci-dessus ou ajouterais simplement un nouveau lien vers l'index? Lequel est le plus facile à créer et à maintenir?
HTTP://www.spamdomain.com --> HTTPS://www.example.com
Dans: https://support.google.com/webmasters/answer/93633?hl=fr
Matt Cutts avertit que la création de redirections 301 dans les chaînes peut ne pas être suivie si la chaîne a trop de liens. Le googlebot normal ne peut pas les suivre. (Oh mon Dieu! Est-ce que je viens de citer Cutts? Love ya Matt!)
Cela nous indique peut-être que Google n'est pas intéressé par le chemin d'une redirection 301 autant que par le résultat. En d'autres termes, il est probable qu'il n'y ait pas de relation de base de données entre les URL indiquant une redirection 301 au sein de l'index Google. Pures spéculations bien sûr. Mais regardons les choses de cette façon. Du point de vue des programmeurs, il n’est pas nécessaire de garder trace des redirections 301 si je mets simplement un nouveau lien en tant que résultat de la redirection 301 dans l’index, comme suggéré ci-dessus.
Tant que la redirection 301 reste, les deux liens ont une source et une cible et restent valides. En d'autres termes, ils restent tous les deux dans l'index. Cependant, dès que la redirection 301 est supprimée, le lien ajouté à la suite de la redirection 301 devient instantanément invalide et est supprimé. Est-ce que je commence à avoir un sens?
Pour mémoire, je suis sûr que le schéma comporte bien plus que ce que j'ai décrit. Cependant, si je ne me trompe pas, je soupçonne plutôt que ma logique suit suffisamment la réalité pour en être une illustration.
Il n'y a qu'un moyen de savoir (peut-être) si vous êtes un utilisateur de la console de recherche Google. (C'est un gros peut-être.)
Donc quelle est la réponse?
Si, dans le scénario que vous décrivez, vous ajoutez la propriété HTTPS et supposez que vous redirigez tout le site de HTTP à HTTPS, vous voyez que les liens apparaissent pour la propriété HTTPS, alors je dirais que la réponse est la suivante:
OUI.
Si, dans le scénario que vous décrivez, vous ajoutez la propriété HTTPS, et NON en supposant que vous redirigez le site entier de HTTP vers HTTPS, vous ne verrez pas apparaître de liens pour la propriété HTTPS en fonction de ce que nous savons de l'index Google. est claveté. Dans ce cas, la réponse est:
NO.
Sans aller plus loin dans les anciens brevets, etc., nous ne pourrons peut-être jamais connaître la réponse, même si nous le savions. Il n'y a qu'un seul moyen de savoir et ce n'est pas recommandé.
Si vous vous inquiétez de mauvais liens vers votre site HTTP, il ne fera pas de mal et il serait certainement sage de désavouer les liens de la propriété HTTPS. Votre appel.
La réponse est - lequel est l'indexation de Google?
Il n'indexera qu'une version. C'est celui que vous désavouez.
Faites-le avec le domaine racine (domain: example.com) et vous n'avez même pas besoin de spécifier un protocole.
Non, il n'est pas nécessaire de soumettre à nouveau le domaine SSL. Vous avez déjà désavoué les liens pour la version HTTP; en d'autres termes, ils ne sont plus pris en compte "(compte lorsque" Google] évalue votre site " .
Par conséquent, l'effet négatif ne peut pas être transmis au nouveau site (HTTPS): il a déjà été traité.
Le fait que les sous-domaines et les protocoles soient ajoutés séparément dans la console de recherche ne semble pas avoir d'incidence sur le problème.
Dans le fichier de désaveu, domain:example.com couvre tous les cas de www cname (s) et tous les sous-domaines, sous http: // et https: //. Donc, peu importe ce que leur domaine fonctionne, ou quels sous-marins sont en cours d'exécution, ce sera désavoué
https://support.google.com/webmasters/answer/2648487?hl=fr dit:
Si vous souhaitez que Google ignore tous les liens d'un domaine entier (par exemple, exemple.com), ajoutez la ligne domaine: exemple.com.
Exemple, domain:blogger.com empêcherait le blogueur lui-même et les blogs de tous les peuples de tous les sous-domaines, https ou non, de revenir en arrière.
En ce qui concerne le mécanisme de déclenchement dans le moteur de Google, je ne peux que supposer qu'une nouvelle vérification/propriété de domaine https serait toujours désavouée lors de l'utilisation du style générique domain:example.com. Ne serait pas blessé de le télécharger si en cas de doute, tu sais?
Peut-être que je suis un peu en retard à la fête mais un de mes collègues vient de trouver cette information utile:
https://Twitter.com/methode/status/653980343658151936
Voici une transcription du tweet de Gary Illyes (souligné par moi):
d'accord, vérifié avec l'équipe: oui, vous devez réutiliser le fichier de désaveu dans le profil de site https dans SC .