Refonte de site internet : les étapes pour préserver son référencement
Une refonte de site internet ne concerne pas uniquement le graphisme ou le choix d’un nouveau système de gestion de contenu. Elle peut modifier les adresses des pages...
Choisir son agence web
Une refonte de site internet ne concerne pas uniquement le graphisme ou le choix d’un nouveau système de gestion de contenu. Elle peut modifier les adresses des pages, l’arborescence, les textes, les liens internes, les balises HTML, les performances et les règles d’exploration des robots. Chacun de ces éléments participe à la visibilité du site dans les moteurs de recherche.
Le risque apparaît lorsque la nouvelle version est mise en ligne sans lien précis avec l’ancienne. Une page qui bénéficiait de visites, de liens externes ou d’une position dans les résultats peut alors renvoyer vers une erreur 404, afficher un contenu différent ou devenir inaccessible aux robots. Le domaine reste le même, mais les signaux associés aux anciennes URL ne sont plus correctement transmis.
La protection du référencement doit donc être traitée comme un chantier à part entière, au même titre que la conception, le développement ou la recette fonctionnelle. L’objectif n’est pas de conserver chaque élément à l’identique, mais de maîtriser les changements et de vérifier leurs conséquences.
La première étape consiste à décrire précisément ce qui va changer. Une refonte peut porter sur un seul aspect ou sur plusieurs en même temps :
Plus les changements sont nombreux, plus la phase de préparation doit être détaillée. Une modification du design sur des URL inchangées ne présente pas les mêmes enjeux qu’un changement de domaine accompagné d’une nouvelle arborescence. Cette distinction aide à établir un plan de migration réaliste et à affecter les contrôles nécessaires.
Il est également utile de fixer des critères de validation avant le lancement. Ils peuvent concerner l’accessibilité des pages stratégiques, la présence des balises essentielles, le fonctionnement des formulaires, la conservation des données de mesure et la correspondance entre les anciennes et les nouvelles adresses.
Une refonte ne peut pas préserver ce qui n’a pas été identifié. Il faut constituer un inventaire des URL existantes à partir de plusieurs sources : exploration du site, fichiers du serveur, données de suivi d’audience, rapports de performance et fichiers de sitemap déjà utilisés. Chaque source révèle une partie du patrimoine numérique.
L’inventaire doit, lorsque les données sont disponibles, associer à chaque URL des informations utiles à la décision :
Cette liste permet de distinguer les pages à conserver, celles à regrouper, celles à réécrire et celles qui doivent disparaître. Une page peu visitée peut toutefois recevoir des liens externes ou répondre à une intention de recherche précise. La décision ne doit donc pas reposer sur un seul indicateur.
Conservez une copie datée de cet état des lieux. Elle servira de référence pour comparer la nouvelle version et interpréter les changements observés après le lancement.
La table de correspondance, aussi appelée plan de redirection, relie les anciennes adresses aux nouvelles. Elle constitue le document central de la migration. Pour chaque URL ancienne, indiquez la destination prévue et la raison de la décision.
| Situation | Traitement recommandé | Point de vigilance |
|---|---|---|
| Adresse conservée | Ne pas créer de redirection | Vérifier le contenu et le code de réponse |
| Adresse modifiée | Redirection permanente vers la page équivalente | Éviter de renvoyer vers une page d’accueil sans rapport |
| Deux pages réunies | Redirection vers la page qui reprend réellement l’information | Mettre à jour les liens internes |
| Contenu supprimé sans équivalent | Réponse adaptée selon le contexte | Ne pas multiplier les destinations artificielles |
Lorsqu’une page change d’adresse, une redirection permanente côté serveur est généralement le mécanisme approprié pour orienter les utilisateurs et les robots vers la nouvelle URL. Sa configuration dépend de l’environnement technique : serveur Apache, Nginx, plateforme hébergée ou CMS. Le principe reste identique : une ancienne adresse doit conduire à une page pertinente, sans chaîne de redirections inutile.
Testez les cas particuliers : paramètres d’URL, variantes avec ou sans barre finale, majuscules, anciennes extensions de fichiers, pages paginées, fichiers téléchargeables et versions imprimables. Une règle trop générale peut provoquer des boucles, des destinations incohérentes ou des redirections vers des pages qui ne correspondent pas à la demande initiale.
Le référencement dépend aussi de la manière dont les pages se relient entre elles. Une nouvelle navigation peut rendre certaines pages plus profondes, supprimer des liens contextuels ou laisser des contenus importants sans accès depuis une page active. Les robots comme les utilisateurs doivent pouvoir comprendre la hiérarchie du site.
Avant la mise en ligne, vérifiez que :
La refonte offre une occasion de corriger les liens cassés et les parcours confus. Elle ne doit pas conduire à retirer massivement des liens qui permettaient de découvrir des pages utiles. L’architecture finale doit refléter les besoins des visiteurs et la logique des contenus, plutôt qu’une organisation dictée uniquement par les contraintes du CMS.
Chaque page conservée ou créée doit faire l’objet d’un contrôle éditorial et technique. Les éléments à vérifier comprennent le titre HTML, la description, les niveaux de titres, le contenu visible, les attributs alternatifs des images lorsque ceux-ci sont nécessaires à la compréhension, ainsi que les données structurées utilisées de manière pertinente.
La balise canonique doit désigner la version principale d’une page lorsque plusieurs URL peuvent afficher un contenu identique ou très proche. Elle ne remplace pas une redirection et ne doit pas pointer systématiquement vers la page d’accueil. De même, une directive d’exclusion dans le fichier robots.txt ne sert pas à retirer une page des résultats dans tous les contextes. Les mécanismes d’exploration et d’indexation doivent être distingués.
Examinez également les éléments suivants :
Le contenu ne doit pas être copié automatiquement vers toutes les pages. Une migration réussie conserve la pertinence des informations tout en permettant leur amélioration lorsque l’intention des utilisateurs a évolué.
La version en préparation doit être testée dans un environnement qui ne risque pas d’être indexé comme une seconde version publique. Une protection par authentification ou un contrôle d’accès adapté est préférable à une consigne laissée au seul fichier robots.txt. Ce dernier peut empêcher l’exploration, mais il ne constitue pas une barrière de confidentialité.
La recette doit couvrir les parcours visibles et les réponses techniques. Utilisez une liste de contrôle comprenant notamment :
Les tests doivent être effectués avec plusieurs modèles de pages : accueil, catégorie, article, fiche produit si nécessaire, page de contact, page avec média et page supprimée. Une erreur présente sur un modèle peut se reproduire sur des centaines d’URL.
Le lancement doit suivre un déroulé écrit. Choisissez une période où les personnes compétentes peuvent surveiller les premiers contrôles et intervenir rapidement en cas d’anomalie. Prévoyez une sauvegarde exploitable de l’ancienne version, de la base de données et des fichiers de configuration avant toute bascule.
Le plan de déploiement peut inclure les actions suivantes :
Évitez de modifier simultanément la structure, le contenu, le ciblage géographique et le domaine sans plan de suivi renforcé. Lorsque plusieurs facteurs changent à la même période, l’analyse des variations devient plus difficile.
La mise en ligne ne clôt pas la migration. Les jours et semaines suivants doivent être consacrés à la vérification des anciennes URL, de la couverture des pages et de l’activité des utilisateurs. Les outils pour administrateurs de moteurs de recherche peuvent signaler des erreurs d’exploration, des problèmes de pages canoniques, des URL exclues ou des anomalies de sitemap.
Comparez les données avec l’état des lieux initial, en tenant compte des évolutions normales de la demande. Surveillez notamment :
Les journaux serveur apportent un éclairage complémentaire : ils montrent les URL réellement demandées par les robots et les utilisateurs, y compris des adresses absentes des outils d’analyse d’audience. Une hausse des erreurs concentrée sur un répertoire révèle souvent une règle de réécriture mal conçue ou une partie oubliée de la table de correspondance.
Certaines erreurs résultent d’une préparation incomplète plutôt que d’un problème de technologie. Les identifier en amont réduit les corrections d’urgence.
Une procédure de recette signée par les responsables du contenu, du développement et du suivi SEO permet de répartir les contrôles et d’éviter les angles morts.
Avant le lancement, réunissez les éléments suivants dans un dossier de migration :
Cette documentation facilite aussi les évolutions ultérieures. Elle évite de recommencer l’inventaire à chaque intervention et permet de comprendre pourquoi une URL a été conservée, fusionnée ou retirée.
Non. Les URL sans utilité, sans contenu pertinent et sans signal notable peuvent être retirées selon le contexte. En revanche, chaque suppression doit être étudiée et documentée. Une page qui reçoit des visites, des liens ou qui répond à une intention spécifique mérite une décision explicite.
Elle permet de relier une ancienne adresse à une nouvelle destination pertinente, mais elle ne compense pas un contenu supprimé, une architecture confuse ou un blocage d’exploration. La redirection doit être associée à des liens internes à jour et à des contrôles après lancement.
Le sitemap doit correspondre aux URL canoniques accessibles et indexables de la nouvelle version. Il est donc préparé avant le lancement, puis contrôlé et transmis lorsque le site public est correctement configuré. Les anciennes adresses redirigées n’ont pas vocation à y rester comme si elles constituaient les pages principales.
Commencez par identifier les URL concernées, leur origine et leur valeur. Ajoutez une redirection lorsqu’une page équivalente existe, corrigez les liens internes et vérifiez les anciennes règles de réécriture. Une page sans équivalent peut rester supprimée si cette décision est cohérente, mais elle doit être distinguée d’une erreur de migration.
Oui, mais l’analyse devient plus exigeante. Documentez les changements, conservez les pages stratégiques, testez les modèles de contenu et comparez les données avec prudence. Lorsque cela est possible, regrouper les changements par étapes facilite l’identification de la cause d’une variation.
