Le WordPress d'aujourd'hui, décodé pour les développeurs

SEO & GEO

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.

Par WordPress Développement • 6 septembre 2023 • 4 min de lecture • Aucun commentaire
Des pages de recrutement indexées six mois après la clôture des offres

« 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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi