Page vs Article WordPress : Comprendre la Différence

Dernière mise à jour : septembre 2026

La différence technique entre une page et un article WordPress est simple — l’une est statique et hiérarchique, l’autre est chronologique et catégorisable. Ce qui est moins simple, c’est de structurer un site correctement avec ces deux types de contenus. Sur les sites en maintenance, les erreurs de structuration page/article sont parmi les problèmes les plus fréquents — et parmi les plus coûteux en SEO et en temps de correction.

Page et article — les différences techniques

WordPress propose deux types de contenus natifs, conçus pour des usages distincts.

Un article (post) est un contenu daté, associé à une chronologie. Il peut être classé par catégories et par étiquettes, il alimente le flux RSS du site, et il apparaît dans les archives (par date, par catégorie, par auteur). Les articles sont conçus pour les contenus qui s’inscrivent dans le temps : actualités, billets de blog, guides, analyses, tutoriels.

Une page est un contenu statique, sans date de publication visible et sans taxonomie. Les pages peuvent être hiérarchisées (parent/enfant), ce qui permet de créer des arborescences logiques : /services/, /services/maintenance/, /services/hebergement/. Les pages sont conçues pour les contenus structurels du site : accueil, à propos, contact, mentions légales, pages de services.

La distinction est nette en théorie. En pratique, c’est dans l’application de cette distinction que les sites accumulent de la dette technique.

Les erreurs de structuration les plus fréquentes

Des pages de services créées comme articles. C’est l’erreur la plus courante. Le prestataire qui a construit le site a créé « Maintenance WordPress », « Hébergement », « Sécurité » comme des articles de blog. Résultat : ces pages de services apparaissent dans le flux blog avec une date de publication, elles sont classées dans des catégories éditoriales, et elles « vieillissent » visuellement — un article daté de 2022 pour un service toujours proposé en 2026 envoie un signal de négligence aux visiteurs comme à Google.

Des landing pages en articles. Une page de destination pour une campagne, un formulaire d’inscription, une offre spécifique — créés comme articles. Ils se retrouvent indexés dans le sitemap du blog, catégorisés avec les billets éditoriaux, et noyés dans les archives chronologiques. Le visiteur qui arrive depuis une publicité atterrit sur un contenu qui ressemble à un billet de blog, pas à une page de conversion.

Des contenus permanents en articles. Conditions générales de vente, mentions légales, politique de confidentialité, FAQ globale — ces contenus n’ont pas de date de péremption, pas de catégorie thématique, pas de raison d’apparaître dans un flux RSS. Les créer en articles, c’est les soumettre à une logique chronologique qui n’a aucun sens pour ce type de contenu.

Des actualités créées en pages. L’erreur inverse : des communiqués, des annonces de mise à jour, des retours d’expérience créés comme des pages statiques. Sans catégorisation possible, sans archives, sans flux RSS — ces contenus deviennent invisibles. Ils ne participent pas au maillage interne thématique du site et n’alimentent pas la présence éditoriale.

Des pages structurelles sans hiérarchie. Les pages de services existent, mais sans arborescence : /maintenance/, /hebergement/, /securite/ au même niveau que /contact/ et /a-propos/, au lieu d’une structure /services/maintenance/, /services/hebergement/. L’URL ne reflète pas la logique du site, la navigation n’a pas de cohérence hiérarchique, et Google perd le signal de regroupement thématique.

Des portfolios ou témoignages en pages. Chaque réalisation client, chaque témoignage créé comme une page individuelle. Pas de taxonomie pour filtrer par secteur ou par type de projet, pas d’archive pour les parcourir — une collection de contenus isolés, impossibles à organiser ou à mettre en avant de manière dynamique.

L’impact SEO d’une mauvaise structuration

Les erreurs de structuration page/article ne sont pas qu’un problème d’organisation interne. Elles ont des conséquences mesurables sur le référencement.

Sitemap désorganisé. Les plugins SEO (Yoast, Rank Math) génèrent des sitemaps séparés pour les pages et les articles. Si une page de services est un article, elle apparaît dans le sitemap des articles avec les billets de blog. Google reçoit un signal confus sur la nature du contenu — et un sitemap désordonné, c’est un crawl moins efficace.

Cannibalisation de mots-clés. Un article « Notre service de maintenance WordPress » et une page « Maintenance WordPress » ciblent le même mot-clé. Google doit choisir lequel positionner — et il ne choisit pas toujours celui que vous voulez. C’est une erreur de maintenance qui impacte directement le SEO.

Maillage interne incohérent. Le maillage interne repose sur la structure du site. Si les types de contenus sont mélangés, les liens internes perdent leur logique : un article de blog lie vers un « article » qui est en fait une page de services, les catégories regroupent des contenus hétérogènes, les archives chronologiques mélangent éditorial et commercial.

Autorité diluée. L’autorité (link juice) que le site accumule se distribue entre les contenus via le maillage interne. Quand la structure est incohérente, cette autorité se disperse vers des contenus mal classés au lieu de se concentrer sur les pages stratégiques — celles qui doivent se positionner dans les résultats de recherche.

Comment diagnostiquer et corriger

Faire l’inventaire. Lister tous les contenus du site — pages et articles — avec leur type, leur URL, leur catégorie (pour les articles) et leur position dans la hiérarchie (pour les pages). La commande WP-CLI wp post list --post_type=post,page --fields=ID,post_title,post_type,post_name,post_parent --format=csv produit cette liste en quelques secondes.

Appliquer la règle de base. Pour chaque contenu, la question est simple : ce contenu s’inscrit-il dans une chronologie, ou est-il structurel et permanent ? S’il a une date de péremption, s’il fait partie d’une série, s’il se range dans une catégorie thématique — c’est un article. S’il définit la structure du site, s’il est permanent, s’il doit s’intégrer dans une hiérarchie de navigation — c’est une page.

Corriger les types. Changer un article en page (ou inversement) dans WordPress n’est pas un simple changement de statut. L’URL change (les articles ont souvent un préfixe de catégorie dans le permalien, les pages non), le contenu sort d’une catégorie et entre dans une hiérarchie (ou l’inverse), et les pages d’archives qui le listaient ne le montrent plus. Chaque changement de type nécessite une redirection 301 de l’ancienne URL vers la nouvelle, une mise à jour des liens internes qui pointaient vers l’ancienne URL, et une vérification du maillage.

Tester sur un site de staging avant d’appliquer en production. Les changements de type de contenu peuvent casser des templates (un article qui devient une page n’utilise plus le même template PHP), des menus de navigation, et des widgets qui affichent les « derniers articles » ou les « pages enfants ».

Ce diagnostic de structure devrait faire partie de la maintenance régulière du site — pas seulement lors de la refonte. Un site qui accumule des contenus mal typés pendant trois ans est beaucoup plus difficile à corriger qu’un site vérifié chaque trimestre.

FAQ

Peut-on changer le type d’un contenu (article → page) sans perdre le contenu ?

Le contenu lui-même (texte, images, médias) est conservé. Ce qui change : l’URL (le permalien est reconstruit selon les règles du nouveau type), les taxonomies (un article qui devient page perd ses catégories et étiquettes), et le template d’affichage. Le risque principal est la perte de trafic SEO si l’ancienne URL n’est pas redirigée en 301 vers la nouvelle. Sur un site avec du trafic organique significatif, chaque changement de type doit être accompagné d’une redirection et d’une vérification dans Google Search Console.

Faut-il utiliser des Custom Post Types plutôt que des pages ou des articles ?

Les Custom Post Types (CPT) sont pertinents quand un contenu ne correspond ni à un article ni à une page : des fiches produits, des réalisations de portfolio, des témoignages, des offres d’emploi, des biens immobiliers. Créer un CPT pour chacun de ces types donne une taxonomie dédiée, des templates spécifiques et une architecture propre. Le piège : créer des CPT pour tout, y compris pour des contenus qui seraient parfaitement à leur place comme articles ou pages. Un CPT ajoute de la complexité — templates à maintenir, requêtes supplémentaires, plugins de gestion — donc il ne se justifie que quand les deux types natifs ne conviennent pas.

Comment savoir si la structure de mon site pose problème pour le SEO ?

Deux vérifications rapides. D’abord, regarder le sitemap XML (généralement accessible à /sitemap.xml) : si des pages de services apparaissent dans le sitemap des articles, ou si des billets de blog se retrouvent dans le sitemap des pages, la structure est incohérente. Ensuite, vérifier dans Google Search Console les pages indexées : si Google positionne un article de blog plutôt que la page de services sur un mot-clé stratégique, c’est un signe de cannibalisation liée à une mauvaise structuration. Un audit de maintenance incluant la vérification de la structure des contenus permet d’identifier et de corriger ces problèmes avant qu’ils n’impactent le trafic.

Vous suspectez des problèmes de structuration sur votre site WordPress ?