PAS7 Studio
Zurück zu allen Artikeln

@pas7/llm-seo für statische Websites: deterministische llms.txt und Canonicals

Ein praktischer Leitfaden zu @pas7/llm-seo: llms.txt-Artefakte aus einer Konfiguration erzeugen, Canonical-URLs aus Manifests bauen, gemischtes Routing unterstützen und alles in CI prüfen.

15. März 2026· 8 Min. Lesezeit· Technologie
Geeignet fürFrontend EngineersTechnical SEO EngineersNext.js-Teams mit statischen oder hybriden SitesTech Leads, die deterministische Content-Pipelines aufbauen
Editorial-Cover mit einer Static-Site-Build-Pipeline, die llms.txt, llms-full.txt, Canonical-URLs und CI-Reports aus einer Konfigurationsdatei erzeugt

schnellüberblick

Das Paket lässt sich leichter als Infrastruktur verstehen als als einmaliger Generator. Man beschreibt die Site einmal, danach laufen Generierung und Prüfungen in der Build-Pipeline. [1][2][5]

Erzeugung von llms.txt und llms-full.txt aus einer einzigen Konfiguration. [1][3]
Canonical-URLs aus Manifest-Items bauen statt sie Abschnitt für Abschnitt von Hand zusammenzusetzen. [1][2][3]
Unterstützung für gemischtes Routing pro Manifest-Abschnitt mit prefix, suffix, locale-segment und custom. [1][2]
Linting für Policy-Probleme wie restricted claims, Duplikate und leere Abschnitte. [1][4]
CI-Checks mit klaren Exit-Codes und optionalem JSON-Report. [1][5]
Einbindung des Generators in Next.js- und Static-Site-Builds ohne viel eigenes Glue-Code. [1][5][6]

Eine einzelne llms.txt-Datei anzulegen ist leicht. Schwieriger ist es, sie über Zeit korrekt zu halten. Routen ändern sich, Bereiche wachsen, Sprachen kommen dazu, und Canonical-Regeln driften auseinander, wenn sie an mehreren Stellen manuell gepflegt werden. [1][2][3]

Genau diese Lücke versucht @pas7/llm-seo zu schließen. Das Paket behandelt LLM-orientierte SEO-Dateien als Outputs eines gemeinsamen Konfigurationsmodells zusammen mit Canonical-Generierung und Validierung, statt sie als Textdateien stehen zu lassen, die sich langsam von der echten Site entfernen. [1][2][5]

Wichtig ist auch die Deterministik. In den Format-Dokumenten sind sortierter Output, explizite Line Endings, konfigurierbares Trailing-Slash-Verhalten und stabile Generierung aus denselben Eingaben beschrieben. Genau das brauchen Build-Systeme, wenn generierte Dateien in CI geprüft werden sollen. [3][5]

Die Kernidee

Das Paket ist nützlich, weil es Routing, Artefakt-Generierung und Validierung an dieselbe Source of Truth bindet. [1][2][3][5]

Der schnellste Weg, das Paket zu verstehen, ist ein Blick darauf, wofür die Konfiguration zuständig ist.

Ein gekürztes Konfigurationsbeispiel aus der Dokumentation zeigt die Struktur gut:

TS
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 und Brand

Die Konfiguration definiert Base URL, Default Locale, Brand-Metadaten und die Site-Abschnitte, die als Hubs oder Referenzpunkte im generierten Output auftauchen sollen. [1][2][3]

Manifests

Jeder Manifest-Abschnitt beschreibt ein Routing-Muster und eine Liste von Items. Daraus bezieht das Paket die Informationen für Canonicals und Inhaltsreferenzen. [1][2]

Policy

Policy-Regeln erlauben es Teams, Claims zu begrenzen, Whitelist-Phrasen zu definieren und die Generierung mit redaktionellen Vorgaben abzugleichen. [1][4]

Output und Format

Output-Pfade, Trailing-Slash-Verhalten, Locale-Strategie und Line Endings werden explizit gesetzt, damit die Generierung in verschiedenen Umgebungen stabil bleibt. [1][2][3]

Warum die Konfiguration wichtig ist

Wenn die Struktur der Site gut beschrieben ist, lässt sich dem Rest des Pakets deutlich leichter vertrauen. [1][2][3]

Dieses Paket wäre deutlich weniger nützlich, wenn es nur Textdateien schreiben würde. Wichtiger ist, dass es Canonical-URLs aus route-aware Manifests ableiten kann. [1][2]

Für einfaches Prefix-Routing einsetzen

Ein Abschnitt kann prefix nutzen, wenn die Site ein einfacheres Routing-Modell hat und vor allem konsistenter Canonical-Output gebraucht wird. [2][3]

Für gemischtes Section-Routing einsetzen

Das Paket unterstützt suffix, locale-segment und custom Route-Styles, was wichtig ist, wenn Blog, Docs und Contact-Section nicht denselben Path-Regeln folgen. [1][2][6]

Custom Pathname-Logik verwenden, wenn nötig

In den Config-Dokumenten gibt es pathnameFor. Das ist ein starkes Signal dafür, dass das Paket auf echtes Produktions-Routing ausgelegt ist und nicht nur auf idealisierte Pfadstrukturen. [2]

Canonicals nicht in einer separaten manuellen Liste pflegen

Genau so beginnen URL-Regeln zu driften. Das Paket funktioniert am besten, wenn die Canonical-Generierung direkt aus den Manifests kommt, die den Inhalt ohnehin schon beschreiben. [1][2][3]

Der Hauptnutzen

Für mehrsprachige oder gemischt geroutete Sites ist die Canonical-Generierung meist der fragile Teil. Hier wird sie explizit und wiederholbar. [1][2][6]

Der dokumentierte Build-Flow ist kurz, und genau deshalb lässt sich das Paket leicht in ein reales Projekt einbauen.

Artefakte vor dem Site-Build erzeugen.

Die empfohlene Pipeline beginnt mit llm-seo generate --config llm-seo.config.ts. [1][5]

Die Site ganz normal bauen.

Das Paket ist für statischen und hybriden Output gedacht, bei dem Dateien in public/ Teil des normalen Build-Ergebnisses sind. [1][3][6]

Sitemap und hreflang prüfen, wenn sie Teil des Stacks sind.

In der Doku steht nextjs-sitemap-hreflang check in derselben Pipeline, sodass SEO-Artefakte abgestimmt bleiben und nicht isoliert geprüft werden. [1][5][6]

llm-seo check nach dem Build ausführen.

Der Check-Step kann generierte Dateien validieren, Fail-Thresholds anwenden, JSON-Reports erzeugen und bei Bedarf machine-hint URLs per HTTP live prüfen. [1][5]

Die Rolle zur Build-Zeit

Das Paket ergibt am meisten Sinn, wenn LLM-orientierte SEO-Dateien in derselben Pipeline erzeugt und geprüft werden wie die Site selbst. [1][5][6]

Das Paket ist darauf ausgelegt, klar zu scheitern, und genau das macht den Einsatz in CI einfacher.

Auch die Policy-Seite ist nützlicher, als es zunächst klingt. In der Dokumentation sind restricted claims, Whitelists, Duplicate Detection und Checks für leere Abschnitte beschrieben. Damit bewegt sich das Paket von reiner Dateigenerierung in Richtung Content Governance. [1][4]

Dazu kommt ein stabiler Report-Contract für Automatisierung. Wenn --emit-report verwendet wird, enthält der JSON-Output Status, normalisierte Issues, Summary Counts, File Paths und Canonical-URL-Summaries. Genau mit so einer Struktur können CI und Dashboards konsistent arbeiten. [1][5]

0

Generierung oder Prüfungen wurden erfolgreich abgeschlossen. [1][5]

1

Nur Warnings, aber nur wenn --fail-on warn aktiviert ist. [1][5]

2

Fehler bei Validierung oder Checks. Das ist der normale CI-Fail-Fall. [1][5]

3

Doctor Network oder Availability Failure. [1][5]

Warum das wichtig ist

Deterministische Generierung wird stärker, wenn dazu klares Failure-Verhalten und machine-readable Reports kommen. [1][4][5]

Das Paket selbst ist geradlinig, aber Fehler entstehen trotzdem im umliegenden Workflow.

llms.txt als einmalige Textdatei zu behandeln statt als generiertes Build-Artefakt. In der Doku werden Generierung und Validierung in CI klar empfohlen. [3][5]

Die Routing-Wahrheit außerhalb der Manifests zu halten. Wenn die Manifests das reale Routing nicht beschreiben, bleibt auch der Canonical-Output nur teilweise korrekt. [1][2][6]

Policy-Linting vom ersten Tag an zu aggressiv zu aktivieren. Der Policies-Guide eignet sich eher als Review-Tool als als grober Erstblocker. [4]

Report-Output oder Live-Checks bei größeren Sites auszulassen. Stabile Generierung ist für sich nützlich, aber Validierung wird noch wertvoller, wenn die Site mehrere bewegliche Teile hat. [1][5]

Anzunehmen, dass jeder Abschnitt denselben Route-Style nutzen sollte. Das Paket unterstützt gemischtes Routing genau deshalb, weil viele reale Sites es brauchen. [1][2][6]

Praktische Erwartung

Das Paket funktioniert am besten, wenn Konfiguration, Manifests, Routing und CI dieselbe Site beschreiben. [1][2][5][6]

Diese offiziellen Quellen stützen das Verhalten des Pakets, das Routing-Modell, die Policy-Regeln und den CI-Contract, die in diesem Artikel beschrieben werden.

Geprüft: 15. März 2026Gilt für: moderne statische WebsitesGilt für: Next.js Static Export und hybride Routing-SetupsGilt für: manifestbasierte Content-PipelinesGilt für: Teams, die LLM-orientierte SEO-Artefakte zur Build-Zeit erzeugen

Der schwierige Teil ist selten, eine einzelne Textdatei zu erzeugen. Schwieriger ist es, Routing-Regeln, Canonicals, Policy-Checks und Build-Output synchron zu halten, wenn die Site wächst.

PAS7 Studio kann helfen, daraus eine wiederholbare Pipeline mit deterministischen Artefakten, saubereren Manifests und CI-Checks zu machen, die Drift vor dem Release auffangen.

Verwandte Artikel

growth

AI SEO / GEO im Jahr 2026: Ihre nächsten Kunden sind nicht Menschen — sondern Agents

Suche verschiebt sich von Klicks zu Antworten. Bots und AI-Agents crawlen, zitieren, empfehlen — und kaufen zunehmend. Erfahren Sie, was AI SEO / GEO bedeutet, warum klassisches SEO nicht mehr reicht und wie PAS7 Studio Marken im agentischen Web sichtbar macht.

blogs

Der leistungsstärkste Chip von Apple? M5 Pro und M5 Max brechen Rekorde

Eine Analyse zu Apple M5 Pro und M5 Max im März 2026. Wir zeigen, warum diese Chips als die stärksten professionellen Laptop-SoCs von Apple gelten können, wie sie sich gegen M4 Pro, M4 Max, M1 Pro, M1 Max schlagen und was der Vergleich mit aktuellen Intel- und AMD-Chips zeigt.

telegram-media-saver

Automatisches Tagging und Suche für gespeicherte Links

Integration mit GDrive/S3/Notion für automatisches Tagging und schnelle Suche über Such-APIs

services

Bot-Entwicklung und Automatisierungs-Dienste

Professionelle Telegram-Bot-Entwicklung und Automatisierung von Geschäftsprozessen: Chatbots, KI-Assistenten, CRM-Integrationen und Prozessautomatisierung.

Professionelle Entwicklung für Ihr Geschäft

Wir erstellen moderne Web-Lösungen und Bots für Unternehmen. Erfahren Sie, wie wir Ihnen helfen können, Ihre Ziele zu erreichen.