見つけてもらうための設計

この記事で言いたいこと：作ることと見つけてもらうことは、まったく異なる設計行為だ。500ページを書いても、noindexが1行あれば誰にも届かない。発見性は機能ではなく、インフラだ。

1. 見えない壁

トキストレージのLPサイトには、114本のエッセイ、100以上のユースケース、技術資料、ニュースレター——合計500ページ以上のコンテンツがある。すべてGitHub Pagesで静的に配信されている。

だが、そのすべてのページに<meta name="robots" content="noindex, nofollow">が入っていた。

開発初期に入れたまま、そのままになっていた。検索エンジンのクローラは全ページを丁寧に無視する。Googleで「トキストレージエッセイ」と検索しても、1件もヒットしない。500ページが、インターネット上に存在しないのと同じ状態だった。

作ることに没頭していた。ページが増えるたびにコンテンツは充実し、リンク構造は洗練され、エッセイ間のクロスリンクも整備された。だが発見性という層だけが、最初の1行のまま凍結していた。

500ページを書くよりも、1行のnoindexを消すほうが、発見性への貢献は大きい。

2. 基盤層——noindex解除とOGP

最初にやったのは、全ページのnoindex, nofollowをindex, followに変更することだ。ただし2つの例外がある。職務経歴書と履歴書は個人情報を含むため、noindexのまま残した。

同時にOpen Graph Protocol（OGP）タグを全ページに追加した。OGPは、SNSやメッセージアプリでURLを共有したときに表示されるタイトル・説明文・画像を制御するメタデータだ。og:title、og:description、og:url、og:type、og:site_name。Twitter Cardのtwitter:card、twitter:title、twitter:description。

499ページに一括で追加した。Pythonスクリプトで各ページの<title>タグと<meta name="description">から値を取得し、OGPタグに変換する。手作業では2〜3ページが限界だが、スクリプトなら499ページを数秒で処理できる。

sitemap.xmlとrobots.txtも作成した。サイトマップは501のURLを含む。robots.txtはクローラにサイトマップの場所を伝える。Google Search Consoleに登録し、サイトマップを送信した。

これで、Googleの検索結果にページが表示されるための最低条件が揃った。

3. 構造化データ——JSON-LD

次に、JSON-LD形式の構造化データを全ページに埋め込んだ。検索エンジンがページの意味構造を機械的に理解するためのメタデータだ。

エッセイページにはArticleスキーマを適用した。headline（見出し）、author（著者名とプロフィールURL）、publisher（組織名とロゴ）、inLanguage（言語）、description（説明文）。Googleの検索結果でリッチスニペットとして表示される可能性が生まれる。

非エッセイページにはWebPageスキーマを適用した。シンプルなページ名、URL、言語情報。

ここでも499ページをスクリプトで一括処理した。エッセイかどうかの判定は、ファイル名とページ内の.article-contentクラスの存在で行う。

構造化データは、検索エンジンに「このページは何か」を説明する翻訳層だ。

4. hreflang——言語の橋

トキストレージのサイトは日英バイリンガルだ。index.htmlとindex-en.html、safari-webp.htmlは日本語のみ、usecase-hula-en.htmlは英語のみ——ページによって日英ペアがあったりなかったりする。

日英ペアが存在する158組（316ページ）にはhreflangタグを追加した。

<link rel="alternate" hreflang="ja" href="...index.html">と<link rel="alternate" hreflang="en" href="...index-en.html">。さらにhreflang="x-default"で日本語版をデフォルトに指定する。これにより、Googleは日本語で検索しているユーザーには日本語版を、英語のユーザーには英語版を表示するようになる。

同時に、全ページにcanonicalタグを追加した。GitHub Pagesは末尾スラッシュの有無で同じページに複数のURLが生まれうる。canonicalタグは「このURLが正式な住所だ」と検索エンジンに伝え、重複コンテンツの問題を防ぐ。

5. AI検索への対応——llms.txt

ここまでが人間の検索エンジンへの対応だ。だが2026年の検索ランドスケープは、もはやGoogleだけではない。

Perplexity、ChatGPT、Google AI Overviews——AIが直接ウェブを読み、回答を生成する時代になっている。これらのAIクローラは従来のSEOとは異なる発見経路を持つ。llms.txtは、この新しい経路に対応するためのファイルだ。

概念は単純だ。サイトのルートにllms.txtを置き、サイトの概要、主要ページ、技術的な事実を平文で記述する。AIクローラはHTMLを解析するよりも、この平文ファイルから効率的にサイトの全体像を把握できる。

書いた内容は、トキストレージの三層分散保管の説明、TokiQRのCodec2 WASM技術、主要ページへのURL、キュレーションした技術エッセイとビジネスエッセイのリスト、そしてKey Facts——Codec2の450bps、QRコードバージョン40の2,953バイト制限、NDL納本の受付番号。

AIに自社を説明するための、もう一つのフロントドアだ。

llms.txtは、AIへの自己紹介状だ。
HTMLの構造を解析させるのではなく、「私たちはこれです」と平文で伝える。

6. パフォーマンス——Core Web Vitals

SEOのもう一つの柱は、ページの表示速度だ。Googleは Core Web Vitals——LCP（最大コンテンツ描画）、CLS（累積レイアウトシフト）、INP（次のペイントまでのインタラクション）——をランキング要因に組み込んでいる。

コードを分析すると、contact-form.jsとtracker.jsにdefer属性がなかった。ブラウザはこれらのスクリプトをダウンロードし実行するまで、ページの描画をブロックする。

475ページのスクリプトタグにdeferを追加した。ブラウザはDOMの構築と並行してスクリプトをダウンロードし、DOM構築後に実行する。ユーザーが最初のコンテンツを見るまでの時間が短くなる。

あわせて、ロゴ画像の空のalt属性をalt="TokiStorage"に修正し、FAQアコーディオンのボタンにaria-expanded属性を追加した。アクセシビリティの改善は、SEOスコアにも直結する。

7. 作ることと見つけてもらうこと

この一連の作業で気づいたのは、「作ること」と「見つけてもらうこと」は完全に異なるレイヤーの設計行為だということだ。

エッセイを書くことは楽しい。アーキテクチャを設計するのも楽しい。コードを書き、ページを公開し、リンク構造を整備する。だがそのすべてが、noindexの1行によって無効化されていた。

発見性は、コンテンツの「品質」とは独立した設計対象だ。どれほど優れたエッセイを書いても、OGPタグがなければSNSで共有されたときにただのURLとして表示される。構造化データがなければ、検索結果でリッチスニペットにならない。hreflangがなければ、英語ユーザーに日本語ページが表示される。

これはTokiQRの設計でも経験した構造だ。音声をCodec2で圧縮し、QRコードに埋め込み、ブラウザでデコードする——その技術的な設計がどれほど精緻でも、Safariが静かにWebPをJPEGにフォールバックしていれば画質は半分になる。問題は常に、見えにくい場所に横たわっている。

発見性は機能ではない。インフラだ。
電気が通っていなければ、どんな家電も動かない。

8. ソロ開発とSEOの関係

なぜnoindexが放置されていたのか。答えは単純だ。ソロ開発では、プロダクトを作る人と、プロダクトを届ける人が同じだからだ。

組織には、開発チーム、マーケティングチーム、SEO担当がいる。それぞれが専門領域に集中し、見落としを補い合う。ソロ開発にはそのフィードバックがない。作ることに没頭すると、届けることを忘れる。届けることに集中すると、作ることが止まる。

だが、ソロ開発にはソロ開発の利点がある。499ページの一括更新を、合議なく、承認プロセスなく、即座に実行できる。SEOの施策を思い立ってから全ページにデプロイされるまでの時間が、組織では数週間、ソロでは数時間だ。

AIとの協働がこのスピードを可能にしている。Pythonスクリプトの生成、全ページの解析、パターンの検出と修正——人間がやれば数日かかる作業を、AIが数分で処理する。ソロ開発者はAIの手を借りて、組織のスケールに匹敵する変更を実行できる。

バイブコーディングの応用だ。「noindexを全ページで解除して、OGPタグを追加して」と伝えれば、AIは499ページの構造を分析し、適切な箇所にタグを挿入するスクリプトを書く。hreflangのペアリングも、JSON-LDのスキーマ選択も、同じ流れで処理される。

9. 発見の多層構造

振り返ると、発見性には明確なレイヤー構造がある。

存在許可——noindexの解除。検索エンジンに「来ていいよ」と伝える。
自己紹介——OGPタグ、構造化データ。「私はこういうページです」と伝える。
住所整理——canonical、sitemap.xml。「正式な住所はここです」と伝える。
言語案内——hreflang。「あなたの言語にはこちらを」と伝える。
AI対応——llms.txt、JSON-LD。「AIのあなたにはこれを読んで」と伝える。
快適さ——Core Web Vitals。「速く、正しく表示します」と伝える。

どの層が欠けても、発見性は損なわれる。noindexがあればすべてが無効。OGPがなければSNS共有が弱い。hreflangがなければバイリンガルの価値が半減する。llms.txtがなければ、AI時代の検索に対応できない。

これは、トキストレージの三層分散保管——物理（石英ガラス）、国家（国立国会図書館）、デジタル（GitHub）——と同じ構造だ。保管にも発見にも、冗長性と多層性が必要になる。一つの層に依存すれば、その層が崩れたときにすべてを失う。

作ったものが世界に存在するためには、作ること以外の設計が要る。noindexの1行が500ページを無にし、llms.txtの1ファイルがAIへの扉を開く。発見性はコンテンツの品質とは独立した設計対象であり、多層的に構築しなければ、どこか一つの欠落で全体が沈黙する。

500ページを書くよりも、見つけてもらう設計を1日で積むほうが、
世界への到達距離は大きく変わる。
作ることと届けることは、対等な設計行為だ。