The mesh & links
The mesh is the whole interlinked set of pages plus the link graph between them. The crucial thing: those links are derived from the registry, not hand-placed and not stored on the page body.
What it is
Every page sits somewhere in an authority topology — a hub, sub-hub, or spoke at some tier (A = conversion, B = feeder, D = spoke). From that topology GoToMesh computes, for each page, four things:
- up-links — the parent hub(s) this page funnels into,
- sibling links — peer pages on a shared cluster axis,
- breadcrumbs — the path from an apex hub down to the page,
- redirects — old URLs that resolve to the current slug.
All of it is derived. The page body never contains a link to another page; the link graph lives in the registry beside everything else.
Why it matters
Keeping links out of the page body is what makes the mesh cheap to maintain. When a link edge moves — a new sibling appears, a hub is added — the engine just re-derives the projection and the site re-renders. That is a restamp (reason relink): no writer, no prose rewrite, no page file even touched. Only a real content change pulls the expensive writer step back in.
Mesh links live in the registry, so there is no second copy to drift. Re-derivation happens on every change, automatically and deterministically — the graph is always consistent with the registry.
How it works
You declare the link policy once, in gtmesh.config.yaml under link_rules. Each rule is a when → then against a page’s type, role, or entity, and sets one or more of:
| Rule field | What it does |
|---|---|
up | The parent a page links up to — e.g. hub_of(entity), or nearest_hub_in_authority_flow |
up_by_subtype | Sub-type-keyed parents (e.g. a brand_vs_brand comparison links up to both brand hubs — a dual parent) |
siblings | The peer axis — a cluster (same: topic) or a reference-table column, plus a count |
Rules are first-match-wins per field, so specific rules (by page type or entity) must sit above the generic role: spoke fallback or they get shadowed. The graph is then pruned per environment: each environment in gtmesh.config.yaml environments declares which statuses it renders, so a dev build only links among review/published pages, while prod links only the live set.
Key files & flags
| Thing | What it is |
|---|---|
gtmesh.config.yaml link_rules | The up / up_by_subtype / siblings policy |
gtmesh.config.yaml tiers / authority | The authority topology the links flow along |
gtmesh.config.yaml environments | Which statuses each environment renders (prunes the graph) |
registry/redirects.csv | The durable old-slug → current ledger the SSG emits 301s from |
gtmesh render-manifest --env <env> | The renderable slug set for an environment |
Related
- The page registry — where the links actually live
- The mental models — the authority layer and tiering
- Lifecycle & reconcile — why a moved edge is a cheap
relink