AIで作ったサイトを公開する前のチェックリスト

AIでサイトを作ると、build が通り画面が映るだけで「できた」と錯覚しやすいです。公開後に「検索に出ない」「キーボードで動かない」「スマホで崩れる」が出ます。公開前に確認する項目をまとめます。

先に結論：公開前に確認する7領域

1. 検索・技術SEO
2. アクセシビリティ
3. 性能（CWV）
4. コンテンツ・事実
5. プライバシー・計測
6. 配信・同期
7. 運用・復旧

これらは BUILD ORBIT が各 Project で実際に回している品質ゲートを、一般化して並べたものです。

公開可否は4つのゲートで順に決める

チェック項目を一度に眺めるのではなく、失敗した場所で止めます。

1. 生成物：build後のHTML、404、metadata、sitemap、robots、assetが揃っている。
2. 反復検証：型、content schema、内部リンク、直接URL、アクセシビリティの自動チェックが通る。
3. ブラウザと人手：主要画面をキーボード、320px、200%拡大、no-JSで確認し、事実・表現・同意導線を人が読む。
4. 配信と復旧：dist/と納品物が一致し、本番反映を別工程に分け、直前版へ戻す手順がある。

このNoteのownerは「公開してよいかを決める順序」です。自動テスト、ブラウザ確認、人手レビューの担当分けはAIコーディングの品質ゲートで詳しく扱います。

1. 検索・技術SEO

• 各ページに一意な title（50–60文字目安）がある
• description がページごとに異なり、検索意図に合う
• canonical が自己参照になっている
• robots.txt と sitemap.xml が整合し、重要ページが含まれている
• 孤立ページ（内部リンクのないページ）がない
• OG / Twitter Card の画像とテキストがある
• 構造化データ（Article / Breadcrumb 等）が可視本文と一致する
• draft・noindex ページが本番に混ざっていない

GoogleのAIによる概要やAIモードを意識しても、専用のタグやファイルを足すことを公開条件にはしません。まず通常検索でクロール・インデックスされ、スニペットの対象になるHTMLか、ページの主題・見出し・内部リンク・構造化データが可視本文と一致しているかを確認します。AI向けの断片を量産するより、実際の判断材料と一次出典を読者に示します。

Google Search CentralのTechnical requirementsでは、Googlebotを遮断しないこと、HTTP 200で応答すること、index可能な本文があることを最低条件とし、条件を満たしてもindexは保証されないと説明しています（2026年9月1日確認）。

2. アクセシビリティ

• キーボードだけで全主要操作ができる
• focus が視認できる
• 見出し順が論理的（h1→h2→h3）
• 画像に alt がある（装飾は空値）
• 色だけで状態を示していない
• reduced motion を尊重している
• 320px と 390px で横スクロールしない
• 200% 拡大で利用できる
• no-JS でも本文と主要導線が読める

WCAG 2.2は、知覚可能・操作可能・理解可能・堅牢という原則の下に検証可能な達成基準を置いています（2026年9月1日確認）。BUILD ORBITはaxe-coreを自動確認に使い、キーボードや文脈の確認は人手に残します。

3. 性能（Core Web Vitals）

• LCP ≤ 2.5s（初期画像・本文の表示）
• INP ≤ 200ms（操作応答）
• CLS ≤ 0.1（レイアウト崩れ）
• 初期 JS が最小（動かす範囲を絞ったか）
• 画像の寸法指定と lazy loading
• 第三者スクリプトを最小に

web.devのCore Web Vitalsでは、LCP・INP・CLSをモバイルとデスクトップに分け、実ユーザーの75パーセンタイルで評価することを推奨しています（2026年9月1日確認）。ラボの一度きりのLighthouseと混同しないでください。

4. コンテンツ・事実

• 公開日・更新日が実態と一致する
• 出典（一次情報）が表示されている
• 架空の数値・レビュー・導入事例を使っていない
• タイトルが過剰に煽っていない
• 読後に次の行動が決められる

5. プライバシー・計測

• 計測は同意後にのみ送信（consent 前提）
• 入力値を外部へ送信しない設計を明記
• 個人情報を過剰に集めない

6. 配信・同期

• dist/ と実際の upload 先が一致する
• 不要なファイル（.map・シークレット）が含まれていない
• 404 ページが静的で存在する
• キャッシュヘッダが意図通り

BUILD ORBIT は prepare:upload と check:delivery で、build 成果と upload 成果の file count / SHA-256 パリティを確認しています。

公開判定を一行で記録する

チェックを通した事実だけでは、あとから「何を根拠に公開したか」を再現できません。対象route、主張、確認した生成物、判定、次の担当を一行に残します。

route=/notes/example/ | claim=本文と主要導線はJSなしで読める | evidence=dist/example/index.html + check:links | decision=PASS | next=手動FTP反映は未実施

PASSはローカルの生成物と品質ゲートを通ったという意味に限定し、公開サーバーの応答、Search Console、実ユーザーの指標まで確認したことを意味しません。FAILなら公開作業を止め、OBSERVEなら不確実性と再確認日を記録します。この境界を作ると、AIが生成した「完了しました」という文面を、検証可能な事実へ置き換えられます。

7. 運用・復旧

• 更新手順が誰でもできる
• Git で履歴が残る
• 本番反映は別の明示作業として切り離されている
• 破損時に前バージョンへ戻せる

Build Simulator で構成ごとのゲートを出す

Build Simulator に目的を入力すると、採用構成とともに「品質ゲート」の項目を出力します。公開前チェックのたたき台として使えます。結果はテキスト・Markdown・JSON でコピーでき、ブラウザ内だけで処理するため入力が外部へ送信されることはありません。

よくある見落とし

• build 成功＝公開可能、と見なす
• no-JS での表示を確認しない
• スマホ幅（320px）で試さない
• 計測タグを同意前に送る
• draft ページが本番に混ざる

次の行動

1. このリストを印刷・コピーして使う
2. 構成は Astro静的サイトを作る前に決める5つのこと で決める
3. Simulator で構成ごとのゲートを出す
4. 公開は別の明示作業として実行する