Pour les éditeurs

Comblez la longue traîne que votre rédaction ne peut pas atteindre.

Une publication a déjà l’autorité, les archives et les standards. Ce qu’elle n’a pas, c’est un après-midi libre par langue pour les milliers de questions précises qui ne justifient jamais un journaliste — mais qui représentent une part importante de ce qui est recherché. C’est cette couche que couvre Xt4b, sous votre relecture, sur un domaine que vous possédez.

Validation avant publicationUne ligne par marchéSyndication ou hébergement

Ce à quoi les archives ne répondent pas encore.

Pas l’article du jour. La couche de référence en dessous, là où vit la demande de recherche durable.

La longue traîne sans réponse
Les questions précises à faible volume que votre rédaction traiterait si elle avait un après-midi libre : procédures, comparaisons, délais, définitions, détails locaux. Isolées, elles sont petites ; ensemble, elles représentent l’essentiel des recherches.
La couche intemporelle
Du contenu de procédure et de référence qui n’expire pas avec le cycle de l’actualité et continue de générer des impressions entre les articles qui montent puis retombent.
Un marché à la fois
Chaque langue est planifiée à partir des recherches de son propre marché, avec ses propres dates, plutôt qu’une traduction automatique des archives anglaises que personne dans ce marché ne taperait jamais.
Séries et clusters
Les entrées peuvent être regroupées pour qu’une série d’articles construise vraiment un sujet, au lieu de disperser des articles isolés sur un thème sans jamais y revenir.
Une surface lisible par machine
Sitemap, URL canoniques, données structurées et un llms.txt par blog, générés à partir de ce qui est publié — pour que les crawlers et les moteurs de réponses puissent lire les archives correctement.
La syndication selon vos conditions
S’il ne doit pas s’agir d’un blog hébergé, récupérez les articles via l’API en Markdown ou en HTML rendu et publiez-les dans le CMS que vos rédacteurs utilisent déjà.

La version régulière d’une archive.

Cinq étapes, et la troisième est celle qui préserve les standards d’un titre : ce que la rédaction garde et ce qu’elle écarte.

  1. 01

    Analyser le domaine

    Gratuit et sans compte : la page d’accueil et le sitemap, ainsi que les requêtes auxquelles la publication ne répond pas encore. Sur une grande archive, cet écart est généralement la partie intéressante.

  2. 02

    Connectez un marché

    Un enregistrement DNS pour un nom d’hôte de blog sous un domaine que vous possédez, une ligne de langue pour commencer. Rien n’est installé et votre CMS continue de servir l’archive qu’il sert aujourd’hui.

  3. 03

    Fixez le standard éditorial

    Le plan montre la requête, l’intention, le plan détaillé et la date. Votre rédaction écarte ce qui ne correspond pas aux standards du titre — avant qu’un seul mot soit écrit.

  4. 04

    Laissez la validation activée

    La validation peut être exigée pour tout le compte, ce qui est généralement le bon réglage par défaut pour un éditeur : rien n’est publié sous votre titre sans qu’une personne ne le valide.

  5. 05

    Des rapports par site et par requête

    Search Console en lecture seule : les requêtes de longue traîne pour lesquelles le domaine gagne des impressions, marché par marché, à côté des sujets que votre rédaction suit déjà.

Ce qui reste à la rédaction.

Les standards d’un titre ne sont pas un gabarit, et une pipeline ne peut pas s’y substituer. Tout ce qui comporte un risque juridique, se lit comme un reportage ou touche un sujet sur lequel vos juristes ont un avis est une décision qui revient aux personnes dont les noms figurent sur le titre.

Ce que Xt4b peut faire, c’est maintenir la couche de référence à jour — par marché, selon un rythme régulier — pendant que la rédaction consacre son temps au travail que seule la rédaction peut faire.

  1. Les standards éditoriaux, le style maison et la ligne que vous ne franchirez pas
  2. Tout ce qui se lit comme un reportage plutôt que comme une explication
  3. Le risque juridique, la diffamation et les sujets qui exigent un avocat
  4. Les sujets interdits à la production automatisée
  5. Les corrections, et la décision de ce qui est retiré

Un pic, ou une archive.

Le trafic d’actualité est par nature en pics. La couche en dessous ne l’est pas, et c’est cette couche qui mérite d’être automatisée.

Des pics, rien d’autre

  • Un trafic qui arrive avec un sujet et repart avec lui
  • Rien de publié dans les semaines entre deux sujets
  • Les questions de référence traitées par qui est disponible
  • Une seule langue, quel que soit le nombre de marchés que sert le titre
  • Aucun reporting sur la longue traîne, parce qu’elle n’a jamais été construite

Des pics et une archive

  • Une base de pages durables sous le trafic d’actualité
  • Un article à chaque jour de publication, pic ou pas
  • Une réponse par requête, relue avant publication
  • Chaque marché planifié à partir de ses propres recherches
  • Les impressions par requête, par marché, dans Search Console

Ce que ce n’est pas

Ce n’est pas une rédaction, pas un fil d’agence et pas un remplacement du reportage. Il ne publie pas à chaud, ne réagit pas aux événements et ne décide pas de ce qui compte — et si la réputation d’une publication repose sur l’accès original et l’analyse, cette réputation n’est pas touchée par ce qui est publié ici.

La mise en garde habituelle s’applique aussi, sans ornement : les positions, le trafic et les revenus ne sont pas garantis. L’archive ici est un ensemble de travaux publiés selon un rythme régulier, relus par vous, sur un domaine que vous possédez.

La surface lisible par machine, gratuitement.

Chaque blog est servi avec les fichiers qu’attendent un crawler ou un moteur de réponses, générés à partir de ce qui est publié — ce qui compte d’autant plus que l’archive grandit.

Un sitemap listant chaque article publié, un robots.txt qui invite au crawl, une URL canonique sur chaque page, des données structurées par article et un llms.txt qui indexe l’archive pour les modèles qui en lisent un. Rien de tout cela ne nécessite un plugin, une compilation ou un développeur.

Les éditeurs qui ont déjà un CMS peuvent plutôt récupérer les mêmes articles sous forme de données : Markdown ou HTML rendu, une requête par page de résultats, filtrée par site et par langue.

  1. Sitemap généré à partir des seuls articles publiés
  2. URL canoniques, une page par article
  3. Données structurées avec la date réelle de l’article
  4. Un llms.txt qui indexe le blog pour les modèles de langage
  5. API en lecture seule pour syndiquer vers votre propre CMS
Ce que renvoie l’API de lecture, champ par champ

Les questions que posent les éditeurs.

Notamment si cela remplace une rédaction, si tout peut être relu, et comment une grande archive ne se gêne pas elle-même.

Est-ce que cela remplace les rédacteurs ou les journalistes ?

Non, et cela ne doit pas être présenté ainsi. Il comble la couche sous la salle de rédaction : les questions de référence et de procédure qui ne justifient jamais un après-midi de journaliste mais qui, ensemble, représentent une part importante des recherches. Le reportage, le jugement et la voix restent à la rédaction.

Pouvons-nous tout relire avant publication ?

Oui, et pour un éditeur c’est le réglage judicieux. La validation peut être exigée pour le compte : chaque brouillon attend donc qu’une personne le valide — et la relecture peut se faire plus tôt, au moment de la planification, où écarter une entrée ne coûte rien.

Va-t-il produire de l’actualité ?

Non. Il n’existe aucun mécanisme pour réagir à un événement, et rien ne doit prétendre le contraire. Le plan couvre des questions durables — comment fonctionne quelque chose, ce qu’implique une procédure, comment deux options se comparent — c’est-à-dire la partie de la surface d’une publication qui n’a pas besoin d’une rédaction d’astreinte.

Comment gère-t-il plusieurs marchés en même temps ?

Chaque langue est une ligne distincte avec son propre plan et son propre calendrier, planifiée à partir des recherches de ce marché. C’est la différence entre ajouter un marché et traduire vers un marché : les entrées allemandes sont construites à partir de requêtes allemandes, pas de vos archives anglaises.

Les articles peuvent-ils plutôt aller dans notre propre CMS ?

Oui. L’API de lecture renvoie chaque article en Markdown ou en HTML rendu, avec les métadonnées et les images, via une clé au niveau du compte — un build ou un import peut donc les publier là où vos rédacteurs travaillent déjà. Rien dans l’API ne peut réécrire dans Xt4b.

Et le contenu dupliqué par rapport à nos archives ?

Chaque entrée cible une requête à laquelle le domaine ne répond pas encore, et chaque page porte sa propre URL canonique. Là où vos archives répondent déjà à une question, c’est cette page qui doit se positionner, et le blog renvoie vers elle au lieu de la reformuler.

Le volume nuit-il à un site ?

Publier en volume des pages quasi identiques, oui, c’est pourquoi le plan prévoit une requête par article et que le rythme est un choix plutôt qu’un réglage de production maximale. Un calendrier plus lent de réponses distinctes est la façon la plus défendable de construire une archive.

Combien cela coûte, et qu’est-ce qui est garanti ?

20 € par site, par langue, par mois, l’analyse étant gratuite et sans compte. Les résultats, non : les positions, le trafic et les revenus ne sont pas garantis, ce qui est indiqué dans les conditions d’utilisation et dans chaque réponse de ce site.

Commencez par vos archives

Construisez la couche sous l’actualité.

Analysez le domaine et lisez le plan : les requêtes auxquelles vos archives ne répondent pas encore, les plans détaillés derrière, et les dates auxquelles elles seraient publiées.

Relecture avant publication20 € / site / langue / mois3 jours gratuits, sans carte bancaire