# Des pages de recrutement indexées six mois après la clôture des offres

> Symptôme constaté dans Search Console, diagnostic de l'absence de noindex à l'expiration d'une offre, correctif par un statut personnalisé, prévention durable.

- Auteur : WordPress Développement
- Publié le : 2023-09-06
- Mis à jour le : 2023-09-06
- Catégorie : SEO &amp; GEO
- URL : https://www.wpmoderne.fr/seo/pages-recrutement-indexees-apres-cloture-offres/

## L’essentiel

- Aucune offre expirée ne passait automatiquement en noindex
- Un statut personnalisé archive plutôt que supprime
- Une tâche planifiée vérifie chaque jour les dates d'expiration

« Cette offre n'est plus disponible » : ce message, affiché sur la page elle-même, contredisait ce que montrait encore Google six mois après la clôture réelle du recrutement, plusieurs candidats ayant contacté l'entreprise en réponse à une offre qu'ils avaient trouvée via une recherche, sans savoir qu'elle n'était plus d'actualité depuis longtemps.

Le site de recrutement concerné gérait ses offres d'emploi via un type de contenu personnalisé `offre_emploi`, avec une date d'expiration renseignée manuellement par les recruteurs, mais sans aucun mécanisme automatique reliant cette date à un traitement d'indexation.

## Diagnostic : la date d'expiration restait une simple information

L'examen du code du thème a montré que la date d'expiration servait uniquement à afficher le message « offre non disponible » sur la page elle-même, une fois la date dépassée, sans jamais toucher au statut de publication de l'article ni ajouter de balise `noindex`. L'article restait donc publié, exploré et indexé indéfiniment, malgré son contenu devenu obsolète pour un visiteur comme pour un moteur de recherche.

Ce décalage entre l'information affichée et le traitement d'indexation explique pourquoi l'équipe interne, en consultant simplement le site, ne percevait aucun problème : le message d'expiration s'affichait correctement. Le problème se situait uniquement dans la couche invisible du référencement.

## Correctif : un statut de publication personnalisé

> L'essentiel à retenir : Aucune offre expirée ne passait automatiquement en noindex ; Un statut personnalisé archive plutôt que supprime ; Une tâche planifiée vérifie chaque jour les dates d'expiration

Plutôt que de supprimer l'article expiré, ce qui aurait fait perdre l'historique utile pour les statistiques de recrutement, un statut de publication personnalisé `archive_emploi` a été enregistré, distinct à la fois du statut publié et du statut brouillon :

```
function offre_emploi_statut_archive() {
    register_post_status( 'archive_emploi', array(
        'label'                     => 'Archivée',
        'public'                    => true,
        'exclude_from_search'      => true,
        'show_in_admin_all_list'    => true,
        'show_in_admin_status_list' => true,
        'label_count'               => _n_noop( 'Archivée (%s)', 'Archivées (%s)' ),
    ) );
}
add_action( 'init', 'offre_emploi_statut_archive' );
```

Ce statut conserve l'article accessible aux administrateurs et aux personnes disposant du lien direct, tout en signalant explicitement au reste du système que cette offre ne relève plus du contenu actif du site.

## Ajouter la balise noindex correspondante

Le statut personnalisé, à lui seul, ne suffit pas à empêcher l'indexation : il fallait encore ajouter une balise `noindex` conditionnelle sur les pages dont le statut vaut `archive_emploi`, en complément du retrait de ces pages des listings publics :

```
function offre_emploi_noindex_archive() {
    if ( is_singular( 'offre_emploi' ) && 'archive_emploi' === get_post_status() ) {
        echo '<meta name="robots" content="noindex,follow">' . "\n";
    }
}
add_action( 'wp_head', 'offre_emploi_noindex_archive' );
```

## Automatiser la bascule via une tâche planifiée

Restait à automatiser le passage du statut publié vers le statut archivé au moment précis de l'expiration, sans dépendre d'une action manuelle du recruteur qui oublie fréquemment de revenir sur l'offre après la clôture du poste. Une tâche WP-Cron quotidienne vérifie désormais les dates d'expiration dépassées :

```
function offre_emploi_archiver_expirees() {
    $offres = get_posts( array(
        'post_type'   => 'offre_emploi',
        'post_status' => 'publish',
        'meta_query'  => array( array(
            'key'     => 'date_expiration',
            'value'   => current_time( 'Y-m-d' ),
            'compare' => '<',
        ) ),
    ) );
    foreach ( $offres as $offre ) {
        wp_update_post( array( 'ID' => $offre->ID, 'post_status' => 'archive_emploi' ) );
    }
}
if ( ! wp_next_scheduled( 'offre_emploi_verif_quotidienne' ) ) {
    wp_schedule_event( time(), 'daily', 'offre_emploi_verif_quotidienne' );
}
add_action( 'offre_emploi_verif_quotidienne', 'offre_emploi_archiver_expirees' );
```

## Prévention pour les futures offres

Cette automatisation règle le problème pour toutes les offres à venir, mais ne corrige pas rétroactivement les offres déjà expirées depuis longtemps. Un script ponctuel a donc été exécuté une seule fois pour appliquer le nouveau statut à l'ensemble des offres closes accumulées avant la mise en place du mécanisme :

- Identification des offres avec une date d'expiration passée et un statut toujours publié
- Bascule en masse vers le statut `archive_emploi` via `wp_update_post()`
- Vérification manuelle d'un échantillon avant la bascule complète

> Une date d'expiration affichée à l'écran n'a aucune valeur pour un moteur de recherche si elle ne déclenche aucune action réelle sur le statut de la page.

## En résumé

Faire vivre une information de date d'expiration uniquement dans l'affichage visuel d'une page, sans la relier à son statut de publication ni à sa balise d'indexation, condamne les contenus obsolètes à rester indexés indéfiniment. Un statut personnalisé, couplé à une tâche planifiée quotidienne, referme ce trou de façon durable sans sacrifier l'historique des offres passées.
