On a reçu une alerte Search Coverage un matin. Le genre d’alerte silencieuse que personne ne surveille, parce que le site « tourne sans problème depuis dix ans ». Sauf que Google, lui, avait décidé de désindexer plus de 60 % des pages. Le site tournait sous WordPress 3.5.1, version sortie en janvier 2013, et son dernier commit de maintenance remontait à l’époque où on débattait encore du responsive design comme d’une option. En ouvrant la Search Console, on a vu un LCP moyen à 5,1 secondes, un INP qui dépassait les 600 ms, et un temps de réponse serveur qui oscillait entre 1,8 et 2,8 secondes. Ce n’était pas un site « lent ». C’était un site qui demandait à Googlebot d’attendre trois secondes juste pour recevoir le premier octet de HTML.
Un TTFB à 2,8 secondes et 147 requêtes réseau
Première chose qu’on a faite : ouvrir les DevTools, onglet Network, cocher « Disable cache ». La page d’accueil lançait 147 requêtes, dont 83 avant même l’événement DOMContentLoaded. Le pire, c’est que 39 d’entre elles étaient des fichiers CSS et JS chargés par des plugins inactifs mais toujours listés dans le header. WordPress 3.5.1 n’a jamais vu passer les API de priorisation des ressources ni le moindre fetchpriority="high". Chaque plugin balançait son wp_enqueue_style() sans condition, souvent en synchrone.
Le TTFB moyen de 2,8 secondes n’était pas dû à PHP 5.6 – le serveur, un VPS correct, tournait en réalité avec une pile LAMP récente. Le problème, c’était une combinaison de sessions PHP non optimisées, d’un cache d’objets inexistant, et d’une dizaine de rewrites Apache qui s’empilaient depuis 2013 dans le .htaccess. Chaque requête exécutait le front controller de WordPress en entier, sans aucune forme de micro-caching. On parle d’un coût CPU par visite qui ferait hurler n’importe quel hébergeur aujourd’hui.
Le navigateur passait 1,4 seconde rien que dans le parsing et l’exécution de JavaScript non minifié. Le jquery-migrate.min.js chargé par défaut par le thème hérité pesait 10 Ko, mais forçait l’évaluation synchrone de jquery.js en version 1.8.3. Résultat : tous les scripts métiers, même ceux qui manipulaient le DOM après interaction utilisateur, étaient bloquants. L’INP à 600 ms trouvait son origine dans ces long tasks en chaîne, pas dans un composant précis.
Le vrai coupable n’est pas la version PHP, c’est l’accumulation de plugins zombies
On lit souvent que les vieux WordPress sont lents à cause d’une version PHP obsolète. C’est vrai en partie, mais ici, le PHP tournait encore sur une version maintenue. Le diagnostic a révélé autre chose : 34 plugins actifs, dont 12 orphelins – plus mis à jour depuis 2015 ou 2016. Ces plugins ne se contentaient pas d’être inutiles. Ils injectaient chacun au moins une ressource dans le front, parfois avec des appels externes vers des CDN disparus.
Parmi eux, un plugin de « protection anti-hotlinking » redirigeait les requêtes vers une image pixel vide via une série de 302, sauf que Googlebot tentait de suivre ces redirections sur plusieurs profondeurs. Résultat : des milliers de soft 404 générées par la Search Console, et une part non négligeable du crawl budget brûlée dans des boucles que rien ne stoppait.
Ce qu’on a fait : désactivation immédiate des plugins non audités, suppression physique des dossiers pour éviter les hook d’activation résiduels, et remplacement du système de cache. On a aussi posé une règle dans le fichier robots.txt pour bloquer l’exploration des chemins de redirection historiques le temps du nettoyage – une rustine, mais nécessaire quand le crawl budget est déjà dans le rouge.
Migrer sans casser le SEO : le plan d’action choisi
Quand un site aussi ancien doit sortir de l’ornière, la migration peut tuer ce qui reste de son référencement. L’équipe a choisi de ne pas répliquer l’URL canonique à l’identique tant que le plan de redirection n’était pas vérifié. On a segmenté le sitemap en trois fichiers distincts : pages statiques, articles de blog, et produits e-commerce. Cela permettait à Googlebot de revisiter progressivement chaque type de contenu sans que les erreurs d’un segment contaminent les autres.
On a ensuite basculé l’ensemble du front sur un rendu statique, en dehors de WordPress. Une partie du contenu a été prégénérée avec Astro, l’autre avec un simple scraping maîtrisé des pages existantes pour produire du HTML pur, sans aucune dépendance side-server au chargement.
⚠️ Attention : couper le moteur PHP de WordPress en frontal ne retire pas la responsabilité de ce qui se passe dans les URL historiques. Toute URL qui répondait en 404 propre sur l’ancien site doit continuer à le faire, ou renvoyer une redirection 301 pertinente. Un dump complet des URLs connues a été extrait depuis la Search Console et les logs avant toute manipulation.
On a aussi découvert, au passage, que le thème original générait 12 000 combinaisons d’URL via un système de facettes non canonisées. Le noindex par directive robots appliqué aux pages de facettes a été la première bouffée d’oxygène pour le crawl budget, avant même que la performance de chargement ne s’améliore.
Pourquoi un WordPress 3.5.1 reste parfois en production
Du code legacy, ça se garde rarement par plaisir. Ce site-là appartenait à une PME qui avait développé un module de réservation propriétaire greffé directement dans le core de WordPress. Extraire ce module impliquait de casser l’admin back-office, et personne n’avait osé toucher parce qu’il n’y avait ni tests ni documentation. La peur du downtime a pérennisé une version de WordPress qui aurait dû disparaître il y a huit ans.
Le coût technique, lui, se mesurait chaque jour en perte de positions, en taux de rebond sur mobile supérieur à 80 %, et en non-indexation silencieuse. Ce n’est pas une exception : on retrouve ces installations fossilisées chez des acteurs B2B qui ont un trafic faible mais critique, et qui repoussent les mises à jour parce que le coût immédiat du développement semble plus élevé que la perte de visibilité. Sauf qu’à 5 secondes de LCP sur mobile, Google ne te pardonne plus rien.
Headless et génération statique : un LCP divisé par trois
Quand on a sorti tout le front du PHP, on a recollé le contenu dans un projet Astro, prégénéré, déployé derrière un CDN avec compression Brotli et cache par tag invalidation. Le LCP moyen est passé de 5,1 à 1,4 seconde. Le TTFB s’est stabilisé sous les 150 ms. L’INP a disparu des radars CrUX parce que le thread principal n’avait plus à évaluer un monceau de scripts à chaque navigation.
Le rendu statique n’est pas une solution magique. Il faut que les données soient disponibles au moment du build. Dans ce cas précis, le module de réservation a été isolé derrière une API minimaliste, consommée côté client uniquement sur la page de réservation. Le reste du site, purement informatif, pouvait devenir totalement statique. On a évité l’hydratation inutile, et surtout on a sorti jQuery du chemin critique. La gestion d’état des composants dynamiques a été confiée à une librairie légère dont on parle dans un autre article sur le state management avec Zustand.
Le plus intéressant, c’est que Googlebot a recommencé à crawler le site dans les 72 heures après la migration, avec un volume de requêtes divisé par trois mais une profondeur de crawl bien supérieure. Moins d’URL poubelles, plus de signal utile.
Ces vieilles installations nous rappellent une règle d’or des Core Web Vitals
Un site abandonné ne se dégrade pas « doucement ». Il tombe d’un coup dans une zone où les signaux de classement se retournent contre lui. Ce cas nous a rappelé que l’optimisation des Core Web Vitals ne commence pas par choisir un outil ou ajuster un fetchpriority. Elle commence par nettoyer ce qui ne devrait plus être en production. Avant de penser « lazy-loading des images », on a supprimé 47 000 fichiers inutiles dans le répertoire wp-content/uploads/2020/ qu’un plugin de cache abandonné avait dupliqués en triple taille.
Le lien avec l’optimisation des Core Web Vitals est direct : tout ce qu’on y documente à propos de la mesure, du choix de CDN ou de la priorisation du LCP devient inefficace si on travaille sur une base pourrie. C’est le genre de boulot où le diagnostic prend trois jours pour une correction effective de deux heures. Ce qui compte, c’est d’avoir le courage de dire à un client qu’un site de 2013 n’est plus maintenable, et qu’une migration bien conduite coûte moins cher que la chute silencieuse du trafic.
La migration a révélé une toute autre dette : celle des logs
En reconstruisant les redirections, on s’est retrouvé à analyser des logs Apache que personne n’avait ouverts depuis 2015. On y a trouvé 18 000 appels mensuels à des routes xmlrpc.php saturées de tentatives de brute force. Aucun lien avec la performance visuelle, mais un impact direct sur la disponibilité du serveur et donc sur les mesures CrUX en conditions réelles.
On a migré l’analyse en temps réel avec une edge function, et profité de la refonte pour poser un monitoring propre. Pour écrire et debugger ces fonctions, on a testé les deux environnements qu’on utilise au quotidien : un IDE local lourd et une alternative qui a le vent en poupe, dont on parle dans notre comparaison Claude Code vs Cursor IDE. Ce n’est qu’un détail opérationnel, mais quand on gère à distance un site en pleine résurrection, le choix de l’outil de debug compte presque autant que le runbook de migration.
Questions fréquentes
Peut-on optimiser un WordPress 3.5.1 sans le mettre à jour ?
On peut améliorer quelques symptômes : activer la compression gzip au niveau du serveur, vider les tables d’options gonflées, désactiver les plugins inactifs. Mais sans mise à jour majeure, les gains restent marginaux. Le vrai levier, c’est de découpler le front pour échapper au rendu PHP, en gardant l’admin WordPress pour la gestion de contenu si l’équipe y tient.
Le headless est-il adapté à un petit site WordPress historique ?
Oui, si le contenu est majoritairement statique et que le nombre d’URLs ne dépasse pas quelques centaines, la prégénération complète est fiable et bien moins coûteuse à maintenir qu’une stack PHP chaque jour plus vulnérable. Le frein, c’est la dépendance à l’admin WordPress pour les non-développeurs : il faut prévoir une interface de preview correctement configurée.
Les redirections internes anciennes posent-elles encore problème en 2026 ?
Absolument. Même si Google est devenu meilleur pour gérer les chaînes de redirections, chaque 302 ou 301 supplémentaire grignote du crawl budget. Sur un site déjà en difficulté, c’est la double peine : moins de pages indexées et un TTFB empiré par la multiplication des résolutions de redirections avant d’atteindre la cible.
