Pipeline de blog
Ce que vous obtenez : un article qui répond à une recherche réelle, dans votre voix, avec des faits vérifiés, une image 1200x630 et un frontmatter valide, qui attend votre relecture dans son propre dossier.
Première chose à faire : placez un fichier BLOG.md rempli à la racine de votre projet (le modèle se trouve dans ce dépôt). Chaque étape le lit.
À lire en premier, à chaque fois
BLOG.mdà la racine du projet : site, lecteur, objectif, voix, mots à éviter, catégories, cadence, règles SEO et d'image, valeurs par défaut du frontmatter et la liste des Corrections. Là oùBLOG.mdet cette compétence divergent,BLOG.mdprime.references/frontmatter-contract.mdavant d'écrire tout frontmatter.- Le fichier de référence pour l'étape que vous exécutez, et rien d'autre dont vous n'avez pas besoin.
Pas encore de BLOG.md ? Arrêtez-vous et proposez d'en créer un. Lisez 3 à 5 des articles ou pages existants de la personne, posez les questions de chaque section du modèle, écrivez le fichier et demandez-lui de le vérifier. Un article écrit sans cela ressemble à n'importe qui.
Comment ça fonctionne
Un article de blog est la réponse à quelque chose qu'une personne tape dans Google. La connaissance peut provenir d'une conférence, d'une newsletter ou d'un appel client ; l'article la reconstruit autour d'une seule recherche : un titre qui correspond à la recherche, la réponse près du haut, des titres de section formulés comme les gens cherchent.
Rafraîchissez avant d'écrire du nouveau. Vérifiez si un article ou une page existante cible déjà la recherche. Un article que Google montre déjà, avec des vues et sans clics, vaut plus qu'un nouvel article à partir de zéro, et nécessite une fraction du travail. Deux pages visant une seule recherche perdent généralement toutes les deux.
Le dossier de travail
Un dossier par article, dans le projet de la personne : posts/<AAAA-MM-JJ>-<slug>/. La date est le jour de publication prévu. Le slug est l'adresse finale et le nom du fichier. Chaque étape écrit un fichier dans le dossier, donc le dossier sert de mémoire : toute étape peut être réexécutée ou reprise plus tard sans refaire les étapes précédentes.
| # | Étape | Lit | Écrit | Instructions |
|---|---|---|---|---|
| 1 | Idéation | BLOG.md, données de recherche, articles et pages existants | posts/_ideas/topic-ideas.md | references/01-ideation.md |
| 2 | Brief | un sujet | brief.md | references/02-brief.md |
| 3 | Recherche | brief.md | research.md | references/03-research.md |
| 4 | Brouillon | research.md, brief.md, BLOG.md | draft.md | references/04-draft.md |
| 5 | Visuels | draft.md | visuals.md, <slug>.svg, <slug>.png | references/05-visuals.md |
| 6 | Publication | draft.md, visuals.md | l'article dans src/content/blog/, images dans public/images/blog/, publish.md | references/06-publish.md |
La chaîne complète : étapes 2 à 6 dans l'ordre pour un sujet. L'étape 1 est une étape par lots : exécutez-la lorsque la liste d'idées s'épuise, environ une fois par mois pour une cadence hebdomadaire.
"Planifier mon premier article" (ou "planifier mon prochain article") : étape 1, puis étape 2. Exécutez l'idéation, montrez la shortlist, laissez la personne choisir un sujet (pas nécessairement le n°1 ; enregistrez le choix et la raison dans topic-ideas.md), puis rédigez son brief. Arrêtez-vous après le brief et dites quelle étape vient ensuite. Lorsque la personne demande de "trouver des idées de sujets", exécutez l'étape 1 uniquement ; lorsqu'elle demande de "rédiger le brief pour ", exécutez l'étape 2 uniquement.
Une seule étape : la personne nomme l'étape et l'article. Lisez le fichier de cette étape et ses entrées, et ignorez le reste.
Un rafraîchissement : sautez les étapes 1 et 2. Créez le dossier posts/<aujourd'hui>-<slug>-refresh/, exécutez les étapes 3 et 4 en mode rafraîchissement, puis l'étape 6.
Les chemins ci-dessus sont ceux du site de démarrage. Si BLOG.md liste d'autres dossiers, utilisez ceux-là.
Règles
Elles remplacent tout fichier d'étape. BLOG.md peut en ajouter.
- N'inventez jamais une source, une statistique, une citation ou un lien. Chaque URL dans un article a été ouverte pendant la recherche. Une affirmation que vous ne pouvez pas vérifier est supprimée, ou marquée
[NON VÉRIFIÉ]pour que la personne la confirme. La propre expérience de la personne compte comme une source lorsqu'elle est étiquetée comme sienne. Un chiffre provenant de son travail nécessite un fichier dans le projet ou une citation de chat datée enregistrée dansresearch.md(étape 3) ; sans cela, c'est[NON VÉRIFIÉ]et reste hors du fichier publié. - Vérifiez les faits concernant les outils et les plateformes par rapport à la documentation actuelle. Les fonctionnalités et les limites changent, et le mode d'emploi de l'année dernière est souvent erroné aujourd'hui.
- Les chiffres de recherche sont des données ou ils sont étiquetés. Le volume et la difficulté proviennent d'un outil que quelqu'un a exécuté, avec la date, ou le fichier indique "non estimé". Un nombre deviné présenté comme une donnée est pire que pas de nombre.
- La personne relit chaque brouillon avant sa publication. Les nouveaux articles reçoivent
draft: true. La compétence ne push, ne déploie ni ne basculedraftpar elle-même. La seule exception est un rafraîchissement d'un article en ligne, qui conservedraft: false(voir étape 6). - Approbation : quand, comment et où vont les modifications. C'est le seul endroit où la compétence le définit ; l'étape 6 le suit.
- Quand : à tout moment après que l'étape 6 a écrit le fichier publié et que la personne a lu l'article. La même session convient.
- Comment : un changement. La personne définit
draft: falsedanssrc/content/blog/<slug>.md, ou le dit à Claude. Confirmez quedateest le jour de publication en même temps. - Où vont les modifications : avant l'étape 6, dans
posts/<dossier>/draft.md. Après l'étape 6, dans le fichier publié uniquement.draft.mdreste en tant que brouillon qui a été remis, etpublish.mdliste chaque modification effectuée après. - Ce qui retarde : tout ce qui reste à faire avant la date (une page manquante, une affirmation
[NON VÉRIFIÉ], une ligne que l'audit de liens imprime) maintient l'article àdraft: truejusqu'à ce que ce soit terminé.
- La date est la porte de publication. Le démarreur cache un article daté dans le futur jusqu'à son jour et le liste sous Articles à venir.
- Le travail client reste anonyme sauf si le client a accepté d'être nommé. Supprimer le nom est le début : vérifiez les combinaisons de catégorie, de lieu et de calendrier qui l'identifient encore ("une boutique de bougies dans le Vermont qui a lancé en mars" est un nom). Convertissez les revenus en ratios ou pourcentages.
- Répondez d'abord. Un temps de contexte que le lecteur reconnaît de son propre travail, puis la réponse avant la fin du troisième paragraphe. Une question n'ouvre jamais un article.
- Écrivez pour la recherche, avec un seul appel à l'action. Titres de section formulés comme les gens cherchent, chiffres en numéraux, paragraphes courts. L'action principale est celle de la section 3 de
BLOG.md, et correspond àctadanssrc/site.config.mjs. Le démarreur montre ce bouton, avec une boîte d'abonnement, à la fin de chaque article, donc le corps n'a pas besoin de lien d'appel à l'action de clôture. Le corps peut lier à l'action principale une fois, dans le texte, uniquement là où cela s'intègre à l'article, et uniquement vers une page qui existe ou vers l'adressecta. - Lie uniquement vers des pages qui sont en ligne à la date de publication de l'article. Cela signifie chaque lien vers le propre domaine du site, articles et pages confondus. Écrivez les liens vers le propre site sous forme de liens relatifs (
/about/). L'étape 6 a la vérification. - La voix appartient à la personne. Un brouillon qui ressemble à du contenu compétent d'un inconnu a échoué, même si chaque règle est respectée.
Les corrections deviennent des règles
Lorsque la personne corrige la même chose deux fois (un mot, une ouverture, un style de titre), proposez d'ajouter une ligne datée à la section Corrections de BLOG.md. L'étape 4 lit cette section avant chaque brouillon, donc une correction faite une fois reste faite.
Avant de remettre un brouillon
Recherchez dans le brouillon chaque mot de la section "Mots à éviter" de BLOG.md, par exemple :
grep -n -i -E "mot un|mot deux|—" posts/<dossier>/draft.md
Une recherche de mots manque les formes de phrases. Exécutez la recherche de formes à l'étape 4 ("Formes qu'une recherche de mots manque"), puis lisez le brouillon une fois pour les formes que BLOG.md liste et qu'aucune recherche ne détecte, comme une question d'ouverture ou un récapitulatif de clôture. Vérifiez également chaque phrase factuelle par rapport à research.md (étape 4).
Ensuite, dites à la personne, en quelques lignes : où se trouve le brouillon, la recherche cible, la date prévue, tout ce qui est marqué [NON VÉRIFIÉ], toute question de confidentialité, et ce qu'elle doit décider.
Optionnel : une version newsletter
Si la personne publie également une newsletter (Substack, Beehiiv, Kit ou similaire), la même connaissance peut y être diffusée. Donnez à la version newsletter son propre titre et sa propre phrase de recherche, afin que les 2 pages ne soient pas en concurrence dans Google, et ajoutez l'archive de la newsletter à la vérification de chevauchement aux étapes 1 et 2.
Outils
Claude Code, ou Claude avec accès aux fichiers du projet. Les données de recherche proviennent d'outils gratuits : auto-complétion Google, Google Search Console, le plan Ubersuggest gratuit et une simple recherche Google pour la première page. Si un outil n'est pas connecté, demandez à la personne de coller ce qu'elle voit (Ubersuggest fonctionne très bien sur son site Web), ou marquez le nombre comme non estimé. Un nouveau site sans données ni outils peut toujours avancer : references/01-ideation.md a le chemin.
Pas d'accès Web dans cette session : l'étape 1 classe les idées sur les preuves dont elle dispose et marque le reste "non vérifié". La personne colle les suggestions d'auto-complétion et la première page pour la seule recherche cible qu'elle a choisie, à l'étape 2, avant que le brief ne soit approuvé. Personne ne colle pour toute la shortlist. Gardez les clés API hors de BLOG.md et hors des dossiers d'articles.