dido-checklist-sito-web

Webサイト QA チェックリスト

2段階のスキルです。検証可能な項目（ページをダウンロードし、HTML、ヘッダー、JSON-LD、リダイレクトを確認するもの。あるかないかで判断できます）と、判断が必要、または人間にしか確認できない項目（実際の決済、翻訳の品質、条項の法的適合性）があります。

黄金律：実際に確認していない項目には、絶対にチェックを付けないでください。 レポートの各項目には明確な判定を記載します。未検証は正当で、よくある判定です。40項目を検証し、60項目を検証不能と明記したレポートは、100項目すべてに緑のチェックを付け、その半分をでっち上げたレポートよりも、はるかに価値があります。このスキルを有用なものに保つ唯一の方法です。

部分的な依頼

ユーザーが一部分だけ（「XのテクニカルSEOを確認して」など）を依頼した場合は、該当するセクションだけを実行し、レポートの書式と誠実さに関する同じルールを適用してください。

ステップ 0. コンテキスト（省略しないでください）

これらの回答がないと、項目の半分は該当しない可能性があり、意図された設定をエラーとして報告するおそれがあります。まとめて一度に質問し、ユーザーから回答がない場合は、レポートの冒頭に記載した前提に基づいて作業を進めてください。

1. サイトのURLと、テスト対象の環境が異なる場合はそのURL（ステージングまたは本番環境）。
2. 種類：ショーケースサイト、ブログ／編集サイト、ECサイト、ログイン機能付きWebアプリ、多言語ポータル。
3. タイミング：リリース前、移行後（その場合は旧URLの一覧が必要）、稼働中のサイトの監査。
4. 利用可能なアクセス権：Search Console、GA4、CMS管理画面、ホスティング、テスト用メールボックス。これらがない場合、セクション全体が未検証のままになります。最後ではなく、最初に明記してください。
5. スタック（CMS、フレームワーク、ホスティング、CDN）と、分かる場合はそれぞれの担当者。

次に、環境の機能を検出し（ステップ 0-bis）、以下のタグマップを使って対象範囲を定義してください。

ステップ 0-bis. 環境の機能を検出する（前提にしないでください）

このスキルは、さまざまなホスト（claude.ai、Claude Code、API）で実行されます。利用できるツールを決めつけず、最初に一度だけ試して、結果をレポートの付録に記載してください。

機能	確認方法	利用できる場合	利用できない場合
HTML取得	利用可能なWebツールでホームページをダウンロードする	HTMLに関する[A]項目を実行できます	fetchもshellも利用できない場合、チェックリスト全体が[M]になります。その旨を伝えて、作業を中止してください
HTTPシェル	curl -sI https://<dominio>	ヘッダー、リダイレクト、ステータス、TLSを検証できるため、以下の昇格を適用できます	該当項目は、使用するツールを明記して未検証のままにしてください
エージェント型ブラウザー	ブラウザー制御ツールがあるか	[B]項目を実行します	[B]項目は実行手順とともにユーザーに引き継ぎます
提供されたエクスポート	ユーザーがScreaming Frog／Lighthouse／Semrushのデータを添付しているか	多くの[M]項目を[A]にできます	変更なし

機能に応じた昇格。 [M]は「HTMLだけでは不十分」という意味であり、「不可能」という意味ではありません。HTTPシェルが利用できる場合は、委任せず、必ず次の項目を実行してください：GO-05、GO-08、GO-09、PRF-06、PRF-07、PRF-08、PRF-09、SEC-02、SEC-03、SEC-04、EML-01、EML-03。適用した昇格をレポートに明記してください。

注記（特殊なケースであり、通常のルールではありません）。 claude.aiのコンテナーではネットワークが許可リスト方式になっているため、curlで顧客サイトにアクセスできず、Web取得ツールだけを使います。その場合、HTMLは取得できますが、ヘッダー、リダイレクト、JavaScriptのレンダリングは確認できません。Claude CodeまたはAPIでは通常shellを利用できます。制限のない環境で、claude.aiの制約を報告しないでください。

タイプからタグへ：明示的な対応表

完全な語彙、7つの値（モードタグ [A]/[B]/[M] とは異なります）： #tutti、#lancio、#ecom、#login、#multi、#blog、#form。

軸	ステップ 0 への回答	有効になるタグ
基本	常に	#tutti（フィルター不可）
タイミング	ローンチ前または移行後	#lancio
種類	ショーケース	種類タグなし
	ブログ／編集コンテンツ	#blog
	E コマース	#ecom + #login + #form
	ログイン機能付きウェブアプリ	#login + #form
特徴（サイト上で確認できるもの。申告だけでは不可）	フォームが1つでもある	#form
	会員専用エリアがある	#login
	複数の言語がある	#multi
	ニュース／ブログセクションがある	#blog

これは和集合であり、積集合ではありません。 項目は、そのタグの少なくとも1つが有効であれば実行します。多言語の E コマースで顧客エリアもある場合、ほぼすべての項目が有効になります。これは正しく、最もリスクの高いケースです。

フィルターはセクション単位ではなく、項目ごとに適用します。 それ以外は適用対象となるセクション内にも、種類タグ（#ecom、#login、#form、#blog、#multi）が付いた項目があります。各項目のタグは reference/checklist.md のタイトルの横にあります。そのタグが有効でない場合、理由を添えて、1行ずつ N/A としてマークしてください。範囲としてまとめたり、NON VERIFICATO のままにしたりしないでください。明記された N/A は情報です。該当しない項目の NON VERIFICATO は、実際の見落としを隠すノイズです。

機能がないこと ≠ 機能が壊れていること。 項目が、サイトに存在しない機能（サイト内検索、コメント、動画、モーダル、利用者の声、llms.txt、会員専用エリア、フィルター）に関する場合、結果は N/A: funzionalità non presente sul sito です。KO でも NON VERIFICATO でもありません。該当機能がないことを確認してから、そのように記載してください。N/A は観察結果であり、そのまま価値があります。

レポートの付録に、次のように記載してください：Tag attivi: #tutti #ecom #form, voci in perimetro: N su M。M は reference/checklist.md の項目数です。 この行がなければ、対象範囲を再現できません。

対象範囲を定義したら、実行する直前に reference/checklist.md をセクションごとに読み込みます。

具体的な検証方法

各項目には、実行できる担当者を示すモードタグが付いています：

タグ	意味	実行者
[A]	自動：ページをダウンロードして読むだけ	あなた自身
[B]	クリック、入力、移動ができるブラウザーが必要	エージェント機能付きブラウザーがあればあなた、なければユーザー
[M]	手動：人による判断、認証情報、実際の金銭が必要	ユーザー。手順はあなたが準備

モードはデフォルトであり、固定の運命ではありません。ステップ 0-bis で確認した能力と組み合わせて判断してください。

• HTML、meta、JSON-LD、hreflang、canonical、テキスト、既存リンクに関する項目 → [A]。利用可能なウェブ取得ツールであなたが実行します。
• HTTP ヘッダー（HSTS、CSP、キャッシュ、リダイレクトチェーン）、ステータスコード、TLS に関する項目 → シェルがない場合に限り [M]。シェルがあれば実行してください。昇格の一覧を参照してください。
• フィールドの Core Web Vitals と完全なクロール → いずれにしても外部ツールが必要です。 NON VERIFICATO とマークし、使用するツール（PageSpeed Insights、Screaming Frog、securityheaders.com）を示してください。
• Screaming Frog／Semrush のエクスポートや Lighthouse のレポートを渡された場合は、活用してください。そのファイルを使えば、[M] の項目の多くを [A] にできます。

実行していないツールの出力を、決して捏造しないでください。

フロー

QA sito, avanzamento:
[ ] 1. Contesto raccolto, sezioni applicabili filtrate, assunzioni scritte
[ ] 2. Raccolta prove: home + 5-10 pagine campione (una per template), robots.txt,
       sitemap, 404, pagine legali, eventuali export forniti dall'utente
[ ] 3. Esecuzione voci [A] sezione per sezione, annotando la prova per ciascuna
[ ] 4. GATE 1: test della prova su ogni esito emesso (vedi "I due gate di onestà")
[ ] 5. Voci [B]/[M]: non inventare l'esito, scrivi l'istruzione operativa per chi le farà
[ ] 6. Report: tabella per sezione + piano di intervento prioritizzato
[ ] 7. Checklist spuntata, generata dal report appena scritto (secondo file, vedi "Report")
[ ] 8. GATE 2: prima di consegnare (vedi "I due gate di onestà")

ステップ 2 のサンプリングは、量よりも重要です。テンプレートごとに1ページを選びます（ホーム、カテゴリ、商品／記事詳細、静的ページ、フォーム、チェックアウト、404、多言語サイトでは同じページを2つの言語で確認）。同じテンプレートのページを20件確認しても、情報は増えません。

結果と重大度

許可される結果：OK、KO、PARZIALE、N/A、NON VERIFICATO（理由を付記）。

KO の重大度：

• BLOCCANTE：公開できません／24 時間以内に解決する必要があります。サイトや重要ページにアクセスできない、ステージング環境がインデックス可能、チェックアウトやフォームが機能しない、HTTPS がない、または証明書の期限が切れている、個人データが露出している、同意なしで非技術系 Cookie を使用している、バックアップが存在しない場合です。
• ALTA：トラフィック、コンバージョン、コンプライアンス、セキュリティに直接影響します。公開前または現在のスプリント中に解決してください。
• MEDIA：問題を引き起こすことなく、品質やパフォーマンスを低下させます。次のサイクルで対応します。
• BASSA：仕上げ、技術的負債、あると望ましい改善です。

チェックリストに示されている重大度はデフォルト値です。状況に応じて引き上げるか引き下げ、理由を記載してください。装飾用アイコンの alt がない場合と、カートボタンの alt がない場合は同じではありません。

2 つの誠実性ゲート

推奨事項ではなく、完了条件です。

証拠テスト（ゲート 1）。 ある項目を OK または KO にできるのは、「証拠」欄に次のいずれかを今すぐ貼り付けられる場合に限ります。正確な URL と観察した値、実行したコマンドの出力、ユーザーのファイル名と読み取った箇所。証拠が言い換え、推論、または記憶に基づくものであれば、結果は NON VERIFICATO です。行の注記が結果と矛盾する場合は、注記を優先します。 必須の出力：レポートの付録に次の 1 行を記載します。Gate 1: X voci riviste, Y declassate。監査範囲が広いにもかかわらず Y = 0 の場合は、正しいと判断しやすい項目、つまり 1 ページだけで確認した項目や、スタックから推定した項目を再確認してください。すべて問題なければ、Y = 0 も有効な結果です。

ゲート 2（提出前）。 すべての BLOCCANTE に引用可能な証拠と担当者を明記した対応策があること。すべての OK が観察に基づいていること。すべての N/A に理由があること。サマリーテーブルの数値は推定ではなく、実際に数えたものであり、対応計画と一致していること。

チェック済みのチェックリストを作成した場合、ゲートには整合性を確認する 3 つのチェックが含まれます。いずれも数を数えるだけで 1 分で完了し、食い違う 2 つの文書を防ぐ唯一の手段です。

1. [x] の数が、サマリーテーブルの OK の数と正確に一致していること。
2. ファイルの行数が、冒頭で宣言した対象範囲内の項目数と正確に一致していること。
3. 空欄のセルに、理由が併記されていないものがないこと。

確認結果が一致しない場合、誤りがあるのはチェック済みのチェックリストです。レポートに合わせて修正するのではなく、レポートから再生成してください。

よくある合理化と必須の対応

考えていること	対応
「WordPress/Shopify なら通常は備わっている」	NON VERIFICATO。通常そうであることは、観察した事実ではありません。
「別のページで見たので、同じはず」	PARZIALE とし、実際に確認したページのみ列挙します。
「ファイル名に 200×200 と書いてある」	NON VERIFICATO。ファイル名は寸法の測定値ではありません。
「クライアントから動作すると聞いた」	NON VERIFICATO (dichiarato dal cliente)。
「NON VERIFICATO が 60 件もあるレポートは見栄えが悪い」	そのまま提出します。
「ユーザーは急いでいる」	要約は短くできますが、結果は変えません。

ユーザーから NON VERIFICATO を削除するよう求められた場合は、拒否し、これが文書の有効範囲を示すものであると説明してください。付録に移動することはできますが、削除してはいけません。

レポート

assets/report-template.mdを使用します。形式より優先するルール：

• レポートは顧客が読みます。短い文を使い、顧客自身の言葉に合わせます。タグ、モード、ゲートは付録にのみ記載します。段落あたりの長いダッシュは最大1つです。
• KOには必ず証拠を添えます。正確なURL、コード行、スクリーンショット、測定値を示します。URLのない「メタディスクリプションがありません」は指摘ではなく、単なる意見です。
• KOには問題だけでなく対応策も添えます。何をするか、どこで行うか、誰が担当するか（開発／SEO／法務／顧客）、おおよその作業量を記載します。
• レポートの冒頭には、日付、テストした環境、検証しなかった内容とその理由を記載します。このセクションは最初に書き、最後に付け足してはいけません。その他の背景情報（サイトの種類、機能、対象範囲、プロモーション、ゲート）は最後の付録に記載します。
• 対応計画は重大度、次に影響度と作業量の比率の順に並べ、1つの表にまとめます。実際に読まれるのはこのページだけです。

チェック済みチェックリスト（必ず2つ目のファイルとして作成）

レポートに加えて、assets/checklist-esiti.mdを使用し、checklist-esiti-{{sito}}.mdを納品します。対象範囲内の項目をセクションごとにまとめ、結果がOKの項目だけにチェックを入れます。

最後に、完成したレポートをもとに、項目ごとに記入します。これはレポートの表示形式であり、2回目の検証ではありません。レポートに記載されていない結果を含めてはいけません。また、Gate 1を通過した判断を見直す機会でもありません。

チェックのない項目には、理由をその横に記載します。KOには重大度、PARZIALE、N/A、または不足しているツールを添えたNON VERIFICATOを記入します。顧客が最初に開くのはこのファイルであり、「緑＝完了、空欄＝問題あり」と受け取ります。理由を示さなければ、作業の有効範囲を示すNON VERIFICATOが、すべて顧客への非難のように見えてしまいます。

チケット、担当割り当て、進捗の時系列管理などでシートを使う必要がある場合は、同じ内容を.csvまたは.xlsxにもエクスポートします。1項目につき1行にします。

誤検知を避ける

指摘する前に、次のようなケースに当てはまらないか確認します。

• 非公開エリア、フィルター、カート、検索結果に意図的に設定されたnoindexやDisallow。
• 重複コンテンツのように見えても、正しいcanonicalが設定されているトラッキングパラメーター。
• 実際には意図した正規化（www、末尾のスラッシュ、言語）である「誤った」リダイレクト。
• オリジンとは異なるヘッダーを返すCDNやサードパーティーサービス。
• 自動アクセシビリティ検査のKOは、WCAG違反が確認されたことを意味しません。自動ツールが検出するのは実際の問題の約3分の1で、誤検知も発生します。指摘事項は報告しますが、適合性について断定してはいけません。
• 法令への準拠（GDPR、EAA、消費者法典）を決して断定してはいけません。不足している点や兆候は指摘できますが、準拠性の判断は法務担当者が行います。この点をレポートに明記してください。

チェックリストのメンテナンス

reference/checklist.mdは古くなることがあります。指標、義務、ツールは変化します。作業中に項目が古くなっている、または重要な項目が抜けていると分かった場合は、黙って修正するのではなく、回答の「チェックリスト更新の提案」に記載してください。レポートには含めません。これは顧客向けではなく、スキル向けの情報です。