SEO • Données structurées

Quand utiliser le schema JobPosting pour une offre d’emploi ?

Utilisez JobPosting uniquement pour une véritable offre d’emploi, renseignez les propriétés utiles et gardez le balisage cohérent avec le contenu visible.

Par l’équipe Limpi. Les faits externes sont distingués des méthodes Limpi et aucune visibilité, position ou citation automatique n’est garantie.

Réserver JobPosting aux véritables offres d’emploi

JobPosting sert à décrire une offre d’emploi identifiable. Une page carrière générale, une présentation de l’entreprise ou un formulaire de candidature spontanée ne devient pas une offre simplement parce qu’elle parle de recrutement. Avant de baliser, vérifiez qu’un poste précis est proposé et que les informations affichées correspondent à cette offre. Sur la page Limpi qui explique le schema, le type reste WebPage : elle décrit JobPosting sans être elle-même une annonce de recrutement.

Définir une source unique pour les informations de l’offre

Le titre du poste, le lieu, l’employeur, la description et les autres propriétés doivent provenir des mêmes données que la page visible. Évitez de maintenir un JSON-LD séparé qui peut conserver un ancien intitulé après modification de l’annonce. Si le recrutement est géré dans un ATS, vérifiez la synchronisation avec le site. Une source unique réduit les écarts entre ce que lit le candidat et ce que décrit le balisage structuré.

Distinguer une offre active d’une archive

Lorsqu’un poste n’est plus ouvert, la page et les données structurées doivent refléter cette situation. Ne laissez pas un JobPosting ancien actif indéfiniment pour conserver une URL. Définissez une politique de fermeture, d’archivage ou de redirection adaptée au contenu. Si la page devient une présentation générique du métier sans poste disponible, son type de donnée structurée doit être réévalué. Le cycle de vie de l’offre fait partie de la qualité du balisage.

Vérifier les lieux et modalités réellement proposés

Les informations de localisation, télétravail ou type d’emploi doivent correspondre à l’offre publiée et ne pas être ajoutées pour élargir artificiellement sa portée. Une annonce multi-sites mérite une modélisation cohérente avec les lieux effectivement disponibles. Relisez la page comme un candidat : les données structurées ne devraient pas révéler des conditions absentes du texte ni contredire les modalités indiquées par les ressources humaines.

Ne pas confondre schema valide et garantie de diffusion

Un objet JobPosting conforme au vocabulaire Schema.org décrit correctement une offre, mais cela ne garantit pas une présentation particulière dans un moteur. Les plateformes peuvent imposer des critères supplémentaires et modifier leurs fonctionnalités. Le rôle de votre audit est d’abord de vérifier la fidélité de la donnée structurée au contenu réel. Toute promesse d’apparition automatique serait trop forte et détournerait le balisage de sa fonction descriptive.

Tester plusieurs annonces et le template commun

Validez le JSON-LD sur une offre récente, une offre avec localisation différente et une annonce proche de sa clôture. Comparez les propriétés générées. Une erreur de mapping dans le template peut affecter toutes les annonces. Contrôlez aussi les URLs d’employeur ou de candidature lorsqu’elles sont utilisées par votre système. Le test doit chercher les valeurs dupliquées, vides ou héritées d’une offre précédente, pas seulement une erreur de syntaxe JSON.

Synchroniser suppression et mise à jour du balisage

Quand le recruteur modifie ou ferme une offre, le schema doit évoluer dans le même déploiement ou la même opération CMS. Évitez les caches qui servent longtemps une ancienne version structurée. Si une page est redirigée, vérifiez que l’ancienne donnée structurée ne reste pas accessible dans une copie. Une procédure de publication bien conçue traite le contenu visible, l’URL et le balisage comme les différentes représentations d’une même offre.

Documenter le modèle pour les équipes recrutement

Les personnes qui publient les annonces doivent savoir quelles données alimentent le schema et quelles valeurs sont obligatoires dans votre propre système. Fournissez des champs structurés plutôt que demander de modifier du JSON-LD manuellement. Signalez les annonces incomplètes avant publication et conservez un contrôle périodique des offres actives. Cette organisation limite les incohérences lorsque plusieurs recruteurs ou outils interviennent sur le même site.

Clôturer le contrôle sur Schema.org JobPosting

Pour clôturer ce contrôle, conservez une URL représentative, le constat initial, la cause identifiée, la modification appliquée et le résultat du test après correction. Sur un motif répété, notez aussi le nombre d’occurrences avant et après afin de distinguer une résolution globale d’un exemple isolé. Vérifiez la cohérence avec les pages liées /seo/donnees-structurees, /seo/quel-schema-org-utiliser, /seo/schema-localbusiness et assurez-vous qu’aucune nouvelle contradiction n’a été créée dans le template, le maillage ou la configuration concernée. Présenter JobPosting comme type décrivant une véritable offre d’emploi. Ne pas conseiller de baliser une page générique de carrière ou un contenu éditorial comme une offre inexistante. Si plusieurs équipes interviennent, attribuez la correction à une source précise — CMS, template, build, contenu ou configuration — et documentez les exceptions volontaires. Rejouez le contrôle avec les mêmes critères lors d’une prochaine migration ou refonte. Une anomalie ambiguë doit rester en revue plutôt qu’être corrigée automatiquement : la fermeture de l’alerte doit reposer sur une preuve reproductible et sur le comportement réellement servi au public. Pour Schema.org JobPosting, ajoutez enfin un contrôle sur un second gabarit ou un second état afin de vérifier que la règle ne dépend pas d’un seul exemple. Comparez le résultat au besoin décrit par « Quand utiliser le schema JobPosting pour une offre d’emploi ? » et conservez dans le rapport la raison pour laquelle la correction choisie respecte l’intention de cette URL. Cette vérification complémentaire donne un point de comparaison utile si le même motif réapparaît après une mise à jour du CMS ou du design system.

Sources officielles

Les règles des moteurs et des fournisseurs de crawlers peuvent évoluer. Les affirmations techniques de cette page sont bornées par les documentations officielles ci-dessous.