AIでホームページができた。その「完成」で見落としやすい技術的な確認点
「うちのお店のホームページを作って」
ClaudeやCodexなどのAIにそう頼むと、写真や紹介文、メニュー、お問い合わせフォームまでそろったページを作れます。利用環境や権限によっては、インターネット上への公開まで進められます。
スマートフォンでもきれいに表示されれば、「ホームページが完成した」と感じるでしょう。
ただし、見た目が完成していることと、技術的な確認が済んでいることは別です。
検索エンジンにどう認識されるか。フォームから送った内容は届くか。アクセス解析は正しく動くか。秘密情報が公開されていないか。
こうしたことは、画面を眺めるだけでは判断できません。
AIを使ってホームページを作るときに、公開前後で確認したい技術的なポイントを紹介します。
「作って」と頼んだ範囲に、何が含まれているか
AIがどこまで作業するかは、依頼内容、利用するツール、接続先のサービス、操作権限などによって変わります。
ページのコードを作るだけの場合もあれば、サーバーへの公開や外部サービスの設定まで進められる場合もあります。
そのため、「AIにはSEOやセキュリティの対応ができない」と一括りにはできません。一方で、「ホームページを作って」と頼めば、必要な設定や検証がすべて済むと考えることもできません。
特に、初めて作る人にとって難しいのは、知らない項目は、AIへの依頼にも完成後の確認にも入れにくいことです。
例えば、「canonical」「HTTPステータスコード」「サーバーサイドバリデーション」という言葉を知らなければ、それらが適切かを尋ねる機会もないかもしれません。
これは人が制作する場合にも共通する問題です。AIで短時間に見栄えのよいページを作れるからこそ、表示以外の確認を意識しておく必要があります。
1．検索に出してよい設定になっているか
URLを入力してページを開けても、Googleの検索対象に登録されているとは限りません。
最初に確認したいのが、検索への公開に関わる設定です。
noindexとrobots.txt
noindexは、検索エンジンにページをインデックス登録させないための指定です。制作中のページに付けた設定が、本番にも残っていないかを確認します。
この指定はHTML内だけでなく、HTTPレスポンスヘッダーのX-Robots-Tagに入ることもあります。
また、robots.txtはクローラーのアクセスを制御するものです。noindexとは役割が異なり、クロールを禁止すれば確実に検索結果から消える、という関係ではありません。Googleのnoindex解説
Search Consoleとサイトマップ
Google Search Consoleは、Googleがサイトをどう認識しているか、インデックス登録に問題がないかを確認するために役立ちます。
サイトマップは、検索エンジンにページの存在を伝える手助けになります。
ただし、Search Consoleへの登録は検索掲載の必須条件ではなく、サイトマップを送信してもインデックス登録は保証されません。 設定することに加え、公開後の状態を見ることが大切です。Search Consoleの概要、サイトマップについて
2．画面の表示と、裏側の情報が一致しているか
ブラウザに見える内容のほかに、検索エンジンや外部サービスが読み取る情報もあります。
canonicalとページごとのメタ情報
canonicalは、重複・類似するURLの中で、正規ページとして扱ってほしいURLを示すものです。
これがテスト用ドメインを指していたり、すべてのページでトップページを指していたりしないかを確認します。ページごとのタイトルや説明文も、内容に合っている必要があります。Googleの正規URL解説
HTTPステータスコード
「ページがありません」と画面に表示していても、サーバーが正常を示す200を返している場合があります。
このような状態は「soft 404」の原因になります。存在しないページでは適切な応答を返し、移転したページでは必要に応じてリダイレクトするなど、画面とサーバーの応答を合わせる必要があります。GoogleのJavaScript SEO解説
JavaScriptレンダリングとOGP
JavaScriptで本文を表示するサイトでは、クローラーが必要な内容を取得できるかも確認します。GoogleはJavaScriptを処理できますが、すべてのボットが同様に実行できるわけではありません。
SSRやSSGは、そのために検討される技術です。ただし、すでに本文がHTMLに含まれるサイトに、名前だけを理由として追加するものではありません。GoogleのJavaScript SEO解説
XやLINEなどで共有した際の画像・タイトルに関わるOGPも、本文とは別の設定です。サイト内では正常でも、共有すると画像が出ない、といった問題が起こり得ます。Open Graph仕様
3．構造化データは、内容に合っているか
構造化データは、店舗、記事、商品などの情報を、機械が理解しやすい形式で伝えるためのものです。
例えば店舗なら、住所や営業時間などを記述できます。
ただし、構造化データに書いた内容は、ページ上の情報と一致している必要があります。追加すれば必ずリッチリザルトが表示されるわけでもありません。Googleの店舗向け構造化データ解説
また、GoogleのAIによる概要やAIモードへの対応については、専用の特殊なマークアップやAI向けファイルが必須とされているわけではありません。従来のSEOの基本が引き続き重要です。GoogleのAI検索向けガイド
「SEO対応済み」「AI検索対策済み」という説明だけでなく、何を設定し、何を検証したのかを確認しましょう。
4．表示の速さと、操作のしやすさを確認したか
自分のパソコンで快適に開けても、スマートフォンや通信環境が変わると、使い勝手が違うことがあります。
確認の目安になるのが、Core Web Vitalsです。
- LCP：主要な画像や文章が表示されるまでの時間
- INP：操作に対する反応の速さ
- CLS：読み込み中に起きるレイアウトのずれ
大きな画像、重いJavaScript、複雑なアニメーションなどは、表示や操作に影響します。画像の容量・配信サイズや読み込み方法も含めて確認します。GoogleのWeb Vitals解説
アクセシビリティも、見た目だけでは確認しきれません。
入力欄に適切なラベルが付いているか。キーボードで操作できるか。入力エラーの内容が伝わるか。見た目がボタンでも、操作できる要素として実装されているか。
「スマホ用のレイアウトがある」ことと、「さまざまな利用者が操作できる」ことは、別の確認です。 W3Cのフォームガイド
5．GA4は、設置だけで終わっていないか
GA4のコードを入れても、必要なデータを正しく取得できているとは限りません。
例えば、画面を切り替えてもページ全体を読み直さないSPAでは、ページビューの計測方法を確認する必要があります。設定によって、画面の切り替えを取りこぼしたり、二重に記録したりする可能性があります。GoogleのSPA計測ガイド
問い合わせも、「送信ボタンを押した」と「正常に送信できた」を区別して計測したいところです。
実際にサイトを操作し、DebugViewなどで想定したイベントが届いているかを確認します。GoogleのDebugView解説
また、フォームに入力されたメールアドレスや問い合わせ本文などを、解析データへ混ぜて送らない設計も必要です。Googleの個人情報送信防止ガイド
6．フォームは、見た目・送信処理・メール到着まで確認したか
フォームの入力欄があることと、問い合わせを受け付けられることは別です。
公開したサイトから実際にテストし、送信処理が成功するか、担当者の受信箱に届くか、自動返信が正しく届くかを確認します。
さらに、技術面では次の確認があります。
- サーバーサイドバリデーション：ブラウザ上の入力チェックを迂回されても、サーバー側で不適切な入力を拒否できるか
- レート制限・スパム対策：フォームやメール送信APIの大量利用を抑える仕組みがあるか
- XSS対策：入力内容を管理画面などに表示する場合、悪意あるコードが実行されないように処理しているか
入力チェックは、ブラウザ側だけでは十分ではありません。また、入力を検証することと、安全に画面へ表示することも別の対策です。OWASPの入力検証ガイド、XSS対策ガイド
メールについては、SPF・DKIM・DMARCなど、送信元ドメインの認証設定も確認対象です。送信処理が成功していても、受信側で拒否や迷惑メール判定が起きる可能性があります。Googleのメール送信者向けガイド
7．HTTPS以外の安全性も確認したか
HTTPSは通信を保護するための仕組みです。フォームの処理、保存した情報、管理画面のアクセス権限まで、すべてを守るものではありません。OWASPのTLS解説
例えば、外部サービスの秘密鍵を、ブラウザに配信するJavaScriptへ含めていないかを確認します。
「環境変数に入れたから安全」とも限りません。開発環境によっては、公開用の環境変数がビルド時に配信コードへ組み込まれます。公開を前提とした識別子と、秘密にすべき認証情報を区別する必要があります。OWASPの秘密情報管理ガイド
会員機能や管理画面がある場合は、認証と認可も重要です。
ログインできることが「認証」、その人が情報を閲覧・変更してよいかを判断することが「認可」です。管理ボタンを画面から隠すだけでなく、サーバー側でも権限を確認する必要があります。OWASPの認可ガイド
CSPなどのセキュリティヘッダーも、サイトの構成に応じて検討する項目です。OWASPのHTTPヘッダーガイド
必要な対策は、案内だけのサイトと、個人情報・予約・決済を扱うサイトでは異なります。
8．更新や障害に対応できる状態か
公開時に動いていても、その後ずっと同じ状態で使えるとは限りません。
利用しているライブラリに脆弱性が見つかったとき、更新できるか。変更によって不具合が出たとき、以前の状態へ戻せるか。データを保存しているなら、バックアップから復元できるかを確認します。OWASPの依存関係管理ガイド
キャッシュの設定も関わります。更新後も古いページが表示され続けないか、会員向けの情報を共有キャッシュへ保存していないかなど、配信内容に合った制御が必要です。MDNのキャッシュ解説
コードの保管先、デプロイ方法、設定の管理場所と合わせて、修正や復旧の方法も残しておきましょう。
AIへの依頼に「確認して、結果を示す」まで含める
これらの専門用語を、すべて覚えてから制作を始める必要はありません。
ただ、「ホームページを作って」という依頼の後に、技術的な点検を追加することはできます。
例えば、次のような頼み方です。
このサイトを本番公開する前に、技術面を点検してください。
検索への公開設定、canonical、HTTPステータス、レンダリング、構造化データ、OGP、表示性能、アクセシビリティ、GA4、フォーム、メール認証、秘密情報、アクセス権限、運用・復旧について、サイトの機能に応じて確認してください。
各項目を「確認済み」「未対応」「確認できない」「対象外」に分け、確認方法と結果、追加で必要な権限や作業を示してください。
そのうえで、AIの「完了しました」という返答だけで判断せず、公開URLの応答、Search Console、GA4のイベント、受信したテストメールなど、実際の結果を確認します。
ホームページの完成条件に、「ページが表示できた」に加えて、「必要な技術的確認を終えた」まで含める。
AIで制作を進めるときに、最初から決めておきたいことです。
SENTICでは、Web制作と、業務でのAI活用の仕組みづくりをお手伝いしています。