Llms Txt Bundle Laravel Package

Product Decisions This Supports

• Whether to ship an llms.txt surface at all. This bundle automates generation of an llms.txt file (the emerging convention for telling LLM crawlers/answer engines what your site contains) directly from route metadata. It turns an open "should we do AEO/GEO?" question into a small, reversible build.
• Build vs. buy. Buying here means one bundle plus a route option; building means a custom controller, template, caching, and route-filtering logic you'd own forever. The scope is narrow enough that buy wins unless you need bespoke output formats.
• Rollout scale / "will this hurt us at scale?" gate — now largely answered. v1.3.0 stops loading the whole route collection on every /llms.txt request and caches only the routes carrying the llms_txt option alongside the compiled routes (invalidated with them; cache:warmup writes it). Measured: 15.9 ms → 1.8 ms (~9×) at 1,000 attribute routes, 720 ms → 19 ms (~38×) at 10,000. If a previous objection was "our route table is huge," that objection is now weak.
• Deployment model / infrastructure viability. The cache is written by cache:warmup and works with a read-only build directory — this unblocks adoption in immutable/containerized deployments (Docker, Kubernetes, read-only release artifacts), which is often the real blocker for build-time-cached features.
• Whether to enable the optional discovery surface. discovery.link_header (emitting a Link header) is off by default and now requires opting into symfony/web-link. That's a deliberate, costed choice per property rather than a default-on behavior.
• Prioritization signal on the dependency itself. v1.3.0 contains no new user-facing capability — it is performance and dependency-hygiene work. Read that as a maturing, maintained package (good for a low-risk bet), not a feature roadmap you should plan around.
• Use cases that fit: public marketing/docs sites, API documentation portals, multi-brand or multi-section sites where different route groups warrant different llms.txt content, and teams already annotating routes with attributes.

One framing correction worth carrying into any stakeholder doc: the release data describes a Symfony bundle (silarhi/llms-txt-bundle, %kernel.build_dir%, cache:warmup, Twig preload()/link()), not a Laravel package. Treat this as a Symfony-ecosystem option; a Laravel codebase would need a Laravel-specific equivalent or a static file.

When to Consider This Package

Consider it when:

• You are on Symfony and can express route-level intent via the llms_txt route option (attribute-based routing). The whole value proposition depends on annotating routes.
• You want per-route curated output (different sections/entries per route group) rather than one hand-maintained static file.
• You operate a large route table — the v1.3.0 caching work is precisely aimed at you, and the benchmarks are persuasive.
• You deploy to read-only build directories and already run cache:warmup; the feature now fits that pipeline cleanly.
• You want an opt-in, low-blast-radius experiment: link_header off by default, no runtime coupling, easy to remove.

Look elsewhere when:

• You are on Laravel or another framework — nothing in this release changes that; you'd be adopting a Symfony bundle into a non-Symfony app.
• You only need a static llms.txt committed to the repo. That's cheaper until content churn makes generation worthwhile.
• Your routes are not attribute-annotatable (legacy YAML/XML routing, heavy dynamic routing) — the selection mechanism won't reach them.
• You need agent-facing endpoints (MCP servers, structured tool manifests). llms.txt is a different, still-unstandardized artifact; don't let it stand in for that work.
• You require guaranteed vendor support. The llms.txt convention is not ratified by all LLM vendors; budget this as a cheap hedge, not a strategic commitment.

Upgrade caveats before you bump to v1.3.0:

• symfony/web-link is now an optional dependency and no longer ships with the bundle. If your app calls preload() / link() / AbstractController::addLink() and was relying on it transitively, add it explicitly or the container build will fail.
• Enabling link_header without symfony/web-link fails at container build time, not at runtime — a build-pipeline failure, so catch it in CI rather than in production.
• An invalid llms_txt option still fails the /llms.txt request, not cache:warmup. Warmup will not surface bad configuration — add a smoke check for /llms.txt to your deploy verification.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, reversible bet on AI-driven discovery. Answer engines and coding assistants increasingly look for a machine-readable summary of a site; this bundle generates one from metadata we already maintain, so it stays in sync instead of rotting like a hand-written file. The latest release removes the main reason to hesitate — it is now roughly 9–38× faster at scale (sub-20 ms even at 10,000 routes) and works in our read-only container builds. No new dependencies, no default-on surface area, easy to switch off.

To engineering: Small Symfony bundle; v1.3.0 replaces per-request route-collection scanning with a cached list of only the opted-in routes, stored next to the compiled routes and invalidated with them, written by cache:warmup. Read-only build dirs are supported. Two things to action: (1) symfony/web-link is now optional — require it explicitly if we use WebLink anywhere or if we enable link_header, otherwise the container build fails; (2) invalid route options fail the request rather than warmup, so add a deploy-time check on /llms.txt. Note this is Symfony, not Laravel — if the target app is Laravel, this assessment doesn't transfer.

Risk posture: Opt-in per route, link_header off by default, no runtime coupling, trivially removable. The only real exposure is the dependency change at upgrade time, which CI will catch.