Redesigning dolist.com from the Ground Up¶

Q: How do you plan 301 redirects for a multi-site migration?

Use a mapping spreadsheet: old URL, new URL, page type, SEO priority, status, and comment. Avoid lazy redirects to the homepage, redirect chains, and forgotten URLs. Every redirect is an editorial and SEO decision — you're choosing where to transfer search intent.

Q: What information architecture works for a complex B2B site?

Clearly distinguish between families: Platform (the tools), Services (human support), Challenges (client problems), Resources (proof and content), Company (positioning). This structure prevents pages from overlapping and gives each family a distinct role.

Q: What are the main risks in a web redesign?

The highest risks are SEO (organic traffic loss from changed or poorly redirected URLs) and redirects (forgotten URLs generating 404s). Content quality, tracking continuity, and form functionality follow. Rigorous page-by-page QA and post-launch monitoring are essential.

Q: What tools help manage a web redesign effectively?

Spreadsheets remain hard to beat for URL mapping and status tracking. Search Console and an SEO tool are essential for auditing existing pages. Simple Python scripts (requests + BeautifulSoup) can automate quality checks on titles, meta descriptions, H1s, and status codes across the entire site.

Some web projects start with a blank page.

This one started with four websites.

Four websites for a single company.
Four entry points.
Four ways of presenting offerings that, in reality, were all part of the same ecosystem.

On one side, there was dolist.com, the main site: the brand, the blog, resources, customer stories, a significant share of the historical SEO equity.

Alongside it:

a site for Campaign, the email and SMS activation platform;
a site for Welkom Editor, the email builder;
a site for Dolist services, covering consulting, Studio, deliverability, data, and training.

On paper, each site had its own logic.

In practice, for someone discovering Dolist for the first time, things could quickly get confusing.

Where does the platform begin?
Where do the services end?
Is the email builder a separate product?
Is consulting a standalone offer?
Why are some areas of expertise on one domain and others elsewhere?
And above all: how does it all come together into a clear proposition?

The redesign of dolist.com was therefore not just a visual refresh.

It was a complete overhaul of the web ecosystem.

An attempt to bring order to years of accumulated content, offers, URLs, habits, SEO pages, resources, and historical decisions.

What this article covers

This is not a perfect methodology for web redesigns.
It's a retrospective on a real project — with its trade-offs, blind spots, constraints, mistakes, and moments of uncertainty.

Summary

Full redesign of dolist.com: consolidating 4 separate websites (dolist.com, campaign.dolist.com, email-builder.dolist.com, services.dolist.com) into a single unified web ecosystem.

What this article covers:

Why multi-site fragmentation was a problem — SEO, usability, coherence
The information architecture chosen — Platform, Services, Challenges, Resources
SEO work — slugs, titles, meta descriptions, 301 redirects
Content work — rewriting, HTML cleanup, editorial voice
QA testing, forms, post-launch tracking
What was hard, what worked well, and lessons learned

Source specification document

This project started with a full specification document. I'm making it available as-is — some figures have been removed, the rest is intact.

Download the specification document (PDF, 956 KB)

The Real Problem¶

The issue wasn't just:

"The website needs a new design."

It was more like:

"Our web presence no longer clearly reflects what Dolist has become."

Dolist isn't just a SaaS editor.
Dolist isn't just a service provider.
Dolist isn't just an email marketing platform.
Dolist isn't just an expert blog on email marketing.

It's a more hybrid entity:

an email and SMS activation platform;
a collaborative email builder;
marketing and technical support services;
deliverability expertise;
strong subject matter around GDPR, security, accessibility, and responsible digital practices;
historical editorial content;
highly SEO-driven resources;
customer case studies;
training programs;
a genuine professional culture around digital addressing.

The website therefore had to do something quite difficult:

bring everything together without flattening it.

The ecosystem needed to be unified without losing the specifics.

Campaign couldn't become a vague product page.
Welkom Editor couldn't disappear behind the word "tool."
Services couldn't be reduced to a list of support offerings.
Resources couldn't become a poorly organized library.
And existing SEO equity couldn't be sacrificed in the name of a cleaner redesign.

Why This Project Interested Me¶

This project interested me because it ticked exactly the boxes of web projects I find most stimulating.

Not projects where you apply a recipe.

Projects where you have to connect things that don't always speak the same language:

SEO wants to preserve what exists;
design wants to simplify;
content wants to explain;
business wants to sell;
internal teams want to find their offerings;
users want to understand quickly;
the CMS imposes its constraints;
redirects remind you that every URL has a history.

On this kind of project, a decision is almost never clean.

Changing a slug may seem trivial, but it touches SEO, redirects, readability, old campaigns, and internal linking.

Merging two pages may seem logical, but it can lose an important nuance.

Removing a page can make the structure cleaner, but break an old entry point.

Rewriting an H1 can improve clarity, but weaken a historical keyword ranking.

That's what makes the project interesting.

A web redesign, taken seriously, isn't about "making things more modern."

It's about constantly arbitrating between readability, performance, legacy, and forward vision.

Context: Four Websites, One Story to Rebuild¶

Before the redesign, Dolist existed across multiple websites.

flowchart TD
    A[Dolist web ecosystem before redesign] --> B[dolist.com]
    A --> C[campaign.dolist.com]
    A --> D[email-builder.dolist.com]
    A --> E[services.dolist.com]

    B --> B1[Brand]
    B --> B2[Blog]
    B --> B3[Resources]
    B --> B4[Customer stories]
    B --> B5[Historical SEO]

    C --> C1[Campaign]
    C --> C2[Email & SMS platform]
    C --> C3[Marketing automation]
    C --> C4[Transactional]

    D --> D1[Welkom Editor]
    D --> D2[Email builder]
    D --> D3[Responsive]
    D --> D4[Accessibility]

    E --> E1[Consulting]
    E --> E2[Studio]
    E --> E3[Deliverability]
    E --> E4[Data viz]
    E --> E5[Training]

This fragmentation had a historical rationale.

Each offering had probably needed its own space, pages, messaging, forms, and autonomy at some point.

But over time, this separation created several problems.

Problem 1: Overall Comprehension¶

A visitor could understand one piece of Dolist, but not necessarily the whole.

They could land on Campaign without clearly seeing the associated services.
They could discover Welkom Editor without grasping the connection to Campaign.
They could read a service page without understanding the underlying technological depth.
They could browse the blog without easily navigating back to the offerings.

The risk wasn't a lack of information.

It was fragmentation.

Problem 2: Dispersed SEO¶

The main SEO value was largely carried by dolist.com.

But part of the offering lived elsewhere.

This created a fairly classic situation:

the main domain carries the authority;
satellite sites carry strategic pages;
historical resources live on a different scope;
search intent is split;
cross-site linking is rarely optimal;
future evolutions become harder to manage.

The goal wasn't just to "bring pages back."

The goal was to concentrate value.

Problem 3: Offer Architecture¶

Dolist had multiple levels of offering:

products;
services;
areas of expertise;
client challenges;
resources;
proof points;
institutional pages.

But not everything was organized in an obvious way.

It was necessary to rebuild a hierarchy.

Not just a navigation.

A real information architecture.

mindmap
  root((dolist.com redesigned))
    Company
      Who we are
      Our history
      Our team
      CSR
      Press
      Careers
      Contact
    Platform
      Campaign
      Campaign DevKit
      Welkom Editor
    Services
      Consulting
      Deliverability
      Studio
      Data viz
      Training
      Support
    Challenges
      Communicate with your audiences
      Automate your communications
      Improve deliverability
      Secure your data
    Resources
      Blog
      Guides
      White papers
      Conferences
      Surveys
      Customer stories

This map isn't just a representation of the menu.

It's the logic of the site.

The Goal: Make dolist.com the Single Entry Point¶

The underlying objective was simple to state:

Bring everything back to dolist.com.

But behind that statement, there was a lot of work.

It wasn't just a matter of moving pages.

It required:

rethinking user journeys;
clarifying offering families;
creating consistent slugs;
preserving SEO traffic;
avoiding duplicate pages;
revisiting historical content;
producing new pages;
building a logical relationship between products, services, and challenges;
planning redirects;
verifying forms;
cleaning up imported content;
managing visuals;
preparing for launch;
organizing internal feedback after launch.

The project looked less like a classic redesign and more like a consolidation operation.

flowchart LR
    A[Satellite sites] --> B[Inventory]
    B --> C[Sorting]
    C --> D[Merging]
    D --> E[Rewriting]
    E --> F[Integration into dolist.com]
    F --> G[Redirects]
    G --> H[SEO monitoring]

Project Phases¶

Phase	Main activities	Key challenge
Scoping	Understand the ecosystem, identify sites to consolidate	Missing nothing
Architecture	Rethink sections: Products / Services / Challenges	Structural clarity
Production	Rewrite pages, create visuals, optimize meta	Editorial quality
Migration	Plan redirects, audit old URLs	SEO continuity
QA	Test pages, verify forms, fix details	Final quality
Launch	Go live, internal feedback, ongoing adjustments	Post-launch stability

Starting principle

A redesign shouldn't just make a website prettier.
It should make the system clearer.

Starting Hypotheses¶

At the beginning of the project, I had several hypotheses.

Some proved correct.
Others evolved.

Hypothesis 1: Consolidation Would Improve Clarity¶

This one proved correct.

Having a single website makes it easier to show that Dolist is built around a coherent whole:

Campaign for email and SMS activation;
Campaign DevKit for API and SI use cases;
Welkom Editor for email design;
services for project support;
challenge pages to translate client needs;
resources to back up expertise and proof.

The difficulty was not turning this consolidation into a catch-all.

Hypothesis 2: SEO Would Be the Main Risk¶

This one proved correct too.

When 80% of your SEO value sits on the main domain, you don't want to be clever about it.

Every important page had to be treated as an asset.

Not necessarily preserved as-is, but understood.

flowchart TD
    A[Existing page] --> B{Does it drive SEO traffic?}
    B -->|Yes| C[Analyze intent + queries + backlinks]
    B -->|No| D{Does it have 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[Remove or redirect to closest page]

Hypothesis 3: "Challenge" Pages Would Bridge SEO and Business¶

This was an important hypothesis.

Product pages explain what Dolist offers.

But users don't always search for a product.

They often search for a solution to a problem:

better communicating with their audiences;
automating their communications;
improving deliverability;
securing their data.

"Challenge" pages allowed us to start from the need rather than the tool.

This was also a way to create bridges between Campaign, Welkom Editor, and the services.

Hypothesis 4: Existing Content Would Be Easy to Reuse¶

This one was more optimistic.

In reality, a lot of content needed to be reworked.

Not because it was poor, but because it had been written for different contexts:

older sites;
older pages;
older positioning;
heavily product-focused pages;
heavily service-focused pages;
sometimes overly long content;
inherited WordPress blocks;
phrasing that no longer fit the new structure.

The hardest part wasn't writing.

The hardest part was often deciding what to keep.

The Architecture¶

The new logic for dolist.com had to hold multiple layers together.

Here's how I ended up thinking about it:

flowchart TD
    A[dolist.com] --> B[Company]
    A --> C[Platform]
    A --> D[Services]
    A --> E[Challenges]
    A --> F[Resources]
    A --> G[Conversion]

    C --> C1[Campaign]
    C --> C2[Campaign DevKit]
    C --> C3[Welkom Editor]

    D --> D1[Consulting]
    D --> D2[Studio]
    D --> D3[Deliverability]
    D --> D4[Data viz]
    D --> D5[Training]

    E --> E1[Communicate]
    E --> E2[Automate]
    E --> E3[Improve deliverability]
    E --> E4[Secure data]

    F --> F1[Blog]
    F --> F2[Guides]
    F --> F3[White papers]
    F --> F4[Conferences]
    F --> F5[Surveys]
    F --> F6[Customer stories]

    G --> G1[Contact]
    G --> G2[Forms]
    G --> G3[Newsletter]

What I liked about this structure was that it avoided putting all the weight on product pages.

Products don't stand alone.

They're surrounded by:

challenge pages;
services;
proof points;
content;
institutional pages;
downloadable resources.

That's closer to the true value of Dolist.

pie title Simplified page distribution on the new dolist.com
    "Platform" : 15
    "Services" : 20
    "Challenges" : 10
    "Resources" : 40
    "Company" : 10
    "Conversion / contact" : 5

The Difference Between "Platform," "Services," and "Challenges"¶

This was a central question.

We needed to avoid these three families stepping on each other.

Family	Role	Example user question
Platform	Present Dolist's tools	"What does Campaign do?"
Services	Present human, expert support	"Who can help me improve my campaigns?"
Challenges	Start from the client's problem	"How do I improve my deliverability?"
Resources	Inform, prove, deepen	"Do you have a guide, a case study, an example?"
Company	Reassure and position Dolist	"Who's behind this solution?"

This separation was very helpful.

Because the same area of expertise can appear in multiple places, but with a different angle.

For example, deliverability:

in Campaign, it's a feature and a technical foundation;
in services, it's an expert support offering;
in challenges, it's a client problem to solve;
in resources, it's guides, conferences, and educational content;
in company, it's a long-standing positioning element.

Key point

Good architecture doesn't eliminate repetition.
It gives a different role to each instance of repetition.

Tools and Stack¶

The project stack had nothing spectacular about it.

And that's a good thing.

In a redesign, the main challenge isn't having the most sophisticated tools.

It's maintaining a reliable view of what exists, what decisions were made, and where things stand.

Tools Used¶

Need	Tool / approach	Real value
Page inventory	Sitemap, exports, spreadsheets	Don't miss important URLs
Architecture	Tables, plans, diagrams	Compare possible structures
SEO	Search Console, SEO tools, manual analysis	Identify pages to preserve
Writing	Structured documents	Work on content before integration
Integration	WordPress	Build final pages
Tracking	Spreadsheets and checklists	Manage page by page
Analytics	Matomo, forms, tags	Verify measurement continuity
QA	Manual checklists	Control what often breaks
Internal comms	Launch email and feedback loop	Centralize bugs and typos

I stayed with simple tools because the project already had enough complexity.

Adding too heavy a tooling layer would have slowed things down more than it helped.

Why Spreadsheets Are Hard to Replace¶

For a project like this, the spreadsheet is nearly unbeatable.

Because a redesign is fundamentally a mapping table.

old_url,new_url,page_type,status,seo_priority,action,comment
https://campaign.dolist.com/...,https://dolist.com/platform/campaign/,Product,To migrate,High,Merge,"Strategic page"
https://email-builder.dolist.com/...,https://dolist.com/platform/welkom-editor/,Product,To migrate,High,Rewrite,"Keep key benefits"
https://services.dolist.com/...,https://dolist.com/services/studio/,Service,To integrate,Medium,Rewrite,"Take the Studio approach"

A more elegant tool can help with documentation.

But for tracking URLs, statuses, redirects, titles, meta descriptions, and priorities, the spreadsheet remains highly effective.

Building it Step by Step¶

1. Start from What Exists, Even When It's Imperfect¶

The first step was to look at the existing state without immediately trying to fix it.

This matters.

When you arrive on a redesign, you want to clean up immediately:

this page is too long;
this slug is weird;
this section is no longer clear;
this content is redundant;
this page shouldn't exist anymore.

But before deleting, you have to understand.

A page can be ugly but useful.
Old content can still capture a query.
A poorly organized page may be used in a campaign.
A forgotten form may still generate requests.

I tried to separate three questions:

Question	Why it matters
Does the page exist?	Raw inventory
Is it still useful?	Real value
Should it stay as-is?	Redesign decision

These are three different questions.

2. Rethinking Product Pages¶

Product pages were central.

We needed to present:

Campaign;
Campaign DevKit;
Welkom Editor.

But without isolating them completely from the rest.

Campaign¶

Campaign needed to be positioned as the email and SMS activation platform.

Not merely as a sending tool.

The key aspects to surface:

data centralization;
marketing campaigns;
transactional messages;
automation;
landing pages;
segmentation;
deliverability;
security;
APIs;
performance tracking;
responsible practices.

The risk was creating a page that was too long, since Campaign covers a lot.

I worked with a block logic:

flowchart TD
    A[Campaign page] --> B[Clear hero]
    A --> C[Main use cases]
    A --> D[Data centralization]
    A --> E[Message creation]
    A --> F[Email & SMS activation]
    A --> G[Automation / transactional]
    A --> H[Deliverability]
    A --> I[Security / GDPR]
    A --> J[Performance analytics]
    A --> K[Final CTA]

The challenge was showing depth without losing the reader.

Campaign DevKit¶

Campaign DevKit was a more technical subject.

Here, two mistakes had to be avoided:

over-simplifying and losing technical profiles;
over-detailing and making the page unreadable for decision-makers.

The natural angle was:

Using Campaign's features from your own information system.

So the content covered:

APIs;
connectivity;
information systems;
CRM;
CDP;
ERP;
e-commerce;
data;
secure flows;
transactional messaging;
webhooks;
imports / exports;
documentation.

This is a page where content must reassure without becoming a full technical reference.

Welkom Editor¶

Welkom Editor had a different role.

It needed to be presented as a collaborative email builder — but above all as a tool that solves very concrete problems:

producing emails faster;
maintaining brand consistency;
creating responsive emails;
improving accessibility;
enabling collaboration;
exporting to different ESPs;
avoiding starting from scratch with each campaign.

The challenge here too was not writing a generic "SaaS tool" page.

The subject isn't "a drag & drop builder."

It's more like:

How do you create clean, accessible, compatible, and reusable emails without relying on a full integration every time.

3. Reintegrating Services Without Reducing Them to a List¶

The services.dolist.com site contained a lot of value.

But bringing those services into dolist.com meant making them more readable.

Key areas to address:

email and SMS strategy consulting;
deliverability;
Studio;
data visualization;
training;
technical support;
operational management.

The risk was creating an endless "services" page.

I preferred to think of services as answers to situations.

Client situation	Associated service
"I want to improve my email performance"	Marketing consulting / deliverability
"I want to produce higher quality emails"	Studio / email design / HTML integration
"I want better insight into my results"	Data viz / dashboards
"I want to connect my tools"	API / data support
"I want to build skills"	Training
"I want to delegate operations"	Campaign management

This framing makes services more concrete.

4. Creating "Challenge" Pages¶

The "Challenge" pages were a real structural anchor.

They allow the site to speak less from the offer and more from the need.

The four main pages were:

Communicate with your audiences
Automate your communications
Improve deliverability
Secure your data

These pages matter because they link multiple parts of the site.

Example with "Improve deliverability":

flowchart TD
    A[Improve deliverability] --> B[Campaign]
    A --> C[Deliverability pack]
    A --> D[Deliverability experts]
    A --> E[SPF DKIM DMARC authentication]
    A --> F[Bounce complaint unsubscribe management]
    A --> G[O.P.E.R.A. supervision]
    A --> H[Guides and resources]

This page doesn't replace the Campaign page.

It doesn't replace a service page either.

It serves as an entry point by problem.

That's a logic closer to what users are actually searching for.

5. Updating Company Pages¶

Company pages had a different role.

They're not there just to "seem institutional."

They help explain:

who Dolist is;
where the company comes from;
what it stands for;
why it talks about deliverability, GDPR, security, and responsible digital;
who makes up the team;
how the company positions itself.

The pages involved included:

Who we are;
Our history;
Our team;
CSR;
Careers;
Press room;
Contact.

The trap here was producing overly corporate content.

The goal was to stay concise, credible, and grounded.

No need to force emotion.

Just clearly explain what Dolist is today.

6. Reorganizing Resources¶

Resources were a big chunk.

Dolist had a lot of content:

articles;
guides;
white papers;
conferences;
surveys;
customer stories;
webinars;
videos;
podcasts;
infographics.

The risk with a resource library is that it becomes a well-organized dump.

Everything is there, but no one can find anything.

The challenge was better organizing content formats.

flowchart TD
    A[Resources] --> B[Blog]
    A --> C[Guides]
    A --> D[White papers]
    A --> E[Conferences]
    A --> F[Surveys]
    A --> G[Customer stories]

    C --> C1[Deliverability]
    C --> C2[Marketing automation]
    C --> C3[GDPR]
    C --> C4[Email design]
    C --> C5[Acquisition]

    G --> G1[Public sector]
    G --> G2[Retail]
    G --> G3[Tourism]
    G --> G4[Non-profits]

Visuals, titles, meta descriptions, alt text, and descriptions all needed reworking too.

This work is repetitive.

But it matters.

A poorly named, poorly described, or poorly illustrated resource loses part of its value.

The SEO Work¶

Don't Treat SEO as a Final Layer¶

In a redesign, SEO can't arrive at the end.

If it does, it becomes a repair checklist.

In this project, SEO was present everywhere:

in the structure;
in the slugs;
in the titles;
in the meta descriptions;
in the H1s;
in the redirects;
in internal linking;
in resources;
in challenge pages;
in product pages;
in the handling of old sites.

The real SEO challenge wasn't just optimizing tags.

It was not breaking what existed while building a healthier structure.

Estimated Risk by Workstream¶

Workstream	Estimated risk	Main reason
SEO	★★★★★ Very high	Existing organic traffic across all sites
Redirects	★★★★★ Very high	Any missed URL = 404, SEO loss
Content	★★★★☆ High	Complex trade-offs, long rewriting process
Tracking	★★★☆☆ Medium	Before/after data continuity
Forms	★★★☆☆ Medium	Working forms = conversions
Design	★★☆☆☆ Moderate	Visible risk but more easily reversible

Slugs¶

I aimed for readable, consistent slugs.

Not slugs stuffed with keywords.

Not slugs that are too internal.

Not slugs that age poorly.

Examples:

/platform/campaign/
/platform/campaign-devkit/
/platform/welkom-editor/

/services/email-sms-strategy-consulting/
/services/studio-email-design/
/services/email-deliverability/
/services/marketing-dataviz/

/challenges/communicate-audiences/
/challenges/automate-communications/
/challenges/improve-deliverability/
/challenges/secure-data/

A slug should be precise enough to be useful, but stable enough to last.

Titles and Meta Descriptions¶

I spent a lot of time on titles and meta descriptions.

Not as a cosmetic exercise.

As a way to clarify the intent of each page.

A good title, in this context, needed to:

stay short;
be understandable;
carry the primary intent;
avoid filler;
not over-promise;
stay aligned with the page.

Example logic:

Page	Intent
Campaign	Email & SMS platform
Campaign DevKit	API and connectivity
Welkom Editor	Collaborative email builder
Deliverability	Improving email deliverability
Data viz	Driving marketing performance
Customer stories	Showing concrete proof

This work is meticulous, but it forces you to clarify pages.

If I can't summarize a page in a clean title, it usually means the page itself isn't clear enough yet.

Redirects¶

Migrating old sites to dolist.com was a sensitive point.

Things to avoid:

redirects to the homepage as a lazy fallback;
redirect chains;
redirect loops;
forgotten old URLs;
lost resources;
satellite pages left in limbo;
inconsistent slugs;
removed pages with no equivalent.

Standard redirect plan structure:

old_url,new_url,type,priority,comment
https://campaign.dolist.com/features/centralize-data/,https://dolist.com/platform/campaign/,301,high,"Feature merged into Campaign page"
https://email-builder.dolist.com/features/collaborative-email-builder/,https://dolist.com/platform/welkom-editor/,301,high,"Welkom Editor page"
https://services.dolist.com/studio/,https://dolist.com/services/studio-email-design/,301,medium,"Studio service"

Watch out

A redirect isn't just a technical operation.
It's an editorial and SEO decision: you're choosing where to transfer search intent.

The Content Work¶

The Hardest Part: Saying Less, But Better¶

The most difficult thing wasn't producing text.

The most difficult thing was choosing.

On a project like this, there's an enormous amount to say:

features;
benefits;
expertise;
proof points;
commitments;
use cases;
technical details;
associated services;
complementary resources.

But saying everything in one place makes pages heavy.

I tried to structure content with a more progressive logic:

flowchart TD
    A[Problem or need] --> B[Dolist's answer]
    B --> C[What it concretely enables]
    C --> D[How it works]
    D --> E[Proof / resources / customer stories]
    E --> F[Next action]

The idea was simple:

Don't force the reader to understand everything at once.

Avoiding the "SaaS Landing Page" Tone¶

This was an important point.

I didn't want the pages to look like generic conversion funnels.

The vocabulary needed to stay:

professional;
precise;
understated;
concrete;
usage-focused;
credible.

No need to promise a "revolution."

Dolist already has genuine subject-matter depth.

The job was to make it readable.

Cleaning Up Legacy HTML¶

A very concrete part of the project was also cleaning up inherited content.

Blocks from old WordPress installations, unnecessary spans, poorly formatted lists, inline styles, stray code snippets, broken or missing links.

A typical example:

<h2><span class="TextRun MacChromeBold SCXW58363964 BCX0">Campaign, a security guarantee for your data</span></h2>
<ul>
  <li data-leveltext="" data-font="Symbol" data-listid="15">
    <span data-contrast="auto">A <strong>technically optimized...</strong></span>
  </li>
</ul>

Transformed into something clean:

<h2>Campaign, a security guarantee for your data</h2>

<ul>
  <li>A <strong>technically optimized foundation for data security</strong>.</li>
  <li>Secure access with fine-grained user rights management.</li>
  <li>Data exchanges via standard, secure protocols.</li>
</ul>

Not spectacular.

But necessary.

The Visual Work¶

Building a Coherent Style¶

The redesign wasn't just about text.

A coherent visual universe also needed to be built.

We worked toward a more modern, SaaS-like, premium feel — dark backgrounds, cleaner visuals, blurred interfaces where appropriate, better mockups.

The challenge wasn't making things look nice for the sake of it.

Visuals needed to help understanding.

For example:

showing Campaign without exposing sensitive data;
illustrating Welkom Editor without inventing fake features;
presenting guides with a homogeneous style;
avoiding overly decorative visuals;
maintaining consistency across offer pages, resources, and company pages.

Resource Visuals¶

Guides and white papers needed real visual coherence.

The chosen approach: a clean, premium rendering with an open guide mockup on a dark navy background, reusing pages from the source document rather than adding decorative elements with no connection.

This works well because it provides:

consistency;
the feeling of a real resource;
a higher-quality finish;
continuity across content.

Alt Text, Titles, and Image Descriptions¶

This is repetitive work, but it matters.

Each image needed:

a clean filename;
a useful alt attribute;
a title;
sometimes a caption;
sometimes a description.

Not to do "image SEO" artificially.

But because it contributes to the overall quality of the site.

Example:

Filename:
practical-guide-email-deliverability.webp

Alt:
Dolist guide on best practices for improving email deliverability.

Title:
Practical guide: improving email deliverability

Caption:
A guide to understanding the technical and marketing levers that influence email deliverability.

Description:
Visual of the Dolist guide on email deliverability, presented as an open mockup on a dark navy background.

Forms, Tracking, and Details Often Overlooked¶

A redesign doesn't stop at visible pages.

There are all the connections around them too.

Forms¶

Things to verify:

contact forms;
resource download forms;
newsletter sign-up;
confirmation messages;
internal notifications;
GDPR notices;
post-submission redirects;
fields;
consents.

A page can be beautiful and completely useless if the form doesn't work.

Tracking¶

Measurement also needed consideration:

Matomo;
events;
forms;
page views;
clicks;
conversions;
resource downloads;
potential URL changes;
data consistency before and after launch.

Tracking is often treated as secondary.

But after launch, if the data isn't clean, it becomes very difficult to understand what's happening.

A detail that comes up frequently: the image that appears when you share a URL.

It's not always the one you'd expect.

Things to verify:

the Open Graph image;
Yoast settings;
default images;
caches;
LinkedIn preview cards;
old images still being pulled.

This kind of detail can seem minor.

But it contributes to the perceived quality of the site.

QA Testing¶

QA Isn't Just Quickly Clicking Around¶

QA is a very underestimated phase.

In this project, multiple layers needed verification:

Area	What to check
SEO	Title, meta, H1, canonicals, indexability
URLs	Slugs, old URLs, redirects
Content	Typos, missing text, duplicates
Design	Responsive, spacing, visual consistency
Images	File size, alt text, rendering, cropping
Forms	Submission, notification, confirmation
Tracking	Matomo, events, conversions
Navigation	Menu, footer, internal links
Accessibility	Heading hierarchy, contrast, alt text
Performance	Images, scripts, load time

Standard checklist:

## Page QA

- [ ] Final URL validated
- [ ] Old URL redirect tested
- [ ] Title filled in
- [ ] Meta description filled in
- [ ] Unique H1
- [ ] Consistent H2 structure
- [ ] No broken links
- [ ] Images optimized
- [ ] Alt text filled in
- [ ] CTAs functional
- [ ] Form tested if present
- [ ] Mobile responsive
- [ ] Tablet responsive
- [ ] Desktop responsive
- [ ] Tracking verified
- [ ] Page indexable if required

Bugs and Typos After Launch¶

Even with solid QA, a launched site always reveals things.

Typos.
Spacing issues.
Links.
Pages that behave differently in production.
Details no one noticed in pre-production.

That's why we set up an internal feedback process.

Not "email me every time you spot a typo."

Rather:

centralize complete, actionable feedback with URL, screenshot, and problem description.

Much more efficient.

What Was Harder Than Expected¶

1. Information Architecture¶

On paper, organizing a website seems straightforward.

In practice, every section can be debated.

Is deliverability a service, a challenge, a feature, or an area of expertise?
Answer: a bit of all of those.

Should Welkom Editor be under "platform" or have an autonomous entry?
Should training be a service, a resource, or a standalone page?
Should customer stories be under resources or under proof?
Should company pages be visible in the main navigation?

You have to accept that the perfect architecture doesn't exist.

You have to choose the most useful architecture.

2. Dual-Purpose Pages¶

Some pages serve multiple functions.

A page can be at once:

SEO;
commercial;
educational;
reassuring;
a proof point;
an entry to a form.

That's where trade-offs become subtle.

Optimize too much for SEO and the page becomes cold.
Optimize too much for conversion and it becomes pushy.
Explain too much and it becomes long.
Simplify too much and it becomes vague.

The right balance is rarely found on the first try.

3. Historical Content¶

Some content had existed for a long time.

It had sometimes been modified, revised, moved, and enriched.

Decisions needed to be made:

what to keep;
what to modernize;
what to merge;
what to remove;
what to turn into a resource;
what to redirect.

This work is more editorial than technical.

But it has a very concrete SEO impact.

4. WordPress Details¶

WordPress lets you move fast.

But it can also create a lot of small frictions:

poorly nested blocks;
inherited styles;
HTML added via copy-paste;
inconsistent margins;
oversized images;
unplanned anchors;
responsive behavior to fix;
content modified directly in the editor.

The CMS is never neutral.

It shapes how the site is actually built.

What Worked Well¶

1. Starting from Client Challenges¶

The "Challenge" pages helped move away from a purely catalog-driven logic.

Instead of only saying:

here are our products and services,

the site can also say:

here are the problems we help solve.

That's more natural for a visitor.

2. Giving Services Real Visibility¶

Dolist's services aren't secondary.

They're part of the value.

Consulting, deliverability, Studio, data viz, training, technical support: these are structural subjects.

Bringing them into dolist.com better shows the alliance between technology and expertise.

3. Better Connected Resources¶

Resources shouldn't live beside the site.

They should support the important pages.

A deliverability guide should reinforce a deliverability page.
A customer story should reassure from an offer page.
A conference should feed into an area of expertise.
A white paper should extend a challenge page.

flowchart TD
    A[Challenge page] --> B[Product page]
    A --> C[Service page]
    A --> D[Guide]
    A --> E[Customer story]
    A --> F[Conference]

    D --> A
    E --> A
    F --> A

This linking is what gives the site depth.

4. Building an Evolving Foundation¶

The launched site isn't an end state.

It's a foundation.

This matters.

A redesign doesn't fix everything.

It creates a healthier structure to keep improving:

content;
SEO pages;
resources;
forms;
visuals;
internal linking;
conversions;
measurement.

You have to accept that a living website is never "finished."

What I Learned¶

A Redesign Is an Architecture Project Before It's a Graphic One¶

Design matters.

But it comes after a deeper question:

What do we want to make understandable?

If the structure is unclear, design won't save the site.

It can make it more pleasant, but not necessarily more useful.

SEO Is a Healthy Constraint¶

SEO is sometimes presented as a painful constraint.

On this project, I saw it more as a useful discipline.

SEO forces you to ask the right questions:

what is this page for?
what intent does it cover?
is it redundant?
does it deserve its own URL?
should it be merged?
how does it connect to others?
how do you avoid losing its history?

SEO demands rigor.

Content Is Decisions¶

Content isn't just text to produce.

It's a decision about:

what to highlight;
what to leave out;
the vocabulary you choose;
the promise you're willing to make;
the level of detail you provide;
the path you propose to the reader.

That's why writing takes time.

Small Details Build Perceived Quality¶

A site can lose credibility over small things:

a poorly cropped image;
a missing meta description;
a strange URL;
a broken link;
a typo in an H1;
a form that doesn't confirm submission;
an oversized visual;
a page that loads poorly on mobile;
an inconsistent share image.

These details aren't secondary.

They build the experience.

What I'd Do Differently¶

1. Document Decisions Even Earlier¶

In hindsight, I'd document more of the trade-offs.

Not in the form of long meeting notes.

More like short decision records.

## Decision: create a Challenges section

Context:
Product pages alone don't cover all user intent.

Decision:
Create four need-oriented pages:
- communicate with your audiences;
- automate your communications;
- improve deliverability;
- secure your data.

Impact:
These pages serve as bridges between products, services, and resources.

Watch out:
Avoid overlap with product pages.

This type of note would have been useful for keeping a clear record of choices.

2. Automate More Checks Earlier¶

Some checks could have been automated sooner:

status codes;
missing titles;
missing meta descriptions;
absent H1s;
broken links;
images without alt text;
redirect chains;
unintended noindex pages.

Simple script example:

import requests
from bs4 import BeautifulSoup

urls = [
    "https://dolist.com/",
    "https://dolist.com/platform/campaign/",
    "https://dolist.com/platform/welkom-editor/",
]

for url in urls:
    response = requests.get(url, timeout=10)
    soup = BeautifulSoup(response.text, "html.parser")

    title = soup.title.string.strip() if soup.title else None
    h1 = soup.find("h1")
    meta = soup.find("meta", attrs={"name": "description"})

    print({
        "url": url,
        "status": response.status_code,
        "title": title,
        "h1": h1.get_text(strip=True) if h1 else None,
        "meta": meta["content"] if meta and meta.get("content") else None
    })

Not very complex.

But on dozens or hundreds of pages, it can prevent a lot of oversights.

3. Build an Internal Linking Map Earlier¶

Internal linking is often handled page by page.

I'd prefer to see it as a graph.

graph TD
    A[Campaign] --> B[Automate your communications]
    A --> C[Improve deliverability]
    A --> D[Secure your data]
    B --> E[Marketing automation guide]
    C --> F[Deliverability guide]
    D --> G[GDPR / security page]
    F --> C
    E --> B

This view would better reveal which pages support which intents.

4. Plan More Systematic Post-Launch Monitoring¶

After a launch, I'd want a dedicated dashboard:

Indicator	Why
404s	Detect forgotten old URLs
Redirects	Identify chains or errors
Indexed pages	Spot SEO anomalies
Organic traffic	Track variations
Forms	Verify conversions
Load time	Monitor performance
CTA clicks	Understand journeys
Resource downloads	Measure engagement

An automated workflow could easily send a daily summary during the first few weeks.

This is something I'd like to connect to my other experiments around Scrapy, n8n, and data pipelines.

Connections to Other Projects¶

This redesign connects to several subjects I've explored elsewhere.

Technical Detection with Scrapy¶

In my web technology detection project, I started from a similar idea: turning a set of websites into usable data.

Here, the context is different, but the logic is close:

crawl;
inventory;
qualify;
decide;
track.

See: Building a web technology detector with Scrapy

Expansion Signals with WTTJ / LinkedIn¶

In my article on expansion signals, I was working on detecting weak signals.

In a redesign, there are also weak signals:

a page generating little traffic but high conversions;
an old resource that's still heavily consulted;
a URL never visible in the menu but often shared;
a secondary form that's still useful;
a poorly organized page that's strategically important.

See: Detecting expansion signals with WTTJ, LinkedIn and n8n

Multi-Source Competitive Intelligence¶

The redesign also reminded me of the importance of cross-referencing sources.

You can't make decisions based solely on a sitemap.

You need to look at:

SEO data;
content;
user journeys;
offers;
internal feedback;
technical constraints;
business needs.

See: Building a multi-source competitive intelligence system

SDR Lead Machine¶

Finally, the subject connects to conversion logic.

A website isn't just a presentation support.

It's a component in a larger system:

acquisition;
qualification;
nurturing;
contact;
handoff to sales teams;
signal analysis.

See: Building an SDR lead machine

Frequently Asked Questions¶

Why consolidate multiple websites into a single domain?

Multi-site fragmentation dilutes SEO authority, complicates user navigation, and makes it difficult to present an integrated offering coherently. Consolidating onto a single domain concentrates SEO value in one place, simplifies internal linking, and gives a clear view of the entire ecosystem.

In Dolist's case, 4 domains carried strategic pages without reinforcing each other. Bringing everything back to dolist.com was designed to fix this structural problem.

How do you preserve SEO during a website redesign?

Each existing page must be treated as an asset: analyze its traffic, identify its queries, backlinks, and search intent, then decide whether it should be kept as-is, rewritten, merged with another, or redirected.

SEO shouldn't arrive at the end of the project as a checklist — it should drive trade-off decisions from the start: slug choices, page structure, merge decisions, redirect planning.

How do you plan 301 redirects for a multi-site migration?

The most reliable method remains a mapping spreadsheet: old URL, new URL, page type, SEO priority, status, and comment. Avoid redirects to the homepage "as a convenience," redirect chains, and forgotten URLs.

Each redirect is an editorial and SEO decision: you're choosing where to transfer a search intent. On dozens or hundreds of pages, this work demands rigor and consistent tracking.

What information architecture works for a complex B2B site?

The key is to clearly distinguish families: Platform (the tools), Services (human support), Challenges (client problems), Resources (proof and content), Company (positioning). This structure prevents pages from overlapping.

The same area of expertise can appear across multiple families — deliverability, for example, is both a Campaign feature, an expert service, a client challenge, and a resource topic. Good architecture gives a different role to each instance rather than eliminating them.

What are the main risks in a web redesign?

The highest risks are SEO (loss of organic traffic from changed or poorly redirected URLs) and redirects (forgotten URLs generating 404s that dilute PageRank). Content quality, tracking continuity, and form functionality are next in line.

Rigorous page-by-page QA and post-launch monitoring of 404s, SEO rankings, and conversions are essential.

What tools help manage a web redesign effectively?

Spreadsheets remain hard to beat for URL mapping and page-by-page status tracking. Search Console and an SEO tool (Screaming Frog, Ahrefs, SEMrush) are essential for auditing existing pages.

Simple Python scripts (requests + BeautifulSoup) can automate quality checks on titles, meta descriptions, H1s, and status codes across the entire site. Minimal code, but it prevents a lot of oversights on large-scale projects.

Conclusion¶

This redesign taught me one thing above all:

a company website always ends up reflecting its internal organization — even when that wasn't the intention.

Over the years, pages accumulate.
Offerings evolve.
Content multiplies.
Satellite sites appear.
Resources grow.
Priorities shift.

And one day, you have to pick up the thread.

The redesign of dolist.com, for me, was exactly that.

Picking up the thread.

Understanding what existed.
Identifying what still had value.
Consolidating what needed to be brought together.
Rewriting what had become unclear.
Preserving what was working.
Creating a healthier architecture.
Accepting that everything wouldn't be perfect at launch.
Building a foundation that could evolve.

I don't see this project as a "finished new website."

I see it as a new foundation.

A clearer foundation for presenting Dolist — its products, services, expertise, resources, and commitments.

And maybe that's what a good redesign really is.

Not a spectacular break.

A realignment.

Between what the company has become, what users need to understand, what SEO has built over time, and what the website needs to enable tomorrow.