Réponse courte. Refaites le site lorsqu’il ne représente plus le cabinet, empêche des tâches essentielles, accumule une dette technique risquée ou ne peut pas être maintenu. Avant toute maquette, inventorie chaque URL, contenu, lien et intégration. Conservez les pages utiles, redirigez les anciennes adresses vers leur équivalent réel et mesurez le lancement. Une correction ciblée peut suffire si la base reste saine.
Les symptômes ne demandent pas tous une reconstruction
Un site peut sembler ancien et rester rapide, lisible et exact. À l’inverse, une interface récente peut cacher des pages lentes, des scripts tiers excessifs et des contenus impossibles à mettre à jour. Le diagnostic doit séparer contenu, expérience, technique et gouvernance.
| Signal | Correction ciblée possible | Refonte probable |
|---|---|---|
| Informations obsolètes | Processus de mise à jour et réécriture | Oui si la structure bloque toute correction |
| Mobile difficile | CSS et composants prioritaires | Oui si le système entier n’est pas responsive |
| Lenteur | Images, scripts, cache, hébergement | Oui si la plateforme impose la dette |
| SEO en baisse | Diagnostic indexation, contenu, concurrence | Jamais sur ce seul signal sans cause établie |
| Nouvelle équipe ou offre | Pages et navigation | Oui si le modèle ne représente plus l’organisation |
| Prestataire bloquant | Récupération des accès et export | Oui si la reprise est impossible ou trop risquée |
Documentez les preuves : captures mobiles, erreurs de formulaire, appels récurrents, temps de chargement, URL introuvables, comptes sans propriétaire. Une liste factuelle évite qu’une refonte devienne un simple concours de préférences visuelles.
Une ligne par URL, une décision par contenu
Exportez le sitemap, les URL de Search Console, les pages suivies dans les statistiques et les liens internes. Ajoutez les PDF, images importantes, formulaires et pages non indexées mais utilisées. Pour chaque élément, attribuez une action :
- Conserver : la page répond toujours au besoin et son URL reste stable.
- Améliorer : l’intention reste valable, mais le contenu ou l’expérience évolue.
- Fusionner : plusieurs pages faibles ont un équivalent plus clair.
- Rediriger : l’ancienne adresse possède une destination pertinente.
- Supprimer : aucun contenu équivalent ni utilité ne justifie une redirection.
Inventoriez aussi les propriétaires : qui valide les prestations, l’équipe, les horaires, la confidentialité et les contenus médicaux ? Sans cette gouvernance, le nouveau site vieillira aussi vite que l’ancien.
Rediriger vers l’équivalent, pas systématiquement vers l’accueil
Lorsqu’une URL change, une redirection permanente doit mener vers la page qui reprend réellement son intention. Rediriger toutes les anciennes pages vers l’accueil crée une mauvaise expérience et ne conserve pas automatiquement leur valeur. Évitez aussi les chaînes : ancienne URL vers intermédiaire, puis nouvelle URL.
La feuille de migration contient au minimum l’ancienne URL, la nouvelle URL, le code attendu, le responsable et le statut de test. Elle doit couvrir les variantes avec ou sans barre finale, les HTTP historiques, les documents partagés et les URL qui reçoivent des liens externes.
Conservez le domaine lorsque cela correspond au projet. Vérifiez la canonique, le sitemap, les directives robots et les liens internes sur la version finale. Les annotations linguistiques doivent relier les véritables équivalents si plusieurs langues existent.
Tester des tâches et des risques, pas seulement des pages
La recette éditoriale vérifie noms, rôles, lieux, horaires, prestations, langues, urgence et rendez-vous. La recette technique vérifie les liens, formulaires, redirections, métadonnées, données structurées, affichage mobile, clavier, contraste et poids des pages.
- Tester sur une préproduction inaccessible aux moteurs.
- Geler les changements de contenu pendant la migration finale ou les consigner.
- Faire valider le médical et l’opérationnel par les responsables nommés.
- Parcourir les scénarios d’un nouveau patient sur mobile.
- Tester un échantillon représentatif puis toutes les redirections automatisables.
- Préparer une sauvegarde et un plan de retour adapté à l’infrastructure.
La page confidentialité d’un site santé aide à utiliser la refonte pour supprimer des scripts et formulaires inutiles.
Les premières semaines servent à détecter, pas à conclure trop vite
Après mise en ligne, vérifiez les erreurs serveur, pages introuvables, redirections, indexation, formulaires et Core Web Vitals. Soumettez le sitemap actualisé et inspectez les pages prioritaires dans Search Console. Gardez l’ancien plan d’URL disponible pour corriger rapidement.
Une variation de trafic à court terme n’explique pas sa cause. Comparez des périodes cohérentes, distinguez marque et hors marque, et annotez la date des changements. Les objectifs opérationnels — trouver l’accès, joindre le cabinet, utiliser le bon agenda — complètent la recherche organique.
Pour cadrer un chantier, la page refonte de site médical détaille le service WebClinic ; le guide comparer le prix d’un site médical aide à lire les lignes de migration.
Sources primaires et limites
- Google Search Central — Déplacement de site avec changements d’URL.
- Google Search Central — Redirections et recherche Google.
- Google Search Central — Core Web Vitals.
Une migration comporte toujours un risque. Ce guide réduit les erreurs évitables, mais ne garantit ni conservation du trafic ni amélioration du classement.