ホームページ健康診断をつくる時に大切にしたこと

NAKASHIMA CRAFT で開発を担当している中島Dです。

今回は、ホームページ健康診断 という小さな診断ツールをつくった時の考え方をまとめます。

このツールは、URLを入力すると、公開されているページから分かる範囲で 検索で見つけてもらいやすいか、読みやすいか、安心して開けるか を整理するものです。

いわゆる専門的な診断ツールではなく、ホームページを持っている方が「今の状態をざっくり確認する」ための道具として設計しました。

#まず決めたのは「やらないこと」

このツールをつくる時、最初に決めたのは「何を見るか」よりも「何をしないか」でした。

診断という言葉を使うと、どうしてもセキュリティ診断や脆弱性調査のような印象を持たれる可能性があります。 けれど、このツールで目指したのは、そうした専門的な検査ではありません。

そのため、以下のようなことは行わない方針にしました。

• フォーム送信はしない
• ログインは試さない
• 攻撃的な文字列を送らない
• 隠しページを探さない
• ポートスキャンをしない
• リバースエンジニアリングのような調査をしない

あくまで、通常のブラウザで見られる公開ページを読み取り、その中にある手がかりを整理するだけです。

これは、技術的な安全性のためでもありますが、それ以上に「このツールが何をするものなのか」を誤解されないための線引きでもあります。

#公開情報だけを見る

一番こだわったのは、必ず公開情報だけを利用することです。

診断対象は、URLを入力して通常の GET で取得できるHTMLページに限定しています。 ログイン後の画面、管理画面、非公開ファイル、サーバー内部の情報には触れません。

また、robots.txt で取得を拒否しているパスは診断しないようにしています。 サイト側が「ここは見に来ないでください」と示している場所には踏み込まない、という考え方です。

さらに、ローカルホストやプライベートIP、標準ではないポートも診断対象から外しています。 診断ツールが、意図しない内部ネットワーク確認の踏み台にならないようにするためです。

ツールは便利であるほど、使われ方の幅も広がります。 だからこそ、最初から「できないようにしておく」範囲を丁寧に決めることが大切だと考えました。

#専門用語より、判断しやすさを優先する

もうひとつ大切にしたのは、非エンジニアの方でも読めることです。

ホームページの状態を確認する時、技術者はつい title、meta description、canonical、CSP、HSTS のような言葉を使いがちです。 もちろん、これらは大事な項目です。

ただ、ホームページを運営している方にとって本当に知りたいのは、用語そのものではなく、

• 検索結果で伝わりやすいか
• スマホで見やすいか
• 画像の意味が伝わるか
• 安心して開ける状態か
• 制作会社に何を相談すればよいか

ということだと思います。

そこで画面上では、できるだけ次のような言い換えを使いました。

専門用語を完全になくすのではなく、まずは意味が分かる言葉で伝え、必要な人だけ詳しい情報を確認できる構成にしています。

#点数だけで終わらせない

診断ツールをつくると、どうしても点数を出したくなります。 点数は分かりやすい一方で、「70点です」と言われても、次に何をすればよいのか分からないことがあります。

そこで、点数よりも 先に直すこと を見せる構成にしました。

改善項目では、できるだけ次の情報を出すようにしています。

• どのページの話か
• 今どうなっているか
• 直すとどう良くなるか
• どう直せばよいか
• 制作会社や担当者へどう依頼すればよいか

特に「依頼文」を入れたのは、ホームページの管理を外部に任せている方を想定したためです。

「meta description を設定してください」と言われても、慣れていない方には少し距離があります。 それよりも、「検索結果に出る説明文を設定できるか確認してください」と言える方が、実際の相談につながりやすいはずです。

#日本語サイトとして自然に読む

日本語のホームページを見ていると、英語圏のツールをそのまま使った時に少し違和感が出ることがあります。

たとえば、ページタイトルや説明文の長さです。 単純な文字数だけで見ると、日本語と英語では印象が変わります。

このツールでは、全角文字と半角文字の表示幅を考慮して、タイトルや説明文の長さを見ています。 細かい部分ですが、日本語サイトを自然に扱うためには必要な調整でした。

また、古いサイトでは文字コードがUTF-8ではない場合もあります。 そのため、HTMLを読む時には、HTTPヘッダーやページ内の charset を見て、できるだけ文字化けしないようにしています。

こうした対応は目立ちませんが、小規模事業者のホームページを確認する道具としては大切なところです。

#診断できないことも明示する

このツールでは、診断結果の中に「この診断で分からないこと」も表示しています。

たとえば、JavaScriptで後から表示される内容、実際の利用者環境での表示速度、画像やCSSなどすべての読み込み状況までは確認していません。

公開ページのHTMLから分かることに絞っているため、分からないことは当然あります。 だからこそ、できることとできないことを分けて伝える必要がありました。

「問題ありません」と言い切るためのツールではなく、「まず確認する入口」として使ってもらうためのツールです。

#小さくても、安心して使える道具にする

技術構成としては、画面側を Rust + Leptos、診断API側を Cloudflare Workers で動かしています。 診断ロジックは共通のコア部分にまとめ、外部サイトを取得する部分とは分けています。

この分け方にしたことで、安全対策と診断ロジックを別々に見直しやすくなりました。

また、URLの制限、本文サイズの上限、タイムアウト、アクセス集中時の制限なども入れています。 小さなツールでも、第三者のサイトを取得する以上、乱用されにくい作りにしておく必要があるためです。

#おわりに

ホームページの状態は、専門家でないとまったく分からないものに見えがちです。

でも実際には、公開ページを見ただけでも分かることがたくさんあります。 ページ名が分かりやすいか、説明文があるか、スマホ表示の基本設定があるか、画像に説明があるか、安心して開ける設定があるか。

このツールは、そうした基本的な手がかりを、できるだけやさしい言葉で整理するためにつくりました。

「専門的な検査」ではなく、「ホームページの健康状態を知る入口」として、必要な方に届けばうれしく思います。