@pas7/llm-seo for static sites: deterministic llms.txt and canonicals

A practical guide to @pas7/llm-seo: generate llms.txt artifacts from one config, build canonical URLs from manifests, support mixed routing, and validate everything in CI.

15 Mar 2026· 8 min read· Technology

npm GitHub Talk to PAS7 Studio about SEO automation

Best forFrontend engineersTechnical SEO engineersNext.js teams shipping static or hybrid sitesTech leads building deterministic content pipelines

Editorial cover showing a static-site build pipeline that generates llms.txt, llms-full.txt, canonical URLs, and CI reports from one configuration file

quick read

What the package gives you

The package makes more sense as infrastructure than as a one-off generator. You describe the site once, then let generation and checks run inside the build pipeline. [1][2][5]

Generate llms.txt and llms-full.txt from one config. [1][3]

Build canonical URLs from manifest items instead of hand-assembling them section by section. [1][2][3]

Support mixed routing per manifest section with prefix, suffix, locale-segment, and custom. [1][2]

Lint policy issues such as restricted claims, duplicates, and empty sections. [1][4]

Run CI checks with explicit exit codes and an optional JSON report. [1][5]

Plug the generator into Next.js and static-site builds without a lot of custom glue code. [1][5][6]

Why teams need this in the first place

Adding one llms.txt file is easy. Keeping it correct over time is the harder part. Routes change, sections grow, locales expand, and canonical rules drift when they are maintained by hand in several places. [1][2][3]

That is the gap @pas7/llm-seo tries to close. The package treats LLM-facing SEO files as outputs of one configuration model, alongside canonical generation and validation, instead of leaving them as text files that slowly separate from the real site. [1][2][5]

The determinism is also important. The format docs describe sorted output, explicit line endings, configurable trailing slash behavior, and stable generation from the same input. That is exactly what build systems need if generated files are going to be checked in CI. [3][5]

Core idea

The package is useful because it keeps routing, artifact generation, and validation tied to the same source of truth. [1][2][3][5]

The config works like a contract for the site

The quickest way to understand the package is to look at what the config is responsible for.

A trimmed config example from the docs shows the shape clearly:

import type { LlmsSeoConfig } from "@pas7/llm-seo";

export default {
  site: {
    baseUrl: "https://example.com",
    defaultLocale: "en",
  },
  brand: {
    name: "Pas7 Studio",
    tagline: "Automation and SEO infra for modern products",
    description: "Deterministic LLM/GEO SEO artifacts for static and hybrid sites.",
    locales: ["en", "uk"],
  },
  manifests: {
    blog: {
      sectionPath: "/blog",
      routeStyle: "locale-segment",
      items: [
        { slug: "/llm-seo-basics", locales: ["en", "uk"] },
        { slug: "/canonical-strategy", locales: ["en"] },
      ],
    },
  },
  output: {
    paths: {
      llmsTxt: "public/llms.txt",
      llmsFullTxt: "public/llms-full.txt",
      citations: "public/citations.json",
    },
  },
} satisfies LlmsSeoConfig;

Site and brand

The config defines the base URL, default locale, brand metadata, and the site sections that should show up as hubs or references in the generated output. [1][2][3]

Manifests

Each manifest section describes a route pattern and a list of items. That is where the package gets the information it needs to generate canonicals and content references. [1][2]

Policy

Policy rules let teams restrict claims, allow whitelist phrases, and keep generation aligned with editorial constraints. [1][4]

Output and format

Output paths, trailing slash behavior, locale strategy, and line endings are configured explicitly so generation stays stable across environments. [1][2][3]

Why the config matters

Once the site structure is described well, the rest of the package becomes much easier to trust. [1][2][3]

Routing and canonicals are where it gets interesting

This package would be much less useful if it only wrote text files. The more important part is that it can derive canonical URLs from route-aware manifests. [1][2]

Use it for simple prefixed routing

A section can use prefix when the site follows a straightforward route model and you mainly want consistent canonical output. [2][3]

Use it for mixed section routing

The package supports suffix, locale-segment, and custom route styles, which matters when a blog, a docs area, and a contact section do not all follow the same path rules. [1][2][6]

Use custom pathname logic when needed

The config docs include pathnameFor, which is a strong signal that the package expects real production routing rather than only idealized path structures. [2]

Do not keep canonicals in a separate manual list

That is exactly how URL rules drift. The package works best when canonical generation comes directly from the manifests that already describe the content. [1][2][3]

The main benefit

For multilingual or mixed-route sites, canonical generation is usually the fragile part. This package makes it explicit and repeatable. [1][2][6]

How it fits into a Next.js or static-site pipeline

The documented build flow is short, which is one reason the package is easy to slot into a real project.

Generate artifacts before the app build.

The recommended pipeline starts with llm-seo generate --config llm-seo.config.ts. [1][5]

Build the site normally.

The package is built for static and hybrid output, where files in public/ are part of the normal build result. [1][3][6]

Check sitemap and hreflang if they are part of the stack.

The docs show nextjs-sitemap-hreflang check in the same pipeline, which keeps SEO artifacts aligned instead of validated in isolation. [1][5][6]

Run `llm-seo check` after build.

The check step can validate generated files, apply fail thresholds, emit JSON reports, and optionally live-check machine-hint URLs over HTTP. [1][5]

Build-time role

The package works best when LLM-facing SEO files are generated and checked inside the same pipeline as the site itself. [1][5][6]

Policy linting and CI checks are part of the product, not an afterthought

The package is designed to fail clearly, which makes it much easier to adopt in CI.

The policy side is also more useful than it first sounds. The docs describe restricted claims, whitelists, duplicate detection, and empty-section checks. That moves the package from simple file generation into content-governance territory. [1][4]

There is also a stable report contract for automation. When --emit-report is used, the JSON output includes status, normalized issues, summary counts, file paths, and canonical URL summaries. That gives CI and dashboards something structured to consume. [1][5]

0

Generation or checks completed successfully. [1][5]

1

Warnings only, but only when --fail-on warn is enabled. [1][5]

2

Errors during validation or checks. This is the normal CI failure case. [1][5]

3

Doctor network or availability failure. [1][5]

Why this matters

Deterministic generation is stronger when it comes with explicit failure behavior and machine-readable reports. [1][4][5]

Common mistakes when adopting this kind of workflow

The package is straightforward, but the surrounding workflow can still go wrong.

Treating llms.txt as a one-time text file instead of a generated build artifact. The docs clearly recommend generation and validation in CI. [3][5]

Letting route truth live outside the manifests. If manifests do not describe the real routing, canonical output will only be partially correct. [1][2][6]

Turning policy linting on too aggressively from day one. The policies guide is better read as a review tool than as a blunt first-pass blocker. [4]

Skipping report output or live checks on larger sites. Stable generation is useful on its own, but validation becomes much more valuable when the site has several moving parts. [1][5]

Assuming every section should share the same route style. The package supports mixed routing because many real sites need it. [1][2][6]

Practical expectation

The package does its best work when config, manifests, routing, and CI all describe the same site. [1][2][5][6]

Sources

These official sources support the behavior, routing model, policy rules, and CI contract described in this article.

Reviewed: 15 Mar 2026Applies to: Modern static sitesApplies to: Next.js static export and hybrid routing setupsApplies to: Manifest-based content pipelinesApplies to: Teams generating LLM-facing SEO artifacts at build time

Need a cleaner pipeline for LLM-facing SEO artifacts?

The hard part is rarely generating one text file. It is keeping route rules, canonicals, policy checks, and build output aligned as the site grows.

PAS7 Studio can help turn that into a repeatable pipeline with deterministic artifacts, cleaner manifests, and CI checks that catch drift before release.

Plan an SEO automation audit Open the @pas7/llm-seo package

@pas7/llm-seo for static sites: deterministic llms.txt and canonicals

What the package gives you

Why teams need this in the first place

The config works like a contract for the site

Site and brand

Manifests

Policy

Output and format

Routing and canonicals are where it gets interesting

Use it for simple prefixed routing

Use it for mixed section routing

Use custom pathname logic when needed

Do not keep canonicals in a separate manual list

How it fits into a Next.js or static-site pipeline

Generate artifacts before the app build.

Build the site normally.

Check sitemap and hreflang if they are part of the stack.

Run `llm-seo check` after build.

Policy linting and CI checks are part of the product, not an afterthought

0

1

2

3

Common mistakes when adopting this kind of workflow

Sources

Need a cleaner pipeline for LLM-facing SEO artifacts?

Related Articles

AI SEO / GEO in 2026: Your Next Customers Aren’t Humans — They’re Agents

The most powerful Apple chip yet? M5 Pro and M5 Max are breaking records

Automatic Tagging & Search for Saved Links

Bot Development & Automation Services

Professional development for your business

What the package gives you

Why teams need this in the first place

The config works like a contract for the site

Site and brand

Manifests

Policy

Output and format

Routing and canonicals are where it gets interesting

Use it for simple prefixed routing

Use it for mixed section routing

Use custom pathname logic when needed

Do not keep canonicals in a separate manual list

How it fits into a Next.js or static-site pipeline

Generate artifacts before the app build.

Build the site normally.

Check sitemap and hreflang if they are part of the stack.

Run llm-seo check after build.

Policy linting and CI checks are part of the product, not an afterthought

0

1

2

3

Common mistakes when adopting this kind of workflow

Sources

Need a cleaner pipeline for LLM-facing SEO artifacts?

Related Articles

AI SEO / GEO in 2026: Your Next Customers Aren’t Humans — They’re Agents

The most powerful Apple chip yet? M5 Pro and M5 Max are breaking records

Automatic Tagging & Search for Saved Links

Bot Development & Automation Services

Professional development for your business

Run `llm-seo check` after build.