Pourquoi un mauvais schema est pire que pas de schema, avec Peter Macinković, Head of SEO de Stake

Les données structurées sont souvent vues comme un travail d'étiquetage, mais Peter Macinković, Head of SEO de Stake, y voit un moyen de décrire les relations entre entités. Dans cet entretien du podcast d'Odys, il explique comment fonctionne le schema sur un site de milliers de jeux de casino et de matchs, et quelles erreurs il observe.

Dans cet épisode

• Il dit que le schema doit énoncer le contexte explicitement au lieu de laisser Google deviner ; le traiter comme un simple étiquetage ignore la façon dont le graphe de connaissances relie les choses (2:30, 5:01).

• L'erreur courante est de courir après les rich results : ajouter un balisage FAQ à une page de catégorie peut transformer une intention commerciale en intention informationnelle et nuire au classement (5:31, 6:00, 6:30).

• Pour les matchs dont la durée de vie est d'un jour ou d'une semaine, il utilise le balisage d'événements sportifs, disant que même la cinquième position peut obtenir le même taux de clics que la première (8:00, 8:30).

• Il construit des blocs Organization, WebSite et WebPage qui se référencent par @id et les réutilise partout, y voyant techniquement le schema le plus important de chaque page (9:01, 9:31, 10:00).

• Il qualifie subjectOf de propriété la plus sous-estimée, qui relie des articles externes à une page, et dit que Stake reste numéro un pour les jeux d'argent en ligne sans le cibler (11:00, 12:00, 12:32).

• Le schema est généré par type de page, environ 12 ou 13 chez Stake, avec du JSON manuel fusionné via @id et testé dans Screaming Frog et sur les états d'échec (14:01, 15:00, 15:32, 18:32).

Entretien d'Odys Podcast: The High Stakes Growth Show par Odys, publié sur YouTube.