Qu’est-ce qu’un article orphelin et pourquoi le réparer par l’API REST
Un article orphelin désigne un contenu publié sur le site mais qui ne reçoit aucun lien interne depuis une autre page : il n’est accessible qu’en tapant l’URL directement, via une recherche externe ou un lien de réseau social source : Inlinks, 2024. Réparer ce défaut par l’API REST permet d’ajouter des liens contextuels sur des dizaines d’articles en une seule exécution, sans ouvrir chaque page dans l’éditeur.
C’est ce qu’on a fait fin juin 2026 sur le blog d’une boutique de réparation de smartphones à Paris, cliente Peechy : 54 articles au total, dont 29 en Elementor et 25 en Gutenberg. Le résultat et sa limite servent de fil conducteur à ce tutoriel.
Prérequis
- Un accès administrateur WordPress avec un mot de passe d’application (Application Passwords) pour authentifier les requêtes API.
- La liste complète des articles (
wp-json/wp/v2/posts?per_page=100) avec leur ID, leur titre et leur type d’éditeur. - Les URL ou ID des pages commerciales cibles (fiches de réparation écran, batterie, connecteur de charge, récupération de données, dans notre cas).
- Un script (PHP ou Node) capable d’envoyer des requêtes POST et de parser du contenu HTML ou JSON.
- Une sauvegarde de la base de données avant toute écriture en masse.
Étape 1 : lister les articles et repérer les vrais orphelins
L’API REST de WordPress est une interface qui permet de lire et de modifier le contenu du site par des requêtes HTTP, sans passer par l’écran d’administration source : WordPress REST API Handbook. Un premier appel GET sur wp/v2/posts récupère tous les articles avec leur champ content.rendered.
Pour trouver les orphelins, on ne se fie pas au sitemap : un article présent dans le sitemap peut n’avoir aucun lien entrant. La méthode fiable consiste à croiser deux sources : le rapport « Internal links » de Google Search Console, ou un crawl Screaming Frog filtré sur les pages sans lien entrant source : American Eagle. Sur les 54 articles du blog client, ce croisement a isolé les 25 rédigés en Gutenberg comme totalement orphelins : aucun lien contextuel ne pointait vers eux depuis le reste du blog.
Étape 2 : choisir les ancres et les pages commerciales cibles
Un maillage interne qui ne sert qu’à cocher une case SEO ne rapporte rien. L’objectif ici était de faire converger le trafic des 25 articles orphelins vers quatre pages commerciales : écran, batterie, connecteur de charge et récupération de données. Chaque article a été relu pour repérer les passages où une ancre naturelle avait du sens (« l’écran fissuré » renvoyant vers la page réparation écran, par exemple), plutôt que d’insérer un lien générique en fin de texte.
Étape 3 : injecter les liens contextuels via une requête POST
Sur un article Gutenberg, le contenu réel est stocké dans post_content. Une mise à jour se fait avec une requête POST vers wp-json/wp/v2/posts/<id> contenant le HTML modifié source : WordPress REST API Handbook. Le script parcourt le HTML, repère les mots ou expressions choisis à l’étape précédente, insère la balise <a href="..."> autour, puis renvoie l’intégralité du contenu modifié dans le champ content.
En complément des liens contextuels, un bloc « À lire aussi » a été ajouté en pied de chaque article, avec des liens vers les quatre pages cibles. Résultat sur ce chantier : 93 liens internes contextuels ajoutés sur les 25 articles Gutenberg, répartis entre liens dans le corps du texte et bloc de fin d’article.
Étape 4 : la limite Elementor, et pourquoi elle bloque tout
C’est là que le script s’est arrêté net sur 29 des 54 articles. Sur une page construite avec Elementor, le contenu affiché en frontend n’est pas dans post_content : il est sérialisé en JSON dans le champ meta _elementor_data source : Elementor Developers. Cette structure décrit chaque section, colonne et widget de la page, avec un identifiant widgetType propre à chaque élément (titre, image, bouton, texte) source : Elementor Developers, General Elements.
Concrètement, mettre à jour post_content sur un article Elementor ne change rien à ce que voit le visiteur : Elementor régénère l’affichage à partir de _elementor_data, pas depuis le champ standard source : GitHub Elementor issue #8114. Sur les 29 articles Elementor du blog client, cette limite s’est confirmée telle quelle : impossible de modifier proprement le corps via post_content, il aurait fallu parser et réécrire le JSON de _elementor_data widget par widget, une opération plus lourde et plus risquée qu’une simple insertion de balise HTML.
| Éditeur | Champ réellement utilisé | Modification par API REST |
|---|---|---|
| Gutenberg | post_content | Directe, POST simple sur wp/v2/posts/<id> |
| Elementor | _elementor_data (meta JSON) | Nécessite de parser et réécrire l’arborescence JSON, widget par widget |
Pour qu’un champ meta personnalisé soit exposé et modifiable par l’API REST, il doit être enregistré via register_meta ou register_post_meta source : WordPress REST API Handbook, ce qui n’est pas le cas par défaut pour _elementor_data. Sur ce chantier, la décision a été de traiter les 25 articles Gutenberg par script et de laisser les 29 articles Elementor pour un passage manuel ultérieur.
Étape 5 : corriger la typographie française au passage
Le script qui touche à 54 titres est aussi l’occasion de rattraper les défauts typographiques accumulés au fil des années. En français, une espace insécable précède la ponctuation double (:, ;, !, ?) et encadre les guillemets français source : Blog du Modérateur, 2024. Sur ce blog, les espaces insécables ont été corrigées sur les 54 titres, Gutenberg et Elementor confondus : cette correction touche le champ post_title, disponible en écriture par l’API REST sur tous les articles, quel que soit leur éditeur.
Pièges courants
- Oublier de sauvegarder avant d’écrire en masse. Une requête POST malformée sur 25 articles d’affilée peut corrompre du contenu sans avertissement visible immédiat.
- Traiter Elementor comme Gutenberg. Modifier
post_contentsur un article Elementor donne l’illusion que le lien a été ajouté (le champ change bien en base) alors que rien n’apparaît en frontend. - Insérer des liens sans lire le contexte. Un script qui remplace la première occurrence d’un mot-clé peut créer une ancre absurde en plein milieu d’une phrase.
- Ignorer les guillemets et espaces lors de la génération automatique. Un bloc « À lire aussi » généré par script hérite souvent d’une apostrophe droite ou d’un espace simple là où le français exige une espace insécable.
- Confondre présence dans le sitemap et absence d’orphelinage. Un article indexé peut rester sans aucun lien entrant, ce qui pénalise sa capacité à se positionner source : Inlinks, 2024.
Un article orphelin est-il désindexé par Google ?
Non, pas automatiquement. Un article orphelin peut rester indexé s’il figure dans le sitemap, mais il reçoit peu d’autorité interne et se positionne généralement moins bien qu’un article correctement relié source : Inlinks, 2024.
Peut-on modifier le contenu Elementor par l'API REST ?
Techniquement oui, mais pas via le champ post_content : il faut lire, parser et réécrire le JSON stocké dans le meta _elementor_data, ce qui demande de manipuler la structure de widgets d’Elementor plutôt qu’une simple chaîne HTML.
Faut-il un plugin pour ce type de maillage interne ?
Non. Un script qui utilise l’API REST native de WordPress suffit pour les articles Gutenberg. Pour les articles bâtis avec un constructeur de pages comme Elementor ou WPBakery, voir aussi les erreurs WPBakery courantes qui posent des limites similaires côté frontend.
Comment repérer les articles orphelins sans outil payant ?
Le rapport « Internal links » de Google Search Console suffit pour un premier tri, en identifiant les pages avec zéro lien entrant recensé. Un crawl gratuit avec Screaming Frog (jusqu’à 500 URL) complète le diagnostic en filtrant sur le rapport Inlinks source : American Eagle.
Sur un blog mixte, la vraie question n’est pas « comment automatiser le maillage » mais « quels articles s’y prêtent ». Gutenberg s’automatise proprement en une exécution de script. Elementor demande soit un développement dédié pour manipuler _elementor_data, soit un passage manuel article par article, comme pour tout ce qui touche à l’optimisation d’un site sous Elementor.
Ce problème, Peechy s'en occupe
Plutôt que de tout gérer seul, confiez votre site à une agence qui s'occupe de tout, hébergement, sécurité, maintenance et corrections. Encore plus simple en abonnement : on règle les soucis avant même que vous les remarquiez.
Confier mon site à Peechy