Skip to content

Developers · Pages and Layouts

Developer pages

Last updated 10 November 2026

Pages are the entry points for every URL in your Insites application. Each page is a Liquid file in the directory that maps to a route and handles a specific HTTP method. Pages fetch data via GraphQL, apply authorization policies, and delegate rendering to partials and layouts.

Routing

Each page is accessible at a URL determined by its location in the codebase. For example, is automatically accessible at .

You can override the default URL by setting the property in the page's YAML front matter.

Named Parameters

Use named parameters in your slugs to create dynamic routes. A slug like matches , and you can access the value via .

For optional parameters, use the syntax. For example, matches all of these:

  • - both parameters are null
  • - returns
  • - both parameters populated

Page Structure

page configuration elements

Every page file has two parts:

  1. YAML front matter - Configuration properties wrapped in delimiters. Defines the page's slug, layout, method, authorization, and metadata.
  2. Content body - Everything after the front matter. Contains HTML, Liquid, and JavaScript that renders on the page.
---
slug: my-page
layout: my_custom_layout
searchable: true
---
<h2>Welcome</h2>
<p>Your page content goes here.</p>

Available Properties

Available Properties panel in the Pages editor
Property Options Default Required Description
Auto-generated from file path No Overrides the default URL path. A page at defaults to .
No Which layout to use from . Set to an empty string to render without a layout.
get, post, put, patch, delete get No The HTTP method this page handles. Each page handles exactly one method. Create separate files for different methods on the same route.
No An array of authorization policies to run before rendering. If any policy fails, the user is redirected or receives an error.
No URL to redirect to. Use with to set the HTTP status.
301, 302 302 No HTTP status code for the redirect.
No A JSON object defining custom HTTP response headers. Useful for setting content types (e.g., XML, CSV) or CORS headers.
true, false false No When true, the rendered page content is indexed for search. Search works on the rendered version, so it cannot rely on dynamic data like or URL parameters.
Positive integer 3 No The URL nesting depth this slug is meant to resolve. Do not rely on it to block deeper paths: a page can still answer paths below its slug.
No A custom object accessible via . Use it to pass structured data to layouts and partials.
markdown No Converts the page body from Markdown to HTML before rendering.

Content Types

Pages default to HTML, but you can serve other content types by changing the file extension:

Extension Content-Type URL
text/html /path
application/json /path.json
application/javascript /path.js
text/xml /path.xml
text/csv /path.csv
application/rss+xml /path.rss

Custom Response Headers

Use the property to set custom HTTP headers on a page's response. Pass a JSON object of key-value pairs in the YAML front matter. You commonly use it to override the content type (e.g., serving XML or CSV from a Liquid page) or to set CORS headers for API endpoints.

HTTP Methods

Each page handles exactly one HTTP method. The default is GET. To handle POST, PUT, PATCH, or DELETE on the same URL, create separate page files for each method.

Note

For POST, PUT, PATCH, and DELETE requests, the default behavior is to redirect to the page defined by . If you need to return a response body instead (e.g., for AJAX requests), check the request format and render content accordingly.

Making Pages Searchable

Set in the front matter to index the page content for search. Keep in mind that search operates on the rendered output, so pages that rely on dynamic data (, URL parameters) will not produce meaningful search results.

Creating a Page

You can create pages through the Instance Admin UI or via code.

Via code:

  1. Create a new file in .
  2. Add YAML front matter with the properties you need (slug, layout, method).
  3. Add your page content below the front matter.
  4. Sync or deploy to see the page live on your instance.

Via Instance Admin:

  1. Navigate to CMS in the main menu.
  2. Select Pages.
  3. Click Create Page and fill in the required fields.

Note

Pages created in the Instance Admin can be pulled into your codebase using . We recommend managing pages via code and version control for production applications.