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.

Après des années avec ModSecurity + OWASP CRS sur nginx, j’ai migré arleo.eu vers une stack plus moderne : CrowdSec AppSec sur OpenResty. Le résultat est une architecture WAF inline mieux intégrée, plus facile à maintenir, et plus cohérente avec le reste de la stack de sécurité.

Pourquoi abandonner ModSecurity ?

ModSecurity v2 est en fin de vie active. Le maintien des règles OWASP CRS sur nginx classique génère de la friction : faux positifs fréquents, logs difficiles à corréler avec CrowdSec, et une configuration dispersée entre plusieurs outils sans vision unifiée.

Pourquoi le SRI ?

Quand votre site charge des ressources depuis un CDN tiers — FontAwesome, Mermaid, Animate.css — vous faites confiance à un tiers sur lequel vous n’avez aucun contrôle. Si jsdelivr.net est compromis ou si une version « immuable » est mutée silencieusement, votre site peut devenir vecteur d’attaque.

Le Subresource Integrity (SRI) résout ça simplement : chaque balise <link> ou <script> porte un attribut integrity="sha256-…" que le navigateur vérifie avant d’exécuter la ressource. Si le hash ne correspond pas, le navigateur bloque le chargement.

TL;DR

systemd-analyze security est un outil sous-utilisé. Il scanne tes unit files et calcule un score d’exposition de 0.0 (UNSAFE) à 10.0 (PERFECT). Les services Python custom sortent souvent autour de 9.6 par défaut — c’est mauvais.

J’ai fait passer mon service hugo-mcp (FastAPI exposant 7 tools MCP) de 9.6 → 1.7 sans casser la moindre fonctionnalité. Voici les directives qui comptent vraiment, et celles qui sont des pièges.

Le score initial

$ sudo systemd-analyze security hugo-mcp
→ Overall exposure level for hugo-mcp.service: 9.6 UNSAFE 😨

9.6 sur 10. Le service tourne en root équivalent, peut faire setuid(), peut allouer de la mémoire RWX, voit tous les processus du système, peut écrire partout, peut faire des syscalls arbitraires.

Pour un MCP qui édite du contenu Markdown et déclenche un build Hugo, c’est démesuré.

TL;DR

arleo.eu tournait sur Grav CMS depuis ~3 ans : flat-file, PHP-FPM, ModSecurity, Cloudflare. Tout marchait. Mais la dette opérationnelle s’accumulait : MAJ PHP, plugins Grav à patcher, TTFB qui grimpait à >800ms sur certaines pages.

J’ai migré vers Hugo (générateur de site statique en Go) en deux semaines, en gardant les mêmes URLs, le même contenu, et les deux langues FR/EN. Zéro régression côté SEO, indexation Cloudflare, ou liens internes. Voici comment.

Pourquoi Hugo

J’avais 3 critères :

1. Performance — Statique pur. Pas de PHP, pas de DB. nginx sert directement les .html pré-générés.
2. Sécurité — Surface d’attaque divisée par 10. Plus de PHP-FPM, plus d’exécution serveur sur les pages publiques.
3. Multilingue propre — Hugo supporte nativement i18n via la convention index.{lang}.md (page bundles).

Hugo coche tout. Les alternatives évaluées : Eleventy (JS, mais moins mature niveau i18n), Zola (Rust, super, mais écosystème thèmes plus restreint), Gatsby (trop lourd pour un homelab).

⚡ En bref

Connecter Claude.ai à un site Hugo hébergé dans une VM KVM en 30 minutes : un serveur FastAPI expose 6 outils MCP (lire, créer, modifier, supprimer des pages, rebuilder le site) via JSON-RPC 2.0, un proxy OAuth réutilise l’infrastructure existante, et chaque modification déclenche automatiquement un rebuild Hugo + une purge du cache Cloudflare.

Le code est disponible sur GitHub :

• 🔌 Serveur MCP Hugo : jmrGrav/hugo-mcp
• 🔐 Proxy OAuth : jmrGrav/mcp-oauth-proxy

🧠 Pourquoi

Le protocole MCP (Model Context Protocol) d’Anthropic permet à Claude.ai de se connecter à des sources de données externes via des outils standardisés. Contrairement à Grav CMS qui est dynamique (PHP), Hugo génère du HTML statique — ce qui rend la gestion de contenu via MCP encore plus puissante : chaque modification est compilée et déployée instantanément.

⚡ En bref

Migrer son media stack (Sonarr, Radarr, SABnzbd) dans une VM KVM dédiée sur Ubuntu 24.04 : isolation sécurité, snapshots facilités, NFS QNAP monté dans la VM, reverse proxy nginx sur l’hôte. La migration conserve intégralement les bases de données SQLite et la configuration existante.

Stack cible :

• 🖥️ Hôte : NUC8i3BEH, Ubuntu Server, nginx reverse proxy, Plex (transcodage GPU)
• 📦 VM media-vm : Ubuntu 24.04, 2 vCPU, 8 Go RAM, 120 Go (X5 NVMe), NFS QNAP
• 🎬 Services migrés : Sonarr (port 8989), Radarr (port 7878), SABnzbd (port 6789)

🧠 Pourquoi isoler le media stack dans une VM

Sonarr, Radarr et SABnzbd présentent une surface d’attaque non négligeable : accès réseau vers des indexeurs externes, exécution de scripts post-download, accès au système de fichiers de la bibliothèque. Les confiner dans une VM apporte :