---
title: "Site metadata files: security.txt, humans.txt, manifest, icons"
slug: "site-metadata-files"
category: "seo"
tags: ["seo", "discoverability", "security-txt", "web-manifest", "favicon", "well-known"]
status: "stable"
last_updated: 2026-09-27
summary: "Authoring rules for the non-crawl root files a production site ships: security.txt (RFC 9116), humans.txt, the web app manifest, favicon, Apple touch icon, and the default OG image."
related: ["[[seo/discoverability-files]]", "[[frontend/html-head-tags]]", "[[seo/og-images]]", "[[seo/technical]]", "[[seo/audit-checklist]]", "[[howto/static-site-seo]]"]
---

## Overview

Search engines and AI agents read `robots.txt`, sitemaps, and `llms.txt`; the files on this page serve everyone else. Security researchers look for `security.txt`, browsers look for icons and the manifest, and chat apps look for a social card. None of them change rankings, but a missing icon or a stale disclosure contact is visible to users and auditors. The full catalog of root files, including the crawl and agent files, is in [[seo/discoverability-files]].

## Ship security.txt at /.well-known/ with Contact and Expires

RFC 9116 defines the file. Place it at `/.well-known/security.txt`, served over HTTPS as `text/plain`.

- Required fields: `Contact:` (a `mailto:` or `https:` URI) and `Expires:` (an ISO 8601 timestamp).
- Optional fields: `Preferred-Languages:`, `Canonical:`, `Policy:`, `Acknowledgments:`, `Encryption:`, `Hiring:`.
- The RFC recommends an `Expires:` value less than a year in the future. Put the renewal on a calendar; an expired file tells researchers the contact may be dead.

```
Contact: mailto:security@example.com
Expires: 2027-01-01T00:00:00Z
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt
```

Route the `Contact:` address to a monitored inbox, not a personal account that leaves with an employee.

## Treat humans.txt as optional credit, not metadata

`humans.txt` credits the people, tools, and stack behind the site. No engine reads it and no standard governs it. The humanstxt.org convention uses comment-style section headers such as `/* TEAM */`, `/* THANKS */`, and `/* SITE */`. Ship it if the team wants credit; skip it without loss.

## Reference the web app manifest from every page

The manifest carries install metadata: `name`, `short_name`, `icons`, `start_url`, `display`, `theme_color`, and `background_color`. Serve it at `/manifest.webmanifest` (or `/manifest.json`) and reference it from the head:

```html
<link rel="manifest" href="/manifest.webmanifest">
```

Include at least a 192x192 and a 512x512 PNG in `icons`. Validate with the Application panel in Chrome DevTools. A content site that never expects installs still benefits from correct `name` and `theme_color`.

## Serve icons and the default OG image at fixed paths

Favicon, Apple touch icon, and the fallback social card are static assets referenced from `<head>`:

```html
<link rel="icon" href="/favicon.ico">
<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png">
<meta property="og:image" content="https://example.com/og-default.png">
```

Keep `/favicon.ico` at the root even when an SVG icon is declared; some clients request it directly. The full favicon tag set, including the SVG variant, is in [[frontend/html-head-tags]]. Size the default OG image at 1200x630 and use an absolute URL. Per-page OG images override the default; see [[seo/og-images]] for dynamic generation.

## Related

- [[seo/discoverability-files]]
- [[frontend/html-head-tags]]
- [[seo/og-images]]
- [[seo/technical]]
- [[seo/audit-checklist]]
- [[howto/static-site-seo]]
