Refondre sa landing page sans perdre son référencement : la checklist complète

Une landing page qui vit plusieurs années finit par mériter une refonte — notre article sur quand refondre sa landing page détaille les signaux qui la déclenchent. Mais une refonte réussie côté design peut être une catastrophe côté Google : des URL changées sans redirection, des blocs de contenu qui rankaient supprimés parce qu'ils « faisaient vieux », des titres réécrits sans regarder les requêtes qui amenaient du trafic. Le référencement d'une page est un actif construit sur des mois ; il se détruit en un déploiement. Voici la checklist en trois temps — avant, pendant, après — pour ne pas payer la modernisation au prix des positions.

Avant la refonte : photographier l'existant

On ne peut pas préserver ce qu'on n'a pas mesuré. Avant de toucher à quoi que ce soit, trois relevés s'imposent. D'abord, la Search Console : pour chaque URL concernée, exportez les requêtes qui génèrent impressions et clics, avec leurs positions — c'est la liste de ce que Google associe aujourd'hui à votre page, et donc de ce qu'il faut préserver. Ensuite, l'inventaire des contenus : quels titres (title, H1, H2), quels paragraphes, quelles questions de FAQ correspondent à ces requêtes ? Un bloc de texte qui semble accessoire à l'œil peut être précisément celui qui capte une longue traîne. Enfin, les liens entrants : les pages externes et internes qui pointent vers l'URL — un outil SEO ou un simple crawl de votre propre site les liste. Ce relevé prend une heure et transforme la refonte d'un pari en une opération contrôlée.

La règle d'or : ne changez pas l'URL si vous pouvez l'éviter

La décision la plus lourde d'une refonte n'est ni le design ni le texte : c'est l'URL. Une URL conservée garde son historique, ses liens entrants et ses positions ; une URL changée repart avec un handicap, même correctement redirigée. La recherche sur la persistance du web rappelle l'ampleur du problème général : une étude de Martin Klein et ses co-auteurs publiée en 2014 dans PLOS ONE, portant sur des millions de liens dans des articles scientifiques, a mesuré qu'environ un article sur cinq souffre de « reference rot » — des liens qui ne mènent plus au contenu cité ; et une étude de Ziv Bar-Yossef et ses co-auteurs présentée en 2004 à la conférence WWW a documenté la vitesse à laquelle le web « se décompose », pages disparues ou vidées de leur contenu. Chaque refonte qui casse des URL contribue à cette décomposition — et en subit les conséquences : chaque lien externe qui aboutit sur une 404 est un actif SEO perdu. Si l'URL doit absolument changer (changement de domaine, restructuration), la redirection 301 individuelle — ancienne URL vers nouvelle URL équivalente, pas vers la page d'accueil — est non négociable.

Pendant la refonte : ce qui se conserve, ce qui se réécrit

• Se conserve : l'intention de la page. Une page qui ranke sur « prix de X » doit rester une page qui répond au prix de X — la refondre en page de marque générique jette les positions.
• Se conserve : les formulations qui matchent les requêtes. Le title et le H1 peuvent être améliorés, mais les mots que les visiteurs tapent (relevés en Search Console) doivent y survivre — on réécrit autour des requêtes, pas contre elles.
• Se conserve : les blocs qui captent la longue traîne. FAQ, tableaux, sections précises — vérifiez dans votre relevé quelles requêtes ils servent avant de les supprimer pour « alléger ».
• Se réécrit librement : tout le reste. Design, structure visuelle, preuve sociale, CTA, images — l'essentiel de ce qui améliore la conversion ne touche pas à ce que Google lit en premier.
• S'améliore à l'occasion : la technique. Une refonte est le bon moment pour gagner en vitesse de chargement — critère de classement et de conversion à la fois, comme le détaille notre article sur la vitesse de chargement — et pour vérifier les données structurées et les balises méta décrites dans notre guide du SEO d'une landing page.

Un piège spécifique aux refontes techniques : le passage d'une page rendue en HTML à une page qui dépend du JavaScript pour afficher son contenu. Google exécute le JavaScript, mais avec des délais et des aléas ; une landing page a tout intérêt à rester servie en HTML complet — c'est le comportement par défaut des pages statiques Next.js comme les templates LanderKit, et l'une des raisons du choix de cette stack, expliquée dans notre comparatif Next.js vs WordPress.

Le maillage interne : la partie oubliée

Si d'autres pages de votre site pointent vers l'ancienne URL ou citent l'ancien titre, mettez-les à jour en même temps que la refonte : un maillage interne cohérent aide Google à comprendre la nouvelle version, et des liens internes qui passent par des redirections diluent inutilement. Pensez aussi aux liens que vous ne contrôlez qu'à moitié : campagnes publicitaires (mettez à jour les URL finales plutôt que de vous reposer sur la redirection), signatures d'emails, profils sociaux, et le sitemap XML qui doit refléter les nouvelles URL dès le déploiement.

Après le déploiement : surveiller les bonnes métriques

Les deux premières semaines après une refonte demandent une surveillance active. Dans la Search Console : les impressions et positions sur les requêtes relevées avant refonte (une baisse temporaire de quelques jours peut accompagner la réindexation ; une chute qui s'installe au-delà de deux ou trois semaines signale un vrai problème), le rapport de couverture pour détecter les 404, et l'inspection d'URL pour vérifier que la nouvelle version est indexée. Côté conversion, comparez le taux de conversion avant/après à trafic comparable — c'était le but de la refonte — et le taux de rebond par source. Si la refonte visait la conversion, l'idéal reste de la valider en A/B test plutôt qu'en bascule sèche : l'ancienne version sert de témoin, et un échec se rattrape en un clic.

Le scénario rassurant : refondre par étapes

La refonte « big bang » — tout change le même jour — est la plus risquée pour le SEO comme pour la conversion : si les positions chutent, impossible de savoir quel changement est en cause. Quand la page le permet, la refonte par étapes est plus sûre : d'abord la technique (vitesse, stack) à contenu identique, puis le design section par section, puis les textes — en laissant à chaque étape une ou deux semaines de données. C'est plus lent, mais chaque étape est réversible et attribuable. Et si vous partez d'un template LanderKit pour la nouvelle version — par exemple SaaS Waitlist ou Agence locale selon votre cas —, le code source livré permet précisément de reproduire d'abord vos contenus existants à l'identique dans la nouvelle structure, avant d'améliorer le reste : la technique change, ce que Google lit ne change pas (89 € l'unité, 229 € le pack de 10 templates).