Étude de cas de refonte de site : Douzu Carry Service, entreprise de transport à Miyazaki — ce que nous avons repris de l'ancien site, et comment

Ce qui est le plus à craindre dans une refonte de site, c’est que l’apparence redevienne neuve pendant que le classement dans les moteurs de recherche et le parcours de contact se dégradent silencieusement. Cette fois, nous prenons pour exemple le projet de refonte de « Douzu Carry Service », une entreprise de transport de Miyazaki, pour faire le point sur ce que nous avons fixé avant même de toucher au design.

Quand on parle de refonte de site, la discussion commence souvent par les maquettes de design ou l’apparence de la page d’accueil. Mais lorsque l’ancien site dispose déjà d’un trafic de recherche ou de liens entrants significatifs, il y a des choses à décider avant le design, sous peine de ne plus pouvoir revenir en arrière facilement par la suite. Ce sont la conception des URL et la manière de reprendre les informations de l’ancien site.

Cet article prend pour exemple la refonte de « Douzu Carry Service », une entreprise de transport de Miyazaki spécialisée dans les déménagements individuels, la livraison longue distance et le transport frigorifique, et résume les étapes concrètes que nous avons suivies. Un aperçu succinct est disponible dans le cas récapitulant la structure de Douzu Carry Service, mais cet article approfondit un peu plus le sujet.

Notez que cet article ne présente pas de chiffres d’impact tels que l’évolution du nombre de visites ou de demandes de contact. Ce que nous pouvons présenter ici se limite aux faits — ce qui a été fait, et selon quelles étapes — car les données chiffrées sur les résultats ne font pas partie des sources de cet article.

1. Aperçu du projet — Avant / Après

Commençons par la vue d’ensemble.

Les principales pages statiques — accueil, liste des services, déménagement, transport frigorifique, livraison le jour même, déménagement en établissement pour seniors, tarifs, informations sur l’entreprise, FAQ et contact — ainsi que les neuf pages de zones pour Miyazaki, Miyakonojo, Nobeoka, Nichinan, Kobayashi, Hyuga, Saito, Kushima et Ebino, ont toutes conservé leur URL inchangée pendant la refonte. Ce qui a principalement changé, c’est le traitement des URL dénuées de sens de l’ancien blog et d’un script résiduel inutilisé.

Par ailleurs, le design du nouveau site a été construit sur la base du système de design publié par l’Agence numérique japonaise (Digital Agency). Le fait de sauter l’étape de conception du design depuis zéro nous a permis de consacrer l’effort ainsi économisé au travail de conception des URL et de migration de contenu traité dans cet article. La logique de cette approche est détaillée dans « Pourquoi KomuraSoft construit ses sites web sur le système de design de l’Agence numérique — coût réduit et qualité peuvent coexister ».

S’il fallait retenir un seul point de ce cas, ce serait celui-ci : nous avons terminé l’inventaire des URL et du contenu avant de toucher au design visuel, et ce n’est qu’ensuite que nous avons commencé. Les chapitres qui suivent détaillent ce processus étape par étape.

2. La première étape n’était pas le design, mais un inventaire des URL

La première chose que nous avons produite au lancement de la refonte n’était pas une ébauche de design, mais un tableau d’inventaire listant toutes les URL de l’ancien site.

Concrètement, nous avons recensé de façon exhaustive les éléments suivants.

• Pages statiques (accueil, liste des services, déménagement, transport frigorifique, livraison le jour même, déménagement en établissement pour seniors, informations sur l’entreprise, politique de confidentialité, FAQ, tarifs, blog, contact)
• Les neuf pages de zones (Miyazaki, Miyakonojo, Nobeoka, Nichinan, Kobayashi, Hyuga, Saito, Kushima, Ebino)
• Les articles individuels de l’ancien blog (plus de 100, allant des chroniques locales aux articles de savoir-faire sur les déménagements individuels et longue distance)
• Les « fichiers qui ne sont pas des pages mais restent accessibles publiquement », tels que robots.txt, sitemap.xml, le fichier de vérification de propriété Search Console, et l’ancien script de soumission de formulaire (php/submit.php)

Ce n’est qu’une fois cet inventaire établi que nous avons pu construire un tableau de correspondance décidant, URL par URL, ce qu’il fallait en faire sur le nouveau site. Dans le tableau de correspondance de ce projet, nous avons réparti la décision en deux grandes catégories.

Les pages statiques, les pages de zones et les URL d’articles de blog actuellement significatives ont toutes été classées keep (inchangées). En revanche, les URL avec chaîne aléatoire sans signification auto-numérotées par le système (du type /blog/5lmln1lx0x/) et les noms de fichiers datés comme post20210721.html ont été conçus pour rediriger en 301 vers de nouvelles URL d’articles portant un slug significatif.

Un autre élément relevant de ce processus de décision était php/submit.php, un script cible de soumission laissé sur l’ancien site. Nous avons confirmé qu’il n’était référencé par aucun formulaire du HTML publié, et que les canaux de contact réellement fonctionnels se limitaient aux trois systèmes téléphone, e-mail et devis LINE — nous l’avons donc jugé comme un « script de soumission résiduel » et l’avons configuré en redirection 301 vers /contact/ (nous revenons plus en détail sur le contexte de cette décision au chapitre suivant et au chapitre 5).

Pour la conception des redirections, nous avons appliqué deux règles sans exception.

• Résoudre chaque redirection en un seul saut (ne jamais créer de chaîne de redirections)
• Intégrer une vérification au moment du build confirmant que l’URL de destination existe réellement (pour éviter l’accident d’une redirection 301 vers une URL qui n’existe pas)

Fixer cet inventaire et ce tableau de correspondance avant même d’envisager le design signifie que les étapes ultérieures d’implémentation et de création de contenu peuvent avancer sur la base solide de « quoi mettre sur quelle URL », ce qui réduit le retravail. Ce n’est pas spécifique à ce seul projet — c’est une procédure de base qui s’applique tout aussi directement à toute refonte d’un ancien site disposant déjà de liens entrants ou de trafic de recherche.

3. Une liste de contrôle de conservation pour ne pas « perdre » de contenu

En parallèle du travail de conception des URL, nous avons constitué une liste de contrôle de conservation du contenu afin de vérifier que toutes les informations rédigées sur l’ancien site pouvaient être reproduites sans exception sur le nouveau.

Lors d’une refonte, de petits éléments de discours commercial et des chiffres peuvent disparaître discrètement dans le processus de rafraîchissement du design. Si ce qui disparaît est une information qui influence directement la décision de contact — tarifs, horaires d’ouverture, coordonnées, points forts — cela peut conduire précisément à la situation où le site a meilleure allure mais où les demandes de contact diminuent.

Nous avons donc consigné, pour chaque page principale, les informations indispensables de l’ancien site à conserver. Voici une partie de ce que cela comprenait.

Munis de cette liste de contrôle, nous avons comparé les anciennes et nouvelles pages une par une avant le lancement du nouveau site, en confirmant qu’aucun élément n’avait été perdu. Le point clé est que nous avons garanti, via une liste plutôt que par intuition ou mémoire, que le « matériel de décision » — tarifs, horaires, points forts — était intégralement repris malgré le changement de design.

4. SEO local — la conception des neuf pages de zones

Parmi les pages reprises de l’ancien site figurent neuf pages individuelles, une pour chacune des zones suivantes : Miyazaki, Miyakonojo, Nobeoka, Nichinan, Kobayashi, Hyuga, Saito, Kushima et Ebino.

Ces pages de zones existent comme point d’atterrissage pour les requêtes de recherche incluant un nom de lieu, du type « [nom de lieu] + déménagement » ou « [nom de lieu] + livraison ». Pour un service comme le transport ou le déménagement, où la zone de chalandise est liée à des régions précises, elles jouent le rôle de capter la demande de recherche liée à un nom de lieu que la page d’accueil ou la page tarifs seule ne peut pas entièrement couvrir.

En consultant le tableau de correspondance des URL, les neuf pages de /area/miyazaki/ à /area/ebino/ ont toutes été jugées keep (aucun changement d’URL), et la refonte n’a pas touché à cette structure elle-même. À leurs côtés, on trouve aussi de nombreux articles de blog liés à chaque zone qui couvrent des noms de lieux locaux précis — les quartiers de la ville de Miyazaki ou de Miyakonojo, par exemple — formant une structure où les pages de zones et les articles de blog se complètent.

Des pages comme ces pages de zones — le type produit en multipliant uniquement le nom du lieu dans un format par ailleurs identique — risquent, si le contenu est mince, de ressembler à des copies réutilisées de la même page, tant aux yeux des moteurs de recherche que des lecteurs. Dans ce cas, la répartition des rôles a été reprise de l’ancien site : les pages de zones elles-mêmes traitent le niveau de la zone, tandis que les articles de blog couvrent individuellement le détail au niveau des quartiers au sein de chaque zone. Cette structure évitait déjà la « minceur » typique des pages produites en masse. La refonte a laissé cette structure intacte et conservé les URL inchangées.

5. Consolidation de canaux de contact dispersés

La façon dont nous avons traité php/submit.php, mentionné au chapitre 3, était également une décision importante du point de vue de l’organisation du parcours de contact.

En examinant l’ancien site, nous avons confirmé que seuls les trois systèmes suivants fonctionnaient réellement comme canaux de contact accessibles publiquement.

• Téléphone (0120-931-677, horaires d’ouverture 8h–20h)
• E-mail
• Devis LINE

En revanche, le script cible de soumission php/submit.php lui-même subsistait dans le code, mais n’était référencé par aucun formulaire du HTML publié. Autrement dit, c’était un « script résiduel » qui n’était en réalité plus utilisé. Sur cette base, le nouveau site consolide les trois canaux — téléphone, e-mail et devis LINE — sur la page /contact/, et tout accès à php/submit.php est conçu pour rediriger en 301 vers /contact/.

Lorsque les canaux de contact sont dispersés entre plusieurs pages et scripts, il devient facile de perdre de vue, précisément au moment de la refonte, lesquels sont réellement utilisés. Cette approche — identifier d’abord quels canaux fonctionnent réellement, puis les consolider, comme nous l’avons fait ici — tient aussi comme principe général pour revoir le parcours entre une page d’accueil, des pages de service et une page de contact. Nous avons également abordé cette idée dans un article précédent, « Les trois endroits à corriger en premier sur un site qui ne reçoit aucune demande de contact », qui mérite également d’être consulté.

6. Nettoyage des anciens domaines — traitement d’un domaine de landing page abandonné

Les entreprises comme les sociétés de transport, qui ont créé des landing pages séparées pour chaque service, se retrouvent parfois, sans trop s’en rendre compte, avec leurs domaines dispersés à plusieurs endroits. Dans ce cas également, nous avons dû régler les domaines suivants.

Le troisième cas en particulier constitue une leçon importante. Le contenu de l’ancienne landing page de transport frigorifique — ses arguments autour des véhicules équipés d’unités de congélation à −20 °C, de la disponibilité 24h/24 et 7j/7, et de la livraison programmée et par itinéraire — a déjà été migré vers /refrigerated/ sur le nouveau site. Mais comme l’ancien domaine lui-même ne peut plus être résolu, probablement en raison d’un enregistrement DNS expiré, il n’y a aucun moyen d’y configurer une redirection 301. La leçon est que si l’on laisse un domaine non maintenu et non renouvelé, on risque de perdre soudainement, un jour, l’autorité de liens entrants et le trafic de recherche de marque qui s’y étaient accumulés.

Si votre entreprise exploite des landing pages de service sur des domaines séparés et envisage une refonte, nous recommandons de ne pas se contenter de décider où consolider le contenu, mais de vérifier en même temps le statut contractuel de l’ancien domaine — si le renouvellement est toujours actif et si son DNS est toujours vivant. Pouvoir encore configurer une redirection 301 pendant qu’une récupération est possible fait une réelle différence sur la facilité avec laquelle l’autorité accumulée pourra être reprise par la suite.

7. Vérification avant lancement et tâches après lancement

Avant de lancer le nouveau site, nous avons effectué les vérifications suivantes.

• Comparaison avec la liste de contrôle de conservation du contenu constituée aux chapitres 2 et 3 (les anciennes et nouvelles pages ont-elles des éléments correspondants)
• Vérification en direct des redirections 301 (envoyer réellement des requêtes et confirmer qu’elles renvoient les codes de statut et destinations attendus)
• Confirmation que le fichier de vérification de propriété Search Console renvoie correctement un 200
• Confirmation que les fichiers requis pour le lancement, tels que robots.txt, sitemap.xml et _headers, sont bien publiés

Il y a également des tâches à traiter après le lancement.

• Resoumettre sitemap.xml à Search Console
• Utiliser l’outil d’inspection d’URL pour confirmer individuellement que les URL à ID de l’ancien blog et les noms de fichiers .html datés redirigent bien en 301 comme prévu
• Sur plusieurs semaines, vérifier dans le rapport de couverture si les anciennes URL, auparavant en 404 ou exclues de l’index, finissent par être reconnues comme « Redirection »

Un projet de refonte ne se termine pas au lancement — il vaut mieux le planifier en partant du principe qu’il n’est véritablement terminé qu’une fois que l’on a surveillé les redirections et confirmé que le moteur de recherche les a correctement reconnues après le lancement.

8. Résumé — règles générales pour ne pas échouer une refonte

En distillant la réflexion tirée de ce cas Douzu Carry Service en idées qui s’appliquent également à d’autres projets de refonte, on obtient ce qui suit.

• La conception des URL vient en premier, le design vient après. Pour un ancien site disposant déjà de trafic de recherche ou de liens entrants, finalisez l’inventaire complet des URL et le tableau de correspondance vers les nouvelles URL (mapping 301) avant même d’envisager le design visuel.
• Ne lancez pas sans inventaire de contenu. Confirmez le « matériel de décision » tel que tarifs, horaires d’ouverture, coordonnées et points forts avec une liste de contrôle qui compare les anciennes et nouvelles pages une par une, avant le lancement.
• Ne conservez que les canaux réellement utilisés. Si vous trouvez un formulaire ou un script de soumission inutilisé, vérifiez ce qui se passe réellement, puis consolidez-le dans le canal encore actif.
• Associez chaque redirection à un saut unique et à une vérification de l’existence de la destination. Ne créez jamais de chaînes, et disposez d’un mécanisme qui n’envoie jamais vers une URL inexistante.
• Nettoyez les domaines pendant qu’ils sont encore vivants. Laissez un domaine séparé pour une landing page de service sans maintenance, et un enregistrement DNS expiré peut le rendre irrécupérable — vous coûtant l’opportunité même de reprendre l’autorité accumulée.

Une refonte de site n’est pas simplement le travail de rafraîchir le design — c’est aussi, en soi, un travail de conception consistant à déterminer comment reprendre l’autorité de recherche et le parcours de contact accumulés au fil du temps. Un aperçu concis de ce cas est résumé dans « le cas récapitulant la structure de Douzu Carry Service », qui mérite également d’être consulté.

Si vous avez des préoccupations similaires concernant la conception des URL ou la reprise du contenu existant, nous pouvons avancer ensemble sur l’inventaire de l’ancien site dans le cadre d’une consultation développement de site web.

Articles connexes

• Le cas récapitulant la structure de Douzu Carry Service
• Pourquoi KomuraSoft construit ses sites web sur le système de design de l’Agence numérique — coût réduit et qualité peuvent coexister
• Les trois endroits à corriger en premier sur un site qui ne reçoit aucune demande de contact
• Développement de site web
• Contact

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Par quoi une refonte de site doit-elle commencer ?

Pas par une maquette de design, mais par un tableau d'inventaire répertoriant toutes les URL de l'ancien site. Cela signifie recenser de façon exhaustive les pages statiques, les pages de zones et les articles de blog, ainsi que les « fichiers qui ne sont pas des pages mais restent accessibles publiquement », comme robots.txt, le fichier de vérification de propriété Search Console et les scripts de soumission de formulaire. À partir de là, on construit un tableau de correspondance qui décide, URL par URL, si elle doit être conservée telle quelle ou redirigée (301). Fixer cette base en premier réduit le retravail ultérieur lors de l'implémentation et de la création de contenu.

Quels sont les points clés de la conception des redirections pour éviter une baisse du classement dans les moteurs de recherche lors d'une refonte ?

Conservez exactement telles quelles les URL significatives — pages statiques, pages de zones, etc. — et redirigez uniquement en 301 les URL dénuées de sens, auto-numérotées par le système, vers de nouvelles URL portant un slug significatif. Comme règles de conception, nous appliquons deux points sans exception : chaque redirection se résout en un seul saut, sans chaîne, et le build inclut une vérification confirmant que l'URL de destination existe réellement, afin d'éviter l'accident d'une redirection 301 vers une URL inexistante. Après le lancement, nous surveillons Search Console pendant plusieurs semaines jusqu'à ce qu'il reconnaisse les redirections.

Pourquoi une refonte finit-elle parfois par faire baisser le nombre de demandes de contact ?

Parce que, dans le processus de rafraîchissement du design, des informations qui influencent directement la décision de contact — tarifs, horaires d'ouverture, coordonnées, points forts clés — peuvent discrètement disparaître sans que personne ne s'en aperçoive. En contre-mesure, nous constituons une liste de contrôle de conservation du contenu qui consigne, pour chaque page principale, les informations indispensables de l'ancien site (formules tarifaires, horaires de réception, services couverts, etc.), puis nous comparons les anciennes et nouvelles pages une par une avant le lancement. L'essentiel est de garantir cela par une liste plutôt que par la mémoire ou l'intuition.

Est-il acceptable de laisser à l'abandon une landing page inutilisée sur un domaine séparé ?

La laisser à l'abandon est risqué. Dans ce cas, l'ancien domaine de landing page pour le transport frigorifique ne pouvait plus être résolu, probablement parce que son DNS avait expiré — et même si le contenu avait déjà été migré vers le nouveau site, il ne restait aucun moyen de configurer une redirection 301 depuis l'ancien domaine. Laissez un domaine sans maintenance et sans renouvellement, et vous pouvez un jour perdre soudainement l'autorité de liens entrants et le trafic de recherche de marque qui s'y étaient accumulés. Lorsque vous envisagez une refonte, vérifiez à la fois le statut contractuel de l'ancien domaine et si son DNS est toujours vivant, et configurez la redirection 301 tant que la récupération est encore possible.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.