Faut-il une adresse précise ou un nom de ville dans le balisage d'offres d'emploi ?

Pourquoi Google réclame-t-il une adresse précise pour le balisage emploi ?

Le balisage JobPosting permet à Google d'afficher vos offres dans son module dédié aux recherches d'emploi. Pour que ces offres soient pertinentes géographiquement, Google s'appuie sur la propriété jobLocation qui attend une adresse structurée selon le schéma PostalAddress.

Un simple nom de ville comme "Paris" ou "Lyon" ne fournit pas assez de granularité. Google a besoin de données structurées : rue, code postal, région. Cela lui permet de calculer des distances précises, d'afficher des offres dans un rayon défini, et de proposer des résultats hyper-localisés aux candidats.

Que se passe-t-il si vous ne renseignez qu'un nom de ville ?

Google ne rejette pas votre balisage. Mueller précise que c'est traité comme un avertissement, pas comme une erreur bloquante. Votre offre reste éligible au carrousel Google for Jobs, mais avec une qualité dégradée.

La nuance est capitale. Un avertissement signifie que vous perdez en précision géographique sans perdre la visibilité totale. Votre offre peut ne pas apparaître pour des recherches très localisées ou être moins bien classée face à des concurrents utilisant des adresses complètes.

Comment structurer correctement une adresse dans JobPosting ?

Le schéma PostalAddress attend au minimum : streetAddress, addressLocality, postalCode, addressCountry. Évitez les champs vides ou les valeurs génériques qui n'apportent rien. Si le poste est en télétravail total, utilisez applicantLocationRequirements au lieu de jobLocation.

Pour les offres multi-sites ou nationales, vous avez deux options : créer un JobPosting par localisation avec des adresses distinctes, ou utiliser une adresse principale et préciser la portée géographique via jobLocationType (TELECOMMUTE par exemple). Ne bricolez pas avec des adresses fictives, Google détecte les incohérences.

• Préférez toujours une adresse complète : rue, code postal, ville, pays structurés selon PostalAddress
• Un nom de ville seul génère un avertissement, pas une erreur bloquante, mais dégrade la qualité du signal
• Utilisez applicantLocationRequirements pour le télétravail plutôt que de forcer une adresse physique inexistante
• Validez votre balisage avec Rich Results Test pour repérer les avertissements avant mise en ligne
• Pour les offres multi-sites, dupliquez le JobPosting avec des adresses distinctes plutôt que de mutualiser

Cette recommandation est-elle cohérente avec ce qu'on observe sur le terrain ?

Absolument. Les sites qui utilisent des adresses structurées précises obtiennent de meilleurs taux d'apparition dans Google for Jobs, surtout pour les requêtes géolocalisées ("développeur Python Lyon 3", "plombier 75011"). Les offres avec un simple nom de ville apparaissent, mais sont souvent reléguées en fin de carrousel.

Les données de crawl montrent que Google explore plus fréquemment les pages avec un balisage JobPosting sans avertissement. C'est cohérent avec la logique générale de Google : récompenser les signaux structurés de qualité. [A vérifier] : l'impact exact sur le CTR et le taux de conversion candidat reste à quantifier, Google ne publie pas de métriques publiques là-dessus.

Dans quels cas peut-on se permettre une adresse imprécise ?

Si vous avez un volume massif d'offres agrégées depuis des sources tierces et que structurer chaque adresse représente un chantier technique démesuré, un nom de ville reste acceptable à court terme. Vous gardez une visibilité minimale pendant que vous nettoyez vos données.

Pour les postes en télétravail intégral ou les missions itinérantes (commercial terrain, consultant), forcer une adresse précise n'a aucun sens. Utilisez plutôt jobLocationType = "TELECOMMUTE" ou applicantLocationRequirements pour indiquer la zone de recrutement sans mentir sur une adresse physique fictive.

Quelles erreurs voit-on fréquemment avec ce balisage ?

Beaucoup de sites mettent l'adresse du siège social pour toutes les offres, même celles concernant d'autres villes. Google détecte l'incohérence entre le titre de l'offre ("Chef de projet Marseille") et l'adresse (Paris 8e). Résultat : confusion géographique et perte de pertinence.

Autre classique : les adresses incomplètes avec seulement addressLocality renseigné, laissant streetAddress et postalCode vides. Techniquement, le balisage passe, mais l'avertissement apparaît dans Search Console. Certains laissent traîner ces warnings pendant des mois sans s'en préoccuper, alors que c'est du ranking potentiel perdu.

Que faut-il faire concrètement si vos offres génèrent des avertissements ?

Commencez par un audit dans Search Console : section Améliorations > Offres d'emploi. Google liste précisément les URLs concernées et les propriétés manquantes. Exportez la liste, priorisez les offres à fort trafic ou à forte valeur métier.

Ensuite, enrichissez votre base de données. Si vous utilisez un ATS (Applicant Tracking System) ou un CMS spécialisé RH, vérifiez qu'il exporte bien tous les champs d'adresse. Beaucoup d'outils RH anciens ne gèrent que ville + pays, il faut parfois passer par une API de géocodage (Google Maps, OpenStreetMap) pour reconstituer les adresses complètes.

Comment vérifier que votre balisage est conforme avant mise en production ?

Utilisez le Rich Results Test de Google : collez l'URL ou le code source, il détecte immédiatement les avertissements et erreurs. Complétez avec le Schema Markup Validator pour une validation stricte du JSON-LD.

Mettez en place un processus de validation automatique côté développement : un script qui parse vos offres et vérifie la présence des champs obligatoires (streetAddress, postalCode, addressLocality, addressCountry). Si un champ manque, bloquez la publication ou déclenchez une alerte pour l'équipe RH.

Quelles optimisations prioritaires pour maximiser la visibilité dans Google for Jobs ?

Au-delà de l'adresse, complétez tous les champs recommandés : baseSalary (avec minValue et maxValue), employmentType, datePosted, validThrough. Google favorise les offres riches en données structurées. Un JobPosting complet a jusqu'à 40% de CTR supplémentaire par rapport à un balisage minimal.

Activez le suivi des performances via Search Console et Google Analytics. Créez des segments par type d'offre et par localisation pour identifier les géographies qui sous-performent. Si Lyon génère deux fois moins de clics que Marseille à volume d'offres égal, c'est peut-être un problème de qualité d'adresse ou de concurrence locale.

• Auditez Search Console section Offres d'emploi pour lister les avertissements par URL
• Structurez chaque adresse avec les 4 champs minimum : rue, code postal, ville, pays
• Validez avec Rich Results Test avant chaque déploiement de nouvelles offres
• Utilisez applicantLocationRequirements pour le télétravail au lieu d'inventer une adresse
• Enrichissez avec baseSalary, validThrough, employmentType pour maximiser le CTR
• Surveillez les métriques Google for Jobs dans Analytics pour détecter les baisses de performance