Redesigning dolist.com from the Ground Up

Dolist had four websites for a single offering: dolist.com (brand, blog, resources, most of the SEO), one site for Campaign, one for the Welkom Editor email builder and one for services. The redesign merged them into a single site. Here are the architecture, SEO and content choices, and what I would do differently.

The starting problem

The need wasn’t “a new design” but: our web presence no longer reflects what Dolist has become.

Dolist is at once an email and SMS platform, an email builder, services (consulting, deliverability, Studio, dataviz, training) and a lot of expert content. Spread across four domains, this offering had three problems:

• understanding: a visitor saw one piece of Dolist, rarely the whole;
• scattered SEO: the main domain carried the authority, the satellites carried strategic pages, without reinforcing each other;
• offer hierarchy: products, services, expertise and resources weren’t organized in an obvious way.

flowchart TD
    A[Ecosystem before the redesign] --> B[dolist.com<br/>brand, blog, resources, SEO]
    A --> C[campaign.dolist.com<br/>email & SMS platform]
    A --> D[email-builder.dolist.com<br/>Welkom Editor]
    A --> E[services.dolist.com<br/>consulting, Studio, deliverability, training]

The goal fit in one sentence: bring everything back to dolist.com, bring it together without flattening it.

The chosen architecture

I organized the site into five families, each with a distinct role:

Family	Role	Visitor’s question
Platform	Present the tools (Campaign, Campaign DevKit, Welkom Editor)	“What can Campaign do?”
Services	Human, expert support	“Who can help me?”
Challenges	Start from the visitor’s problem	“How do I improve my deliverability?”
Resources	Prove and go deeper (guides, customer stories, talks)	“Do you have an example?”
Company	Position Dolist	“Who’s behind this?”

The same expertise can show up in several families. Deliverability is a Campaign feature, an expert service, a challenge and a guide topic. Good architecture doesn’t remove repetition: it gives each instance a different role.

The Challenges pages (communicating with your audiences, automating, improving deliverability, securing your data) were the most structuring choice. Visitors rarely look for a product, they look to solve a problem. These pages are an entry point through the need and a bridge between products, services and resources.

Services were designed as answers to situations (“I want to track my results better” → dataviz; “I want to build skills” → training) rather than as a list.

SEO, driven from day one

SEO was the main risk: the main site carried most of the value. Every existing page was treated as an asset to understand, not necessarily to keep as is.

flowchart TD
    A[Existing page] --> B{Brings SEO traffic?}
    B -->|Yes| C[Analyze queries and backlinks]
    B -->|No| D{Business value?}
    C --> E{Should it stay standalone?}
    E -->|Yes| F[Rewrite / optimize]
    E -->|No| G[Merge + redirect]
    D -->|Yes| H[Reposition in the structure]
    D -->|No| I[Delete or redirect to a close page]

Three concrete workstreams:

• Slugs: readable and stable (/plateforme/campaign/, /services/delivrabilite-email/), no keyword stuffing.
• Titles and meta descriptions: if a page can’t be summed up in a clean title, the page itself isn’t clear yet.
• 301 redirects: a mapping spreadsheet (old URL, new URL, priority, comment), no lazy redirects to the homepage, no chains, no forgotten URLs. A redirect is an editorial decision: you choose where to transfer a search intent.

To track all of this, the spreadsheet is still unbeatable. A redesign is fundamentally a mapping table.

Content: say less, but better

The longest part wasn’t writing, it was choosing what to keep. Existing content had been written for old sites and old positioning, and was often too long.

Every page followed the same progression: the need, Dolist’s answer, what it makes possible, how it works, the proof, then the next step. The tone had to stay sober and precise, far from the landing page promising a “revolution”.

A very concrete part was cleaning inherited HTML: spans generated by Word, inline styles, broken lists. Not spectacular, but essential.

For visuals, the agency designed the graphic universe. My role was to make sure each visual showed the real offering, with no sensitive data or fake features, and that each image had a useful file name, ALT text and title.

The details that slip through

A page can be beautiful and completely useless if its form doesn’t work. QA therefore covered much more than display:

• forms: submission, internal notification, confirmation, consent;
• tracking: Matomo, events, conversions, data continuity before and after;
• share image: what shows up on LinkedIn isn’t always what you think;
• SEO: title, meta description, single H1, canonical, indexability;
• responsive, internal links, image weight.

After launch, internal feedback was centralized with URL, screenshot and description, rather than one email per typo.

What was hard

• The structure: is deliverability a service, a challenge or a feature? A bit of all three. The perfect architecture doesn’t exist, you pick the most useful one.
• Dual-purpose pages: too SEO-driven, the page turns cold; too sales-driven, it turns pushy; too complete, it turns long.
• WordPress: badly nested blocks, pasted HTML, inconsistent margins. The CMS is never neutral and requires constant dialogue between whoever integrates and whoever validates.

What I would do differently

1. Document trade-offs earlier, with short decision records (context, decision, impact, watch-out).
2. Automate checks: HTTP codes, missing titles, meta descriptions and H1s, broken links, redirect chains. A twenty-line Python script prevents a lot of oversights across hundreds of pages.
3. Map internal linking as a graph, to see which pages support which intents.
4. Industrialize post-launch monitoring: 404s, indexing, organic traffic, conversions, with an automatic summary during the first weeks.

It’s the same logic as in my other projects: inventory, qualify, decide, track. See the technology detector with Scrapy and the multi-source competitive intelligence.

Takeaway

A redesign is an architecture project before it’s a design project: if the structure is fuzzy, design won’t save the site. SEO acts as a healthy constraint that forces you to ask what each page is for. And every piece of content is a decision: what you highlight, what you leave out, the promise you agree to make. The launched site isn’t finished, it’s a clearer foundation to keep building on.