このサイトにはSEO向けの構造化データ(JSON-LD)を仕込んでいますが、Person スキーマでありながら実名は一切出していません。
const jsonLd = {
"@context": "https://schema.org",
"@type": "Person",
name: "Portfolio",
jobTitle: "Web / インフラエンジニア",
description: "運用保守・インフラ構築からWebアプリ開発まで一気通貫で担うエンジニア",
url: Astro.site?.toString(),
knowsAbout: ["PHP", "Laravel", "WordPress", "Linux", "AWS", "Azure", "OCI", "Docker", "Zabbix", "MySQL"],
};
name には屋号的な文字列を入れる
schema.org/Person の name は本来、個人の氏名を入れることが想定されているフィールドです。しかしこのサイトでは匿名運用が前提のため、サイトの名称(実質的な屋号)を入れています。検索エンジンにとって完璧な意味論ではないかもしれませんが、「このページが何者の情報を表しているか」という参照点を与える目的は最低限果たせると考えています。
効かせるべきは jobTitle と knowsAbout
実名という最も強い識別子を使えない以上、代わりに効かせているのが jobTitle(職種)と knowsAbout(既知の技術領域)です。特に knowsAbout に技術名を列挙するのは、氏名検索では引っかからない代わりに、「PHP Laravel 受託」のような技術名起点の検索意図に応えるための設計です。個人を特定する情報を出せない代わりに、技術スタックの網羅性でページの主題を検索エンジンに伝える、という方針転換をしています。
OGPも同じ制約の中で組む
const ogImage = Astro.site ? new URL("/og.png", Astro.site) : "/og.png";
<meta property="og:title" content={title} />
<meta property="og:image" content={ogImage} />
SNSカードの og:title にも実名は使わず、ページタイトル(サイトの役割を表す文言)をそのまま流用しています。OGP画像も、顔写真的なものではなく、サイトのビジュアルアイデンティティ(ドット絵・星空のモチーフ)を使ったものにしています。「誰であるか」を伝えるカードではなく、「何を提供しているか」を伝えるカードとして設計を割り切っています。
匿名性とSEOはトレードオフではなく、設計の軸をずらす話
実名を出せないことは、SEOにとって単純な「マイナス」ではなく、「何を主語にするか」を変える必要がある、というだけだと捉えています。人物名で見つけてもらうサイトではなく、技術スタックと提供内容で見つけてもらうサイトとして構造化データを組み立てれば、匿名性を保ったままでも検索エンジンに伝えるべき情報はきちんと伝えられる、というのがここまでの実感です。