Skip to Content

The website.page Model: Understanding Odoo's Website Page Architecture

A complete guide to Odoo's website page model for developers and functional consultants
March 11, 2026 by
The website.page Model: Understanding Odoo's Website Page Architecture
Dasolo
| No comments yet

Introduction


In Odoo, models define how data is structured and stored in the database. Every piece of business data you work with lives in a model.


Understanding Odoo models is essential for both developers and functional consultants. Models are the foundation of the Odoo data architecture. They define Odoo fields, relationships, and business logic.


This article focuses on the website.page model. It powers static pages on your Odoo website. Whether you are building custom landing pages, managing content, or integrating with external systems, you will work with this model.

What is the website.page Model


The website.page model represents static website pages in Odoo. It is part of the Website app and stores pages you create manually, such as About Us, Contact, or custom landing pages.


This model in Odoo uses Odoo model inheritance. It inherits from ir.ui.view via the _inherits mechanism. Each website.page record links to an ir.ui.view that holds the QWeb template (arch) and metadata.

Dynamic pages, like the shop or blog listing, are generated differently.


They are not stored as website.page records. The website.page model is specifically for static content you create and edit through the website builder.

Key Fields in the Model


Here are the most important Odoo fields in the website.page model. Understanding these will help you work effectively with website pages.


1. name

Type: Char. This field stores the page title. It is displayed in the browser tab, in menus, and in search results. It comes from the linked ir.ui.view.


2. url

Type: Char. The page URL path. It must start with a slash. Examples: /contactus, /about-us. This is the path visitors use to access the page.


3. view_id

Type: Many2one (ir.ui.view). Required. Links to the QWeb view that contains the page content. The view holds the arch (XML template) and key. Deleting the view cascades to the page.


4. website_id

Type: Many2one (website). The website this page belongs to. In multi-website setups, pages can be specific to one website or shared (when empty).


5. is_published

Type: Boolean. Whether the page is visible to visitors. Unpublished pages return 404 or redirect. Use this to hide pages without deleting them.


6. website_indexed

Type: Boolean. Controls whether search engines can index the page. Set to False for thank-you pages or internal pages you do not want in search results.


7. date_publish

Type: Datetime. The publishing date. Used for scheduled publishing and for displaying when content went live.


8. header_visible

Type: Boolean. Whether to show the website header on this page. Useful for landing pages or full-screen experiences where you want to hide the header.


9. footer_visible

Type: Boolean. Whether to show the website footer. Like header_visible, this lets you create pages without the standard footer.


10. is_homepage

Type: Boolean. Computed field. True when this page is set as the website homepage. Only one page per website can be the homepage.


11. is_visible

Type: Boolean. Computed. Indicates whether the page is visible based on publication status, date, and visibility rules.


12. menu_ids

Type: One2many (website.menu). The menu items that link to this page. A page can appear in multiple menus or in none.


13. create_date

Type: Datetime. When the record was created. Automatically managed by Odoo. Useful for auditing and reporting.


14. write_date

Type: Datetime. When the record was last modified. Also automatically managed. Helps track content updates.


15. arch

Type: Text. The QWeb XML template. Stored on the linked ir.ui.view. Contains the HTML structure and Odoo snippets. Editable via the website builder.


16. key

Type: Char. Unique identifier for the view. Used in module XML and for inheritance. Format is usually module.view_name.


17. type

Type: Selection. The view type. For website pages this is always qweb. Other types include form, list, and tree.


18. active

Type: Boolean. Soft delete flag. When False, the record is archived. Comes from ir.ui.view. Archived pages are not served.


19. website_meta_title

Type: Char. SEO meta title. Overrides the default title in search results. Important for SEO visibility.


20. website_meta_description

Type: Text. SEO meta description. The snippet shown in search engine results. Keep it between 150 and 160 characters for best display.


21. website_meta_keywords

Type: Char. Meta keywords. Less important for modern SEO but still used by some systems. Comma-separated.


22. header_overlay

Type: Boolean. Whether the header overlays the content. Used for hero-style pages where the header sits on top of the banner.


23. header_color

Type: Selection. Header color scheme. Options like transparent, light, or dark. Affects contrast and readability.


24. visibility

Type: Selection. Access control. Options include Public, Signed In, Restricted Group, or With Password. Controls who can view the page.


25. redirect_type

Type: Selection. When the URL changes, this defines the redirect: 301 permanent, 302 temporary, or none. Important for SEO when moving pages.

How This Model Is Used in Business Workflows


1. Landing Pages and Campaigns

Marketing teams create landing pages for campaigns. Each page is a website.page record. They control URL, content, and publication date. Scheduled publishing uses date_publish.


2. Corporate Pages

About Us, Contact, Terms of Service, and Privacy Policy are typically website.page records. They are created once and updated as needed. Menu placement is managed via menu_ids.


3. Thank-You and Confirmation Pages

Pages like "Contact form submitted" or "Task received" are website.page records. Set website_indexed to False so they do not appear in search results.


4. Multi-Website and Localization

In multi-website setups, website_id determines which site shows the page. You can duplicate pages per website with localized content.


5. Gated Content and Restricted Access

The visibility field lets you create pages for signed-in users only, or for specific groups. Useful for member areas or internal documentation.

How Developers Extend This Model


Developers extend website.page using several patterns. Odoo model inheritance is the main mechanism.


Model Inheritance

Use _inherit = 'website.page' to extend the model. Add new Odoo fields, override methods, or add constraints. The inherit model in Odoo keeps your changes in a separate module for easy upgrades.


Adding Fields

Define new Odoo fields in your inherited model. Use the right field type: Char, Many2one, Boolean, Integer, Text, Selection. Consider website-dependent fields for multi-website.


Python Extensions

Override create, write, or unlink to add logic. Use super() to call the original. Be careful with the view_id relationship and cascade behavior.


Odoo Studio

Odoo Studio lets you customize pages without code. Good for quick layout changes. For complex logic or API-driven content, custom modules are more maintainable.

Best Practices


  • Use URL-friendly slugs. Avoid spaces and special characters. Use hyphens for readability.
  • Set website_indexed to False for thank-you pages, confirmation pages, and internal pages.
  • When changing URLs, enable redirect (301 or 302) to preserve SEO value and avoid broken links.
  • Fill website_meta_title and website_meta_description for every public page. This improves SEO visibility.
  • When creating pages via API or XML-RPC, create the ir.ui.view first, then the website.page with view_id. Ensure the view has type qweb and a unique key.

Common Mistakes


  • Creating a website.page without a valid view_id. The view must exist and have type qweb.
  • Using URLs that do not start with a slash. Odoo expects paths like /contactus, not contactus.
  • Forgetting to set website_indexed on thank-you pages. They end up in search results and can dilute SEO.
  • Changing a page URL without setting up a redirect. Old links break and search engines lose the connection.
  • Modifying the arch of a view that was edited in the website builder. The noupdate flag in ir.model.data can prevent your XML changes from applying. Reset it if needed.

Conclusion


The website.page model is central to static page management in Odoo. It stores page metadata, URLs, and publication settings. The actual content lives in the linked ir.ui.view.


Understanding its fields and how it inherits from ir.ui.view will help you configure, customize, and integrate Odoo websites effectively. Whether you are a functional consultant or a developer, a solid grasp of website.page will save time and prevent errors.

Need Help With Your Odoo Implementation ?


Dasolo helps companies implement, customize, and optimize Odoo. We specialize in API integrations and Odoo development. Our team has deep experience with the Odoo data architecture and models like website.page.


If you need help with your Odoo implementation, custom website pages, or integrations, we are here to help. Book a demo to discuss your project.

The website.page Model: Understanding Odoo's Website Page Architecture
Dasolo March 11, 2026
Share this post
Sign in to leave a comment