URLを入れて実行したら、英語のメッセージが数十行。どこから手をつけるか分からず、そっとタブを閉じた——多くの人が一度は通る道です。この記事では、入力方法ではなく「出てきた結果をどう読み解き、どこから直すか」に絞って解説します。結論から言えば、結果画面は上から順に1つずつ直して再チェックするのが最速です。その理由と、そこに至るまでの読み方を順に見ていきます。
なぜ結果画面は見づらいのか——同じドメインに2つのツールがある
見づらさの一因は、validator.w3.org に性質の異なる2つのツールが同居していることにあります。
トップページにあるのは The W3C Markup Validation Service です。見出しは「Check the markup (HTML, XHTML, …) of Web documents」。Perl と OpenSP による DTD/SGML ベースの旧実装で、「Validate by URI」「Validate by File Upload」「Validate by Direct Input」の3タブ構成です。HTML 4.01、XHTML、SVG、MathML など幅広い文書型に対応します。
一方 /nu にあるのが The Nu Html Checker です。Java製で、HTML Living Standard に対応する現行の実装です。トップページからは「try our non-DTD-based validator」という文言でリンクされています。
| Markup Validation Service | Nu Html Checker | |
|---|---|---|
| URL | validator.w3.org | validator.w3.org/nu |
| 実装 | Perl + OpenSP | Java（validator/validator） |
| 方式 | DTD / SGML ベース | 非DTDベース |
| 主な対象 | HTML 4.01・XHTML・SVG・MathML | HTML Living Standard |
| UI | 3タブ構成 | Checker Input 形式 |
ここが重要な点です。旧バリデーターは、対象文書をHTML5と判定すると、チェックをNuエンジンに委譲します。この統合は2008年11月20日の 0.8.4 リリースで導入されました。Newsページには次のように記録されています。
the validator can now check documents for conformance to HTML5, thanks to the integration with the Validator.nu html5 engine.
現代のサイトはほぼHTML5です。つまりトップページから入っても、実質的に読んでいるのはNuの出力ということになります。UIは旧バリデーターのまま、中身はNu。この二重構造が、画面の分かりにくさにつながっています。
なお同ページでUI関連の更新として記録されているのは、2009年3月26日の 0.8.5 リリース（「More options」の矢印挙動の改善など）が最後です。それ以降、大きなUI改修は行われていません。見た目が古く感じられるのは、実際に古いからです。
よく見かける2つの誤解
ここで、いくつかの記事で見かける不正確な説明を整理しておきます。
「HTMLの管理がW3CからWHATWGに移ったので、ツールがNu Html Checkerに名称変更された」——これは正確ではありません。Nu Html Checker は validator.nu 由来の別実装のエンジンで、W3Cがそのインスタンスをホストしている関係です。旧バリデーターが改名したわけではなく、両者は現在も並存しています。
「HTML5チェックは experimental なので警告が1つ出るのが正常」——旧UIの Document Type 選択に該当する表記が残っているのは事実ですが、これを現在の挙動としてそのまま受け取るのは避けてください。実際に出るメッセージは、対象文書によって変わります。
結果画面の解剖——上から順に何が書かれているか
結果画面は、上から「判定の要約」「Checker Input」「メッセージ一覧」の順に並びます。それぞれ何が書かれているかを見ていきます。
Checker Input（折りたたみ領域）
Checker Input には、何を、どの条件でチェックしたかが記録されています。用意されているオプションは次のとおりです。
- Show source：チェックしたソースを結果画面に表示します
- Show outline：見出し構造のアウトラインを出力します
- Show image report：画像と alt の一覧を出力します
- Check error pages：エラーページ自体を検査対象にします
- User-Agent：送信するUA文字列を指定します
- Accept-Language：言語ネゴシエーションを指定します
User-Agent と Accept-Language は、UAや言語によって出し分けているページを検証するときに使います。普段は触る必要がありません。
なおNuのページには「This tool is an ongoing experiment in better HTML checking」、そして「its behavior remains subject to change」と明記されています。挙動が変わりうる前提のツールである点は、頭の片隅に置いておくとよいでしょう。
メッセージ一覧——Error / Warning / Info の3レベル
本体はここです。メッセージには3つのレベルがあります。JSON出力で確認すると、構造は次のようになっています。
type: "error"— エラーtype: "info"かつsubType: "warning"— 警告type: "info"— 参考情報
つまり警告は、内部的にはinfoの一種です。実際にW3C自身のトップページを検証すると、errorは0件、infoが34件、そのうちsubTypeがwarningのものが4件、という結果になりました。infoの件数は多くなりがちです。
位置表記の読み方
各メッセージには、該当箇所が次の形式で示されます。
From line 11, column 2; to line 11, column 180「11行目の2桁目から、11行目の180桁目まで」という意味です。JSONでは firstLine / lastLine / firstColumn / lastColumn に対応します。
ここで一つ実務上のコツがあります。開始位置が省略され、終了位置だけが示されるメッセージがあります。これは範囲ではなく1点を指すケースです。JSONでも lastLine と lastColumn だけが返り、firstColumn は含まれません。
さらに、位置情報を一切持たないメッセージもあります。例えば example.com を検証すると、次の1件だけが返ります。
The character encoding was not declared. Proceeding using “windows-1252”.（文字エンコーディングが宣言されていません。windows-1252として処理を続行します。）これは特定の行の問題ではなく、文書全体に関わる指摘です。行番号を探しても見つからないので注意してください。
ソース抜粋とハイライト
各メッセージの下には、該当箇所のソースが抜粋されます。JSONでは extract がその抜粋、hiliteStart と hiliteLength がハイライト範囲を表します。抜粋は前後の文脈を含むため、ハイライトされている部分だけが問題箇所です。周辺のコードまで疑い始めると、かえって遠回りになります。
エラーの優先順位のつけ方
ここが本題です。数十件のメッセージを前にしたとき、どう崩すかを4つの原則で整理します。
原則1：カスケードエラーを疑う
最も重要な現象がカスケードエラーです。閉じタグが1つずれているだけで、そこから下の構造解析がすべて狂い、無関係に見えるエラーが連鎖して発生します。30件のエラーが、実は原因1つということは珍しくありません。件数を見て絶望する必要はないのです。
原則2：行番号が近いエラーは1つの原因を疑う
実践則として、行番号が近接しているエラーは同一の原因である可能性が高いと考えます。同じ行、あるいは数行以内に固まっているメッセージ群は、まとめて1つの問題として扱います。逆に、行番号が大きく飛んでいるエラーは、それぞれ独立した問題である可能性が高くなります。
原則3：上から1つ直して、再チェック
遠回りに見えて、これが結局最速です。理由は原則1にあります。先頭のエラーを直すと、それが原因で連鎖していたエラーがまとめて消えるからです。下から直したり、全件を一度に直そうとすると、消えるはずだったエラーに時間を使うことになります。1件直す、再チェック、残った先頭を直す。この繰り返しが、結果的に手数を最小にします。
原則4：直さなくてよいものを切り分ける
すべてをゼロにする必要はありません。type: "error" は仕様違反なので、原則として直します。判断が分かれるのが警告です。実際に出た警告の例を挙げます。
The “type” attribute is unnecessary for JavaScript resources.（JavaScriptを読み込む要素に type 属性は不要です。）これは害があるわけではなく、冗長だという指摘です。テンプレート側の問題であれば、まとめて直すほうが効率的です。
Trailing slash on void elements has no effect and interacts badly with unquoted attribute values.（空要素の末尾スラッシュは効果がなく、引用符なしの属性値と組み合わせると問題を起こします。）<meta ... /> のようなXHTML風の書き方に対する指摘です。実務では、CMSやテーマが出力している場合も多く、無理に追う価値は高くありません。
後回しでよいのは、subTypeのない type: "info" と、外部埋め込み由来のものです。広告タグ、SNSのウィジェット、解析タグなどが出力する要素への指摘は、自分のコードでは直せません。自分が書いたコードか、外部から挿入されたコードか。この切り分けを最初に済ませると、実際に対応すべき件数は大きく減ります。
実例：自社サイトを検証してみた
ここまでの原則が実際にどう働くか、当社サイト（threedplus.co.jp）を検証した結果で確かめてみます。以下は2026年7月時点、チェッカーのバージョン 26.7.22 での結果です。
| レベル | 件数 |
|---|---|
| error | 4件 |
| warning | 1件 |
| info | 37件 |
| 合計 | 42件 |
合計42件。この数字だけを見ると身構えます。しかし内訳を見ると景色が変わります。info の37件は、すべて同一のメッセージでした。
Trailing slash on void elements has no effect and interacts badly with unquoted attribute values.テーマが出力する空要素の書き方に由来するもので、37件が同じ原因です。つまり実際に向き合うべきは、error の4件と警告1件だけになります。
同じ行に並んだ2件は、1つのタイポだった
error 4件のうち2件は、まったく同じ位置（567行目）を指していました。メッセージは次の2つです。
Attribute “ait” not allowed on element “img” at this point.An “img” element must have an “alt” attribute, except under certain conditions.該当箇所の抜粋を見ると、原因は一目で分かります。alt と書くべきところが ait になっていました。属性名のタイポ1つで、「ait は img に使えない」「img に alt がない」という2件のエラーが同時に出ていたわけです。原則2（行番号が近いエラーは1つの原因を疑う）が、そのまま当てはまります。修正は1文字です。
残りのエラー2件
- 3行目：
Duplicate attribute “prefix”.（prefix 属性が重複している） - 622行目：
Bad value “ anonymous ” for attribute “crossorigin” on element “script”.（値の前後に余分な空白が入っている）
結論：42件が、実質3箇所
37件はテーマ由来の info、1件は警告、error 4件の原因は3箇所（うち2件は同一のタイポ）。42という件数に対し、実際の作業は3箇所です。上から1件ずつ直して再チェックすれば、すぐに収束します。なお ait のタイポは、ロゴ画像に代替テキストが設定されていない状態を意味します。アクセシビリティの観点から、この1件は優先度を高く扱うべきものです。
見づらさを軽減する設定とURLパラメータ
まず有効にすべきは Show source です。該当箇所のソースがハイライト付きで表示され、行番号を数える手間がなくなります。あわせて、表示を絞り込む Message Filtering で 「Errors & warnings only」 を選べば、infoが消えて対応すべきものだけが残ります。件数が多いときは、まずこれで視界を確保してください。
毎回フォームを操作する必要もありません。次の形式で、最初からソース表示付きの結果を開けます。
https://validator.w3.org/nu/?doc=【URL】&showsource=yesdoc に渡すURLは、URLエンコードしておくと確実です。さらに &out=json を付けると、結果をJSONで取得できます。
https://validator.w3.org/nu/?doc=【URL】&out=json返る構造は、トップレベルが url / version / messages の3キー。各メッセージは type、subType、firstLine、lastLine、firstColumn、lastColumn、message、extract、hiliteStart、hiliteLength を持ちます。typeがerrorの件数を数えるだけでも、CIで「エラー0件」を担保する仕組みは作れます。ローカル実行が必要なら、同じエンジンが validator/validator で vnu.jar として配布されています（Java 17以上が必要です）。
まとめ
- 見ているのは実質的にNuの出力である（UIは旧バリデーターのまま）
- メッセージはError / Warning / Infoの3レベル。警告はinfoの一種
- 件数に惑わされない。カスケードエラーで水増しされている
- 上から1件直して再チェック、を繰り返すのが最速
- Show source と「Errors & warnings only」で視界を確保する
最後に、運用上の姿勢について。バリデーションは全件ゼロにすることが目的ではありません。errorを潰し、warningは意図を確認したうえで判断し、外部由来のものは切り分ける。この線引きをチームで共有しておくほうが、ゼロを目指して疲弊するより実りがあります。判断に迷ったら、HTML Living Standard の該当箇所を確認してください。メッセージの文言は、仕様のどの規定に基づくかを追える程度には具体的に書かれています。
