案件獲得用サイトの問い合わせリンクが、6箇所すべて404だった
ポートフォリオサイトを公開して2ヶ月、別の作業のついでにリンクを検査したら、問い合わせ導線が全滅していました。作って終わりにすると何が起きるか、実例として書きます。
何が起きていたか
Web制作の案件を取るためのポートフォリオサイトを運用しています。
別の作業でリンク構成を調べていたところ、こうなっていました。
https://eternaldct.net/contact/ → 404 ← サイトが張っていたURL
https://eternaldct.net/contact.html → 200 ← 正しいURL
該当箇所は6つ。 しかも場所が最悪でした。
| 箇所 | 文言 |
|---|---|
| ナビゲーション | お問い合わせ |
| ヒーロー（最上部） | 無料相談はこちら |
| 料金プラン | 相談する |
| ほか3箇所 | — |
案件を取るためのサイトで、問い合わせ導線が全部死んでいました。
この期間に「問い合わせよう」と思ってボタンを押した人は、全員404を見ています。何人いたかは分かりません。分からないのが一番まずいところです。
なぜ気づかなかったのか
原因を分解すると、3つ重なっていました。
1. 自分でクリックしない
自分のサイトの問い合わせボタンを押す機会は、まずありません。作るときに一度確認したら、その後は見ないところです。
デザインの崩れなら、たまに開いたときに気づきます。リンク切れは、クリックしないと分かりません。
2. エラーが自分に届かない
404が発生しても、サイト運営者には何も通知されません。訪問者の画面でだけ起きて、静かに終わります。
問い合わせが来ないという結果だけが残りますが、それが「需要がない」からなのか「導線が壊れている」からなのかは、区別がつきません。
3. リンク先が別ドメインだった
問い合わせ先は、ポートフォリオとは別のドメインにありました。
別サイトのURL構成が変わっても、こちらには何も起きません。 同一サイト内なら、ページを消したときに気づく機会がありますが、外部リンクにはそれがありません。
対策：リンク切れを自動で検出する
同じことを繰り返さないよう、公開前のチェックに組み込みました。
やっていることは単純です。記事から外部リンクを抜き出し、1つずつ叩いて応答を見るだけです。
# Markdownのリンク記法 ](url) だけを対象にする
urls=$(grep -rhoE '\]\(https?://[^)]+\)' content/articles/ \
| sed 's/^](//; s/)$//' | sort -u)
for u in $urls; do
code=$(curl -s -o /dev/null -w "%{http_code}" -L --max-time 12 "$u")
case "$code" in
2*|3*) ;;
*) echo " ✗ HTTP $code $u"; fail=1 ;;
esac
done
リンクが1つでも死んでいたら、公開作業自体を止める形にしています。
つまずいた点：コード例のURLまで拾ってしまう
最初は本文中のURLを全部拾う実装にしていました。結果、記事に載せているコマンドの例まで検査対象になりました。
✗ HTTP 400 https://dns.google/resolve?name=あなたのドメイン&type=A
✗ HTTP 404 https://example.com/api/DOMAIN
これらは説明用のプレースホルダで、リンクではありません。
Markdownのリンク記法だけを対象にするように直しました。実際にクリックできる形になっているものだけを見る、という基準です。
気づいた経緯が偶然だった、という問題
正直に書くと、このリンク切れを狙って探したわけではありません。
別の目的（サイト間の導線を整理する作業）でリンクを一覧にしたところ、たまたま見つかりました。その作業をしなければ、今も気づいていません。
これは自動化が静かに壊れる話とまったく同じ構造でした。
- エラーが誰の目にも触れない場所で起きる
- 成功しても失敗しても、体感は同じ「何も起きない」
- 偶然見つかるまで、永久に続く
同じ日に、毎朝の自動処理が14日間止まっていたことも判明しました。どちらも「静かに壊れて、放置される」タイプの問題です。
つまずきやすい点
公開時のチェックリストは実行されなくなる
「公開前にリンクを確認する」とメモに書いても、実行されません。確認する動機がないからです。
公開の手順そのものに組み込む必要があります。当方では、公開コマンドを叩くと自動でチェックが走り、問題があれば公開せずに止まる形にしました。
チェックしてから公開する、ではなく、チェックを通らないと公開できないという順序にするのが肝でした。
末尾のスラッシュとファイル名
今回の原因は /contact/ と /contact.html の違いでした。
ディレクトリ形式のURLを使うサイトと、ファイル名を出すサイトが混在していると、この種の間違いが起きます。他サイトのURLを手で書くときは、実際に開いて確認するのが確実です。
定期的に再検査する
一度直しても、リンク先は変わります。リンク切れは時間とともに増えます。
公開のたびに検査が走る形にしておけば、次に何かを公開したタイミングで自動的に再検査されます。
よくある質問
サイトのリンク切れはどうやって見つければいいですか？
ページからリンクを抽出し、1つずつHTTPステータスを確認する方法が確実です。公開作業の手順に組み込み、リンク切れがあれば公開を中止する形にすると、確認漏れが起きません。
リンク切れが起きても運営者には通知されませんか？
されません。404は訪問者の画面で起きるだけで、サイト運営者には何も届きません。問い合わせが来ないという結果だけが残り、それが需要の問題なのか導線の問題なのか区別がつかなくなります。
外部サイトへのリンクも検査すべきですか？
すべきです。外部サイトのURL構成が変わっても自分側では何も起きないため、同一サイト内のリンクより気づきにくくなります。実績として他のサイトを挙げている場合、そこが切れると記事の説得力ごと失われます。
まとめ
案件獲得用のサイトで、問い合わせ導線が6箇所すべて404になっていました。公開してから見つかるまで、確認する機会が一度もありませんでした。
- 自分の問い合わせボタンは、自分では押さない
- 404は運営者に通知されない
- 偶然見つかるまで、放置され続ける
対策は、公開の手順そのものに検査を組み込むことでした。メモに書いたチェックリストは実行されません。 通らないと公開できない形にするしかありませんでした。
サイトは作った時点では動いています。壊れるのはそのあとです。