Platform Capabilities
See what Structured Pages can build from your catalog: searchable product pages, filters, comparison tools, structured data, APIs, member access, and flexible publishing.
Structured Pages is a structured content platform that turns a list of similar records (products, parts, dishes, venues, events, reference data) into a website where visitors can filter, sort, compare, and land on a real page for any single item.
This is the detailed version. For the short version, start with why people use it.
One source of truth
Your data is maintained once.
A record can appear in the catalog, on its own entity page, in search results, in structured data, through the API, and in other machine-readable representations. Those outputs are generated from the same underlying record rather than maintained separately.
Change a specification once and the published representations update from that source.
The published outputs are generated from the same underlying record. It does not guarantee that the underlying data is correct; that remains your responsibility.
What counts as a catalog
If your data fits a spreadsheet where each row is one thing and each column means the same thing on every row, it fits.
It does not have to be for sale.
| Works well | Example |
|---|---|
| Product and spec catalogs | Cameras, tools, equipment, components |
| Parts and fitment lists | Replacement parts filtered by dimension and compatibility |
| Menus and food data | Dishes filtered by course, allergen, or price |
| Events and schedules | Dates, venues, tracks, ticket links |
| Reference tables | Species, materials, standards, languages, heritage sites |
| Directories | Suppliers, members, or locations, with optional maps |
Not a good fit
Structured Pages is not designed to replace a full ecommerce system, publish primarily long-form editorial content, or handle data that changes continuously and requires real-time updates.
It works best when you have many comparable records with attributes that people need to search, filter, sort, or compare.
Content model
| Capability | Description |
|---|---|
| Single canonical record | Every entity is maintained once and generates its published representations from that same source. |
| Structured entities | Records share a schema, making comparison, filtering, and publishing predictable. |
| Unlimited attributes | Add the fields your dataset requires without changing the underlying publishing model. |
| Typed values | Numeric attributes behave as numbers for ranges and sorting; text attributes remain labels. |
| Optional fields | Missing optional values are omitted rather than rendered as empty labels. |
| CSV and Excel import | Import large datasets directly into the workspace. |
| Multiple catalogs | Independent datasets can coexist on one site with their own filters, while site-wide search can span them all. |
| AI enrichment (optional) | Expand or improve descriptions using your own AI API key. AI is not required to publish or maintain a catalog. |
Catalog experience
Structured Pages generates the browsing tools from the structure of your data rather than requiring you to build each filter manually.
| Capability | Description |
|---|---|
| Faceted filtering | Checkbox filters and range sliders update results immediately. |
| Numeric range filters | Double-ended sliders for price, weight, capacity, dimensions, or other numeric attributes. |
| Attribute filters | Categorical filters are generated from the values in your data. |
| Two catalog views | Responsive cards or a sortable dense table. |
| Sorting | Sort by supported numeric attributes directly from the catalog. |
| Comparison mode | Compare two to four entities side by side. Individual entity pages are indexable; visitor-created combinations are not published as separate indexable pages. |
| Site-wide search | Search across every dataset on the site. |
| Optional maps | Geographic datasets can display an integrated map above the catalog. Enable or disable it as needed. |
The result is a catalog that lets someone start with thousands of records and progressively narrow them down to the few that match what they need.
Entity pages
Every published record gets its own page.
The page layout is deliberately consistent so that visitors can understand one entity and move between entities without learning a new interface each time.
| Capability | Description |
|---|---|
| Consistent layout | Every entity uses the same underlying layout for clarity and maintainability. |
| Single hero image | One optimized 1200 × 630 image per entity can serve both the page and social sharing previews. |
| Structured specifications | Important attributes are presented in a consistent specification panel. |
| Optional CTA | Add a call to action with your own label and destination URL. |
| Optional pricing and stock | Display price, unit, and quantity when appropriate. Empty prices disappear automatically; a quantity of zero can remove an entity from the public catalog until it is restocked. |
| Catalog-style commerce | Combine price, availability, and a CTA link to let visitors browse and then click through to an existing purchasing system without requiring checkout on Structured Pages. |
| Optional FAQ | Add structured FAQ content where appropriate. |
| Optional documents | Attach files such as specification sheets or manuals, publicly or member-only. |
| Optional contact block | Include contact information when it is relevant to the entity. |
What gets generated for you
Published outputs are generated from your catalog and refreshed when the underlying data changes. You do not maintain each representation separately.
| Output | What it's for |
|---|---|
| HTML pages | A clean page for every published entity, plus catalog and category pages. |
| Titles and descriptions | Per-entity metadata, with your own overrides wherever needed. |
| XML sitemap | Keeps published URLs listed for search-engine discovery. |
| robots.txt | Crawler instructions aligned with the live route map. |
| JSON-LD structured data | Machine-readable descriptions of the entities and pages, derived from the same underlying facts. |
| Markdown representations | Lightweight, navigation-free versions of published pages for machine-readable access. |
| Semantic manifest | A line-delimited machine-readable summary of the catalog and its records. |
| llms.txt | A plain-text guide describing the site's available content and resources. |
These outputs are conveniences of the publishing system, not separate things you have to build and maintain.
Access beyond the website
Your catalog can also be accessed programmatically or restricted to specific users. Everything in this section is optional; none of it is required to publish a public catalog.
| Capability | Description |
|---|---|
| Documented REST API | Read-only access to products, categories, search, and ask, with API-key authentication, per-tenant isolation, and rate limits. See /docs/, with the OpenAPI description at /docs/openapi.json. |
| MCP connector | An MCP server wrapping the same authenticated API, allowing compatible AI assistants and tools to query a customer's actual catalog directly. See /mcp/. |
| Invite-only member accounts | Give named people — typically dealers, distributors, or internal teams — their own sign-in. There is no public self-registration. |
| Member-only attributes | Mark specific fields, such as dealer pricing, as visible only to signed-in members. |
| Member-only documents | Restrict specification sheets, manuals, and other files to authenticated members. |
| Embeddable widgets | Embed catalog listings in another website. |
Publishing and hosting
Structured Pages can be used as a hosted service or exported as ordinary files.
| Capability | Description |
|---|---|
| Static export | Export the complete site as ordinary files and host it elsewhere. Nothing needs to be installed or kept running. |
| Live hosting | Point a domain — including a subdomain of a domain you already use — at Structured Pages and manage the catalog live. |
| Private staging | Every workspace starts on a login-gated staging address that is kept out of search results. |
| Same templates either way | Static and live output come from the same setup. Switching between them is a deployment choice, not a rebuild. |
Your existing website can stay where it is
Structured Pages does not require you to replace your main website.
A company can keep its existing corporate or ecommerce site exactly where it is and publish its searchable catalog on a subdomain such as:
catalog.example.com
The two sites can operate alongside each other.
This is useful when the existing website already handles branding, editorial content, ecommerce, customer accounts, or other functions that you do not want to rebuild.
Site structure
A typical Structured Pages site consists of a small number of predictable page types.
| Page type | Purpose |
|---|---|
| Homepage | Introduces the catalog and explains what it contains. |
| Catalog pages | Browse, search, filter, and sort entities. |
| Entity pages | Detailed pages for individual records. |
| Comparison views | Compare selected entities side by side. |
| Content pages | Supporting pages such as About, Contact, Privacy, and Documentation. |
The same underlying record model powers the catalog and its individual entity pages.
Built for large catalogs
Structured Pages is designed around records rather than individually authored pages.
That matters when the catalog grows from dozens of items to hundreds or thousands.
You do not create each page manually. You maintain the underlying records, and the publishing system generates the pages, navigation, filters, metadata, and other outputs from them.
Adding another thousand records does not require another thousand page-building projects.
Design philosophy
Structured Pages deliberately avoids becoming another page builder.
There aren't dozens of templates, hundreds of visual controls, or endless configuration panels. Instead, the platform provides a carefully constrained set of publishing components that work consistently across different datasets.
Those constraints are intentional.
They make large catalogs easier to publish, easier to maintain, and easier to keep synchronized.
Every output, from HTML to Markdown to structured data, is derived from a single source of truth.
The goal isn't unlimited customization.
The goal is predictable, high-quality publishing at scale.
See it with real data
The best way to understand Structured Pages is to see the system working with actual datasets.
Explore the live examples to see how the same underlying publishing model can handle product specifications, industrial equipment, directories, reference data, collections, and other structured catalogs.