llms.txt for Next.js

No first-party convention (yet)

Next.js ships metadata file conventions for robots.txt and sitemap.xml — you export a function from app/robots.ts and the framework serves the file. No such convention exists for llms.txt (there's an open feature request, vercel/next.js discussion #80692), so you wire it yourself. Two patterns, both trivial:

Pattern 1: static file

Drop llms.txt in public/. Next.js serves anything there at the root, so public/llms.txt → yoursite.com/llms.txt. Done.

Right choice when your key pages change rarely. The risk is drift: the file says what your site was.

Pattern 2: route handler

For content that moves — docs, products, posts — generate the file from the same source of truth as your pages:

// app/llms.txt/route.ts
import { getDocs } from '@/lib/content';

export async function GET() {
  const docs = await getDocs();
  const body = [
    '# Acme',
    '',
    '> Acme is a widget API for developers.',
    '',
    '## Docs',
    ...docs.map(d => `- [${d.title}](/docs/${d.slug}): ${d.summary}`),
    '',
    '## Machine-readable surfaces',
    '- [OpenAPI spec](/openapi.json): full API schema',
  ].join('\n');
  return new Response(body, {
    headers: { 'Content-Type': 'text/plain; charset=utf-8' },
  });
}

Add export const revalidate = 3600 if your content source is expensive. The same pattern serves llms-full.txt if you want the full-text companion.

What to include

Curation beats completeness: what the site is (one blockquote), the dozen pages an agent should start from with one-line summaries, and cross-references to your machine surfaces — the OpenAPI spec and any MCP endpoint are the highest-value lines in the file. Full format guidance: the llms.txt guide.

Validate it

Run the llms.txt validator against your deployment — existence, parseability, navigable structure — or scan the site for the full agent-readiness picture.

FAQ

Does Next.js have an llms.ts metadata convention like robots.ts?

No. The metadata file conventions cover robots.txt, sitemap.xml, icons, and OG images — not llms.txt. A feature request is open; until then, use public/llms.txt or a route handler.

Should the route handler set a special Content-Type?

Serve it as text/plain (or text/markdown) with UTF-8. Agents parse the markdown structure from the body; what matters is that the route returns 200 with the content directly.

Static file or route handler?

Static if your key pages are stable. Route handler if the file lists anything that changes — it's the difference between documentation and a snapshot.