Humans.txt Generator

humans.txt is a plain text file, placed at the root of a domain (yourdomain.com/humans.txt), that credits the people behind a website - a small counterpart to robots.txt written for people instead of crawlers. It follows the humans.txt standard set out at humanstxt.org: an informal, community-run convention rather than a governed specification, built around three sections - TEAM (contributors), an optional THANKS (anyone else worth crediting), and SITE, a colophon noting the last-update date and the languages, standards, and tools used to build the site.

This generator is for anyone who wants a correct humans.txt without memorizing the formatting conventions - agencies and freelancers crediting client work, open-source or side projects crediting contributors, and teams who simply want a friendly, human-readable "who built this" file. It builds the file, checks it for the small things that most commonly go wrong, and hands you the finished text - or imports an existing one from a live site so you can update it instead of starting over.

The tool is split into two simple parts - your entries on the left, the live result on the right. Nothing you type is sent anywhere unless you use Import, which fetches one existing file from a URL you provide.

1. 1
   Add your team, or import an existing file (left side)

   Click "+ Add member" for each contributor, enter your site's domain in the Import box to fetch and load an existing humans.txt, or click "Load sample" to see a filled-in example before entering your own details.
2. 2
   Add thanks and site info (left side)

   List anyone else you'd like to credit under Thanks, then fill in the SITE card - last update date, language, doctype, standards, components, and software.
3. 3
   Watch the live result (right side)

   Every change updates the generated file and its verification results immediately - no separate "generate" step.
4. 4
   Copy or download

   Use Copy humans.txt to paste it wherever your CMS or host lets you add a custom static file, or Download humans.txt to get a file ready to upload via FTP to your site's root directory.

Each row in the Verification Results panel is color-coded by severity:

• Green (Passed) - a confirmation that a check found nothing wrong, such as "the TEAM section has at least one member." No action needed.
• Amber (Warning) - a best-practice suggestion, like an empty TEAM section or a missing "Last update" date. Nothing will break, but it's worth addressing before publishing.
• Red (Error) - a genuine formatting problem, such as a website or email field that doesn't look like a valid URL or address. Fix these before publishing.

Short answer: no, not directly. Google Search Central documents robots.txt as part of the crawling process; humans.txt has never been part of that documentation, and Googlebot doesn't fetch or act on it as a matter of course. That said, "it doesn't affect rankings" isn't the whole story - it helps to separate what humans.txt actually does from what it doesn't:

• Direct ranking factor: none. humans.txt carries no ranking weight and isn't part of any documented algorithm input.
• Indirect effect: also none measurable. It isn't fetched during normal crawling, so it has no bearing on crawl budget, indexing, or how other pages on your site rank.
• Diagnostic / transparency value: real, but modest. It's a public record of who's accountable for a site, readable by a human visitor, journalist, or partner doing due diligence - a small trust signal, not a scored one.
• Best practice, not requirement. Publishing one is a low-effort courtesy, in the same spirit as a changelog or credits page - worth doing if you want it, never something a technical SEO audit should flag as missing.

If the goal is proving expertise and trustworthiness to Google specifically, that effort is better spent on a real About page, visible author bylines, and Organization/Person structured data - humans.txt is a nice complement to that work, not a substitute for it.

There's no single correct humans.txt - the standard scales from a one-line credit to a full team-and-colophon listing. Two realistic examples:

A fuller file - small studio, two-person team, one credit

A minimal file - solo developer, nothing else disclosed

Both are valid, spec-following humans.txt files - there's no minimum field count, so match the level of detail to how much you actually want to disclose (see Limitations below).

• Publishing it somewhere other than the root. humans.txt only counts as the standard file at yourdomain.com/humans.txt - a copy inside a subfolder isn't discoverable by the convention.
• Letting it go stale. A humans.txt still crediting people who left years ago, with a "Last update" from a previous redesign, undercuts the point of the file.
• Mixing up TEAM and THANKS. Reserve TEAM for people actually responsible for the site; use THANKS for one-off contributors, donors, or projects you simply want to acknowledge.
• Publishing more personal detail than necessary. A name and role is usually enough - a home city, personal email, or other identifying detail beyond what's already public elsewhere adds exposure without adding value.
• Keep contact details optional. Twitter, email, and location are all optional per person - only include what someone is comfortable making public.

• Link to fuller bios instead of duplicating them. If your team already has detailed bios on an About page, keep humans.txt short and point to that page via the Website field - one place to update instead of two.
• Use a role-based contact for larger teams. Past a handful of contributors, a shared address like [email protected] cuts down on per-person exposure while keeping the file just as useful.
• Update "Last update" when something real changes. Bumping it on every deploy regardless of content makes it meaningless; bumping it when the team or stack actually changes keeps it trustworthy.
• Only disclose what's already public. humans.txt shouldn't be the first place a person's email or location appears online - if it's not on their LinkedIn, portfolio, or your About page already, think twice before adding it here.

humans.txt has no technical requirements, no validator, and no enforcement - nothing on the web reads it automatically, so a missing file, a typo in a field, or a stale "Last update" has zero functional consequence for your site. It's a courtesy file, not a compliance checklist.

Searches for "humans.txt vulnerability" usually aren't about a flaw in the file format itself - it's static plain text with nothing executable, so there's no code to exploit. The real concern is information disclosure: humans.txt is public and unauthenticated, and it often lists full names, personal emails, Twitter handles, and home cities for every contributor. OSINT (open-source intelligence) guides and some security write-ups flag it as a quick, easily-overlooked source for building a staff list ahead of a phishing or social-engineering attempt - the same category of risk as an exposed team page, just less commonly reviewed because it's easy to forget the file exists at all.

That's a reason to be deliberate, not a reason to skip publishing one. Before adding a field, ask whether you'd be comfortable with that name, email, or location surfacing in a search result indefinitely. If not, credit by first name and role only, use a role-based contact instead of a personal one, or drop the location field entirely - the Standards, Components, and Software fields carry none of this risk and are safe to fill in freely.

humans.txt is one of several small text files a domain's root can host by convention. If you're setting one up, these are worth checking too:

• robots.txt - a machine-enforced protocol controlling what crawlers may request. Build one with the Robots.txt Generator.
• security.txt (RFC 9116) - gives security researchers a documented contact for reporting vulnerabilities. Build one with the Security.txt Generator.
• llms.txt - an emerging convention giving AI assistants a curated map of a site's key pages. Build one with the LLMs.txt Generator.
• sitemap.xml - lists indexable URLs for search engines; unrelated to humans.txt functionally, but often declared inside robots.txt. Build one with the Sitemap Generator.