humans.txt is what you get when you take a software README, strip it to the credits page, and paste it at the root of a website. It has existed since 2011 and the specification is exactly as informal as that sentence suggests: the people behind the site, the technologies used, maybe a thanks section. No schema, no JSON, no mandatory fields. Just plaintext.
For most of the last decade, humans.txt was a cute vestige. Developers who cared about IndieWeb norms shipped it. Nobody else noticed. Then something changed.
The Signal Got Rediscovered
Around 2024, AI citation engines started treating /humans.txt as a legitimate source of authorship information. Not because the file format is rigorous — it is not — but because it is the only canonical location where a site publisher states, in their own words: "the people behind this site are X, Y, and Z."
Perplexity, Claude, and the newer AI answer engines need authorship signals to decide whose content to trust. They already read Person and Organization JSON-LD. They already follow rel=author links. But humans.txt adds a third leg to the stool: a voluntary, plaintext declaration that does not require schema knowledge, does not depend on a CMS, and does not come with SEO baggage.
If your Organization schema says "ACME Corp" and your humans.txt says "Name: Jane Smith, Role: Owner," the AI now has two corroborating sources for the same fact. That is exactly how trust networks are built.
What Goes in humans.txt
The file is plain text at your root. The conventional format is IndieWeb-flavored:
/* TEAM */
Name: Jane Smith
Role: Founder and CEO
Site: https://example.com
Contact: jane@example.com
/* THANKS */
Hosted on Netlify. Design inspired by the Susan Kare team at Apple.
Copy review by the incomparable editor at example-editor.com.
/* SITE */
Last update: 2026-04-18
Language: English
Doctype: HTML5
Standards: HTML5, CSS3, Schema.org, llmstxt.org
Components: Eleventy, Nunjucks
The /* TEAM */ section is the one that matters. Everything else is filler the humans.txt spec technically allows but that AI engines largely ignore.
Why This Matters More for Small Sites
Large organizations have LinkedIn, Wikipedia, Crunchbase, and ten other third-party sources that corroborate their authorship. When an AI wants to know who runs apple.com, it does not need apple.com to spell it out.
Small sites — personal blogs, local businesses, indie software projects — are the opposite. If your site is the only place online that clearly names who runs it, the AI has exactly one source of authority, and humans.txt is a cheap way to make that source machine-readable.
For the property management companies, real estate agents, local service businesses, and indie publishers I ship sites for, humans.txt is a one-time 15-minute task that tells every AI engine "the human behind this site is named, contactable, and claimed." That claim is what AI citation engines convert into the confidence to name the site in an answer.
Where humans.txt Lives
humans.txt lives at the root, not in /.well-known/. The spec predates RFC 8615 and has stayed at the root by convention. Do not mirror it to /.well-known/ — you will confuse clients that look in one location or the other.
One Content-Type header is all that is needed:
# netlify.toml
[[headers]]
for = "/humans.txt"
[headers.values]
Content-Type = "text/plain; charset=utf-8"
Cache-Control = "public, max-age=86400"
Apache and Nginx equivalents are straightforward.
humans.txt vs the Alternatives
People ask me why humans.txt instead of:
- About page: About pages are designed for humans, so they have marketing copy, images, calls to action, and navigation. An AI trying to extract "who runs this" has to parse all of that. humans.txt is built for the extraction step.
- Contact page: Contact pages vary wildly and have no format convention. humans.txt has a format convention.
- Author JSON-LD: Should already exist. humans.txt complements it, it does not replace it. Author JSON-LD tells search engines "the author of this article is X." humans.txt tells everyone "the owner of this site is X." Different scope.
- LinkedIn profile: Depends on LinkedIn being crawlable and on your LinkedIn being tied to the domain. humans.txt depends on neither.
When Not to Ship It
If you run a multi-author publication with real editorial processes (news organizations, academic sites, corporate blogs with ghost writers), humans.txt is the wrong tool. You want a per-article author byline with Person JSON-LD pointing to full author pages. humans.txt collapses to a single voice.
If you run a pseudonymous site and do not want your real name public, do not use humans.txt to list a fake name — AI engines cross-reference. Either leave it off or list your pseudonym plus a verification URL (a rel=me link to your pen-name social presence is fine).
The Audit Rule
The Site Analyzer flags a missing humans.txt as a warn-level E-E-A-T issue. It is not critical — a site can rank and get cited without it — but on any site where you have a clear individual owner or small team, it is a free win. The file takes one edit to write, one deploy to ship, and gets indexed by every AI engine that cares about authorship.
If your audit flags "No humans.txt," spend 15 minutes today. List your team, add a Last update date, deploy. You now have a plaintext authorship declaration at a canonical URL, and every future AI citation audit will pass this check.
The Short Version
- humans.txt is a plaintext credits file at the root of your site.
- The
/* TEAM */section is what AI engines actually parse. - It complements Organization and Person JSON-LD; it does not replace them.
- Ship it with a Content-Type header. Update the Last update date once a year.
- The payoff is incremental but real: one more corroborating signal that strengthens every AI citation of your domain.