Filterable Collections & Pagination

What it is

A collection is a card template bound to a content type's published entries — blog, or any custom type you've defined. It isn't a dedicated "archive page" — the same block can appear in a section on any page, a homepage "Featured listings" row, or a full "/blog" listing.

Ask the AI to add it: describe the content type, roughly how many cards per row, and what each card should show. It wraps one card template in a container bound to that content type — you never author a loop or multiple hardcoded cards, and the platform expands the template into one real card per published entry when the page is built.

Inside the card template, any node's text — or an <a>'s link, or an <img>'s image — can reference a {{fieldKey}} placeholder: a built-in (title, slug, excerpt, cover image, published date) or any custom field you defined on that content type.

Live preview in the canvas editor

The canvas editor shows a small sample of real, published entries in a collection's cards — not just the one empty card template — so you can see roughly what visitors will see while you're still styling it. The overlay badge reads "Filterable collection (live preview)" once real data is showing; before any published entries exist for that content type, it still shows the plain unresolved template. A WordPress-sourced collection (see WordPress) previews the same way, showing a small sample of the connection's real posts.

You're always editing the one shared card template, never an individual entry — clicking any of the sample cards selects that same template, so a content or style change applies to every real card once the page is published. Because every sample card maps back to that one template, dragging to reorder, duplicating, and deleting aren't available on a sample card directly; use the Style Panel and inline text editing as usual, or edit the collection's container itself for structural changes.

Filtering

Ask for a filter bar and describe what it should filter by — a price range, a category dropdown, a text search box. The filtering itself runs entirely in the visitor's browser once the page loads, matching against each card's own field values — there's no live query, no backend, and nothing else to wire up.

Four match modes are available:

• Exact match — a dropdown or select filtering a category-style field.
• Contains — a text search box, case-insensitive.
• Range min / max — a numeric floor and/or ceiling. A price range is two ordinary number inputs (one min, one max) rather than a single two-thumb slider control.

Pagination

A collection can be paginated instead of (or alongside) filtered — ask for it and say how many cards per page, and which style you want:

• Numbered pages — Prev/Next buttons plus clickable page numbers, the classic archive layout.
• Load more — a single button that reveals the next batch of cards each click, and hides itself automatically once every card is shown.
• Infinite scroll — no button at all; more cards load automatically as the visitor scrolls near the end of the grid.

Like filtering, pagination runs entirely in the visitor's browser — every card is already in the page when it loads, and pagination just shows or hides the right ones. Filtering and pagination are aware of each other: type into a filter and the paginated collection re-windows over the filtered results and jumps back to the first page, rather than showing a stale page of the old, unfiltered set.

Both filtering and pagination work identically for a WordPress-sourced collection — the cards are baked in at publish time from the connected WordPress site, and the same in-browser show/hide applies to them. Filter fields for WordPress cards use the same dot-path names as the card's own placeholders (for example a search box on title.rendered). The one difference: a WordPress collection can't use dynamic mode — it always bakes its full set (up to the collection limit) at publish.

Example

For a "Listings" content type with a numeric price field, a typical request:

Add a grid of listing cards below the hero — 3 columns, each card
showing the cover photo, title, and price, linking to its own detail
page. Add a min-price filter above the grid, and paginate it 9 per
page with numbered page buttons.

The AI wires the card template, the filter input, and the pager controls together using the same collection identity, so they all target the right grid without you naming anything yourself.

Taxonomy term cards

A taxonomy's terms — Category, Tags, or a custom taxonomy you've defined — can render as a grid of cards the same way, one card per term. Ask the AI for it the same way you'd ask for a content-type collection, naming the taxonomy instead of a content type.

Inside a term card, the built-in placeholders are the term's name, slug, and description, plus any custom field you defined on that taxonomy via Field Groups. Terms don't have their own detail page the way blog posts and content-type entries do, so a term card links wherever you tell the AI to point it — there's no automatic "/category/slug"-style URL to fall back to.

Limits

• By default, a single collection renders at most 200 cards, newest published entry first — see Dynamic mode below for catalogs larger than that.
• Only published entries are ever included — drafts never appear in a collection, on any deploy surface.
• Page size is capped at 100 cards per page.

Dynamic mode (large catalogs)

Everything above is fully static by default: every card a visitor could ever see is baked into the page at build time, so filtering and pagination need no backend at all — the page works from a download, self-hosted, forever. That's the right fit for most sites, and it's why it stays the default.

For a catalog past the 200-card cap — a large real-estate listing set, a big product catalog — ask for dynamic mode on that collection instead. The first page still bakes statically (fast first paint, works with zero JS), but any page or filter beyond it is answered by a small, cached, public read API on Zitegen's own servers rather than being baked in ahead of time.

Paging or filtering a dynamic collection past its baked first page costs a brief round-trip instead of being instant — normal for a catalog site, and the tradeoff for going past what a static build can hold.