Odoo eCommerce Themes, Designed to Convert

What an Odoo eCommerce Theme Actually Is

In Odoo, a theme is not a template you pour content into. It is a module that supplies the styling system your pages are built on. Every Odoo Website and eCommerce theme is built on Bootstrap 5, and its look is driven by SCSS variables and a set of drag-and-drop building blocks (snippets). Your products, categories, pages, and blog posts live in the database; the theme only controls how they are rendered. That separation is the single most important thing to understand about Odoo themes.

Because content and theme are decoupled, you can switch themes or restyle the store without losing your catalog, your SEO settings, or your page structure. The Theme tab in the Website editor changes global styling, color palette, fonts, page layout, and button styles, and those choices propagate across every page of the store. A theme can also be installed or extended as a module from the Odoo Apps store.

Think of three layers that people casually call “the theme”: (1) the global look set in the Theme tab, (2) the reusable building blocks that assemble pages, and (3) optional theme modules (default, premium, or custom) that ship extra SCSS, snippets, and builder options. Layers 1 and 2 are what most store teams use daily; layer 3 is where partner themes and custom engineering live. Confusing layer 2 with layer 3 is why teams buy a heavy premium theme when Theme-tab tokens plus a few native blocks would have been enough.

For storefront work, treat the theme as the foundation of conversion architecture—not decoration. The rest of this guide works through each layer, then maps them to catalog design, product pages, B2B/B2C multi-website, SEO checklists, performance budgets, and the upgrade decision of customize versus rebuild.

Free, Premium, or Custom: Choosing Your Theme Path

Odoo ships with a capable free theme out of the box, and the Odoo Apps store lists hundreds of additional themes, many free and many paid, built by Odoo partners and the community. Before you pick one, decide which of three paths you are on: run the default theme and customize it, buy a premium theme that matches your industry, or commission a fully custom theme module.

The right path depends on how distinctive your brand needs to be, how much you want to spend up front, and whether you have access to a developer who knows Bootstrap, SCSS, and Odoo's QWeb templating. The default theme plus the Theme tab is enough for many SME stores; a premium theme buys a head start on industry-specific layouts; a custom theme is the answer when the brand cannot be expressed through shared blocks.

If you are evaluating a premium theme from the Odoo Apps store, vet it on five points before you install it. Confirm it targets your exact Odoo series (for example 19.0), because a theme built for an older series can break on a newer one. Check the author's update cadence and whether a release exists for the current series. Read store reviews and the support channel, since abandoned themes stop receiving security and compatibility fixes. Confirm the theme preserves Website Builder editing options so your team is not locked into hardcoded layouts. Finally, budget for version-to-version cost: many Apps authors sell per Odoo major version, so a theme for 18.0 is not automatically free for 19.0—confirm the purchase model on the Apps FAQ and the author's product page before you treat a premium theme as a one-time lifetime asset.

Roundup-style competitor content often ranks themes by demo beauty alone. For an operator, demo beauty is a weak signal. Prefer themes that stay modular (targeted QWeb inheritance instead of full template overrides), ship lean asset bundles, and keep native eCommerce blocks for product schema and catalog filters. A theme that looks polished but strips microdata or freezes the builder will cost more in SEO and rework than a quieter theme that upgrades cleanly.

Whichever path you pick, treat the theme as the foundation of your storefront, not a finishing touch. Re-skinning late is cheap in Odoo—content is preserved—but a late theme swap can still shift page weight and layout in ways that affect conversion and Core Web Vitals, so it is worth choosing deliberately at the start.

The Theme Tab: Setting Brand Identity

The Theme tab is where your store's identity is set. In current Odoo Website docs, theme colors are structured as five colors: three Main colors (mainly buttons and links) and two Light & Dark colors (mainly text and headings). Odoo also generates Color Presets from your palette so backgrounds, text, headings, links, and primary/secondary buttons stay consistent when you apply a preset to a building block. Status colors (success, warning, and similar feedback) live under Advanced and should stay distinct from brand accents so checkout errors do not look like marketing CTAs.

Fonts can come from system fonts (visitor OS defaults—fast and privacy-friendly), Google Fonts, or a custom upload. When adding a Google font, Odoo exposes a Serve font from Google servers control; turn serving off when you need the font hosted on your own server for regulatory reasons such as GDPR-oriented setups. Limit families and weights: every extra family is a render-blocking request that competes with hero images for LCP.

Page layout and button styles are also set here. Primary and secondary buttons can be styled as Fill, Outline, or Flat, with padding, corner radius, and optional on-click effects. That choice applies globally to every call-to-action on the store, including Add to Cart and Buy Now. Link underline behavior (none, on hover, always) and input-field padding and borders belong in the same pass so forms and commerce CTAs feel like one system.

Treat the Theme tab as your design tokens. Lock the palette, fonts, and button style before you build pages, because every building block inherits from them. Changing tokens later is safe—content is preserved—but designing bottom-up against undecided tokens produces a store that looks inconsistent no matter how good the individual blocks are. If you later Switch Theme from the Theme tab, re-check color presets and button styles; a new base theme can reset combinations you thought were permanent.

Building Blocks vs Theme Modules: Assemble Without Code

Odoo pages are assembled from building blocks, the drag-and-drop snippets the Website editor provides. Structure blocks (Intro, Columns, Content, Images, Catalog) act as containers; you drop Inner Content blocks (text, images, buttons, videos, embed code) inside them. This container-and-content model is what lets non-developers build and rearrange pages in a live WYSIWYG editor. Building blocks are not the same thing as an installed theme module: blocks are content you edit; the theme module is the styling and option package underneath.

Every block has its own Style tab for fine-grained tuning—spacing, background, alignment, and responsive behavior. eCommerce-specific blocks target the surfaces that matter for selling: the overall store, the catalog (shop) page, and the individual product page. Blocks can be scoped to apply across all pages or only to specific products, which is ideal for landing pages and seasonal campaigns.

The discipline that separates a clean store from a cluttered one is restraint. Because blocks are free and unlimited, teams tend to stack too many of them. Pick a small set of block patterns and reuse them—a hero, a featured-products grid, a trust strip, a testimonial block—so the store reads as one design system rather than a collage of unrelated widgets. Prefer native eCommerce blocks for product grids and product pages so schema.org product microdata and stock messaging stay intact; heavy custom HTML that reimplements the product card often drops rich-result fields.

Performance budget starts at the block layer. Each carousel, animation, third-party embed, and autoplay video adds JS and layout shift risk. Before you install a premium theme that ships dozens of decorative snippets, ask which five you will actually reuse on launch. Unused snippet libraries still cost you if they load assets globally—test with Lighthouse after install, not after months of content work.

Designing the Shop Page for Conversion

The catalog (shop) page is where most visitors first judge whether your store has what they want. Odoo gives you control over how that page filters, sorts, and displays products. Filters include a price-range slider, tags, and attribute filters that appear automatically when variants exist—up to four expanded by default, with additional attributes collapsed to keep the page tidy.

Layout controls let you set the number of columns and items per page and manually reorder products, so bestsellers and seasonal stock can be surfaced without changing your data. Per-product ribbons and badges highlight bestsellers, new arrivals, and sale items—a low-effort way to draw the eye to high-margin or urgent inventory.

For conversion, the catalog page should answer one question fast: is the thing I want here? Keep filters usable on mobile (sticky or easily opened, not buried under a full-screen carousel), use badges sparingly so they retain signal, and order the grid by what your data shows converts. Match grid density to the catalog type: dense grids suit SKU-heavy B2B; larger tiles suit fashion and home where imagery sells.

Catalog design also feeds discovery channels. Incomplete product data—missing GTIN/category, unpublished products, or empty attributes—hurts both on-site filtering and Google Merchant Center feeds. Publish only complete products, keep titles and images consistent with your theme’s card layout, and treat the shop page as the shared face of inventory, pricing, and SEO, not a gallery that drifts from the ERP record.

Designing the Product Page That Sells

The product page carries the decision. Odoo lets you choose between carousel and grid image layouts, and between Regular and Full-width layouts, so the page can match the product type. A Full-width layout suits a hero product, while a dense Regular layout suits a catalog of SKUs. The Attributes and Specification section can be placed at the bottom or inside an accordion, keeping technical detail available without pushing the buy button below the fold.

Conversion elements live on this page. Buy Now, Add to Cart, wishlist, and compare are toggles you enable per store; product reviews allow logged-in portal users to leave star ratings and comments; and stock or out-of-stock messages set expectations honestly. Each of these is a switch, not a default, so turn on the ones that match how your customers actually buy.

Top and bottom building blocks on the product page are where cross-sells and trust signals belong. Use the top block for urgency or reassurance (free shipping, returns) and the bottom block for related products and reviews. Treat the product page as a set of decisions—image, attributes, proof, and next step—rather than a wall of text.

Theme choices affect product SEO. Official themes and native product templates emit schema.org microdata so search results can show price, availability, and ratings. Custom product templates that hardcode markup without those fields, or that load enormous unoptimized image carousels, trade rich results and LCP for look-and-feel. Compress product images (Odoo converts uploads to WebP for official flows; third-party themes may not) and always fill alt text for accessibility and image indexation.

Mobile, Multi-Website, B2B/B2C, and Omnichannel Consistency

Odoo themes are responsive by default. The Bootstrap 5 foundation means layouts reflow for phones and tablets without separate mobile templates. That default is a starting point, not a finish line: test the catalog filters, the product image carousel, and the checkout button on a real phone, because those are the touchpoints where responsive layouts most often break. Mobile-first design—building the thumb path first, then expanding to desktop—beats “desktop layout that squeezes” when more than half of sessions are on phones.

A single Odoo database can run multiple websites, each with its own theme, domain, and language. Multi-website support lets you separate a consumer brand from a wholesale brand, or run localized stores, all backed by the same products and orders. Each site can be themed independently, so the consumer store can be bright and image-led while a B2B portal is dense and utilitarian. Multilingual sites also get hreflang and x-default tags from Odoo automatically when languages are configured—keep theme text and CTAs translation-ready rather than baked into images.

B2B versus B2C display is set per website. A dedicated B2B shop can hide prices entirely, showing a Contact us prompt instead, require sign-in, and expose company and VAT fields in the delivery step, while a B2C site shows tax-included pricing. Theme those as separate websites rather than cramming both audiences into one storefront: B2B needs clearer tables, bulk-friendly quantity controls, and restrained decoration; B2C needs stronger imagery, social proof, and urgency patterns. Pricing and catalog rules belong in configuration; the theme’s job is to make the correct mode readable.

Omnichannel brands should align website theme tokens with Point of Sale customer-facing surfaces—logo, primary color, and product naming—even though POS is not a Website theme module. Shoppers who browse on the phone and buy in store (or the reverse) notice brand drift faster than teams expect. Share the same product images and titles between eCommerce and POS; keep promotional ribbons honest across channels; and avoid website-only “sale” styling that contradicts in-store pricing.

Themes, Performance Budgets, and Core Web Vitals

Your theme directly affects page weight and therefore Core Web Vitals—the speed and stability signals search engines use in ranking. The two theme-driven factors that matter most are image weight and the amount of CSS and JavaScript a theme bundles. Premium themes that ship many animated blocks and sliders can load more assets than a lean default-theme build, so a richer theme is not always a faster one. In 2026 theme practice, performance-first design has overtaken decorative overload: lean bundles and purposeful motion beat carousels that tank LCP.

Set a practical budget before you build pages: one hero image optimized for the viewport, one or two font families at two weights max (or system fonts), a fixed set of reusable blocks, and no third-party widgets on the shop and product templates unless they prove conversion lift. Odoo compresses uploads and converts them to WebP in official flows; official theme images ship compressed. Third-party themes may not compress as aggressively—verify on a staging site with PageSpeed Insights or Lighthouse before and after install.

Because Odoo renders catalog content server-side rather than fetching it client-only, the theme's job is mostly presentation weight, not data loading. That keeps the controllable performance budget concentrated on images, fonts, and block count—three levers you can manage from the editor without writing code. Treat a regression in LCP (Largest Contentful Paint) or CLS (Cumulative Layout Shift) as a release blocker before you ship a theme change.

Fonts remain an underrated part of that budget. Prefer system fonts when brand guidelines allow; when brand fonts are mandatory, host them yourself when privacy rules require it and subset weights. Pair disciplined font loading with compressed hero images and a restrained block count, and a default-theme store will often pass Core Web Vitals on the same infrastructure where a heavier premium theme struggles.

Theme-Level SEO Checklist for Odoo eCommerce

Design and SEO share the same scaffolding. Odoo enforces best practice of one H1 per page and lets you set the title tag, description, and a SERP preview per page through Optimize SEO, with a Fill with AI helper for meta title, description, and keyword suggestions. A theme that respects this—one hero H1, semantic heading order, no level skips—keeps pages crawlable and avoids structure problems that quietly suppress rankings.

Odoo implements schema.org microdata so eCommerce products can show price, availability, and rating rich snippets in search results. Your theme's job is to render product data into that structured markup cleanly; the catalog and product-page blocks do this when configured correctly, which is another reason to prefer Odoo's native blocks over heavy custom overrides that strip the markup. Images need descriptive alt text; social share images can be set per page or as a default under Tracking & SEO.

Stability matters as much as structure. Odoo auto-generates a sitemap at /sitemap.xml that is cached and updated every 12 hours and, for large sites, chunked into files of up to 45,000 URLs following the sitemaps.org protocol. Renaming products or pages can auto-create 301 redirects; Odoo also supports 301, 302, 308, and 404 redirect mapping per website. A theme change that alters URL patterns without redirects wastes equity, so plan redirects as part of any re-skin or migration.

Odoo 19 also tightens the commercial SEO surface. Website SEO tooling emphasizes keywords, schema preparation, and content checks; eCommerce can enable Google Merchant Center under Website Configuration → Settings → Tracking & SEO, generating a dynamic product feed (commonly referenced as /gmc.xml) with essential product information and availability for published products. Theme and catalog work must keep product titles, images, prices, and availability complete—GMC rejects incomplete feeds even when the storefront looks fine. Use robots.txt editing under Website settings when you need crawl rules, and do not rely on robots.txt alone to hide pages you want fully deindexed (use page Indexed toggles, unpublish, or Search Console removals as documented).

When (and How) to Build a Fully Custom Theme

When the brand cannot be expressed through the Theme tab and shared blocks, the answer is a custom theme module. A custom Odoo theme is a module—not a set of edits to core files—that bundles your SCSS, QWeb templates, and builder options. Because it is a module, you can version it, deploy it across environments, and update Odoo without losing your design—if you inherit narrowly instead of forking entire templates.

Odoo's documentation includes a six-chapter Build a website theme tutorial that walks through creating a complete eCommerce theme for a fictional client, from theming and building with the website builder through two customization chapters, dynamic templates, and going live. It requires working knowledge of XML, Bootstrap 5, SCSS, QWeb (Odoo's templating system), and optionally JavaScript and OWL (Odoo Web Library) for interactive front-end behavior such as dynamic filters or cart widgets.

The companion Website themes how-to covers the full surface a custom theme can touch: setup, theming, layout, navigation, pages, media, building blocks, shapes, gradients, animations, forms, translations, and going live. The cardinal rule is to customize without touching Odoo's core files, so the Website Builder's editing options stay intact for your non-technical team after launch. Prefer small QWeb inheritance hooks over wholesale template overrides; modular inheritance is what survives major-version upgrades and coexists with other Apps modules.

2026 theme engineering also treats accessibility and RTL readiness as baseline—not polish. Contrast ratios, keyboard focus, semantic HTML, and early RTL testing for Arabic/Hebrew locales prevent expensive rework after launch. Dark-mode-aware palettes (light/dark variants already present in Theme colors) should be intentional when you ship campaign landing pages with dark sections.

Rebuild vs Customize: Theme Decisions for Odoo Upgrades

Theme debt shows up at upgrade time. Enterprise database upgrades can move you between major series, but third-party and custom website themes are not free of work: authors must ship a matching series release, and custom modules need manifest and template updates. Before any major upgrade, inventory every theme and website-related App, confirm series availability, and test on a staging copy—do not discover a broken shop only on production cutover.

Customize the current theme when the gap is small: new colors, a few snippets, header/footer tweaks, or targeted QWeb inheritance that still lets the Website Builder edit pages. Stay on customize when the author (or your team) still maintains the series, Lighthouse scores are acceptable, and native product/catalog templates remain in place. Customization that only lives in the Theme tab and builder is the cheapest path through upgrades because Odoo owns the base.

Rebuild (or replace) when the theme is abandoned for your target series, when full template overrides fight every Odoo eCommerce release, when Core Web Vitals fail because of theme JS you cannot trim, or when B2B/B2C multi-website needs have outgrown a single consumer-oriented premium pack. Rebuilding onto default + Theme tab or a slim custom module often costs less than forcing a bloated theme through two major versions—especially when Apps are sold version-by-version.

Practical upgrade sequence for storefronts: freeze new visual features, run SEO and redirect export, upgrade on staging with the theme uninstalled or swapped if it blocks, reinstall the series-matched theme or deploy the migrated custom module, re-apply Theme tab tokens, smoke-test shop/product/checkout on mobile, re-check Optimize SEO samples and GMC feed completeness, then cut over. Treat theme compatibility as a gate equal to accounting and inventory apps—not a cosmetic afterthought.

Common Odoo Storefront Design Mistakes (and Fixes)

A few mistakes recur on Odoo eCommerce stores. The first is theming bottom-up—styling blocks individually before setting the Theme tab—which produces inconsistency. Fix it by locking palette, fonts, and button style first, then building pages against those tokens so every block inherits the same identity.

The second is badge and block overload: enabling every ribbon, comparison, and animation because they are free. Each addition dilutes the signal and adds page weight. Fix it by enabling only the conversion elements your data supports and reusing a small set of block patterns across the store.

The third is ignoring mobile checkout and performance. A theme that looks great on desktop but pushes the buy button below the fold on mobile, or ships heavy sliders, will lose revenue and rankings. Fix it by testing the live store on a phone and with Lighthouse, and treating any LCP or CLS regression as a release blocker before you ship.

The fourth is buying a premium theme for the demo alone without checking series match, builder preservation, and upgrade pricing. Fix it with the five-point vetting list in the theme-path section and a staging install before go-live. The fifth is mixing B2B and B2C in one theme without multi-website configuration—fix with separate websites and display rules so wholesale pricing and consumer merchandising never fight on the same page.

Frequently asked questions