Arttrip : sortir de WordPress un magazine vieux de quatorze ans

Arttrip est un magazine de voyages culturels et d’histoire de l’art, publié depuis 2012. Les textes sont ceux de son autrice, et le restent. Ce que j’ai fait, moi, c’est le sortir de WordPress pour en faire un site statique, sans perdre une page, une URL ni une position dans les moteurs.

Ce que la migration devait préserver

Un site de quatorze ans n’est pas un dossier de contenus. C’est un ensemble de promesses faites aux moteurs de recherche et à tous ceux qui ont un jour partagé un lien. La contrainte que je me suis fixée avant d’écrire la moindre ligne de code : aucune URL existante ne devait casser, dans aucune des quatre langues de publication du magazine — italien, anglais, français et espagnol.

Le site en janvier 2025, sa dernière année sous WordPress, capturé depuis l’Internet Archive.

Le build produit 2 082 pages, soit environ 420 articles par langue, plus les hubs et les index qui les relient. Les redirections depuis les anciens permaliens WordPress sont générées pendant le build plutôt que maintenues à la main, et écrites à la fois dans un fichier de redirections et dans un .htaccess : la règle vit à un seul endroit et les deux sorties ne peuvent pas diverger.

Le plus ancien instantané conservé par l’Internet Archive, juin 2012. Le robot n’a jamais gardé la feuille de style : il ne reste que le HTML nu — pas l’allure du site à l’époque.

Un audit capable de faire échouer le build

La partie que je reprendrais dans n’importe quel projet futur, c’est l’audit SEO. Ce n’est pas un rapport qu’on lit une fois par trimestre : c’est scripts/audit-dist-seo.mjs --strict, exécuté sur le build, et s’il échoue la publication s’arrête.

Il vérifie ce qui pourrit en silence sur un gros site multilingue : des canoniques qui pointent où il faut, des ensembles hreflang qui se référencent mutuellement dans les deux sens, des titres et des descriptions présents et non dupliqués, des pages indexables réellement liées depuis quelque part. Avec quatre langues, ces relations se multiplient vite, et elles cassent d’une manière que personne ne remarque avant que le trafic ne baisse, deux mois plus tard.

En faire une barrière sur le build plutôt qu’un tableau de bord, c’était tout l’enjeu. Un chiffre sur un tableau de bord est un conseil ; un code de sortie non nul est une décision.

Les images, mesurées plutôt que supposées

Chaque photographie est convertie en WebP avec des paliers responsives à 420, 800 et 1280 pixels, produits par un script idempotent que l’on peut relancer après chaque ajout.

Un cas mérite d’être raconté, parce qu’il contredit la règle évidente. Pour quelque 400 photographies de l’autrice, le WebP en pleine résolution sortait plus lourd que le JPEG source — largeur médiane de 1183 pixels, déjà bien compressées. Forcer la conversion par souci de cohérence aurait coûté 65 Mo pour servir des fichiers 11 % plus lourds. Celles-là gardent leurs paliers responsives et sautent le WebP pleine taille. « Tout convertir en WebP » est un bon conseil jusqu’au moment précis où on le mesure.

Un article aujourd’hui, l’un des quelque 420 par langue.

Ce que j’en ai gardé

La recherche passe par Pagefind, indexé pendant le build : un site sans backend dispose quand même d’une vraie recherche plein texte dans quatre langues.

Le résultat qui compte n’est pas la pile technique. C’est qu’un magazine qui réclamait autrefois une base de données, un empilement de plugins et une fenêtre de maintenance est désormais un dossier de fichiers derrière un CDN — et que la chose la plus susceptible de casser, sa relation avec les moteurs de recherche, est la seule qu’un script vérifie à chaque build.