このサイトはどう作られているか
静的サイト生成とレスポンスヘッダー、構造化データ、公開前の自動チェックがどう組み合わさるかを、実際の配信の仕組みから解説します。
本文はプレーンテキスト、ビルドがコンパイラ
このサイトの文章は Markdown という形式のファイルに置かれています。各ファイルの先頭には、タイトルや説明、種別といった短いメタデータのまとまりがあり、それ以降は普通の文章です。データベースも管理画面も、ログインするエディタもありません。ページを増やすとは、ファイルを一つ増やすことと同じです。
そのファイルを HTML に変えるのがビルドという手順です。これをあえて明言する意味は大きい。生成側があらかじめ HTML を作っておくと、完成した文章はサーバーを離れる瞬間のレスポンスにすでに含まれています。クローラは JavaScript を実行したり、API の応答を待ったり、クライアント側のルーターが正しい画面を描くのを願ったりする必要がありません。
その失敗形態は架空の話ではありません。何千という URL を配信し、すべてが 200 ステータスと寸法の合った HTML を返しながら、中身が空の容器要素とスクリプトタグだけというサイトがあり得ます。ブラウザベースの道具は「動いている」と報告します。タグを剥がして単語を数えたときにはじめて問題が見えるのです。
配信の善し悪しを決める三つの性質
見た目の設計以上に、コンテンツサイトの成否を左右する機械的な性質が三つあります。いずれも派手さはありませんが、どれか一つでも欠けばサイトとしての評価に直結します。
| 性質 | 満たすべき状態 | 満たさない場合の結果 |
|---|---|---|
| 文章の所在 | サーバーのレスポンスに含まれる | クロールされても中身が空と判定される |
| 欠落 URL | 本物の 404 ステータスを返す | ソフト 404 が量産され品質が薄まる |
| セキュリティポリシー | 頼る第三者スクリプトを許可する | 何も壊えずに収益だけがゼロになる |
文章はサーバーのレスポンスに含まれていなければならない。 後から取ってくるのではなく。タグを除いた生の HTML の単語数が、記事であるはずのページで数百語を下回るなら、書き方ではなく配信の仕組みに異常があります。
存在しない URL は 404 を返さなければならない。 どんな住所にも同じ汎用ページで答えるサイトは、すべての住所が有効だと検索エンジンに伝えています。そうしたページはクロールされ、インデックスに登録され、カウントされます。正しいエラー画面と正しいステータスを一緒に出すだけで直る話ですが、それは意図的でなければなりません。
セキュリティポリシーは、ビジネスが頼る第三者スクリプトを許可していなければならない。 これが静かな罠です。広告や分析のホストを抜いた厳しい script-src 指令は、ページ上にエラーも、訪問者向けのコンソール警告も、見た目の欠陥も出しません。出るのは、完成したように見えながら何も稼がないサイトです。
公開前に何を検証するか
すべてのビルドでは固定のチェックリストが走り、致命的な失敗は警告として流されるのではなく公開そのものを止めます。そのリストは次の項目を網羅します。
- 生成された各ページに、読める文章が含まれているか。
- エラー画面が存在し、正しいステータスで正しく振る舞うか。
- 広告ネットワークが求める四つのページ（このサイトについて、お問い合わせ、プライバシーポリシー、利用規約）が揃っているか。
- コンテンツポリシーが広告のドメインを許可しているか。
- サイトマップが、実在するページを漏れなく網羅しているか。
- 内部リンクが、一度も生成されなかったページを指していないか。
これらのチェックは、まずビルド成果物に対して走り、そのあと配信後の実サイトに対してもう一度走ります。二度走らせるのは無駄な重複のためではありません。成果物の検査は生成側が正しく動いたことを証明し、実サイトの検査は生成側と訪問者のあいだの何か――キャッシュ、リダイレクトのルール、ホストの設定――が答えを変えていないことを証明します。
保守ルールが厳しい理由
複数のサイトが共通のテンプレートを共有しはじめると、それぞれを勝手に変えていく誘惑が生まれます。一つのサイトに当てた修正は無害に見えます。たいていはそうです。だが同じ欠陥を二十箇所で直さなければならず、二十の写しがほんのわずかに分岐していて当てはまる修正がきれいに当たらなくなるまで、それは無害でいるのです。
これを防ぐルールは単純です。サイトは自分のコンテンツとブランディングを所有し、共有の機構はパイプラインのものです。共有部分への編集はパイプラインを通り、一つのコマンドで全サイトへ配布されます。その際、どのサイトもこっそり分岐していないかも確認されます。ここに工夫はありません。ただ、サイトの集まりと、たまたま似ているだけの単発プロジェクトの集まりの違いがあるだけです。
配信の根底にある仕組みは、この日本語版の姉妹サイトである英語版とも同一です。英語版は別のサイトルートに置かれており、そちらにも同等の解説が日本語とは別の言語で書かれています。言語が違うだけで、ビルドや検査の方針そのものに差はありません。
よくある質問
表示されている HTML は何が生成しているのですか？
ビルド時に一度だけ静的サイト生成が走り、普通の HTML ファイルをディスクに書き出します。リクエスト時にデータベースへの問い合わせも、サーバー側での描画もありません。クローラが受け取るバイト列は、人間が受け取るバイト列と同一です。これが肝で、別の描画工程がこっそり失敗して空っぽの殻を残す余地がそもそも生まれないのです。
なぜセキュリティヘッダーを送るのですか？
コンテンツセキュリティポリシー（CSP）こそが、第三者スクリプトの実行を許すかを決めるものだからです。ポリシーが広告や分析のドメインを明示的に許可していなければ、ブラウザはそうしたスクリプトを黙ってブロックします。画面に壊れた様子はなく、設定が直るまで収益はゼロのままです。パイプラインでヘッダーを検証するのは、まさにこの理由からです。
すべてのページに構造化データが必要ですか？
インデックス対象になるページは、少なくとも自身を説明する基本的な WebPage の記述を持つべきです。質問に答えるページは FAQ のマークアップ、日付のある記事は更新日付付きの Article マークアップの恩恵をさらに受けます。構造化データが順位を直接変えるわけではありませんが、検索結果の見せ方を変え、それがクリック率を変えます。
存在しない URL を開くとどうなりますか？
サーバーは本物の HTTP 404 ステータスコードと、人間に読めるページを一緒に返します。この組み合わせが重要です。200 ステータスで親切なページを返すのはソフト 404 と呼ばれ、検索エンジンはそうしたページを無限にインデックス登録し、サイトの品質信号を薄めていきます。
公開前にどのようなチェックが走りますか？
生成された各ページに読める文章が含まれるか、エラー画面が正しく振る舞うか、広告ネットワークが求める四つのページが揃っているか、コンテンツポリシーが広告ドメインを許可しているか、サイトマップが実在するページを網羅しているか、内部リンクが未生成のページを指していないか、を機械的に検証します。いずれかが失敗すると、警告ではなく公開自体が止まります。