An Odoo website can be beautiful.

Odoo has a stubborn reputation: a powerful management tool, but one that produces bland websites you can spot at a glance. That reputation comes from a misunderstanding of what customisation in Odoo really means. It is not about picking a colour from a menu, but about understanding the three levels at which you can shape the design.

Why Odoo websites all look alike.

Most Odoo websites are built the same way: you enable the Website app, choose one of the available themes, drag and drop a few ready-made blocks, and publish. The result works, but it carries the same visual signature everywhere: the same spacing, the same fonts, the same block layouts.

That is not Odoo's fault. It is the price of convenience. A standard theme and ready-made blocks are quick and accessible, but by definition they are what everyone uses. Standing out means going one step further.

The three levels of customisation.

To understand what you can do with an Odoo theme, you need to distinguish three levels of intervention, from the simplest to the most powerful.

• Level 1: the theme and its options. Colours, fonts, headers, footers: settings you can change without code. Quick, but everyone has access to the same settings.
• Level 2: blocks and snippets. You assemble and adjust the blocks provided. More freedom, but you stay within Odoo's visual vocabulary.
• Level 3: custom code (QWeb + CSS). You write your own components directly in Odoo's template engine. Complete design freedom, with no builder limits.

Nearly all Odoo websites stop at level 1 or 2. Level 3 is where real differentiation happens, and it is exactly where a specialist agency works. To understand this language, our article QWeb explained simply covers the engine behind it all.

What you can really customise.

At level 3, the question is no longer "what does Odoo allow?" but "what does the web allow?". In practice, on our projects we redefine:

• Typography. Variable fonts, fluid sizes, a bespoke vertical rhythm, instead of the 3 default fonts.
• Components. Cards, hero sections, editorial layouts, scroll animations: designed for the brand, not picked from a catalogue.
• Interactions. Micro-animations, transitions and hover effects that convey quality and are impossible with drag-and-drop alone.
• Grid and spacing. The breathing room of a page (often what separates a "professional" site from a "template" site) is coded down to the pixel.

Everything is still managed in Odoo: the client edits their content as usual, forms feed into the CRM, and nothing is outsourced. We add bespoke work without breaking the ecosystem.

Customisation without sacrificing speed.

The classic trap: wanting a spectacular site at the expense of performance. On many platforms, every effect adds a plugin, every plugin adds weight, and the site ends up slow. A slow site loses SEO and conversions, as we explain in is your Odoo website slow?.

The right approach is to code the design cleanly, with no extra layers: native CSS, lightweight animations, no unnecessary libraries. The result is a site that is unique and fast, with Core Web Vitals in the green.

Official benchmark: Google considers a page good with an LCP under 2.5 seconds, an INP under 200 milliseconds and a CLS under 0.1, measured at the 75^th percentile of page loads. Source: Google, Core Web Vitals, accessed in August 2026.

Build on what exists or start from scratch?

You do not always need to redo everything. If your Odoo website is already running, we can gradually recode the key pages (home, services) while keeping the existing instance. That is a redesign, not a rebuild.

If the site comes from another platform, we start from a blank design, but always inside your Odoo. Either way, the goal is the same: a site that looks like you and nobody else.

Our choice: a hand-coded design system.

At WebNest, we never start from a theme. For each client we build a small design system (a coherent set of components, colours and fonts) that we code directly in QWeb inside their Odoo. That is what gives us distinctive, fast sites that are easy to develop further.

It is also why we code by hand rather than using drag-and-drop: the native builder quickly hits its limits as soon as you want to stand out. We cover those limits, and how to get past them, in a dedicated article.