Envoyez un en-tête de lien canonical au lieu d’un en-tête noindex.
L’envoi d’un en-tête canonical présente probablement le même avantage sur le budget d’exploration que l’envoi d’un en-tête noindex, sans les implications SEO de l’exclusion d’URL qui pourraient avoir des backlinks via noindex.
Si vous pouvez configurer votre serveur, vous pouvez utiliser un en-tête HTTPrel="canonical" (plutôt qu’une balise HTML) pour indiquer l’URL canonique d’un document pris en charge par la recherche, y compris les documents non HTML tels que les fichiers PDF.
Nous pouvons configurer notre serveur.
Est-ce que utiliser un en-tête HTTP rel="canonical" plutôt qu'une balise HTML souligne une préférence pour la solution d’en-tête HTTP ?
Googlebot gère les en-têtes no-index de manière très élégante. Il est conseillé de laisser autant de routes que possible ouvertes et utilise les en-têtes pour des règles de haute fidélité concernant les index.
Peut-être que Google gère les en-têtes de lien canonical aussi élégamment que les en-têtes no-index.
J’ai du mal avec ça, à lire la recommandation de Google, il semble qu’il ne s’en soucie pas particulièrement.
Les recommandations pour l’en-tête HTTP rel="canonical" sont les mêmes que pour la balise linkrel="canonical".
Je suppose qu’il n’y a pas grand-chose à perdre et il est possible qu’un mélange de no index et de rel canonical soit la bonne recette Google. Mais je ne suis pas sûr.
Cela annule le paramètre de site récemment introduit pour ce qui est essentiellement une opération nulle (déplacement de ce que nous envoyons comme balise d’en-tête dans un en-tête, sans changement sémantique).
Pour le nouveau paramètre par défaut SiteSetting.allow_indexing_non_canonical_urls = false, voici comment il est implémenté actuellement - et il reste ainsi :
en-tête noindex
balise html canonical (peut être ignorée)
Sans patch et avec SiteSetting.allow_indexing_non_canonical_urls = true
– pas d’en-tête –
balise html canonical
Avec patch et SiteSetting.allow_indexing_non_canonical_urls = true
balise html canonical (peut être ignorée - mais de toute façon identique à l’en-tête)
L’idée derrière tout cela :
Définir canonical comme en-tête http pour obtenir le même avantage que l’en-tête httpnoindex - à savoir un crawl plus rapide.
Cela pourrait rendre noindex obsolète avec ses implications incertaines.
Un autre point sur noindex vs canonical :
noindex est plus qu’un signal très fort pour ne pas mettre la page dans l’index de recherche.
Mais avec noindex, le contenu de la page est toujours traité par Google Bot pour extraire les liens (il existe l’option supplémentaire nofollow pour désactiver cela).
canonical est un signal fort que le contenu à crawler se trouve sur une autre URL canonique.
Dans le cas où Google Bot décide d’accepter ce signal pour une page, il y a de fortes chances qu’il ne traite pas du tout le contenu de la page - et ne traite que l’URL canonique.
Ceci est une ‘expérience de pensée’. Ce n’est implémenté nulle part - et je ne recommande jamais de l’implémenter :
en-tête noindex
balise meta html noindex (au lieu de : balise link html canonical)
– OU –
– pas d’en-tête –
balise meta html noindex
Pourquoi implémenter ou ne pas implémenter cela comme ça ?
Ce changement n’est pas un ‘noop’ :
Google peut gérer les en-têtes et le contenu HTML à différentes étapes de ses files d’attente de traitement. En envoyant des en-têtes, nous pourrions sauter d’autres files d’attente de traitement (par exemple, la file d’attente de rendu) et ainsi libérer du budget d’exploration pour des pages plus importantes.
Je ne suis pas fortement opposé à cela, mais cela me semble si mineur. Google télécharge toujours du contenu de nos jours, je doute que la sauvegarde d’une analyse HTML fasse une réelle différence matérielle.
De nombreux autres domaines nécessitent une attention particulière, les microdonnées sont probablement le premier endroit qui a besoin d’un coup de pouce.
Nous pouvons configurer notre serveur.