構造化データに詳しくなった (関連: “構造化データの基礎”) ので https://schema.org/Person を表現するプロフィールページを作りたくなったが…やめた。 その流れで https://humanstxt.org という取り組みを知ったので、https://t28.dev/humans.txt を作ってみた。
humans.txt
humans.txt は「誰がサイトを作ったか」を伝えるための “人間向けの” テキストファイル。
“機械向け” の robots.txt のようにサイトのルートに置く。テキストファイルなのでシンプルで素早く作れて、
it’s something simple and fast to create.
既存のサイトに手を加えずに
it’s not intrusive with the code.
著者の主張ができる。
you can prove your authorship
rel="author"
https://humanstxt.org は humans.txt を rel="author" で紐づけることを推奨している。
<link type="text/plain" rel="author" href="https://domain/humans.txt" />rel="author" は著者情報を示すための属性値で、Web 標準として定義されている。
Google が rel="author"に関するガイド (rel=“author” に関するよくある質問（上級編）) を出しているが、2013 年と古い…。
最近の参考として使えそうなドキュメントを見つけられなかったが、情報の意味づけ・紐づけの方法としては構造化データの方が主流になっている…ということだと思う。
うーん、rel="author" は使わなくていっか…。
プロフィールページにはならない
最初「humans.txt がお手軽プロフィールページになれば良いな〜」なんて思ったが、これはただのテキストファイルなので、意味づけされたページにならない。
<head> がないので JSON LD は書けないし、HTML じゃないのでタグも書けないし Microdata も使えない。
humans.txt はセマンティックなプロフィールページではなく、あくまで人間向けの簡易ページとして考えるのが良さそう。
構造化データに紐づけるのはやめた
前述のことから humans.txt は構造化データに紐づけても仕方ないと考えた。
{
"@type": "Person",
"@id": "https://t28.dev/#person",
"name": "YAMAMOTO Tatsuya",
"url": "https://t28.dev/humans.txt", // 👈️ ここや
"sameAs": [
"https://t28.dev/humans.txt", // 👈️ ここ
"https://twitter.com/T28_tatsuya",
"https://x.com/T28_tatsuya",
"https://github.com/TatsuyaYamamoto"
]
}