Le recruteur clôture le poste de technicien dans son outil de gestion des candidatures. Le site carrières resté obsolète affiche encore l’offre, son bouton « Postuler » et un balisage JobPosting dont la date de fin est future. Des candidats déposent leur dossier pour un recrutement terminé. L’équipe SEO cherche pourquoi la page continue d’apparaître, tandis que le support répond à des demandes que le métier n’attend plus. Ce retard de clôture crée une charge support évitable.
Fermer un recrutement et retirer sa promesse publique sont deux opérations qui doivent se rejoindre. En pratique, une offre pourvue ne doit plus inviter à candidater pour ce poste. La réponse HTTP, le contenu visible, les données structurées et les chemins de candidature doivent suivre une même décision, sans attendre qu’une baisse de trafic révèle leur divergence.
Un compteur d’offres stable peut cacher des postes déjà pourvus. Une fiche archivée peut rester utile à un lecteur sans représenter une offre active. Vous allez distinguer offre individuelle, archive et page métier durable, puis examiner huit captures fictives pour choisir la correction et la preuve qui permettent de fermer le dossier.
Dawap accompagne les équipes en SEO technique pour les sites et plateformes. Un audit technique du site de recrutement rapproche le référentiel des offres et les sorties publiques. L’enjeu est de corriger ce que le site promet réellement avant de demander une nouvelle exploration au moteur.
Dans quels cas auditer les offres expirées du site carrières
Le recrutement évolue dans une source différente du site
Le besoin concerne un site carrières d’entreprise, un cabinet ou une plateforme d’emploi qui reçoit ses offres depuis un autre outil. Une synchronisation peut publier rapidement les créations et traiter plus lentement les clôtures. Le site possède alors un cycle d’ouverture solide mais un cycle de retrait incomplet.
Le responsable recrutement connaît le poste et sa situation. L’équipe plateforme maîtrise routes, rendu et liens de candidature. Le SEO qualifie la représentation publique attendue. Un audit utile réunit ces responsabilités sur des références précises ; le nombre de fiches présentes dans le CMS ne remplace pas l’inventaire des recrutements réellement ouverts.
Qualifier les fermetures avant d’automatiser les retraits
Le poste peut être pourvu, annulé, suspendu ou encore ouvert malgré une date prévue dépassée. Ces situations n’impliquent pas la même prochaine action. Le site doit recevoir une décision explicite et une version, au lieu de déduire une clôture de la disparition d’un champ dans un export.
Une panne de collecte n’est pas une fermeture. Le lot dont l’état manque rejoint une file de qualification ; il ne déclenche pas automatiquement des milliers de suppressions. Le recrutement et la plateforme décident aussi comment traiter une offre suspendue, sans conserver par défaut un parcours qui continue de recevoir des dossiers.
Distinguer l’offre individuelle de la page métier qui peut durer
Une offre correspond à un recrutement identifié
Le poste possède sa référence, son employeur, son lieu et sa description. Deux annonces proches peuvent correspondre à deux recrutements différents. Une nouvelle ouverture ne doit pas remplacer silencieusement l’ancienne identité pour conserver ses visites ; l’équipe doit pouvoir expliquer ce que le candidat consulte et pour quelle référence il postule.
La documentation Google sur JobPosting réserve ce balisage à la page d’une offre individuelle. Une liste de postes ou un contenu consacré au métier ne reprend donc pas le statut de l’annonce retirée. Cette distinction évite de présenter une rubrique générale comme si elle recrutait pour une référence précise.
Un contenu durable répond à une autre question
Une page métier peut expliquer missions, environnement de travail, parcours internes et modalités de recherche des ouvertures actuelles. Sa valeur dépend de ces informations propres. Une liste vide accompagnée du titre d’un métier n’acquiert pas une utilité durable simplement parce qu’elle conserve une URL.
Quand la dernière offre ferme, la rubrique peut continuer à expliquer le métier et orienter vers les postes réellement ouverts. Elle doit dire ce qui est disponible aujourd’hui. Cette conservation ne justifie pas de garder un formulaire attaché à l’offre pourvue ni de baliser une candidature spontanée comme une annonce active.
Choisir une sortie publique cohérente pour l’offre pourvue
La clôture ne dépend pas seulement de la date programmée
Google documente trois sorties pour une offre devenue indisponible : une date validThrough passée, le retrait de la page avec un statut 404 ou 410, ou la suppression du balisage JobPosting. Sa documentation précise aussi de retirer une offre pourvue avant sa date de fin annoncée. Une échéance future ne prolonge donc pas un recrutement que le métier a déjà terminé.
Le site conserve la cause et la date de clôture fournies par la source. La politique choisit ensuite archive ou retrait. Il n’est pas nécessaire de modifier artificiellement les dates de publication pour simuler une nouvelle offre ; une correction technique doit suivre la décision réelle plutôt que créer un autre recrutement dans les données.
Une archive en 200 doit tenir sa propre promesse
L’archive retenue pour l’exercice affiche clairement la fermeture, désactive la candidature sur le poste et retire JobPosting. Cette politique locale est plus précise que « laisser l’URL accessible ». Le contenu restant doit expliquer ce que le lecteur peut encore apprendre et où trouver des offres actuelles sans lui faire croire que celle-ci accepte des dossiers.
Le cycle de retrait des pages générées par un inventaire aide à choisir l’utilité résiduelle et la réponse adaptée. Pour une offre d’emploi, cette décision doit aussi vérifier le parcours de candidature et le balisage spécialisé ; une sortie HTTP correcte ne suffit pas si un autre écran continue à promettre le poste.
Retirer une annonce sans rediriger tous les candidats vers l’accueil
Une page retirée peut garder une navigation utile
Si l’offre ne possède plus de contenu utile ni de remplaçant réellement équivalent, le retrait prévu conserve un statut d’absence. Le corps peut expliquer la fin et proposer une recherche d’offres. Ces liens constituent une orientation pour le visiteur ; ils ne disent pas que le poste historique a déménagé.
Les effets des statuts HTTP décrits par Google distinguent ces sorties du succès technique. Un 200 ne garantit pas l’indexation, et un contenu d’erreur sous ce statut peut être interprété comme une soft 404. L’audit compare donc protocole et contenu au lieu de compter uniquement les réponses réussies.
La proximité d’intitulé ne prouve pas un remplacement
Une autre offre de technicien peut concerner un lieu, un contrat ou un employeur différent. Le candidat arrivé sur la première référence n’a pas nécessairement le même besoin. Le responsable doit qualifier la relation avant de retenir une redirection permanente, avec la destination finale et la raison du remplacement.
La catégorie ou l’accueil restent accessibles comme navigation. Les transformer en destination automatique de toute clôture masque des décisions différentes. La recette vérifie l’identité de l’offre cible et son état actuel ; une page proche qui ferme demain ne constitue pas une solution durable à l’ancienne URL.
Fermer les chemins de candidature qui survivent à l’annonce
Le bouton visible n’est qu’un chemin parmi d’autres
Le candidat peut suivre un lien mémorisé, un email, un moteur interne ou une route de formulaire indépendante. Retirer le bouton de la fiche laisse ces entrées possibles. L’application qui reçoit la demande doit revalider la référence et l’état du recrutement avant de présenter une candidature comme destinée au poste ouvert.
Le formulaire explique une clôture et conserve une orientation appropriée. Il ne réattribue pas silencieusement le dossier à un autre poste. Les modalités d’une candidature spontanée relèvent d’un parcours distinct, avec ses propres informations ; elles ne servent pas de remplacement invisible à une offre terminée.
Le balisage et le message visible suivent la même version
Un composant JavaScript peut retirer le bouton après chargement pendant que le HTML initial conserve l’invitation et les données structurées. À l’inverse, un fragment ancien peut remettre JobPosting dans une page que le serveur a correctement archivée. La QA compare source et DOM rendu, puis suit la version qui a produit chaque sortie.
Le cache de page, les fragments, le moteur de recherche interne et les exports disposent d’un chemin de mise à jour. La fermeture doit atteindre toutes les représentations de l’offre. Une purge globale improvisée peut masquer temporairement le défaut sans corriger la règle qui republie la même promesse au prochain calcul.
Qualifier les dates sans fabriquer une expiration pour chaque poste
L’échéance connue possède une source
La documentation JobPosting demande validThrough lorsqu’une expiration existe. Si l’offre n’a pas d’échéance ou si elle est inconnue, cette propriété n’est pas ajoutée. Le contrat du site doit donc distinguer date connue, absence d’expiration prévue et donnée manquante à qualifier, au lieu de remplir automatiquement une date future.
Le système garde le fuseau et la précision nécessaires à sa politique de clôture. Une date prévue qui arrive pendant une panne de synchronisation exige une action définie, pas une prolongation arbitraire. Le responsable recrutement indique si le poste reste ouvert et fournit la décision qui autorise une nouvelle représentation publique.
Une ancienne ouverture ne doit pas annuler la clôture
Un export retardé peut contenir une version active d’une offre déjà pourvue. Le consommateur rapproche identifiant et version avant de reconstruire la fiche. Une reprise technique n’a pas le droit de restaurer la candidature depuis le seul dernier message reçu.
Le journal conserve état source, version retenue, motif et sortie publique. Une réouverture réelle produit une décision explicite du recrutement ; elle n’est pas déduite de l’augmentation du nombre de champs ou du retour d’une ligne dans un fichier. Le support retrouve ainsi la différence entre nouvelle décision et ancien événement.
Exercice corrigé : huit captures d’offre et de fin de recrutement
L’offre fictive J42 est connue dans une source fournie, version 2. Le contrôle reçoit un statut HTTP, du HTML statique, la présence dans le sitemap et une éventuelle intention de notification. Il compare ces observations à l’état du recrutement. Les captures ne proviennent pas d’un ATS réel et aucun appel Google n’est exécuté.
La règle d’archive choisie conserve une page 200 avec fermeture visible, candidature retirée et aucun JobPosting. Elle ne représente pas la seule voie documentée par Google. Le parseur vérifie la cohérence de ces éléments ; il ne contrôle pas toutes les propriétés exigées pour l’éligibilité d’une offre aux résultats enrichis.
| Cas | État et capture fournis | Diagnostic attendu | Correction ou preuve |
|---|---|---|---|
| A | J42 ouverte ; page 200, candidature disponible, balisage identifié et date future. | Capture cohérente dans le périmètre contrôlé. | Poursuivre la recette des champs requis et du formulaire réel. |
| B | J42 close ; page 200, bouton actif et JobPosting à date future. | La promesse de recrutement est encore ouverte. | Appliquer archive ou retrait, puis contrôler tous les chemins de candidature. |
| C | J42 close ; archive 200, fermeture visible, sans candidature ni JobPosting. | Archive cohérente avec la politique locale. | Vérifier l’utilité du contenu restant et la navigation vers les offres actuelles. |
| D | J42 close ; URL en 410, sans offre dans le corps ni entrée sitemap. | Retrait cohérent dans la capture. | La notification de retrait possède la précondition publique attendue. |
| E | J42 encore ouverte dans la source ; la page répond 410. | Offre active absente du site. | Rechercher la mauvaise transition avant de restaurer la sortie qualifiée. |
| F | J42 close ; l’URL redirige vers l’accueil sans relation de remplacement. | Redirection à qualifier. | Choisir une vraie destination équivalente ou une archive ou un retrait utile. |
| G | Archive C indexable ; une intention URL_DELETED est préparée. | Précondition de suppression manquante. | Distinguer mise à jour de la page et retrait de l’URL de l’index. |
| H | L’état du recrutement est inconnu ; la capture de l’URL répond 404. | Source à qualifier. | Retrouver la décision métier avant d’accepter ou d’étendre la suppression. |
Le résultat du parseur ne certifie pas l’état Google
A signifie que les éléments inspectés concordent avec les faits fournis. Il ne signifie pas que Google connaît l’URL, accepte son balisage ou affiche l’offre. D indique un retrait cohérent dans une capture ; aucune disparition réelle des résultats n’a été observée dans cet exercice.
E et H demandent deux enquêtes différentes. Une offre connue comme active ne doit pas suivre une transition de retrait ; une source inconnue ne permet pas encore d’interpréter la réponse comme conforme. Le diagnostic garde ces causes distinctes pour éviter qu’un indicateur « nombre de 404 » déclenche la même réparation sur tous les dossiers.
Vérifier identité, version et limites de la capture
Les huit captures, huit gardes et cinq frontières ont été exécutées hors connexion. Les gardes refusent un statut booléen, une horloge sans fuseau, un JSON-LD invalide, deux offres dans une même capture, une autre référence, une échéance illisible ou une version de projection ancienne. Ces résultats éprouvent le contrat fictif et ses limites.
Dans la politique temporelle de l’exercice, un instant avant l’échéance reste acceptable ; à l’échéance exacte, la source active demande une qualification. L’absence d’expiration connue reste possible. Les frontières distinguent aussi archive noindex et retrait 404 pour la précondition de notification. Elles ne définissent pas un instant universel de disparition dans Google.
Informer Google après la correction publique, puis observer séparément
Une mise à jour et une suppression d’URL sont différentes
La documentation de l’Indexing API distingue URL_UPDATED et URL_DELETED. Une demande de suppression exige auparavant une réponse 404 ou 410, ou une balise noindex sur la page. Retirer seulement JobPosting d’une archive 200 indexable ne satisfait pas cette précondition de retrait de l’URL.
Le dossier distingue donc la fin de l’annonce spécialisée et la volonté de supprimer la page des résultats. Le type de notification suit la sortie réellement publiée et le périmètre autorisé de l’API. Une rubrique métier ou un contenu éditorial ne rejoint pas automatiquement ce dispositif parce qu’il appartient au même site carrières.
L’accusé de notification ne prouve pas une disparition
Un succès de l’API confirme le traitement de la notification selon sa réponse. La lecture de ses métadonnées renseigne la dernière notification reçue ; elle ne donne pas la date d’indexation ou de retrait effectif. Le suivi doit conserver la preuve technique actuelle et l’observation du moteur dans deux états différents.
La méthode des alertes d’indexation par population attendue prolonge cette lecture. Une baisse du nombre d’offres présentes peut suivre des clôtures légitimes ; la priorité porte sur les offres actives disparues ou les promesses closes encore servies, avec des sources datées.
Construire une fermeture vérifiable du référentiel au rendu
Un même état alimente la fiche et ses chemins de découverte
Les entrées réunissent référence, état du recrutement, version, échéance qualifiée et politique d’archive. Les sorties comprennent statut, contenu, candidature, JSON-LD, liens et sitemap. Les responsabilités relient recrutement pour la décision, intégration pour la source, plateforme pour les routes et SEO pour la représentation. Les dépendances dont l’état manque produisent une attente attribuée.
La journalisation associe transition et artefacts concernés. En SSR, le rendu lit l’état retenu ; en SSG, la reconstruction doit atteindre la fiche et les listes ; en ISR, la revalidation suit les routes touchées. L’invalidation et les clés de cache gardent la version d’offre. Le déploiement ne doit pas laisser une hydratation JavaScript restaurer la candidature ancienne.
Éprouver les erreurs qui republient une offre close
La CI et la QA vérifient une ouverture, une clôture anticipée, un événement ancien, un cache non renouvelé et un formulaire appelé directement. Elles comparent HTML, rendu, canonical, indexation souhaitée, maillage et sitemap. L’instrumentation enregistre la réponse servie et les logs utiles, sans transformer un passage de Googlebot en certificat de résultat.
Le monitoring distingue anciennes offres encore actives publiquement, offres ouvertes retirées et sources non qualifiées. Le repli suspend le traitement fautif et reconstruit depuis les décisions validées. Restaurer une ancienne version applicative ne doit pas rouvrir tous les recrutements réellement terminés ; le retour dépend des états métier, pas uniquement du code précédent.
Mesurer le coût des candidatures adressées au mauvais état
La correction commence avec les offres encore trompeuses
Cas concret fictif : vingt-quatre demandes concernent des postes déjà pourvus et nécessitent cinq minutes de vérification chacune. La charge représente deux heures de traitement avant les réponses aux candidats. Le seuil opérationnel utile porte sur la durée pendant laquelle une clôture reste contredite par le site, plutôt que sur le seul total des pages indexées.
Le recrutement fournit le nombre de postes réellement ouverts et fermés sur la période. La plateforme rapproche ces transitions des sorties publiques. Les contacts et candidatures reçus après clôture éclairent les défauts de parcours ; ils ne constituent pas une mesure directe du comportement de Google.
Séparer les offres actives, les archives et les pages métiers
La cohorte active mesure découverte, crawl, impressions et candidatures sur les recrutements ouverts. Les archives suivent leur utilité résiduelle et les orientations réellement utilisées. Les contenus métiers disposent d’une intention propre et de liens vers les ouvertures actuelles. Mélanger ces populations peut faire apparaître une fermeture saine comme une perte SEO globale.
Exemple concret fictif : trente offres closes quittent la population active tandis que deux pages d’offres encore ouvertes servent accidentellement 410. La priorité est de qualifier et restaurer ces deux sorties. Le délai de diagnostic dépend des traces et du référentiel disponibles ; une campagne de notification sur toutes les URL ne corrige pas la transition fautive.
Erreurs fréquentes qui prolongent une annonce expirée
Conserver une date future ou renouveler l’offre automatiquement
Une date future héritée de la publication initiale ne démontre pas que le poste reste ouvert. Un traitement qui prolonge toutes les échéances peut masquer les clôtures et produire une activité artificielle. La source doit porter la décision actuelle et le motif qui autorise une mise à jour.
Une réouverture possède une référence ou une relation documentaire explicite selon l’organisation. Le contrat distingue cette opération de la réparation du rendu. La correction technique ne modifie ni la réalité du recrutement ni l’historique des décisions prises par le métier.
Changer le message sans fermer les effets
Afficher « offre terminée » tout en conservant une candidature pour J42 laisse une contradiction pratique. Retirer JobPosting tout en conservant un bouton actif fait de même. La recette part de ce que le candidat peut réellement faire, puis lit les signaux techniques de cette même version.
Contre-intuitivement, conserver moins d’annonces actives peut rendre le site plus utile : les candidats rencontrent des postes auxquels ils peuvent encore répondre. La valeur du contenu durable se construit séparément. Garder chaque ancienne annonce comme si elle recrutait ne constitue pas une stratégie de longue traîne fiable.
Plan d’action : fermer une première population d’offres sans faux résultat
Choisir un flux dont les décisions sont rapprochables
Commencez par un employeur ou une source maîtrisée. Rapprochez les références, leurs états, les dates et les versions avec les URL et formulaires publics. Les responsables choisissent les conditions d’archive et de retrait. Les offres dont l’état reste inconnu conservent une prochaine action attribuée au lieu de suivre le lot.
Les entrées et les sorties du contrôle sont figées avant correction. La journalisation conserve les captures et les causes. L’intégration qualifie la dépendance à la source ; la plateforme attribue les responsabilités du rendu et des caches. Le SEO décrit la population attendue après fermeture et la façon de l’observer.
Publier le correctif avant de demander la nouvelle exploration
La recette exécute les huit situations sur l’application réelle et ajoute les chemins de candidature, les versions anciennes et le rendu après hydratation. Le pilote vérifie statut, contenu, balisage, maillage et sitemap. Les demandes de notification sont préparées depuis ces réponses contrôlées, avec leur motif et leur type.
La fermeture technique exige des sorties cohérentes. L’observation du moteur conserve son propre délai et sa preuve. Si le site repasse correctement mais qu’une ancienne représentation persiste, l’équipe confronte chronologie, crawl et données disponibles ; elle ne modifie pas de nouveau l’état métier pour accélérer artificiellement la courbe.
- Qualifier l’état du recrutement et la version avant de fermer ou de réactiver une URL.
- Corriger ensemble candidature, contenu, balisage et réponse publique, puis vérifier leurs chemins secondaires.
- Distinguer notification reçue et retrait observé avant de clôturer le suivi SEO.
Guides complémentaires pour le retrait et l’observation des offres
La fin d’une offre exige une politique publique et une lecture des observations externes. Les deux méthodes se complètent : l’une choisit et vérifie la sortie, l’autre compare cette intention à ce qui peut être connu du moteur.
Choisir la sortie de la page générée depuis le recrutement
La politique de fin de vie des pages programmatiques rapproche état de l’entité, utilité résiduelle et remplacement. Elle permet de garder une archive utile ou de retirer une URL dont la promesse ne subsiste plus.
Le cas de recrutement ajoute la fermeture du formulaire et les contraintes du balisage d’offre. La matrice générale reste une aide au choix ; le contrôle spécialisé vérifie que le candidat ne peut plus répondre au poste terminé.
Interpréter une exclusion depuis la population attendue
Les alertes d’indexation et leurs preuves de reprise distinguent correction publique et état externe observé. Elles évitent de traiter chaque retrait volontaire comme une panne et chaque notification réussie comme un résultat moteur.
L’équipe conserve date de clôture, version publique et observations disponibles pour chaque cohorte. Les offres ouvertes restent séparées des archives. Une nouvelle anomalie est ainsi reliée à la transition qui l’a produite, plutôt qu’à une variation globale impossible à expliquer.
- L’état source explique pourquoi la représentation publique change.
- Les captures prouvent une sortie technique dans leur périmètre.
- La donnée du moteur conserve sa date et ses limites d’interprétation.
Conclusion : fermer la promesse de recrutement avec le poste
Une offre pourvue doit cesser de proposer une candidature pour ce recrutement. Le référentiel, les formulaires, le rendu et JobPosting doivent suivre cette fin, avec une archive ou un retrait qui explique la situation. La date future du balisage ne remplace pas la décision du métier.
Les pages métiers durables répondent à une autre intention. Leur utilité peut continuer après une clôture, tandis que l’annonce individuelle suit son cycle propre. Les huit captures fictives rendent ces frontières vérifiables sans prétendre prouver un état d’indexation ou une éligibilité complète dans Google.
Un audit technique des offres et du site carrières peut rapprocher décisions de recrutement, routes, candidatures et données structurées. Le premier périmètre est choisi depuis les références dont la situation et les sources sont qualifiées, puis contrôlé jusqu’au rendu public.
Dawap peut vous accompagner en SEO technique pour construire ce cycle de fermeture, préparer ses contrôles et suivre les observations après publication. Nous relions les équipes métier et techniques pour corriger les promesses obsolètes et conserver des pages utiles aux visiteurs.
