# Balises title et meta description sans extension SEO : document_title et wp_head > Avant d'installer une extension SEO, voyons ce que WordPress sait déjà faire pour vos balises title et meta description, avec les bons filtres et les bons pièges à éviter. - Auteur : Clément Hadrot - Publié le : 2020-02-10 - Mis à jour le : 2020-02-10 - Catégorie : SEO & GEO - URL : https://wpmoderne.dev.wordpress-developpement.fr/seo/title-meta-description-sans-extension-seo/ ## L’essentiel - document_title_parts pour personnaliser le - wp_head pour injecter la meta description - Éviter les doublons de balises entre thème et code Un client m'a un jour demandé pourquoi son titre d'article apparaissait deux fois dans l'onglet du navigateur. La réponse tenait en une ligne : son thème appelait `wp_title()` à la main dans `header.php`, en plus de la fonction native de WordPress qui gère déjà cette balise depuis longtemps. Ce genre de doublon est plus fréquent qu'on ne le pense, surtout sur des thèmes anciens migrés d'un projet à l'autre sans grand nettoyage. Avant de brancher une extension SEO complète pour un besoin simple, il vaut la peine de savoir ce que le cœur de WordPress gère déjà nativement, et où s'arrêtent ses capacités. Cet article détaille comment fonctionnent réellement la balise `<title>` et la meta description sous WordPress, sans dépendance externe. ## Comment WordPress construit la balise title Depuis la fonction `_wp_render_title_tag()`, introduite il y a plusieurs versions majeures, WordPress ajoute automatiquement la balise `<title>` dans le `<head>` du document, à condition que le thème déclare le support `title-tag`. C'est le cas de la quasi-totalité des thèmes actifs aujourd'hui : ``` add_theme_support( 'title-tag' ); ``` Le contenu de cette balise passe ensuite par le filtre `document_title_parts`, qui reçoit un tableau associatif avec généralement trois clés : `title`, `page` et `site`. C'est ce tableau que WordPress assemble avec un séparateur (le tiret cadratin par défaut) pour produire la chaîne finale. ``` add_filter( 'document_title_parts', function( $parts ) { if ( is_singular( 'produit' ) ) { $parts['title'] = get_the_title() . ' — en stock'; } return $parts; } ); ``` Ce filtre est le bon endroit pour personnaliser le titre d'un type de contenu personnalisé sans toucher au template. On évite ainsi de dupliquer la balise en la réécrivant en dur dans `header.php`, ce qui est justement la source du problème rencontré par mon client. ## Ce que WordPress ne fait pas : la meta description > L'essentiel à retenir : document_title_parts pour personnaliser le <title> ; wp_head pour injecter la meta description ; Éviter les doublons de balises entre thème et code Contrairement à la balise title, WordPress cœur ne génère aucune balise `meta name="description"`. Il n'existe pas d'équivalent natif à `document_title_parts` pour ce besoin. C'est une des raisons pour lesquelles la quasi-totalité des sites installent une extension dédiée : elle apporte un champ de saisie par article et génère la balise correspondante. Si le besoin est simple, un accroché au hook `wp_head` suffit largement, en s'appuyant par exemple sur l'extrait (`excerpt`) de l'article : ``` add_action( 'wp_head', function() { if ( ! is_singular() ) { return; } $description = get_the_excerpt(); if ( empty( $description ) ) { return; } printf( '<meta name="description" content="%s">' . "\n", esc_attr( wp_trim_words( $description, 30 ) ) ); } ); ``` Cette approche reste volontairement minimale : pas d'interface d'administration, pas de champ dédié, juste un filet de sécurité pour éviter qu'une meta description ne manque totalement. Elle convient à des sites vitrines de quelques pages, pas à un site éditorial où chaque article mérite une accroche rédigée à la main. ## Les pièges classiques à surveiller - Deux fonctions concurrentes qui écrivent la balise title (thème et plugin, ou ancien code oublié dans `functions.php`). - Une meta description générée à partir du contenu brut, sans nettoyage des raccourcis de blocs ni des balises HTML restantes. - Une longueur de title qui dépasse largement les **60 caractères** généralement affichés dans les résultats de recherche, tronquant le message important. - Un séparateur de titre incohérent d'une page à l'autre, quand plusieurs filtres `document_title_parts` s'empilent sans coordination. Pour diagnostiquer un doublon de balise, la méthode la plus fiable reste d'afficher le code source de la page (et non l'inspecteur, qui peut masquer certaines incohérences après exécution du JavaScript) et de chercher littéralement `<title>` avec un raccourci de recherche du navigateur. S'il apparaît plus d'une fois, il y a forcément une fonction en trop quelque part dans le thème ou une extension. ## Quand passer à une extension dédiée Le filtre `wp_head` maison présenté plus haut a une limite claire : il ne propose aucune interface de saisie. Dès qu'une équipe éditoriale doit pouvoir rédiger elle-même sa meta description, ou dès que le site a besoin de balises Open Graph, de contrôle fin de l'indexation par article, ou d'un aperçu de résultat de recherche, une extension dédiée devient largement plus efficace que du code maison à entretenir. La bascule vers une extension ne doit toutefois jamais se faire sans nettoyer le code existant : les filtres `document_title_parts` et les actions `wp_head` ajoutés manuellement doivent être retirés ou adaptés, sous peine de générer exactement le genre de doublon évoqué en introduction. > Avant d'ajouter une nouvelle extension, je vérifie toujours le code source d'une page avec la recherche du navigateur. Deux balises title, c'est un signal presque toujours de la même origine : un vieux bout de code oublié quelque part dans le thème. ## En résumé WordPress gère nativement et bien la balise title, via `add_theme_support( 'title-tag' )` et le filtre `document_title_parts`. Il ne gère en revanche pas du tout la meta description, ce qui laisse le choix entre un filet de sécurité maison sur `wp_head` pour un petit site, et une extension SEO complète dès que l'équipe éditoriale a besoin d'un vrai contrôle rédactionnel. Dans les deux cas, la vigilance porte surtout sur les doublons de code, bien plus fréquents qu'on ne l'imagine sur des projets qui ont changé plusieurs fois de mains.