Programmatic content in GTM30

13.1 Repository structure

Keep the layout boring and explicit so it is easy to reason about and refactor. In this repo, the main patterns look like this:

• app/ – routes implemented as pages, for example app/frameworks/gtm30/programmatic/page.tsx and app/blog/[slug]/page.tsx.
• lib/ – shared data + helpers. Examples in this repo: lib/structured-data.ts (JSON-LD), lib/gtm30-glossary.ts (typed glossary data), lib/frameworks.ts (framework listing).
• components/ – reusable UI like TableOfContents, Breadcrumbs, and SummarizeAIButton.
• public/ – static artifacts, including public/llms.txt to guide LLMs.

13.2 Entity schemas in TypeScript

If you want to move toward true programmatic generation, the best “starting point” in this repo is the existing pattern used for the GTM30 glossary: a typed array in lib/ plus routes that read it. From there, you can expand into a broader entity model (problems, use cases, integrations, alternatives) with the same approach.

• Keep a stable entityId and a human-readable slug.
• Put your “GTM traits” (ICP, pains, intent, lifecycle) in the entity record so templates and analytics can reuse them.
• If you add locales, keep the global entityId stable and localize the display fields (title/description/slug) per language.
• Model relationships as arrays (e.g. related problems, related glossary terms) to drive internal linking automatically.

Cursor then auto-completes and validates every field as you edit, and refactors safely when you rename traits or relationships.

13.3 Page generation in Next.js

This repo mixes static pages (hand-written framework pages) and dynamic routes for data-driven content (e.g. glossary terms and blog posts). Programmatic content fits naturally into the “data-driven route” pattern:

• generateStaticParams – enumerate your entity records and output route params (for example, glossary uses { slug }).
• generateMetadata – build title, description, and alternates.canonical from the same record.
• Page component – resolve the record by slug and render a consistent “spine” (H2 sections in a stable order).

Keep display logic in these template components, not scattered across many route files.

13.4 Structured data generation

Centralize JSON-LD builders so they always read from the same entity objects as your page templates:

• In this repo, JSON-LD helpers live in lib/structured-data.ts (for example createArticleSchema, createWebPageSchema, createDefinedTermSchema).
• Pick the closest schema.org types you already use (Article, WebPage, DefinedTerm, BreadcrumbList), and extend only when you have a strong reason.
• In the page component, render a <script type="application/ld+json"> tag with JSON.stringify of this object.

That way, crawlers and LLMs read the same structure your UI uses – no drift between UI and structured data.

13.5 Analytics wiring

This repo doesn't currently have a dedicated lib/analytics/ layer. If/when you add tracking, keep it centralized and always attach entity metadata.

• Centralize tracking calls in one place (one client component or helper), so the event schema stays consistent across pages.
• Send page_view with: entityId, entityKind, pageType, locale, and intentLevel.
• Reuse the same schema for CTAs, tool usage, and outbound clicks.

All downstream tools then see consistent traits and intent signals because they originate from the same entity model.

13.6 Mapping table from entity to traits

Keep mappings from entities to traits in code, close to the schema, so Cursor can refactor them with you:

• Implement helpers like useCaseToTraits(entity) that return trait objects such as icp_segment, company_size, primary_pain, lifecycle_stage_focus.
• Add boolean traits for high-intent behaviours (for example high_intent_use_case_viewer: true).
• Feed these traits into your analytics and automation stack so they stay aligned with what people actually read.

13.7 Multilingual implementation in Next.js

In this repo, multilingual content is currently implemented as explicit routes (for example /sgh/fi) rather than a global [locale] segment. The principle still holds: keep logic tied to stable ids, not to the language.

• Use per-language pages where it makes sense, but keep slugs and internal links consistent and canonicalized.
• If you later move to a shared entity store, localize display fields (title/description/slug) and keep the global entity id stable.
• Use generateMetadata to set canonical URLs (and optionally alternates.languages when you connect locales).
• Always send both locale and entityId in analytics. Automation runs on entityId, not language.

13.8 LLM integration from the same codebase

In this repo, the practical baseline for LLM integration is: (1) structured pages + JSON-LD, (2) public/llms.txt, and (3) the SummarizeAIButton that builds prompts from the page content.

• Keep canonical URLs and JSON-LD consistent, so LLMs have a stable source of truth.
• Use llms.txt to tell assistants to prefer canonical pages and glossary definitions when summarizing.
• If you later add retrieval, index content by entityId + section headings (matching the template spine) so it stays aligned with the page structure.

The key is consistency: the same entity ids and sections should power pages, structured data, analytics, and any retrieval you add later.

13.9 Working with this in Cursor

Cursor fits best when it operates on the structured system, not on random text blobs. Use it to:

• Generate new entity records from ICP descriptions, while keeping fields typed and consistent.
• Refactor schemas when you adjust GTM30 fields, with type errors surfacing drift.
• Generate boilerplate templates for new page types that still follow your spines and structured data patterns.
• Maintain mapping functions, analytics helpers, and retrieval utilities next to the entity types.

The stricter your entity model, the more safely you can let Cursor automate content, mappings, and retrieval around it.