Quelle est la différence entre les redirections canonique et 301?
Je ne suis pas en mesure de faire la différence entre les redirections canonique et 301.
Le lien canonique et les redirections 301 existent depuis des années, mais ils génèrent continuellement de la confusion et des questions sur la meilleure solution pour gérer la redirection.
Alors, pouvez-vous élaborer les problèmes généraux avec les redirections 301 et l'option canonique?
Lorsque vous utilisez la redirection 301, vous indiquez à Google que la page en cours est définitivement déplacée vers une autre URL.
Cannonical est utilisé pour empêcher les sanctions de Google en cas de duplication de contenu. Lorsque vous l'utilisez, la page actuelle existe, mais indique à Google que "copie" d'une autre "page maître". Par exemple, je peux vous donner les URL des produits OpenCart, elles sont comme ceci:
domain.com/product-1
domain.com/category-1/product-1
domain.com/category-1/subcategory-1/product-1
C'est exactement 3 mêmes pages avec le même contenu et Google n'aime pas le contenu dupliqué comme ceci. Donc, dans ce cas, vous devriez mettre dans chaque page une balise rel canonique à la page "maître". Par exemple, nous choisirons "domain.com/category/subcategory/product:
<link rel="canonical" href="domain.com/category/subcategory/product">
OpenCart le fait par défaut, mais je ne l'utilise que pour l'exemple.
Une balise canonique et une redirection 301 sont deux choses très différentes.
Une balise <link href="...." rel="canonical" /> indique généralement aux moteurs de recherche "si quelqu'un recherche le contenu de cette page, utilisez l'URL ...".
Une redirection 301 indique aux moteurs de recherche ET aux navigateurs "Hé, la page que vous recherchez a été déplacée de manière permanente vers l'URL située sur ....".
Considérez que vous avez une page de produit sur example.com/product.php et qu’elle est disponible en 3 couleurs différentes: bleu, noir et rouge. Supposons que lorsque l'utilisateur sélectionne une couleur, la page s'actualise pour afficher une image du chapeau dans la couleur choisie et pour ce faire, l'URL devient example.com/product.php?color=blue de sorte que la page sache à quelle image de couleur s'afficher. spectacle.
Maintenant, quand un robot de recherche arrive, il verra 4 URLs pour cette page, example.com/product.php, example.com/product.php?color=blue, example.com/product.php?color=black, example.com/product.php?color=red. Google ne sait pas qu'il s'agit de "variantes" de la même page, mais suppose que chacune d'elles est une page distincte, car chacune a une URL unique. Et quand il explore ces 4 pages, il verra que le contenu ne change pas (sauf pour l'image). Cela signifie que le contenu des quatre pages est fondamentalement identique, et vous devez donc les classer dans la catégorie "contenu en double".
Pour résoudre ce problème, indiquez une URL canonical dans le product.php du <head> pour indiquer à Google que example.com/product.php est la page à laquelle Google doit envoyer les utilisateurs. Pour que cela soit correctement implémenté, la canonical de chacune des "variantes" doit également pointer sur la même URL, et non sur l'URL de la variante.
Maintenant, d'un point de vue strictement SEO/bot, vous pouvez utiliser les redirections 301 pour accomplir la même chose. Chaque fois que Googlebot se rend sur l'une de vos pages de variantes (example.com/product.php?color=blue), votre serveur indique à Googlebot que cette page a été définitivement déplacée vers example.com/product.php et Google finit par désindexer les pages de variantes. conservez la page "principale" de product.php dans son index.
Le problème vient toutefois lorsque les utilisateurs réels visitent la page. Étant donné que les navigateurs suivent les redirections 301, et non les URL canoniques, chaque fois qu'un utilisateur accède à cette page et tente de sélectionner une couleur pour afficher le chapeau sympa en rouge en accédant à example.com/product.php?color=red, votre serveur renvoie une redirection 301 vers example.com/product.php, et votre navigateur accédera à cette URL. Comme vous pouvez le constater, le problème est que l'utilisateur ne pourrait jamais voir les pages de variantes.
Une autre façon de penser est que la balise canonical est une "suggestion", tandis que la redirection 301 est davantage un "ordre". Les navigateurs et les robots suivront toujours les redirections 301. Les robots utiliseront la canonical pour déterminer les URL à indexer et celles à ignorer. Votre navigateur ignorera généralement le canonical car il n’est pas pertinent pour son travail.
Le TL; DR réponse:
1 redirect - Version technique de "Bonjour, je n'utilise plus /requested-url, mais plutôt /this-new-url. Veuillez mettre à jour vos informations en conséquence."
Canonical - Dites aux robots: "Bonjour. Pour cette page, je préfère /this-url comme URL. Si vous avez indexé cette page avec une autre URL, veuillez ne pas tenir compte de celle-ci et utilisez celle-ci. .
Une chose qui fait la différence entre une page à étiquette canonique et une redirection 301 est le code HTML initial que vous voyez.
Disons que vous avez ces deux URL:
http://example.com/duplicate
http://example.com/original
... et vous utilisez une redirection 301 de la première URL à la seconde.
Si vous analysez les résultats dans un navigateur Web ordinaire, vous devriez voir une page indiquant que la page s'est déplacée avec le mot "ici" en tant que lien hypertexte vers la nouvelle page ou quelque chose de similaire.
J'utilise l'outil de ligne de commande CURL pour tester certaines pages. Sur les pages de redirection, le code HTML suivant est affiché:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://example.com/newurl">here</a>.</p>
</body></html>
De plus, j'ai lancé CURL -I pour voir les en-têtes de la redirection, et le résultat est:
HTTP/1.1 301 Moved Permanently
Date: Sat, 30 May 2015 17:47:32 GMT
Server: Apache
Location: http://example.com/newurl
Content-Type: text/html; charset=iso-8859-1
En ce qui concerne les pages étiquetées comme canoniques, vous ne verrez jamais le code d'état déplacé ni le message de la page déplacée comme ci-dessus.
Chaque voie a ses avantages et ses inconvénients.
Si vous utilisez canonique, l'avantage est qu'il peut y avoir moins de requêtes sur le serveur, car deux pages sont dupliquées et il y a peu de chance que l'autre regarde en double, en particulier si elle n'est publiée dans aucun sitemap soumis à un moteur de recherche.
L'inconvénient est que rel=canonical pourrait être quelque chose que certains moteurs de recherche ne comprennent toujours pas et, par conséquent, votre classement pourrait être affecté par ces moteurs de recherche. De même, si le contenu des pages affectées change au point où deux pages ne sont plus dupliquées ou liées, l'utilisation de rel=canonical risque de vous gêner, en fonction de la façon dont Google le perçoit.
Je préfère le faire via la redirection 301.
L'avantage de 301 est que les utilisateurs sont déplacés vers la page correcte et que l'URL du navigateur Web des clients est mise à jour pour afficher la nouvelle URL à la place de l'ancienne. En outre, tous les moteurs de recherche du monde seront satisfaits de cette méthode, car les redirections 301 ne sont pas nouvelles, contrairement à rel = canonical.
L'inconvénient est qu'une demande supplémentaire est nécessaire pour terminer la redirection et que, dans les navigateurs Web normaux, la demande est souvent automatique, car la plupart des gens n'aiment pas voir des messages tels que "le document a été déplacé ici".
Ayant tout pesé, je continuerais personnellement avec les redirections 301 et optimiserais mon serveur pour réduire au minimum le temps de latence. Sur un serveur bien optimisé, la fourniture locale du premier octet d'une page avec une redirection 301 ne devrait pas prendre plus de 400 millisecondes.