Stop AI from hallucinating about your domain, new Next.js package for AI Domain Data Standard

[ai-domain-data]

The Problem: AI assistants frequently get domain details wrong. They scrape outdated pages, infer from partial data, and hallucinate information about your site. There's been no standard way for domains to publish authoritative identity data that AI systems can read directly.

The Solution: The AI Domain Data Standard — an open, vendor-neutral format (similar in spirit to security.txt) that lets you publish a canonical JSON profile at /.well-known/domain-profile.json. AI systems can read this directly from your domain, eliminating guesswork and misinformation.

For Next.js Developers: We just released @ai-domain-data/nextjs — a zero-config package that adds AI Domain Data support to your Next.js site in minutes.

Quick Setup

npm install @ai-domain-data/nextjs

App Router:

// app/.well-known/domain-profile.json/route.ts
import { createAIDomainDataRoute } from "@ai-domain-data/nextjs/app-router";

export const GET = createAIDomainDataRoute({ useEnv: true });

Pages Router:

// pages/api/.well-known/domain-profile.json.ts
import { createAIDomainDataHandler } from "@ai-domain-data/nextjs/pages-router";

export default createAIDomainDataHandler({ useEnv: true });

Add environment variables to .env.local:

NEXT_PUBLIC_SITE_NAME=Your Site Name
NEXT_PUBLIC_SITE_DESCRIPTION=Your site description
NEXT_PUBLIC_SITE_URL=https://yoursite.com
[email protected]
NEXT_PUBLIC_ENTITY_TYPE=Organization

That's it. Your site now serves /.well-known/domain-profile.json with full TypeScript support and built-in schema validation.

Why This Matters

• Reduces AI misinformation — Give AI systems the correct information about your domain
• Improves SEO — Works seamlessly with schema.org and existing structured data
• Zero vendor lock-in — Self-hosted, open standard, no SaaS dependencies
• Future-proof — As AI adoption grows, so does the need for authoritative domain data

Learn More

• Package: npmjs.com/package/@ai-domain-data/nextjs
• Standard: ai-domain-data.org
• GitHub: github.com/ai-domain-data/spec/tree/main/packages/nextjs
• Specification: ai-domain-data.org/spec/v0.1

The standard is still new (v0.1.1), but we're seeing early adoption from Jekyll sites. A WordPress plugin has been submitted, pending approval, and now Next.js is out, complete and ready to roll.

Would love to hear your thoughts and feedback, about the standard itself & the Next.js package!

---

Note: This is an open standard, not a commercial product. All tooling is MIT-licensed and free to use.

[engripaye]

---

My feedback

This looks extremely promising — especially as AI systems increasingly rely on heuristics, scraping, and partial data to infer site identity. Having an authoritative, self-hosted “source of truth” at /.well-known/domain-profile.json feels like a natural evolution, similar to how security.txt and ads.txt standardized other parts of the web’s metadata layer.

Here are a few thoughts after reviewing the spec and the Next.js package:

1. The Problem is Real, and the Timing Makes Sense

AI assistants do routinely hallucinate or guess domain details, especially for newer or smaller sites. There’s currently no standardized, machine-readable way to declare canonical domain identity data. This fills an obvious gap.

2. The Install/Integration Flow in Next.js Is Excellent

The zero-config approach with createAIDomainDataRoute() is exactly the DX I would expect. Serving the well-known file through the App Router or Pages Router without extra routing config is a big win. The fact that the schema is fully typed is also a huge plus.

3. Mirrors Existing Web Standards (a Good Thing)

The mental model is immediately familiar:

• security.txt → security policies
• robots.txt → crawler rules
• ads.txt → authorized sellers
• domain-profile.json → AI-facing canonical domain info

That makes adoption easier.

4. Great That It’s Open & Vendor-Neutral

The fact that it’s MIT-licensed, self-hosted, and not tied to any SaaS service gives it credibility. No vendor lock-in is the right move for something that aims to be a standard.

5. A Few Early Questions / Suggestions

• Extensibility: Will the spec allow custom fields under a namespaced key, similar to schema.org extensions?
• Validation: Are there plans for a CLI or CI validator to help catch schema errors before deployment?
• Caching: Any recommendations for caching headers or versioning, especially for domains served through CDNs?
• AI Adoption Roadmap: Are there any confirmed or upcoming LLM providers planning to consume this standard? (Even informal commitments would help adoption.)

6. Overall

The idea solves a real problem, the implementation looks thoughtful, and the DX for Next.js is surprisingly clean. I think a standard like this will become increasingly important as AI systems become a major channel through which users discover and interact with domains.

Would love to keep an eye on the evolution of the spec — especially as more frameworks and CMS plugins are added.

---

[ai-domain-data]

Thank you for the thoughtful feedback! It's exactly the kind of deep engagement we hoped to see. Let me address your questions:

1. Extensibility & Custom Fields

Right now, v0.1.1 intentionally disallows additional properties to keep the payload predictable for consumers. The spec does allow the optional jsonld field, which can embed full schema.org JSON-LD blocks—this gives you a namespaced way to include extended structured data while keeping the core AIDD fields clean.

For future versions, we're considering a few approaches:

• Namespaced extension fields (e.g., extensions.vendor-specific)
• Versioned schema evolution (v0.2, v0.3) with community proposals
• The ability to propose additions through the spec repository

The goal is balancing flexibility with predictability. We're tracking this in our spec repository and would love input on what extension patterns would be most useful.

2. Validation & CI

Yes! We have a CLI (@ai-domain-data/cli) that includes validation:

npm install -g @ai-domain-data/cli
aidd validate --path=./domain-profile.json

It's perfect for CI/CD pipelines. You can gate deployments, run it in pre-commit hooks, or add it to your GitHub Actions. The CLI exits with code 0 on success, non-zero on validation failure, so it integrates cleanly with automation.

We also have a GitHub Action that validates on every commit. The Next.js package includes built-in validation at runtime, but the CLI is the way to go for pre-deployment checks.

3. Caching & CDN Recommendations

Great question. The spec doesn't mandate specific cache headers, but here are our recommendations:

• Cache-Control: public, max-age=3600, s-maxage=3600 (1 hour) is a good default. The data doesn't change frequently, but you want it fresh enough that updates propagate reasonably quickly.
• Versioning: The spec field in the JSON acts as a version identifier. When you upgrade to a new spec version, update the spec URL (e.g., v0.1 → v0.2), which effectively invalidates old cached versions.
• CDN Considerations: Most CDNs will cache the /.well-known/domain-profile.json endpoint by default. If you're using Vercel, Cloudflare, or similar, the standard cache headers work well. For edge cases where you need immediate updates, you can purge the CDN cache after deploying changes.

The Next.js package sets appropriate cache headers by default, but you can override them if needed.

4. AI Adoption Roadmap

This is the million-dollar question, and I'll be transparent: we're still in early days. The standard is new (v0.1.1 just released), and we're focused on building adoption from the publisher side first.

That said, the value proposition is clear:

• LLMs increasingly need authoritative domain data
• The /.well-known/ pattern is familiar and trusted
• The schema.org alignment makes it easy for AI systems that already process structured data

We're actively reaching out to AI vendors, but adoption on the consumer side will likely follow once there's a critical mass of publishers. That's why we're pushing hard on integrations (Jekyll, Next.js, WordPress) to make it dead simple for sites to adopt.

If you have connections to AI/LLM teams, we'd love introductions. The more early feedback we get from potential consumers, the better we can shape the spec.

Overall

Your point about this becoming "increasingly important as AI systems become a major channel" is exactly why we built this. The web needs a standard way to declare canonical identity, and the timing feels right.

We're committed to keeping this open, vendor-neutral, and community-driven. Your feedback helps shape that evolution. If you're interested, we'd love to have you follow along in the spec repository or even contribute integrations for other frameworks.

Thanks again for taking the time to dig in. This kind of thoughtful engagement is what will make the standard successful.