Qu'est-ce que l'encart Google Jobs, et est-ce gratuit
L'encart Google Jobs est une mise en forme spéciale des résultats de recherche qui regroupe les offres d'emploi trouvées sur le web, avec logo de l'entreprise, lieu, type de contrat et lien direct vers la page d'origine. Google le décrit comme une expérience qui va « au-delà du lien bleu standard » pour les recherches liées à l'emploi (Google Developers, documentation JobPosting). L'accès à cet encart est gratuit : ajouter les données structurées appropriées rend une offre éligible à cet affichage, sans frais ni enchère. Aucune mention de paiement n'apparaît dans la documentation officielle.
Concrètement, chaque offre qui respecte les règles décrites plus bas peut apparaître dans cet encart, qu'elle vienne d'une grande entreprise, d'un cabinet de recrutement ou d'une PME. La visibilité ne dépend pas d'un budget publicitaire mais de la qualité technique de la page et du balisage.
La condition technique : une page par offre, lisible par Googlebot
Chaque offre doit disposer de sa propre page, et le balisage JobPosting doit être posé sur cette page précise, pas sur une page qui liste plusieurs postes. Google est explicite : « Put structured data on the most detailed leaf page possible. Don't add structured data to pages intended to present a list of jobs » (Google Developers, documentation JobPosting). Une page « toutes nos offres » avec un tableau récapitulatif ne peut donc pas porter le balisage : il faut une URL dédiée par poste.
Cette page doit être accessible à Googlebot sans obstacle : pas de blocage dans le robots.txt, pas de balise noindex, pas de connexion obligatoire pour la consulter. Si plusieurs URL affichent la même offre, une balise canonique doit indiquer laquelle est la version de référence. C'est la même logique que pour une fiche de poste bien structurée : un contenu unique, à une adresse stable, que le robot peut lire sans authentification.
Les propriétés obligatoires du balisage JobPosting
Cinq propriétés sont obligatoires dans le balisage JobPosting, selon la documentation Google : title, description, datePosted, hiringOrganization et jobLocation. Sans l'une d'elles, l'offre n'est pas éligible à l'encart.
| Propriété | Contenu attendu |
|---|
| title | Titre du poste, par exemple « Software Engineer » |
| description | Description complète du poste en HTML, avec responsabilités et qualifications |
| datePosted | Date de publication d'origine, au format ISO 8601 |
| hiringOrganization | L'organisation qui recrute, pas le lieu |
| jobLocation | Le lieu physique où la personne travaillera |
La description doit être complète : la documentation Google interdit explicitement les descriptions incomplètes. Une annonce qui renvoie vers un PDF externe ou qui se contente d'un intitulé sans détail ne respecte pas cette exigence.
Les propriétés recommandées qui font la différence
Sept propriétés recommandées enrichissent l'affichage et améliorent l'éligibilité aux filtres de recherche, d'après la documentation Google : employmentType, validThrough, baseSalary, jobLocationType, applicantLocationRequirements, directApply et identifier.
| Propriété | Rôle |
|---|
| employmentType | Type de contrat : FULL_TIME, PART_TIME, CONTRACTOR, TEMPORARY, INTERN, VOLUNTEER, PER_DIEM ou OTHER |
| validThrough | Date d'expiration de l'offre, au format ISO 8601 |
| baseSalary | Salaire de base réel proposé par l'employeur |
| jobLocationType | Valeur TELECOMMUTE quand le poste est en télétravail à 100 % |
| applicantLocationRequirements | Zones géographiques éligibles ; devient obligatoire dès que jobLocationType vaut TELECOMMUTE |
| directApply | Booléen indiquant si la candidature peut se faire directement, sans redirection |
| identifier | Identifiant unique de l'offre, utile pour la suivre dans le temps |
validThrough mérite une attention particulière : c'est la date qui permet à Google de retirer automatiquement une offre expirée, avant même que quelqu'un intervienne manuellement. La laisser vide ou obsolète, c'est compter sur une intervention manuelle pour chaque poste pourvu.
baseSalary reste réservé au salaire réel fixé par l'employeur : la documentation précise que cette propriété est destinée à l'employeur, pas à une estimation de marché. Un cabinet qui diffuse pour un client ne doit renseigner cette propriété que si le client a validé le montant affiché.
Un exemple de balisage JobPosting correct
Un balisage minimal correct combine les cinq propriétés obligatoires et les propriétés recommandées pertinentes pour le poste. Voici deux exemples construits strictement à partir des propriétés listées dans la documentation Google, pour un poste sur site à Casablanca et un poste en télétravail à Lyon.
Poste sur site, Casablanca :
<script type="application/ld+json">
{
"@context": "https://schema.org/",
"@type": "JobPosting",
"title": "Comptable senior",
"description": "<p>Sous la responsabilité du directeur financier, vous tenez la comptabilité générale, préparez les déclarations fiscales et supervisez un assistant comptable. Profil attendu : diplôme en comptabilité, 5 ans d'expérience minimum, maîtrise d'un ERP de gestion.</p>",
"identifier": {
"@type": "PropertyValue",
"name": "Entreprise Exemple (fictive)",
"value": "AC-2026-014"
},
"datePosted": "2026-09-26",
"validThrough": "2026-11-26",
"employmentType": "FULL_TIME",
"hiringOrganization": {
"@type": "Organization",
"name": "Entreprise Exemple (fictive)",
"sameAs": "https://www.example.com"
},
"jobLocation": {
"@type": "Place",
"address": {
"@type": "PostalAddress",
"streetAddress": "Adresse de l'établissement",
"addressLocality": "Casablanca",
"addressCountry": "MA"
}
}
}
</script>
Poste en télétravail, Lyon :
<script type="application/ld+json">
{
"@context": "https://schema.org/",
"@type": "JobPosting",
"title": "Chargé de recrutement",
"description": "<p>Vous gérez le sourcing, les entretiens de préqualification et le suivi des candidatures pour plusieurs clients du cabinet. Poste ouvert en télétravail complet, rattachement à l'équipe basée à Lyon.</p>",
"identifier": {
"@type": "PropertyValue",
"name": "Cabinet Exemple (fictif)",
"value": "RT-2026-031"
},
"datePosted": "2026-09-26",
"validThrough": "2026-11-26",
"employmentType": "FULL_TIME",
"directApply": true,
"jobLocationType": "TELECOMMUTE",
"applicantLocationRequirements": {
"@type": "Country",
"name": "FR"
},
"hiringOrganization": {
"@type": "Organization",
"name": "Cabinet Exemple (fictif)",
"sameAs": "https://www.example.org"
},
"jobLocation": {
"@type": "Place",
"address": {
"@type": "PostalAddress",
"addressLocality": "Lyon",
"addressCountry": "FR"
}
}
}
</script>
Ces deux exemples utilisent uniquement les noms de propriétés confirmés par la documentation Google : aucune propriété inventée, aucune valeur de démonstration présentée comme un vrai poste existant.
Les règles de contenu qui font retirer une offre
Une offre conforme sur le plan technique peut quand même être exclue si son contenu viole les consignes de Google. La documentation liste plusieurs cas précis : une offre pour un poste faux ou inexistant, une offre dont le but principal est de collecter des informations sur les candidats, une offre qui usurpe l'identité d'une autre personne ou organisation, un lieu de travail qui ne correspond pas à la réalité, ou un langage grossier ou offensant dans le titre ou la description.
Sont également interdits le bourrage de mots-clés dans le titre ou la description pour manipuler le classement, la publicité déguisée en offre d'emploi, la demande d'un paiement au candidat, et la collecte de CV pour un poste qui n'est pas réellement ouvert. Une offre doit aussi proposer un moyen concret de postuler : pas de simple invitation à un événement, pas de connexion obligatoire pour voir les détails.
Pour un cabinet qui diffuse des dizaines d'offres pour des clients différents, ces règles imposent une discipline : chaque page doit décrire un poste réellement ouvert, avec un lieu exact et une voie de candidature claire, ce qui rejoint les bonnes pratiques déjà nécessaires pour une fiche de poste utilisable par les candidats.
La fonctionnalité est-elle disponible en France et au Maroc
Oui, l'encart Google Jobs est disponible dans les deux pays. La documentation Google liste les pays pris en charge par continent ; la France apparaît dans la liste Europe, et le Maroc dans la liste Afrique du Nord et Moyen-Orient (Google Developers, documentation JobPosting). Un recruteur qui publie une offre depuis Casablanca ou depuis Lyon peut donc viser cet encart avec le même balisage, à condition d'adapter le lieu et, le cas échéant, les règles locales mentionnées dans la description.
Côté demande, un relevé Nooralto via DataForSEO de septembre 2026 mesure environ 27 100 recherches mensuelles en France pour « google jobs » et autant pour « google for jobs », contre environ 1 000 recherches mensuelles au Maroc pour « google jobs ». L'écart de volume ne signifie pas que la fonctionnalité est absente au Maroc : il reflète surtout des habitudes de recherche différentes.
Diffuser via un jobboard ou sur son propre site
Diffuser une offre sur un jobboard ou un ATS externe dispense en général de gérer soi-même le balisage, puisque la plateforme s'en occupe pour les offres qu'elle héberge, mais cela laisse le recruteur dépendant de la qualité technique de cette plateforme et de sa politique de retrait des offres expirées. Diffuser sur son propre site donne un contrôle complet sur le balisage, la vitesse de mise à jour et le retrait d'une offre pourvue, mais demande une page par offre correctement construite et maintenue.
Un jobboard massifie la visibilité auprès d'audiences déjà en recherche active, ce qui convient à des volumes de recrutement élevés. Un site propre valorise la marque employeur et permet de faire remonter chaque offre dans les résultats liés au nom de l'entreprise, ce qui compte pour un cabinet qui construit sa réputation dans la durée. Les deux approches ne s'excluent pas : une offre publiée sur le site du cabinet peut être relayée en parallèle sur un jobboard, tant que chaque version respecte les mêmes règles de contenu et reste à jour.
Comment tester son balisage avant de publier
L'outil de test des résultats enrichis de Google (search.google.com/test/rich-results) permet de vérifier une page avant publication, par URL ou en collant directement le code source. L'outil examine « la page accessible publiquement pour voir quels résultats enrichis peuvent être générés par les données structurées qu'elle contient » et signale les erreurs de balisage détectées.
Une fois la page en ligne, le rapport sur les résultats enrichis de Search Console prend le relais dans la durée : il indique le nombre d'éléments structurés valides et invalides détectés sur le site, distingue les problèmes critiques, qui empêchent l'utilisation des données structurées par Google, des problèmes non critiques, qui n'affectent que l'apparence du résultat. C'est le point de contrôle à consulter régulièrement quand on gère un volume d'offres qui change chaque semaine.
Comment retirer une offre expirée
Trois méthodes permettent de retirer une offre expirée de l'encart Google Jobs, selon la documentation Google : renseigner la date validThrough au passé, supprimer la page en renvoyant un code 404 ou 410, ou retirer la balise JobPosting de la page tout en la laissant en ligne. Les trois fonctionnent ; la première est la plus simple à automatiser puisqu'elle ne demande qu'une mise à jour de date.
Google prévient explicitement des conséquences d'un défaut de retrait : « Failure to take timely action on expired jobs may result in a manual action. » Laisser une offre pourvue visible pendant des semaines n'est donc pas neutre : Google indique que cela peut entraîner une action manuelle. Pour accélérer la prise en compte du retrait, Google recommande d'utiliser l'Indexing API plutôt qu'un simple sitemap, car elle « incite Googlebot à explorer la page plus rapidement ».
L'Indexing API : à quoi elle sert vraiment
L'Indexing API permet de notifier directement Google quand une page d'offre d'emploi est ajoutée, mise à jour ou supprimée, ce qui accélère sa prise en compte par rapport à une simple exploration classique. Google réserve explicitement cette API aux pages contenant des données structurées JobPosting ou des événements diffusés en direct (BroadcastEvent dans un VideoObject), et la présente comme utile pour les sites avec « beaucoup de pages courte durée de vie comme les annonces d'emploi ».
Techniquement, l'API accepte deux types de notification, mise à jour ou suppression, et permet de regrouper jusqu'à 100 appels dans une seule requête HTTP en mode batch. La documentation mentionne un quota par défaut de 200 requêtes pour les phases d'intégration et de test, avec une demande d'approbation nécessaire pour aller au-delà ; aucun quota quotidien précis en production n'est indiqué dans le guide de démarrage. La mise en place suppose d'activer l'API, de créer un compte de service et de vérifier la propriété du site avant d'envoyer la première requête.
Pour un cabinet qui publie et retire des offres plusieurs fois par semaine, cette API évite d'attendre le prochain passage de Googlebot pour qu'une offre pourvue disparaisse réellement des résultats.
Les erreurs fréquentes qui excluent une offre
Un premier piège est l'offre expirée qu'on oublie de retirer : sans mise à jour de validThrough ni suppression de la page, Google peut continuer à afficher un poste déjà pourvu jusqu'à ce qu'une action manuelle intervienne. Un deuxième est le balisage posé sur une page qui liste plusieurs offres au lieu d'une page dédiée à un seul poste, ce que la documentation exclut explicitement.
| Erreur constatée | Conséquence selon la documentation Google |
|---|
| Offre expirée non retirée | Risque d'action manuelle sur le site si le problème persiste |
| Balisage sur une page liste plutôt qu'une page détaillée | Contenu jugé non pertinent, offre non éligible |
| Description incomplète ou absente | Offre non éligible à l'encart |
| Lieu affiché différent du lieu réel | Classé parmi les violations de contenu |
| Aucun moyen concret de postuler | Classé parmi les violations de contenu |
Ces erreurs sont rarement volontaires : elles viennent le plus souvent d'un processus de publication qui n'a pas prévu de retirer les offres pourvues ou qui a réutilisé un gabarit de page liste pour gagner du temps.
Checklist avant de publier une offre
Avant de mettre en ligne une offre destinée à l'encart Google Jobs, il vaut mieux vérifier chaque point plutôt que de le supposer acquis.
- Une page dédiée à cette offre, distincte de toute page liste
- Page accessible à Googlebot : pas de robots.txt bloquant, pas de noindex, pas de connexion requise
- Les cinq propriétés obligatoires renseignées : title, description, datePosted, hiringOrganization, jobLocation
- employmentType et validThrough renseignés
- jobLocationType à TELECOMMUTE et applicantLocationRequirements renseignés si le poste est en télétravail complet
- baseSalary renseigné seulement si le montant a été validé par l'employeur
- Un moyen concret de postuler, sans connexion obligatoire
- Test de la page dans l'outil de résultats enrichis avant publication
- Un processus de retrait dès que le poste est pourvu, sitemap ou Indexing API
- Suivi régulier du rapport résultats enrichis dans Search Console
Pour un cabinet ou une DRH qui gère plusieurs postes en parallèle, cette liste est aussi ce qui sépare une présence organique construite sérieusement d'une accumulation de pages qui finissent par disparaître des résultats.
Où l'IA aide réellement, sans survendre
L'IA aide sur trois tâches précises de ce processus : rédiger une description de poste complète et conforme, générer puis valider le balisage JobPosting propriété par propriété, et déclencher le retrait automatique dès la clôture d'un poste. Aucune de ces tâches ne remplace la décision humaine sur le contenu du poste ou le choix du candidat retenu.
Rédiger la description complète exigée par Google prend du temps quand chaque offre doit détailler responsabilités et qualifications sans être incomplète : une IA peut produire ce texte à partir d'une fiche de poste existante, à relire avant publication. Générer le JSON-LD à la main, propriété par propriété, est source d'erreurs de syntaxe ou d'oubli d'une propriété recommandée ; une génération automatisée réduit ce risque, à condition d'être vérifiée dans l'outil de test avant mise en ligne. Enfin, automatiser le retrait dès qu'un poste est pourvu, en mettant à jour validThrough ou en supprimant la page, évite l'oubli qui expose à une action manuelle. C'est ce type d'automatisation, appliqué au recrutement, que Nooralto met en place pour les cabinets et DRH qui publient des offres en volume, sans jamais retirer la décision finale des mains du recruteur.
Un projet de site vitrine ou de refonte pour héberger ces pages d'offres passe par les mêmes exigences techniques de base : voir notre approche de création de site internet. Pour toute question sur la mise en place, le formulaire de rappel ou la page contact permettent d'échanger directement.
Questions fréquentes
Google Jobs est-il payant pour les recruteurs ?
Non. Ajouter le balisage JobPosting rend une offre éligible à l'encart Google Jobs sans frais ni enchère ; la documentation Google ne mentionne aucun coût pour cet affichage.
Faut-il une page par offre ou une seule page avec toutes les offres ?
Une page par offre. Google demande de poser le balisage JobPosting sur « la page détaillée la plus précise possible » et interdit explicitement de l'ajouter à une page qui liste plusieurs postes.
Que se passe-t-il si on oublie de retirer une offre pourvue ?
L'offre expirée peut continuer à s'afficher, et Google prévient qu'un défaut de retrait dans les temps « may result in a manual action ».
Google Jobs fonctionne-t-il aussi au Maroc, pas seulement en France ?
Oui. Le Maroc figure dans la liste des pays disponibles pour la fonctionnalité, dans la zone Afrique du Nord et Moyen-Orient de la documentation Google, au même titre que la France dans la zone Europe.
Le salaire (baseSalary) doit-il toujours être affiché ?
Non, cette propriété est seulement recommandée. Elle doit correspondre au salaire de base réel fixé par l'employeur : un cabinet qui diffuse pour un client ne la renseigne que si le montant a été validé.
Quelle est la différence entre publier sur un jobboard et sur son propre site pour Google Jobs ?
Sur un jobboard, la plateforme gère en général le balisage des offres qu'elle héberge. Sur son propre site, le recruteur garde le contrôle complet du balisage, de la mise à jour et du retrait, mais doit construire et maintenir chaque page lui-même.
L'Indexing API est-elle obligatoire pour apparaître dans Google Jobs ?
Non, elle n'est pas obligatoire, mais Google la recommande pour les pages JobPosting plutôt qu'un simple sitemap, car elle incite Googlebot à explorer la page ajoutée ou retirée plus rapidement.