Schema offre d'emploi et ATS : où poser le JSON-LD

Pour une offre d'emploi affichée via un ATS (Workday, SmartRecruiters, HelloWork, Taleo, Welcome to the Jungle, iCIMS et consorts), le balisage schema.org/JobPosting doit être posé sur la page effectivement indexée par Google, pas nécessairement sur la page carrière de votre site principal. C'est là que la plupart des implémentations françaises échouent : le service marketing balise consciencieusement /carrieres/nom-du-poste sur le domaine de l'entreprise, alors que Google explore, indexe et affiche dans son expérience "Offres d'emploi" l'URL réelle du sous-domaine ou de la page hébergée par l'ATS.

Cet article couvre trois points précis, sans reprendre ce qui a déjà été traité ailleurs sur le blog : où le JSON-LD doit physiquement vivre selon l'architecture technique choisie, la relation de canonical entre votre page carrière et la page de l'ATS, et la duplication, légitime mais mal gérée, avec Indeed, HelloWork et les autres jobboards qui reçoivent la même annonce par multiposting.

Repérer où vit réellement votre annonce

Avant de décider où placer le balisage, il faut identifier la page que Google indexe réellement, ce qui suppose de distinguer trois architectures courantes sur le marché français.

Le sous-domaine dédié, du type carrieres.entreprise.com ou jobs.entreprise.com, est en réalité un site à part entière géré par l'ATS. Même si le nom de domaine rassure, le HTML, le template et le contrôle technique appartiennent au prestataire, pas à vous.

L'iframe embarqué est la configuration la plus trompeuse : votre page /carrieres affiche visuellement l'annonce, mais celle-ci est en fait chargée depuis un document distinct servi par l'ATS, avec sa propre URL. Ce que l'internaute voit et ce que Google indexe ne sont pas la même chose.

Le widget en JavaScript réécrit le contenu de votre page carrière après le chargement initial, sans changer l'URL affichée. Le texte de l'annonce n'existe pas dans le HTML source, seulement après exécution du script.

• Ouvrez l'outil d'inspection d'URL dans Search Console sur la page carrière et regardez le HTML tel que Google l'a récupéré : le texte de l'annonce y figure-t-il, ou seulement un conteneur vide ?
• Comparez l'URL affichée dans les résultats "Offres d'emploi" de Google avec celle de votre page carrière : un domaine ou un chemin différent signale que c'est l'ATS qui est indexé.
• Désactivez temporairement JavaScript et rechargez la page : si l'annonce disparaît, le contenu est injecté côté client et absent du HTML initial.

Pourquoi cette distinction change tout pour le balisage

Confondre ces trois cas coûte cher, mais silencieusement : rien n'affiche d'erreur bloquante dans l'outil de test des résultats enrichis lancé sur la mauvaise URL, il se contente de ne rien trouver à valider ou de valider un balisage qui ne décrit, en pratique, aucun contenu visible pour un vrai visiteur humain sur cette page précise. L'équipe marketing continue de croire que "le balisage est en place" pendant des semaines, parce que le code source contient bien un bloc JSON-LD JobPosting quelque part sur le site.

Le seul indicateur fiable n'est ni le code source de votre CMS ni la documentation de l'ATS, mais le comportement observé dans Search Console : quelle URL exacte Google associe-t-il à l'offre lorsqu'il la fait remonter dans l'expérience "Offres d'emploi", et cette URL contient-elle, dans le rendu qu'il a récupéré, le texte que le balisage prétend décrire. Toute décision d'implémentation qui suit doit se fonder sur cette URL-là, pas sur l'URL que vous auriez préféré voir indexée.

Où poser le JSON-LD quand le contenu est dans un iframe

Les consignes de Google sur les données structurées reposent sur un principe simple : le balisage doit être une représentation fidèle du contenu visible de la page qui le porte. Si le JobPosting est déclaré dans l'en-tête de votre page carrière, mais que le texte de l'annonce n'existe, lui, que dans le document chargé par l'iframe, votre page ne "contient" pas réellement ce qu'elle prétend baliser au sens où les outils de validation l'évaluent. Le résultat est au mieux un rich result qui échoue silencieusement à la validation, au pire un signal jugé non conforme au contenu réel de la page.

La correction logique découle du diagnostic : le balisage appartient au document qui sert réellement le texte, c'est-à-dire l'URL chargée dans l'iframe, pas à la page qui l'encadre. Si vous ne contrôlez pas ce gabarit, deux options existent. La première consiste à activer le générateur de JobPosting intégré à l'ATS lorsqu'il existe : la plupart des suites SaaS récentes en proposent un, mais il n'est pas toujours activé par défaut et se cache souvent dans des paramètres SEO peu documentés. La seconde consiste à restructurer la page carrière pour qu'elle héberge elle-même le texte complet de l'offre, l'iframe devenant alors un composant secondaire, par exemple réservé au seul formulaire de candidature.

Un point technique aggrave souvent le problème : l'URL chargée dans l'iframe est parfois exclue par le robots.txt de l'ATS, précisément parce qu'elle n'a jamais été pensée pour être indexée seule, uniquement affichée en widget. Dans ce cas, même si vous vouliez vérifier la cohérence entre balisage et contenu réel, Googlebot lui-même ne peut pas explorer la source pour la confirmer, ce qui fragilise davantage la légitimité du balisage placé côté parent.

Le canonical entre la page carrière et la page ATS

Le rel=canonical signale à Google quelle URL préférer parmi plusieurs versions proches d'un même contenu. Le problème, ici, est que la page carrière et la page ATS sont souvent deux pages bien réelles, en ligne, avec un texte quasi identique, et non une simple variante technique (paramètres d'URL, version imprimable) comme dans le cas d'école habituel.

Deux architectures cohérentes existent, et il faut en choisir une plutôt que de les mélanger. Dans la première, la page carrière porte le texte complet de l'annonce et le balisage JobPosting, se déclare canonique sur elle-même, et ne fait qu'un lien classique, pas un iframe, vers le formulaire de candidature hébergé par l'ATS. Dans la seconde, la page carrière reste volontairement un résumé court qui renvoie vers l'ATS pour le détail complet : dans ce cas, ne posez ni balisage complet ni canonical auto-référent sur cette page résumée, car un contenu mince associé à un rich result est précisément le genre de configuration qui attire une vérification manuelle.

L'erreur la plus fréquente consiste à copier le même JSON-LD sur les deux pages tout en laissant chacune se déclarer canonique de son côté. Vous obtenez alors deux versions indexables et concurrentes de la même offre, que Google devra départager lui-même, avec un résultat imprévisible et des signaux dilués des deux côtés. Décidez une seule URL de référence par poste, et gardez cette décision cohérente dans le sitemap, les liens internes et toute soumission à des agrégateurs.

La duplication face à Indeed, HelloWork et consorts

Le multiposting est la norme, pas l'exception, sur le marché français : une seule saisie dans l'ATS pousse automatiquement l'annonce vers Indeed, HelloWork, Welcome to the Jungle, LinkedIn ou France Travail. Un texte quasi identique existe donc légitimement sur une demi-douzaine de domaines que vous ne contrôlez pas, et la déduplication classique par canonical est sans effet ici : Indeed ne va pas pointer un canonical vers votre site.

Il faut distinguer deux mécanismes bien séparés. Le classement organique classique traite chaque domaine comme une entité indépendante et ne fusionne rien automatiquement. L'expérience "Offres d'emploi" de Google, elle, applique une logique différente : elle tente de repérer que plusieurs fiches décrivent le même poste, en s'appuyant sur des signaux comme le nom de l'organisation employeuse, l'intitulé et le lieu, puis regroupe ces sources pour présenter plusieurs options de candidature au chercheur d'emploi plutôt que de classer une source au-dessus des autres.

Concrètement, cela signifie que lutter contre la duplication elle-même est moins utile que de garantir la cohérence des champs structurés à travers toutes les copies syndiquées, pour que Google reconnaisse effectivement votre annonce comme une source légitime du même poste plutôt que comme une fiche orpheline mal appariée.

• Le nom de l'organisation dans hiringOrganization doit être écrit à l'identique sur toutes les copies, sans variante ("Société X" contre "Société X SAS").
• Le lieu doit suivre un format cohérent, idéalement avec la même granularité (ville, code postal) sur chaque plateforme.
• Un décalage de quelques jours dans datePosted entre les copies, dû au délai de propagation du multiposting, est courant et généralement toléré, mais un écart de plusieurs semaines mérite une vérification.
• Le type de contrat doit correspondre à la même valeur logique d'une plateforme à l'autre, même si le libellé affiché diffère légèrement.

Ce que vous pouvez modifier dépend de votre ATS

Toutes les plateformes ne se valent pas sur ce terrain. Certaines proposent un module de site carrière personnalisable, capable d'injecter automatiquement un JobPosting par fiche de poste si l'option est activée dans les paramètres SEO. D'autres, en particulier les instances par défaut des grandes suites d'entreprise sans module carrière dédié, ne donnent accès qu'à une charte graphique (logo, couleurs) sans aucun accès à l'en-tête HTML des pages générées.

• Si votre ATS propose un module de site carrière personnalisable, vérifiez d'abord dans ses paramètres SEO s'il existe déjà un générateur de balisage JobPosting avant de tenter un contournement manuel : il est souvent présent mais désactivé par défaut.
• Si l'accès au thème est limité, demandez directement au fournisseur si une fonctionnalité de balisage structuré existe côté produit, même si elle n'est pas visible dans l'interface standard.
• Si aucun accès n'est possible, la seule option robuste reste de rapatrier le texte complet de l'annonce sur une page que vous contrôlez entièrement, puis d'y poser vous-même le balisage.
• Après tout changement de fournisseur d'ATS, revérifiez systématiquement le balisage : une migration casse fréquemment l'implémentation existante sans que personne ne s'en aperçoive avant plusieurs semaines.

Hygiène de datePosted et validThrough

Les ATS recyclent fréquemment leurs URL : le même identifiant de poste peut être réattribué à une nouvelle offre une fois l'ancienne pourvue, ou l'URL expirée redirige vers une page générique "poste non disponible". Si votre page carrière, elle, continue d'afficher l'ancien contenu ou un ancien balisage avec un validThrough déjà dépassé, vous créez une incohérence entre le balisage et la réalité de la page, exactement le type de signal que les systèmes de validation des données structurées sont censés repérer.

Le traitement correct est simple à énoncer mais souvent négligé dans le processus : une offre close doit renvoyer un vrai code 404 ou 410 si la page disparaît, ou voir son balisage JobPosting retiré si la page reste en ligne à titre d'archive. Ce qu'il ne faut pas faire, c'est laisser une page en code 200 avec un validThrough déjà passé pendant que l'ATS a clôturé le poste depuis longtemps de son côté. Si votre processus repose sur "l'ATS ferme le poste automatiquement, puis quelqu'un pense à mettre à jour le site deux semaines plus tard", ce délai est le vrai problème, même si personne ne le formule ainsi en interne.

• Retirez le balisage JobPosting dès la clôture réelle du poste, pas au prochain passage de mise à jour du site.
• Ne laissez jamais un validThrough dans le passé sur une page encore indexée avec un code 200.
• Si l'ATS et le site sont deux systèmes séparés, assurez-vous que la clôture d'un poste dans l'un déclenche bien une action dans l'autre, plutôt que de compter sur une mise à jour manuelle.

Checklist avant de publier une offre balisée

• Identifiez l'URL réellement indexée via l'inspection d'URL de Search Console avant de décider où placer le JSON-LD.
• Vérifiez que le contenu visible sur cette URL précise contient effectivement tout ce que décrit le balisage : intitulé, description complète, lieu, type de contrat.
• Choisissez une seule page canonique par poste et respectez ce choix dans le sitemap et les liens internes.
• Alignez hiringOrganization, jobLocation et datePosted avec les copies syndiquées sur Indeed, HelloWork et LinkedIn.
• Programmez le retrait du balisage, ou la sortie propre de l'URL, au moment exact de la clôture du poste, pas une semaine après.
• Retestez systématiquement avec l'outil de test des résultats enrichis après toute migration d'ATS ou changement de gabarit de page carrière.