Faut-il abandonner rel=author pour Schema.org sur vos contenus ?

Pourquoi Google a-t-il abandonné rel=author ?

La balise rel=author permettait de relier un contenu à un profil Google+ d'auteur. Google affichait alors la photo et le nom de l'auteur directement dans les résultats de recherche, créant un lien visuel entre créateur et contenu.

Le problème ? Ce système n'a jamais fonctionné à l'échelle. La majorité des éditeurs ne l'ont jamais implémenté correctement, et Google+ n'a jamais atteint la masse critique nécessaire. Mueller confirme que Google avait déjà cessé d'exploiter cette balise bien avant la fermeture officielle du réseau social.

Quelle est la différence entre rel=author et Schema.org ?

Contrairement à rel=author qui reposait sur une infrastructure Google propriétaire, Schema.org est un standard ouvert maintenu par un consortium (Google, Microsoft, Yahoo, Yandex). Il permet de structurer l'information auteur directement dans le code HTML via JSON-LD, microdata ou RDFa.

Schema.org offre une granularité bien supérieure. Vous pouvez spécifier le type d'auteur (Person ou Organization), ajouter des propriétés comme sameAs pour lier aux réseaux sociaux, indiquer jobTitle, ou encore relier plusieurs co-auteurs via un tableau. Rien de tout ça n'était possible avec rel=author.

Google utilise-t-il réellement ces données pour le classement ?

Mueller ne le dit pas explicitement, et Google reste volontairement flou sur ce point. Plusieurs brevets mentionnent l'« author authority » comme signal potentiel, mais aucune confirmation officielle n'a jamais été donnée sur son utilisation active dans l'algorithme de ranking.

Ce qui est certain : les données structurées auteur alimentent les rich snippets (affichage du nom d'auteur dans les SERP), le Knowledge Graph, et probablement les systèmes de compréhension du contenu liés à E-E-A-T. Ignorer Schema.org auteur, c'est renoncer à ces affichages enrichis qui impactent le CTR.

• rel=author est mort : toute implémentation encore active ne sert strictement à rien et peut être retirée sans risque
• Schema.org Article + propriété author : c'est le standard actuel recommandé par Google pour structurer l'information d'auteur
• JSON-LD privilégié : Google préconise ce format pour sa maintenabilité et sa séparation du HTML de contenu
• Lien avec E-E-A-T probable mais non confirmé : les données auteur structurées peuvent influencer la perception de l'expertise et de l'autorité d'un site
• Impact mesurable sur le CTR : l'affichage du nom d'auteur dans les SERP modifie le taux de clic, surtout dans les niches YMYL

Cette déclaration masque-t-elle des zones grises ?

Mueller reste prudent sur un point crucial : aucune indication précise sur le poids réel de Schema.org auteur dans l'algorithme de classement. Il confirme que Google veut ces données, mais ne dit jamais explicitement si elles influencent directement le ranking ou servent uniquement à l'affichage des SERP.

Nos observations terrain suggèrent que l'impact est indirect mais mesurable. Sur des requêtes YMYL (santé, finance, juridique), les sites avec auteurs structurés Schema.org bien reliés à des profils externes crédibles (LinkedIn, Twitter, sites institutionnels) tendent à mieux performer. Corrélation n'est pas causalité, mais le pattern est récurrent. [À vérifier] : est-ce que Schema.org auteur alimente directement les systèmes d'évaluation E-E-A-T ou seulement les rich snippets ?

Tous les sites sont-ils concernés de la même façon ?

Soyons honnêtes : un site e-commerce pur n'a aucun besoin de baliser des auteurs sur ses fiches produits. Schema.org Product suffit amplement. En revanche, un site éditorial (blog, média, plateforme de contenu UGC) qui ignore le balisage auteur passe à côté d'opportunités d'affichage et probablement de signaux E-E-A-T.

La nuance se situe dans les sites hybrides : marketplace avec blog intégré, SaaS avec centre de ressources, etc. Là, il faut segmenter. Articles de fond et guides nécessitent un balisage auteur rigoureux. Pages commerciales transactionnelles, non. Malheureusement, beaucoup de CMS appliquent Schema.org Article de façon aveugle à toutes les pages, diluant la pertinence du signal.

Quels risques si on laisse traîner rel=author ?

Techniquement, aucun risque de pénalité. Google ignore simplement la balise. Mais maintenir du code mort dans vos templates, c'est une dette technique inutile. Pire, certains CMS ou plugins WordPress continuent de générer automatiquement ces balises obsolètes, créant du bruit dans le code source.

Le vrai problème : la confusion entre anciens et nouveaux standards. On voit régulièrement des sites qui implémentent à la fois rel=author ET Schema.org auteur, mais avec des informations contradictoires (nom différent, URL de profil qui ne match pas). Google doit alors arbitrer, et rien ne garantit qu'il choisisse la bonne source. Nettoyez vos implémentations.

Comment migrer de rel=author vers Schema.org ?

Première étape : auditer l'existant. Scannez vos templates pour identifier toutes les occurrences de rel=author et rel=me (utilisé pour lier Google+ au site). Supprimez-les intégralement. Vérifiez aussi vos plugins WordPress (Yoast, Rank Math, All in One SEO) : certaines versions anciennes génèrent encore ces balises par défaut.

Ensuite, implémentez Schema.org Article en JSON-LD sur chaque page de contenu éditorial. La propriété author doit pointer vers un objet Person avec au minimum name et url (lien vers la page auteur du site). Ajoutez sameAs pour relier aux profils sociaux crédibles (LinkedIn, Twitter) si l'auteur en possède. Testez avec le Rich Results Test de Google pour détecter erreurs et avertissements.

Quelles erreurs provoquent l'échec du balisage auteur ?

Erreur n°1 : utiliser un objet author vide ou générique. On voit régulièrement des sites qui mettent "Admin" ou "Équipe éditoriale" comme nom d'auteur. Google ne valorisera jamais ça. Si l'auteur est anonyme ou collectif, mieux vaut omettre la propriété plutôt que de la remplir avec du placeholder.

Erreur n°2 : incohérence entre Schema.org et affichage visible. Si le nom affiché dans l'article diffère du name en JSON-LD, Google peut ignorer le balisage. Pareil pour l'URL : la propriété url de l'objet Person doit pointer vers une vraie page auteur indexable, pas un profil social externe en premier choix.

Faut-il créer des pages auteur dédiées même pour les petits sites ?

Oui, si vous avez plusieurs contributeurs réguliers et que vous jouez la carte de l'expertise éditoriale. Une page auteur bien construite (bio, liste des articles, liens vers profils externes, éventuellement photo) renforce la crédibilité E-E-A-T. Elle donne aussi une cible indexable pour la propriété url de Schema.org.

Pour un blog mono-auteur ou un site corporate avec 2-3 articles par an, c'est probablement overkill. Dans ce cas, utilisez la page "À propos" comme URL auteur et assurez-vous qu'elle contient une bio substantielle et des liens vers des preuves de crédibilité (LinkedIn, publications externes, certifications).

• Supprimer toute occurrence de rel=author et rel=me des templates et plugins
• Implémenter Schema.org Article avec propriété author (type Person) sur les pages éditoriales
• Créer des pages auteur dédiées indexables avec bio et liste des publications
• Relier author.sameAs aux profils sociaux crédibles (LinkedIn prioritaire)
• Vérifier la cohérence nom/URL entre JSON-LD et affichage visible dans l'article
• Tester chaque implémentation avec Rich Results Test et corriger les erreurs détectées