Pages

Pages are the standalone pages of your site — your home page, features, pricing, about, contact, and any landing pages. You build them by stacking blocks in a visual editor; there is no code to write.

How a page is built

A page is an ordered list of blocks. Each block is one section of the page — a hero at the top, a features grid below it, a pricing table, a call to action. You add blocks, fill in their fields, and drag them into the order you want.

Find your pages under Content → Pages. Create one with New page, give it a title and a URL slug (the /about part of the address), and open the editor.

Block types

SpiderPublish ships a rich set of block types you can drop onto any page:

  • Hero — a headline, subheadline, and call-to-action buttons, optionally over a background image or video.

  • Features grid — a grid of feature cards, each with an icon, title, and description. The icon accepts a Lucide icon name (e.g. bolt, lock, zap, check-circle) — rendered as a crisp SVG — or an emoji.

  • Stats bar — a row of key metrics (a number and a label).

  • Rich text — free-form formatted text.

  • Call to action — a focused headline, supporting line, and button.

  • Pricing table — plans with prices, feature lists, and buttons; one plan can be highlighted.

  • Testimonials — customer quotes with names and roles.

  • FAQ — a list of question-and-answer pairs.

  • Code example — a formatted code block with a language label.

  • Comparison table — a feature matrix across columns.

  • Logo cloud — a lineup of customer or partner logos.

  • Image — a single image with alt text and an optional caption.

  • Video embed — a YouTube or Vimeo video.

  • Spacer — controlled vertical spacing between blocks.

  • Component — drop in any reusable component from the marketplace or one you built yourself.

The exact fields for each block are shown in the editor as you add it.

Folders

Once you have more than a dozen pages, a flat list stops helping. Folders group pages in Content → Pages — create one, drag pages into it, nest folders inside folders, and collapse the ones you are not working on. A folder can also carry default SEO and location settings that the pages inside it inherit.

A folder is an organiser, not a page. It has no URL of its own and never appears on your live site by itself — it will not show up in search results, your sitemap, or a visitor's address bar.

Two things make folders worth setting up rather than just tidy:

  • A navigation menu item can be bound to a folder, so the menu tracks the folder's pages automatically instead of being retyped every time you add one.

  • A folder can have a landing page — the page a visitor arrives at when they click the folder in a menu.

The folder's landing page

Open a folder's settings and you will see two choices:

  • First page by position (the default) — the folder points at whichever published page currently sits first in the folder. Drag a different page to the top and the folder follows it. This needs no configuration at all: drop a page in and the folder has a destination.

  • Choose a page — pick a specific page as the folder's landing page. Useful when you want a written overview page to be the entry point, even though it is not first in the list.

If you choose a specific page and later delete or unpublish it, the folder quietly falls back to first-by-position. It does not break and it does not need fixing.

If a folder has no published pages at all — everything inside is still a draft — the folder simply has no destination. In a menu it renders as plain text rather than a link that goes nowhere.

Designing a folder landing page

The landing page knows what is in its folder. In a Liquid template or a component, folder.children gives you the folder's published pages in order, each with its title, URL, description, and image — so you can build a real index page (cards, a list, a directory) instead of writing the links out by hand:

{% if folder %}
  <h2>{{ folder.title }}</h2>
  {% for child in folder.children %}
    <a href="{{ child.url }}">
      <h3>{{ child.title }}</h3>
      <p>{{ child.seo_description }}</p>
    </a>
  {% endfor %}
{% endif %}

folder is only present when the page being rendered is that folder's landing page, so the {% if %} guard keeps the same template safe to use everywhere.

Folders with the CLI or an agent

  • Create a folder with content_create_page and is_folder: true.

  • Move a page into it by setting parent_id to the folder's id (send null to move it back out).

  • Set an explicit landing page with index_page_id on the folder (send null to go back to first-by-position).

  • content_list_pages returns is_folder and parent_id, which is how an agent discovers the folder id it needs for a navigation binding.

Folders are never published — publishing one is refused on purpose, because a folder has no URL.

Publishing a page

A page has two states: draft and published. Publishing makes it part of your site, but it does not push it to the live edge by itself — for that you deploy. The usual flow is: edit → publish the page → deploy the site.

Publishing, unpublishing, and deleting a page are safe actions: in the CLI and through agents they preview what will change and ask you to confirm.

Doing it with the CLI or an agent

Every page action is available outside the dashboard:

  • CLI — spideriq content pages lists your pages; create and edit commands follow the same pattern. See the CLI Reference.

  • MCP / agents — tools like content_create_page, content_update_page, and content_publish_page let an AI agent build and publish pages for you. See the MCP Reference.

A page's blocks are a simple ordered list — each block has a type and a data object:

{
  "title": "Home",
  "slug": "home",
  "blocks": [
    { "type": "hero", "data": {
        "headline": "Ship sites in minutes",
        "subheadline": "One platform for pages, blog, forms, and booking.",
        "cta_primary": { "label": "Start free", "url": "/signup" }
    } },
    { "type": "features_grid", "data": {
        "items": [
          { "icon": "bolt", "title": "Fast", "description": "Deploys in seconds." },
          { "icon": "lock", "title": "Safe", "description": "Preview before publish." }
        ]
    } },
    { "type": "cta_section", "data": { "headline": "Ready?", "cta_primary": { "label": "Get started", "url": "/signup" } } }
  ]
}

Create it over the API (or have an agent do it):

curl -X POST "https://spideriq.ai/api/v1/dashboard/content/pages" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d @home.json

Not sure which fields a block takes? Call GET /content/help/block-fields?block_type=hero (or the template_inspect_block_fields MCP tool) — it returns the exact field names so you never guess.

Tips

  • Slugs are forever-ish. Changing a published page's slug changes its URL; set up a redirect if the old URL was shared.

  • Each block has its own fields. If a block looks empty after rendering, check that you filled the fields the block expects (the editor flags fields it does not recognize).

  • Reuse with components. If you find yourself rebuilding the same section across pages, turn it into a component.

  • Group before you grow. Putting a section's pages in a folder early means its menu can be bound once and then left alone, however many pages you add later.

Next steps