A custom page gives you control over a particular route's content, layout, and browser interactions. Build with Cedros's page blocks, add custom code where you need it, then preview and publish the saved page.
Custom pages are saved on your site; they do not need an installable ZIP. If you need reusable site styling or server-side functionality, start with Choosing between a custom page, theme, and extension.
Start with the page and its purpose
Decide on the page's audience, route, main action, and required content before choosing an implementation. Check that the route is available and that any form, product, or service the page uses already exists.
Open Site → Pages → New page. Choose Use Page Builder for a layout assembled from blocks, or Write Raw Code for a custom implementation. For the full editor walkthrough, see Creating and publishing a page.
Use existing blocks when they cover the job. They provide editable content and participate in the site's theme. A starter gives you an initial layout to change; a shared template keeps a reusable layout connected to multiple pages. See Using shared layouts before linking pages that should change together.
For development through MCP, connect to the intended site and read its current Page Builder catalog. Use the returned templates, zones, block types, and field definitions rather than copying a document from a different installation. Keep block IDs stable when updating an existing page. The custom-page authoring reference covers the document and theme contracts.
Choose a web code mode
The Raw Code block offers two web modes:
| Mode | Use it for |
|---|---|
| React | Components and interactions that should share the site's theme. Enter your source in React Web Code. |
| HTML / CSS / JS | A self-contained design rendered in a sandboxed frame, with separate HTML, CSS, and JavaScript fields. |
Adding or changing React code requires administrator access. React runs in the page's browser context, so review it as code you are trusting on your site. The HTML mode's frame is isolated and does not inherit Cedros theme variables.
React code can export a component or call render(...). React and its hooks are available in the runtime. This editor is not a full application repository: an import does not install an npm package, and arbitrary packages or local project files are not automatically available. Check supported modules before depending on them.
Supply a useful Markdown Fallback as well. Include the page's essential information and links for Markdown readers and surfaces where the live code cannot render. A fallback does not reproduce interactive behavior.
Try a small React example
With Code Mode set to React, paste this into React Web Code:
export default function Page() { return <p>Welcome to our site.</p>; }
For Markdown Fallback, enter Welcome to our site. as plain text. Preview the page and confirm that the message appears. This small component uses no backend or external dependency and inherits its text styling from the page.
Replace the message with your content, then expand the component in small steps. Use semantic elements such as headings, paragraphs, links, and buttons. Give the complete page a clear title and a sensible heading order, and make interactive controls usable with a keyboard.
Inherit colors and typography, as this example does, or use the theme variables listed in the custom-page authoring reference. These let custom React content follow the active theme and the visitor's light or dark mode. When using a theme variable, provide a fallback value. If you add a stylesheet, scope selectors under a unique page root; avoid global rules targeting body, html, or the rest of the site.
Let the theme control the outer page width. Fill the available container with width: 100% and max-width: 100%; avoid 100vw, fixed minimum widths, or negative margins that cause sideways scrolling. Do not use the operating system's color preference to override the visitor's chosen Cedros mode.
Connect real data and actions
Page code runs in the visitor's browser. Anything embedded in its source or returned to it can be inspected by the visitor. Never put MCP credentials, provider secrets, or database credentials in the code, block properties, or Markdown fallback.
Use the site's existing blocks and integrations for supported actions such as submitting a form. For a custom API request, confirm the actual endpoint, authentication requirements, request shape, and response format from that service's documentation. Custom code does not grant access to private Cedros data.
Keep privileged work on the server through an appropriate extension or service. The server must check the caller's permissions; hiding a button or filtering data in the browser is not access control. Allow only the data the visitor should receive to reach the page.
Give every request a loading state, an empty state, and a useful failure message. Show success only after the action succeeds. Test the real destination and error path before launch, and check whether repeating an action could create duplicate submissions or purchases.
Review and publish the saved page
- Set the title and route, review the page's search metadata, and save the intended content. A new draft remains unpublished; saving an already published page from the editor can update the live page, so check its status before editing.
- Preview at desktop, tablet, and mobile web sizes. Check text, images, keyboard access, links, layout width, and both light and dark modes.
- Try every interaction and check the Markdown fallback. For connected services, verify actual results as well as the page's success message.
- Review the saved preview for the revision you intend to release. When replacing a live page, compare it with the current published version and preserve other intended changes.
- Resolve validation and release-readiness blockers, then publish the reviewed revision. If you edit again, review the new revision before publishing it.
- Open the public route as a visitor and verify the content and actions there. An editor preview does not prove that a published page or its integrations work.
Through MCP, use the Page Builder's validation, saved-preview, readiness, and publishing tools for the selected page. Read their current schemas and include the reviewed revision where requested. See MCP permissions and publishing controls for access and revision checks. Paid AI generation or review is not required to write and review a page manually.
Fix common problems
The page shows fallback text instead of the component. Check the selected mode, syntax, exported component, and supported imports. Reduce the code to a small working component, then add the failing part back. Keep the fallback informative while you fix the code.
The design ignores the theme. HTML mode uses an isolated frame. In React mode, check for hard-coded colors or fonts and replace them with inherited theme variables where appropriate.
The page scrolls sideways on a phone. Look for fixed widths, 100vw, large images, or content that cannot wrap. Keep the custom root within its host container and test again at a narrow width.
Saving React changes is denied. Ask an administrator to review and save the code with the required access. Page-edit permission alone may not be enough.
The preview works but the public page does not. Confirm the published revision and route, then test with the visitor's access. Check failed requests and any dependency on an administrator's signed-in session. Do not publish credentials to make a request work.