Documentation

Documentation / Combinations

Public Hub Pages

A public hub page is a single landing page on your destination site that gathers every article a combination produces — a “directory page” for visitors to scan and click through. Publishing one is opt-in per combination and OFF by default.

What a public hub page is

Each combination in Power Author is a template that produces one article per (seed keyword × modifier) pair. A public hub page is the optional parent of those articles on the live site: a single URL that lists every generated article in the combination, optionally grouped under section headings drawn from a chosen modifier group.

On Specific Resume, hub pages live under /career-advice/{slug}. The exact path on your destination is destination-defined; the slug field on the combination is just the URL segment.

When to use one

Reach for a hub page when a combination's articles share a parent topic and benefit from a single discoverable entry point — for example, “Cover letter examples” covering dozens of roles across several fields. Skip the hub for combinations that are still being drafted, or where each article stands alone and doesn't need a directory.

Hub layout

The hub_nav_style field on a combination controls the on-page layout. There are three values; pick the one that matches the depth of your varying-group modifier tree.

  • Grouped by parent (key grouped, default): each article sits under the immediate parent of its varying-tag. Each parent becomes a section heading with an optional one-line intro drawn from that modifier's description, then a link grid of articles in the bucket. Best for shallow (1–2 level) trees where every L2 is a meaningful section on its own.
  • Grouped by Top-level (L1) (key grouped_by_top): each article sits under the L1 ancestor of its varying-tag — one section per top-level modifier. All L2 and L3 articles in the same L1 branch sit together as a flat link grid under that section, and the L1 modifier's description renders as the section intro. Recommended when the role tree has 3+ levels (e.g. field → role → niche) and you want one section per field.
  • Flat link list (key flat): a single grid of every article in the combination, with the hub title and intro above the list and no section headings. Best when there's no meaningful grouping or the article count is small.

Switching hub_nav_style on an already-published hub does not call unpublish — the new layout ships on the next Push hub to site or full publish run.

Required fields for publishing

Before a hub page can ship to the destination site, the combination needs:

  • publishAsHub = true
  • A non-empty slug (the public URL segment)
  • At least an English title in the per-locale hub copy

These are validated at publish time by validatePublishableCombinations. A missing field fails the next article publish run with a clear error so you don't accidentally ship a half-configured hub.

Hub copy fields (per locale)

Each enabled language has its own row of hub copy in combination_translations:

  • title — the H1 on the hub page and the SEO page title.
  • description — the intro paragraph rendered above the sections (or above the flat grid).
  • metaDescription — the SEO meta description.

Translations

Source-language copy (typically English) is authored manually here — in the combination editor, or via the MCP upsert_combination_hub_copy tool. Other locales are not triggered by saving hub copy; they come from the workspace Translate Taxonomy run, which translates the source copy into every enabled language.

Publishing flow

A hub appears on the destination site as part of the next publish run that includes at least one article from the combination — the definitions sync ships the hub block alongside the articles. The combination editor also exposes explicit Push hub to site, View on site, and Unpublish hub page controls so you can update hub-only copy without round-tripping through a full article publish.

Example use case — a hub for a job-posting platform

Imagine a major job posting platform wants a directory of cover letter examples for every role on the site, grouped by field. The end-to-end shape:

  • Combination: cover letter examples for {{role:plural}}.
  • Modifier groups: role with two levels — L1 = field (e.g. Healthcare, Engineering) and L2 = role (e.g. Registered Nurse, Software Engineer).
  • Hub slug: cover-letter-examples.
  • Hub title (en): “Cover Letter Examples by Role”.
  • Hub intro (en): a short two-sentence paragraph framing the directory and what visitors will find.
  • Hub layout: Grouped — sections per L1 field, each with an optional one-line description above the role grid (drawn from the L1 modifier's description).

Result: visitors land on /career-advice/cover-letter-examples, scan the field sections, click into a role, and read the role-specific cover letter example article.

For an MCP-driven version of this same flow (Claude or another assistant calling the tools end-to-end), see Integrations → MCP (AI assistants).

Authoring modifier descriptions

The L1 (field) descriptions used in the grouped layout aren't stored on the modifier itself — they live on the per-locale modifier_translations.description column. You can author them one at a time in the dashboard, but for the “describe every L1 in a group” workflow the fastest path is the MCP bulk tool. See Integrations → MCP (AI assistants) for bulk_update_modifier_descriptions.