Refondre dolist.com de A à Z

Dolist avait quatre sites pour une seule offre : dolist.com (marque, blog, ressources, l’essentiel du SEO), un site pour Campaign, un pour l’email builder Welkom Editor et un pour les services. La refonte les a fusionnés en un seul site. Voici les choix d’architecture, de SEO et de contenu, et ce que je referais autrement.

Le problème de départ

Le besoin n’était pas « un nouveau design », mais : notre présence web ne reflète plus ce que Dolist est devenu.

Dolist, c’est à la fois une plateforme e-mail et SMS, un email builder, des services (conseil, délivrabilité, Studio, dataviz, formations), et beaucoup de contenus experts. Répartie sur quatre domaines, cette offre posait trois problèmes :

• la compréhension : un visiteur voyait un morceau de Dolist, rarement l’ensemble ;
• le SEO dispersé : le domaine principal portait l’autorité, les satellites portaient des pages stratégiques, sans se renforcer ;
• la hiérarchie des offres : produits, services, expertises et ressources n’étaient pas rangés de façon évidente.

flowchart TD
    A[Écosystème avant refonte] --> B[dolist.com<br/>marque, blog, ressources, SEO]
    A --> C[campaign.dolist.com<br/>plateforme e-mail & SMS]
    A --> D[email-builder.dolist.com<br/>Welkom Editor]
    A --> E[services.dolist.com<br/>conseil, Studio, délivrabilité, formations]

L’objectif tenait en une phrase : tout rapatrier sur dolist.com, rassembler sans tout aplatir.

L’architecture retenue

J’ai organisé le site en cinq familles, chacune avec un rôle distinct :

Famille	Rôle	Question du visiteur
Plateforme	Présenter les outils (Campaign, Campaign DevKit, Welkom Editor)	« Que permet Campaign ? »
Services	L’accompagnement humain et expert	« Qui peut m’aider ? »
Enjeux	Partir du problème du visiteur	« Comment améliorer ma délivrabilité ? »
Ressources	Prouver et approfondir (guides, cas clients, conférences)	« Avez-vous un exemple ? »
Société	Positionner Dolist	« Qui est derrière ? »

Une même expertise peut apparaître dans plusieurs familles. La délivrabilité est une fonctionnalité de Campaign, un service expert, un enjeu et un sujet de guides. Une bonne architecture ne supprime pas les répétitions : elle donne un rôle différent à chacune.

Les pages Enjeux (communiquer avec vos publics, automatiser, améliorer la délivrabilité, sécuriser vos données) ont été le choix le plus structurant. Les visiteurs cherchent rarement un produit, ils cherchent à résoudre un problème. Ces pages servent d’entrée par le besoin et de pont entre produits, services et ressources.

Les services, eux, ont été pensés comme des réponses à des situations (« je veux mieux piloter mes résultats » → dataviz ; « je veux monter en compétences » → formations), plutôt que comme une liste.

Le SEO, piloté dès le début

Le SEO était le premier risque : le site principal portait l’essentiel de la valeur. Chaque page existante a été traitée comme un actif à comprendre, pas forcément à conserver à l’identique.

flowchart TD
    A[Page existante] --> B{Apporte du trafic SEO ?}
    B -->|Oui| C[Analyser requêtes et backlinks]
    B -->|Non| D{Valeur business ?}
    C --> E{Doit rester autonome ?}
    E -->|Oui| F[Réécrire / optimiser]
    E -->|Non| G[Fusionner + rediriger]
    D -->|Oui| H[Repositionner dans l'arborescence]
    D -->|Non| I[Supprimer ou rediriger vers une page proche]

Trois chantiers concrets :

• Les slugs : lisibles et stables (/plateforme/campaign/, /services/delivrabilite-email/), sans bourrage de mots-clés.
• Les titres et métas : si une page ne se résume pas en un titre propre, c’est que la page elle-même n’est pas encore claire.
• Les redirections 301 : un tableur de correspondance (ancienne URL, nouvelle URL, priorité, commentaire), sans redirection vers l’accueil par facilité, sans chaînes, sans URL oubliée. Une redirection est une décision éditoriale : on choisit où transférer une intention de recherche.

Pour suivre tout ça, le tableur reste imbattable. Une refonte est fondamentalement une table de correspondance.

Le contenu : dire moins, mais mieux

Le plus long n’a pas été d’écrire, mais de choisir quoi garder. Les contenus existants avaient été écrits pour d’anciens sites, d’anciens positionnements, et souvent trop longs.

Chaque page a suivi la même progression : le besoin, la réponse Dolist, ce que ça permet concrètement, comment ça marche, les preuves, puis l’action suivante. Le ton devait rester sobre et précis, loin de la landing page qui promet une « révolution ».

Une partie très concrète a été le nettoyage du HTML hérité : spans générés par Word, styles inline, listes cassées. Pas spectaculaire, mais indispensable.

Côté visuels, l’agence a conçu l’univers graphique. Mon rôle était de vérifier que chaque visuel montrait les vraies offres, sans données sensibles ni fausses fonctionnalités, et que chaque image avait un nom de fichier, un ALT et un titre utiles.

Les détails qu’on oublie vite

Une page peut être très belle et parfaitement inutile si son formulaire ne marche pas. La recette a donc couvert bien plus que l’affichage :

• formulaires : envoi, notification interne, confirmation, consentements ;
• tracking : Matomo, événements, conversions, continuité des données avant et après ;
• image de partage : ce qui s’affiche sur LinkedIn n’est pas toujours ce qu’on croit ;
• SEO : titre, méta, H1 unique, canonical, indexabilité ;
• responsive, liens internes, poids des images.

Après le lancement, les retours internes ont été centralisés avec URL, capture et description, plutôt qu’un mail par coquille.

Ce qui a été compliqué

• L’arborescence : la délivrabilité est-elle un service, un enjeu ou une fonctionnalité ? Un peu tout ça. L’architecture parfaite n’existe pas, il faut choisir la plus utile.
• Les pages à double rôle : trop SEO, la page devient froide ; trop commerciale, elle devient agressive ; trop complète, elle devient longue.
• WordPress : blocs mal imbriqués, HTML collé, marges incohérentes. Le CMS n’est jamais neutre et impose un dialogue constant entre celui qui intègre et celui qui valide.

Ce que je referais autrement

1. Documenter les arbitrages plus tôt, avec de courtes fiches de décision (contexte, décision, impact, point de vigilance).
2. Automatiser les contrôles : codes HTTP, titres, métas et H1 manquants, liens cassés, redirections en chaîne. Un script Python de vingt lignes évite beaucoup d’oublis sur des centaines de pages.
3. Cartographier le maillage interne comme un graphe, pour voir quelles pages soutiennent quelles intentions.
4. Industrialiser le suivi après lancement : 404, indexation, trafic organique, conversions, avec un résumé automatique les premières semaines.

On retrouve ici la même logique que dans mes autres projets : inventorier, qualifier, décider, suivre. Voir le détecteur de technologies avec Scrapy et la veille concurrentielle multi-source.

À retenir

Une refonte est un projet d’architecture avant d’être un projet graphique : si la structure est floue, le design ne sauvera pas le site. Le SEO y joue le rôle d’une contrainte saine, qui oblige à se demander à quoi sert chaque page. Et chaque contenu est une décision : ce qu’on met en avant, ce qu’on laisse de côté, la promesse qu’on accepte de porter. Le site lancé n’est pas terminé, c’est une fondation plus claire pour continuer.