Hakaru Lab ｜ 公開: 2026-09-27 ｜ 検証記事
対象読者：静的なサイト(サーバー側でページを組み立てず、あらかじめ作られたHTMLファイルをそのまま配る仕組み)を運用していて「デプロイが成功した＝ちゃんと公開できた」と思い込んでいないか確認したい個人開発者・小規模運用者、および同種のサイトを立てたいと情報収集をしている方。
3行要点
・当ラボは自分が運用する静的サイト(hakarulab.com)を点検し、(1)ソフト404(存在しないURLが200を返す)、(2)OGタイトルの途中終端、(3)canonicalタグの欠落、という3つの公開欠陥を見つけて直した。
・静的サイトを運用しており「デプロイ成功の表示だけを見て公開完了と判断している」個人開発者・小規模運用者が、3種の公開欠陥を自分のサイトで点検するチェック項目として使える。
・対象は当ラボの1サイト(hakarulab.com)の実測にとどまり他サービスでの再現性は確認していない。結論は2026年9月6日時点の実装と記録にもとづく実測値で、公開時点ではページ構成が変わっている可能性がある。
検証の前提
・検証日：2026-09-06
・観測の締め日：2026-09-16 9時(⑤の公開処理の実行記録のみ、検証日以降も記録の最終行まで通して確認)
・検証環境：Cloudflare Pages上で静的HTMLファイルを直接配信する構成(SPA(Single Page Application。1枚のHTMLでURLをアプリ側が処理する構成。詳しくは②)用のルーティング設定なし)。確認手段はプログラムからの直接HTTPリクエスト(ブラウザ相当のUA(User-Agent。アクセス元のソフトを名乗る識別文字列)および公開確認用UAを使用。実際にブラウザを開いて確認した記録は出典に含まれていない)
・利害関係：本記事に広告リンクはありません
当ラボは、記事を公開したあとに自動処理でページのURLへアクセスし、応答コードが200(正常に取得できたことを示すHTTPステータスコード)であれば「公開できた」と記録する仕組みを使っていた。だが実際に自分のサイトを開いて中身を読む点検を行うと、この前提が崩れているページが複数見つかった。応答コードだけを見る確認は、存在しないURLでも200が返ってくる状態(次節のソフト404)の前では意味を持たない。この点検では計測まわりの欠落(索引状況を示すSearch Console(Google Search Console。検索での見え方を無料で確認できるツール。出典参照)検証タグの不在等)も見つかったが、本記事は公開状態そのものに関わる3つの欠陥——ソフト404・OGタイトルの途中終端・canonical未設定——に絞ってまとめる。
存在しないURLにアクセスしたとき、本来であれば「見つからない」ことを示す404(Not Found)が返るべきだが、当ラボのサイトでは200(正常応答)とともに日本語のトップページの中身が返ってきていた。同じ状態は、当時まだ実体を用意していなかった英語版ハブ(`/en/`)やフィード配信用URL(`/feed.xml`)でも起きていた。これはソフト404と呼ばれる状態で、検索エンジンがこの応答を「中身のあるページ」として誤って扱う可能性がある(当ラボの測定範囲外であり、Google Search Centralの説明を根拠とした一般論。出典参照)ほか、公開確認の仕組みでも存在しないURLと実在するページを区別できなくなる問題を引き起こしていた。
原因はCloudflare Pages側の仕様にある。公式ドキュメントによれば`404.html`を配置していない場合、同サービスはSPA(Single Page Application。1枚のHTMLでURLをアプリ側が処理する構成)をデプロイしているとみなし、すべてのリクエストをルート(`/`)にマッチさせる(出典参照)。当ラボのサイトは複数の静的HTMLファイルを配信する構成だが`404.html`が無かったため、この仕様どおりトップページが返っていたと判断している。
直し方は2通りに分かれる。本来「存在しないURL」には404を返すべきで、当ラボは`404.html`を設置した(トップページ等へのリンクと、robotsメタタグ(検索エンジンのクローラーに索引作成の可否を伝える`<meta>`タグ)`<meta name="robots" content="noindex">`(出典参照)を含む1枚のページ)。設置後、存在しないURLへのアクセスで404が返るようになったことを確認した。一方`/en/`と`/feed.xml`は本来「存在すべきURL」だったので、404にするのではなく実体(`en/index.html`)とフィード生成処理を用意し、200で中身を返すようにして直した。ソフト404の是正には「404にする」と「実体を作る」の2通りがあり、URLが本来存在すべきかどうかで使い分けが必要である。
```mermaid
flowchart LR
A[存在しないURLへアクセス] --> B{404.htmlの有無}
B -- 無し --> C["200 + 日本語トップページ(ソフト404)"]
B -- 有り --> D[404 + 404ページの内容]
```
模式図: 404ページの有無による応答の違い(当ラボの1サイトでの2026年9月6日時点の観測。公式ドキュメントとの突き合わせは9月10日実施。出典参照)
OGP(Open Graph Protocol。SNSでリンクを貼ったときに表示されるカードの見出し・説明・画像を指定するメタ情報の規格)のうち、見出しにあたる`og:title`が、英語記事1本(`/en/posts/30days-50man`)で本来の題名の途中で切れて「Is 」のような断片になっていた。原因は、記事タイトルに含まれていた引用符(`"`)がHTML属性値としてエスケープ(特殊な意味を持つ文字を別の表記に置き換える処理。`"`は`"`と書く)されないまま挿入されていたことだった。属性値の中に生の引用符が混ざると、そこで属性が終わったとみなされ残りの文字列は外側に押し出されてしまう。
当ラボはこれを、既存の公開済みHTMLに対して冪等(同じ処理を何度実行しても結果が変わらない性質)に修復をかける処理で直した。`<title>`タグの平文の題名から特殊文字を正しくエスケープした属性値を作り直し、既存の`og:title`タグと食い違っていれば置き換える手順である。修復後、該当記事で`og:title`が`"`で正しくエスケープされた状態になったことを確認した。
canonical(正規URL)タグは、同じ内容が複数のURLで見える可能性があるときに「このURLが本物です」と検索エンジンに伝える`<link rel="canonical" href="...">`というタグである(仕様の詳細は出典参照)。当ラボの点検時点で、記事3本・英語版記事1本・方法論ページの計5ページにこのタグが無いことが分かった。示されていないと、複数の経路で見えた場合にどちらを本物として扱うか不確定になる可能性がある。
直し方として、当ラボは既存の公開済みHTMLに対し実際のURLを組み立ててcanonicalタグを追加する一括付与処理を用意した(記事は`https://hakarulab.com/posts/<slug>`(slug。URL末尾に使う記事識別用の英数字文字列)、英語版記事は`/en/posts/<slug>`、方法論は`/methodology`)。すでにタグがあるページには何もしない設計で、9月6日未明にこの処理を実行した時点でタグを追加したのは5ページだった(前段の5ページと同じ)。これとは別に新規記事のビルド処理にもcanonical付与を組み込んであり、同日中に追加公開した英語版記事3本はビルド時点で付与された。9月6日終了時点でタグを持つページは、一括付与5とビルド時付与3を合わせて8になる。「8ページ」は一括付与処理単体の成果ではなく2処理の合計であり、配信内容を取得しURL一致まで読み戻し確認したのは1ページにとどまる。
この3つの欠陥はいずれも、応答コードやビルドの成否表示だけを見ていては気づけなかった。当ラボが実際に行ったのは、公開したはずのページを開いて中身を読み、一度閉じたあとでもう一度読み直して確認する手順である。閉じてから読み直すのは、開きっぱなしの画面がキャッシュや編集中の状態をそのまま映しているだけの可能性を排するためである。あわせて、公開確認用の専用ユーザーエージェントとキャッシュ回避のクエリ付きURLを使い、プログラムから直接HTTPリクエストを送って生の応答を確認した(実際にブラウザを開いて確認した記録は出典に含まれていない)。
この点検を受けて、当ラボは公開確認の自動処理そのものにも手を入れた。従来は応答コードが200であれば公開成功とみなしていたが、修正後は取得した本文に題名の先頭20文字が含まれるかも照合するようにした。ただしこの追加は当ラボのサイト構成では②のソフト404を検知できない。公開処理は同じ実行の中でデプロイ前にトップページ(`index.html`)へ新規記事への題名付きリンクを挿入しており、ソフト404でトップページが返っても当の題名がすでに載っているため照合は素通りしてしまう。本文照合を追加したことは事実だが「ソフト404を検知できるようになった」とは言えず、そのページにしかない文字列(本文中の固有の一節やcanonicalのURLなど)で照合しない限りこの失敗様式は見抜けない。
もう一点、この修正では読み戻し自体が拒否(403)された場合にボットとして弾かれたとみなし、本文照合を経ずに公開済みとして記録する例外も新たに設けた。この例外はもとからの穴ではない。実行記録では9月4日と5日にも403での拒否があり、当時はいずれも失敗(未公開扱い)として記録されている。今回この分岐を新設したことで、検証を強めるはずの改修の中に照合をすり抜ける経路を自分で新しく作ってしまった。しかもこの判定はHTTPステータス403そのものではなくエラーメッセージの文字列に「403」が含まれるかで行っており、403以外の失敗でも同様に公開済み扱いになりうる。
この確認方式が適用された自動公開は9月6日9時の1件のみである。同日18時31分の英語版3ページの追加公開は別経路で、本節の処理を通っていない。当ラボの公開処理の実行記録を観測の締め日(2026年9月16日9時。記録の最終行)まで通して読むと、この9月6日18時31分の公開を最後に新規公開は発生しておらず、本節の確認方式が再び適用された例も無い。したがって題名の不一致を実際に検知した事例はまだない。
静的サイトを運用している方向けに、当ラボが今回の点検から作ったチェックリストである。これから新しくサイトを立てる方は公開前に組み込んでおくとよい。
一つでも当てはまらなければ、「公開したつもり」のページが紛れ込んでいないか見直す価値がある。
採用(当ラボの決定): 当ラボは、404ページの設置(存在しないURL向け)・英語版ハブとフィード配信の実体化(存在すべきURL向け)・OGタイトルの属性値エスケープ修復・canonicalタグの一括付与とビルド時付与・公開確認処理への本文照合の追加を、9月6日にhakarulab.comへ適用済みである。適用後、存在しないURLが404を返すこと、該当の英語記事のOGタイトルが正しくエスケープされていること、対象ページについて9月6日終了時点で8ページ(一括付与5・ビルド時付与3)にcanonicalタグが付いていること(トップページ等は対象外)を確認しており、この状態を継続する。ただし今回追加した本文照合は当ラボのサイト構成上②のソフト404を検知できない(トップページに同じ題名がすでに載るため)。また同じ改修で新設した403例外は本文照合をすり抜けて公開済みと記録されうる経路であり、以前からの穴ではなく今回自分で持ち込んだ穴である。いずれも未解消であり次の課題として残る。
推奨(読者への助言): Cloudflare Pagesなどの静的ホスティングで自分のサイトを運用している個人開発者・小規模運用者には、⑥のチェックリストで自分の環境を照らし合わせることをおすすめする。とりわけ公開確認をHTTP応答コードだけに頼らず、実際に配信されているページを開いて確認することを勧める——当ラボ自身この確認を欠いたまま3つの欠陥に気づかずにいたためである。あわせて検証強化策を入れる際も、照合対象がサイト内の別の場所に紛れ込んでいないかを疑うことを勧める——当ラボ自身、検証を強めたつもりの改修で新しいすり抜け経路を作ってしまったためである。基準日は検証日(2026年9月6日)であり、公開時点では数値が変わっている可能性がある。
方法： 本記事は、当ラボが運用するサイト(hakarulab.com)の実際の公開済みHTMLファイル、404ページのソースファイル、公開確認処理・メタ情報修復処理のソースコード、公開処理の実行記録にもとづく検証である。数値・挙動はすべて当ラボが観測した実測を記載している。
未確認事項：
訂正履歴：
出典：
当ラボ(hakarulab.com)の調査・執筆・検証は複数のAIによる分業で行っています。本記事は当ラボ自身が運用するサイトの公開状態を実際のファイルと記録にもとづき点検し直した記録です。方針の決定と最終確認は運営側の人間が担っています。