En travaux.
Ça sonne cheap, je sais.
Mais laisse-moi te dire pourquoi c’est volontaire, contrôlé et (oui) utile.
J’ai racheté les fichiers, fouillé les backups, et découvert que l’ancien site n’avait pas de snapshot sur la Wayback Machine (vérifié).
Résultat : il faut reconstruire avec soin pour que Google reconnaisse qu’on est le même projet — pas juste un clone vide.
Tu veux savoir comment je vais gérer les redirections, le SEO, les archives et ce que tu peux attendre ? Good. Je te dis tout, point par point.
Pourquoi j’ai tout repris à zéro (3 bonnes raisons)
J’assume : j’aurais pu remettre un “coming soon” et fermer la porte.
Je ne l’ai pas fait parce que : 1) l’ancienne base est foirée (plugins cassés), 2) WordPress costaud mais trop lourd pour mes usages, 3) je voulais un site rapide pour 2026 avec un workflow moderne.
Premièrement, l’ancien CMS gérait mal les images (plus de 40 % des articles avaient des médias orphelins).
Deuxièmement, le budget d’hébergement pour un WordPress performant te coûte au moins 15 €/mois minimum si tu veux éviter les 503 à chaque pic de trafic (perso, j’ai vu des taux d’erreur à 18 % sur des posts populaires).
Troisièmement, j’ai eu envie d’un build statique avec Astro pour gagner en perf et en contrôle (builds incrémentaux, génération côté serveur quand il faut).
Bref.
La décision est technique, financière et éditoriale.
Et oui, ça implique du taf : 3 phases de relance, 1 semaine de QA, et des checks SEO à chaque étape.
💡 Conseil : utilise un export XML du RSS en complément des backups — ça garde les permaliens et les dates de publication (pratique pour conserver l’autorité).
Migration WordPress → Astro en 48h (technique et concret)
J’ai planifié la migration en 3 étapes claires : export, transform, déploy.
Étape 1 : exporter tout le contenu en XML + images (48 Go max dans mon cas).
Étape 2 : convertir chaque article en Markdown frontmatter friendly (script Node.js perso, 1 200 fichiers convertis en 2 heures).
Étape 3 : construire sur Astro, déployer sur un hébergeur static + CDN (Cloudflare pour moi).
Concrètement, j’ai lancé la première conversion la nuit du 01 au 02 mars 2026.
Le script a géré les shortcodes, les embeds YouTube (re-routés en iframes optimisées) et les images à la volée (resize en WebP).
Résultat : gain de poids moyen par page de 45 % (c’est pas magique, c’est compressé).
Attention à un truc : les permaliens.
Si tu changes la structure des URLs sans 301, tu perds du trafic.
Alors je garde la structure historique pour 90 % des articles et j’ajoute des redirects 301 pour les autres.
⚠️ Attention : 301 mal configurés = perte de jus SEO. Teste chaque redirection avec un crawler (Screaming Frog ou equivalent) avant la mise en prod.
SEO : comment je tente de récupérer 10 ans d’autorité
Je ne te promets pas la lune.
Ce que je fais : préserver les slugs, réécrire les méta pour 150–160 caractères, réactiver le sitemap.xml et soumettre une première version à Google Search Console en moins de 24 heures après déploiement.
Concrètement, 4 actions prioritaires :
- garder 95 % des URLs historiques,
- ajouter des balises canonical propres,
- recréer un sitemap et un fichier robots.txt strict,
- relancer les pages qui génèrent encore du trafic (top 30 selon Analytics).
J’ai un fichier CSV avec 1 200 URLs triées par trafic (top 30, top 200, longue traîne).
Les 30 premiers ont droit à un audit de contenu et parfois à une réécriture (70–100 mots mis à jour) pour éviter la duplication.
Pour les pages mortes, j’applique 410 quand c’est assumé (meilleure pratique pour dire “on ne revient pas”).
Tu veux un exemple concret ?
L’article “Comment optimiser son PC pour 1440p” (hypothétique) est conservé, amélioré de 300 mots, et relié à un nouveau dossier “builds 2026” (ça aide le maillage interne).
📌 À retenir : soumettre le sitemap à la Search Console accélère l’indexation — fais-le dans les 24 h suivant le déploiement.
Et oui, j’ai lié les contenus techniques au dossier code créateur (voir l’article sur /articles/code-createur/ pour le background), parce que le maillage interne compte pour du beurre quand il n’existe pas.
Ce qui change pour toi (5 trucs utiles)
- Chargement ultra-rapide : pages < 700 ms en moyenne (test Lighthouse).
- Design responsive revu : header plus léger, sidebar optionnelle (pour mobile, tout est full width — logique).
- Mode lecture : export PDF en 1 clic pour chaque test hardware (faut pas tout perdre quand tu offline).
- Filtre taggage amélioré : tu peux chercher par plateforme, genre, et tech (ex : “RTX 50 series”, “roguelike”).
- Newsletter mensuelle : résumé des 5 meilleurs articles + un “deal” hardware (si j’en trouve un cool).
Chaque item a un but : rendre la visite plus fluide et garder les anciens visiteurs (ceux qui se souviennent des tests de 2019, tu sais).
Pour les power users, j’ai mis en place un flux RSS alternatif et un JSON feed pour ceux qui veulent parser.
Petit aside (parce que j’aime bien les apartés) : j’ai remis mon vieux script de recommandation d’articles qui tourne en LocalStorage depuis 2018 (oui, ça existe toujours et non, je ne l’ai pas converti en SaaS).
Gestion des archives et des backlinks (6 étapes précises)
Archive = nerf de la guerre pour récupérer de l’autorité.
Voici ma checklist en 6 étapes, testée sur 2 autres projets perso :
- récupérer toutes les bases (DB + uploads) — vérifié, 2 backups distincts (S3 + GitHub Actions).
- convertir le contenu et conserver les dates originales (import en frontmatter).
- restaurer 90 % des images principales en WebP et garder les noms de fichiers quand possible.
- générer des 301 pour les URLs modifiées et garder 410 pour les dead-ends volontaires.
- reconstruire le sitemap et envoyer à la Search Console.
- monitorer les erreurs 404 pendant 30 jours et corriger les plus fréquentes.
J’ai déjà mis en place des alertes Slack pour les 404 qui dépassent 10 hits par jour.
Si tu veux creuser la technique, j’explique le script de conversion dans un billet à venir (spoiler : Node.js + unified + remark).
💡 Conseil : si tu gères un site, garde toujours 3 copies des contenus critiques — base, assets, et export XML.
FAQ
Q : Combien de temps va durer la maintenance visible ?
R : La fenêtre visible est de 48 heures maximum pour la migration initiale. Les ajustements SEO et les 404 fixes prennent ensuite 30 jours de monitoring.
Q : Est-ce que mes anciens bookmarks vont fonctionner ?
R : 95 % des permaliens sont conservés. Pour les 5 % restants, j’ai mis en place des 301 et une page de redirection intelligente qui propose les articles similaires.
Q : Puis-je proposer un vieux article pour restauration ?
R : Oui. Envoie un lien (URL) via le formulaire de contact (page contact à venir). Je priorise les articles avec au moins 10 backlinks détectés dans les 12 derniers mois.
Bon.
Si tu vois encore un “en travaux” demain matin, c’est probable que je peaufine les redirects (et que je bois un café).
Sinon, tu vas retrouver le contenu qui te plaisait, amélioré, plus rapide, et mieux organisé.
Et si t’as un vieux lien cassé qui te tient à cœur, envoie-le — je le check en priorité (promis, pas de spam).
