Contexte

Bing Webmaster Tools remontait une recommandation “There are too many pages with insufficient content” (sévérité : modérée) — 15 pages en erreur, toutes du même type :

• https://www.arleo.eu/en/tags/svg/
• https://www.arleo.eu/en/tags/sonarr/
• https://www.arleo.eu/en/categories/incidents/
• etc.

Ces pages sont les taxonomies Hugo — les listes par tag et par catégorie. Elles ne contiennent pas d’article en elles-mêmes, juste une liste de liens. Pour Bing, c’est du thin content.

Stratégie choisie

Trois options s’offraient :

1. Bloquer via robots.txt → déconseillé : empêche le crawl, masque les liens internes
2. Enrichir le contenu des pages de taxonomie → trop coûteux pour un blog technique
3. noindex,follow → la bonne réponse : on dit aux robots de ne pas indexer la page, mais de suivre les liens vers les articles

L’option 3 est retenue. Le follow préserve le maillage interne — les robots continuent de découvrir les articles via ces pages.

Contexte

Google Search Console remontait quatre catégories de problèmes sur arleo.eu :

• 404 Googlebot : /fr/tag/cloudflare, /en/tag/nginx, /fr/tag/javascript… URLs avec préfixe /fr/ ou singulier /tag/ jamais servi par nginx
• 16 pages “Exclue par la balise noindex” : toutes des pages de redirection générées par aliases: dans le frontmatter Hugo
• Balise robots : noodp hardcodée dans le thème LoveIt
• Sitemap FR/EN : 104 vs 105 URLs — un tag doublon FR et deux tags manquants

Acte 1 : aliases Hugo → redirections nginx 301

Pourquoi Hugo génère des pages noindex

Hugo génère les entrées aliases: du frontmatter comme des fichiers HTML statiques :

Problème

Les diagrammes Mermaid sur arleo.eu rendaient côté client via cdn.jsdelivr.net. Trois conséquences concrètes :

1. CSP contrainte — script-src cdn.jsdelivr.net et worker-src cdn.jsdelivr.net obligatoires (Mermaid v11 utilise des Web Workers pour ses parsers).
2. Flash de rendu — le diagramme apparaît après l’exécution JS, créant un décalage visible.
3. Thème dark ignoré — Mermaid initialisait le SVG en mode clair même quand le thème du site était dark.

La solution : générer les SVG au build avec mmdc, en dehors de tout contexte navigateur.

Contexte

arleo.eu tourne sur Hugo (VM KVM) → OpenResty (NUC) → Cloudflare (CDN/WAF). Objectif : score A+ sur Mozilla Observatory avec une CSP stricte qui résiste aux injections côté edge.

Le parcours a traversé trois stratégies en quelques semaines — nonces, hashes, puis origin allowlist — avant d’aboutir à une solution stable et automatisée.

Acte 1 : pourquoi hash-based a échoué

L’idée de départ semblait solide : Hugo Pipes externalise tout le JS avec SRI, on liste les hashes dans la CSP, résultat propre. En pratique, deux problèmes ont rendu l’approche impossible.

TL;DR

Le plugin Cloudflare de hugo-mcp v2.0 implémente 3 modes de purge cache (full, partial, smart). Le mode partial calcule les URLs liées à invalider (canonique + sitemap + RSS + listing + home) pour préserver 95% du cache CDN à chaque modification. Concrètement : 6 URLs purgées au lieu de tout vider. Ce post détaille le calcul, les pièges, et pourquoi smart est devenu le défaut.

⚡ En bref

Un audit de la stack sécurité du NUC révèle une double inspection WAF redondante : ModSecurity + OWASP CRS chargent 11 872 règles en mémoire malgré SecRuleEngine Off, en parallèle d’un CrowdSec AppSec déjà actif et couvrant le même périmètre. Après suppression du module nginx ModSecurity et 5 autres correctifs ciblés, nginx passe de ~520 MB à ~27 MB PSS. Sécurité identique, empreinte divisée par 20.

🏗️ Architecture avant audit

La stack sécurité reposait sur six couches empilées :

TL;DR

hugo-mcp v2.0.0 introduit un plugin-system Python qui permet à n’importe qui d’ajouter des hooks après chaque create_page / update_page / delete_page. 200 lignes de code pour le coeur, 3 plugins de production fournis (IndexNow, Google Indexing, Cloudflare). Ce post explique le design, les arbitrages, la sécurité, et montre comment écrire son propre plugin en 5 minutes.

TL;DR

Le 9 mai 2026, j’ai basculé arleo.eu de Grav (CMS PHP) vers Hugo (générateur de site statique Go) en une session. Bascule atomique (≈ 0 seconde de downtime), 22 articles legacy migrés sous /posts/ avec aliases SEO pour préserver les URLs Google indexées, monitoring BetterStack /ping intact pendant toute l’opération.

Le code et le script de migration sont open source : github.com/jmrGrav/grav-to-hugo-migration.

TL;DR

Le 9 mai 2026, j’ai livré en une session marathon les 10 chantiers du sprint sécurité MCP que j’avais annoncé en début de journée. hugo-mcp est désormais en v1.9.0 (GitHub Release), commit 1404f83 GPG-signé.

Voici le recap haute-volée + un zoom pédagogique sur 2 chantiers qui ont une vraie valeur en dehors de mon contexte précis : C2 token rotation et C6 TLS interne.

Recap des 10 chantiers

Détails complets dans le CHANGELOG v1.9.0 et le commit 1404f83.

Le problème

Tu as un site Hugo. Tu veux pouvoir :

1. Éditer le contenu via Claude.ai (publier un article, corriger une coquille, mettre à jour un draft) sans toucher à un terminal SSH.
2. Versionner la structure (layouts, themes, hugo.toml, scripts de déploiement) dans Git, comme un dev sérieux.

Premier réflexe : « tout dans Git ». Les articles aussi. Le MCP commit, push, le webhook GitHub fait un rebuild. Propre, dans la philosophie GitOps.

Sauf que ça ne marche pas si bien. Voici pourquoi, et la solution simple que j’appelle la Stratégie 4.

Pourquoi « tout dans Git » casse en pratique

Imaginons que ton MCP fait un git commit à chaque create_page. Stratégie naïve, mais souvent proposée. Voici les problèmes :

Problème 1 — Conflit MCP ↔ Git

Tu push depuis ton laptop un nouveau layout (layouts/index.html modifié). Au même moment, le MCP est en train de commiter une nouvelle version d’un article. Race condition, le MCP peut faire un git pull --rebase qui échoue, ou pire, écraser ton commit local.

Problème 2 — Identité Git du MCP

Le MCP commit en tant que qui ? Avec quelle clé GPG ? Si tu as une politique « commits signés obligatoires », le MCP doit gérer une clé GPG, qu’il faut sécuriser, faire tourner, etc.

Problème 3 — Auto-commit indésirable

Tu fais un test, tu crées un article draft pour expérimenter, tu le supprimes. Mais le MCP a déjà commité. Maintenant tu as un commit “wip test” dans l’historique, à rebaser ou squasher manuellement.

Problème 4 — Réversibilité asymétrique

Un git revert côté repo n’a aucun effet sur les fichiers que le MCP a déjà créés. Tu te retrouves avec un repo et un état filesystem désynchronisés.

La Stratégie 4 : séparer les zones

L’idée : MCP et Git n’écrivent jamais sur les mêmes fichiers.

Le .gitignore côté repo :

content/
public/
resources/

Implications :

• Le MCP peut écrire dans content/ quand il veut. Aucun conflit Git possible.
• Tu peux faire git reset --hard côté repo en confiance — content/ reste intact.
• Pas besoin que le MCP gère une identité Git.
• Pas de “commit pollution”.

Trade-off : pas de versioning du contenu

Tu perds le versioning Git du contenu. C’est une perte réelle :

• Pas de git blame sur un article pour voir qui a écrit quoi.
• Pas de git log content/csp-nonce/index.fr.md pour voir l’historique.
• Pas de PR review pour les articles.

Mitigation : snapshots VM + backup content/ chiffré quotidien sur QNAP. Ça couvre la récupération en cas de désastre, mais pas le versioning fin (qui-a-changé-quoi-quand).

Pour mon homelab perso (un seul auteur, articles techniques, pas de workflow de validation éditoriale), c’est un trade-off acceptable. Pour un blog d’équipe avec 10 contributeurs, je reconsidérerais.

Architecture finale