INSIGHT

公開前のWebサイトを、関係者だけで確認するための限定公開チェックリスト

この記事の結論。制作中のWebサイトを、一般公開の前に関係者と確認するときのために、URL・閲覧権限・独自ドメイン・最終確認を分けて進める限定公開のチェックリストです。

公開: 2026年8月23日
著者: Web Director for SEO & Content

対象読者：Web制作を初めて学ぶ人。高校生でも確認の順番が分かるよう、「URL」「見られる条件」「ページの中身」を分けて説明します。

公開前のサイトを、リンク・鍵・目視の順に確認するイラスト

制作途中のサイトを確認してもらいたい。でも、検索やURLの共有だけで誰でも見られる状態にはしたくない。そんなときは、内容・URL・閲覧できる人の条件を一度に公開しないよう、段階を分けます。

今回、自社の静的サイト1件で、認証を付けた仮ページと独自サブドメインを使う限定公開の準備を行いました。この記事は、その作業をそのまま技術日記にせず、Web担当者や事業者が公開前確認に使えるチェックリストへ整理したものです。

結論：確認は「URL」「閲覧条件」「表示内容」を分ける

限定公開で大切なのは、URLを知っているかどうかだけに頼らないことです。少なくとも次の3つを別々に確認します。

確認するもの	何を見るか	失敗すると起きること
URL	仮URLと公開予定の独自URLが、意図したサイトを向いているか	別のサイトや古いページを見てしまう
閲覧条件	認証なし・誤った認証・正しい認証で、結果が分かれるか	URLを知るだけで制作途中の内容を見られる
表示内容	限定公開中に、本体記事や問い合わせ導線を出していないか	確認前の情報が一般に見える

制作中のサイト
    ↓
1. 仮URLで認証の動きを確認する
    ↓
2. 公開予定のサブドメインを接続する
    ↓
3. 実際のURLで認証・表示・導線を確認する
    ↓
本人が公開するか判断する

1. 先に「誰に見せるか」を言葉にする

今回採ったのは、共通のIDとパスワードを知っている人だけが入れる方式です。これは、URLだけを隠すより一段強い確認方法です。

ただし、この方式はメールアドレス単位で本人を確認する仕組みではありません。同じ認証情報を知る人は入れます。個人や会社ごとに閲覧者を区別したい、誰が閲覧したかを管理したい場合は、個人単位の認証を選ぶ必要があります。

最初に「自分だけの確認」「少人数の社内確認」「顧客ごとの確認」のどれなのかを決めると、必要な仕組みを選びやすくなります。

2. いきなり本体を出さず、仮ページで認証を確かめる

認証の設定が正しいかを確かめる段階では、完成した記事を配信しません。代わりに、公開準備中であることだけを示す仮ページを出します。

この順番にすると、認証設定に漏れがあった場合でも、未確認の記事本文や画像が出る範囲を小さくできます。

確認するのは、次の3通りです。

認証情報を入れない：ページ内容が見えない
誤った認証情報を入れる：ページ内容が見えない
正しい認証情報を入れる：仮ページだけが表示される

認証情報そのものは、記事・Gitの履歴・スクリーンショット・チャットに残しません。サービス側の暗号化されたシークレットとして扱い、共有が必要になったら別の安全な経路で本人が管理します。

3. 独自サブドメインは、仮URLの確認後につなぐ

配信サービスから最初に渡される仮URLで認証を確認した後、公開予定の独自サブドメインをつなぎます。

今回の構成では、DNS管理側に次のようなCNAMEレコードを追加しました。

項目	入れるもの
名前	公開予定URLの先頭部分（例：`insights`）
種別	`CNAME`
接続先	配信サービスが指定するホスト名

設定後は、配信サービス側で「有効」とSSLの有効化を確認します。DNSの反映には時間がかかることがあるため、追加直後に表示が変わらなくても、設定を重ねて変更する前に反映状況を待つことが大切です。

4. 最後は、実際に使うURLをシークレットウィンドウで確認する

設定画面が「有効」になっても、実際の閲覧画面が期待どおりとは限りません。ログイン状態やキャッシュの影響を減らすため、ブラウザのシークレットウィンドウで公開予定URLを開きます。

ここでも確認するのは3通りです。

認証情報を入れない状態で、本文が表示されない
誤った認証情報では、本文が表示されない
正しい認証情報で、想定したページだけが表示される

本体サイトに切り替えた後は、さらにCONTACTなど外部リンクが意図した既存ページへ遷移するかを確認します。認証だけが通っても、問い合わせ導線まで正しくなければ公開前確認は完了ではありません。

この手順で確かめられたこと、まだ確かめていないこと

このチェックリストは、2026年8月23日に自社サイト1件で行った限定公開の準備を基にしています。確認済みと、これから最終確認することを分けています。

項目	状態	この時点で分かること
仮URLで認証画面が出ること	確認済み	URLだけでは仮ページを見られない状態を確認した
正しい認証後に仮ページだけを出すこと	確認済み	本体記事を出さずに認証の動きを確認できた
独自サブドメインの有効化とSSL表示	確認済み	DNS接続とHTTPSの準備が完了した表示を確認した
独自サブドメインでの認証・表示の最終確認	確認前	公開予定URLをシークレットウィンドウで確認する必要がある
本体記事への切替とCONTACT導線	確認前	認証を維持したまま、記事表示と外部リンクを確認する必要がある

このため、「どのサイトでも完全に限定公開できる方法」とは言いません。自社の1件で、どこまで確認できたかを残した実務記録です。

公開前のチェックリスト

[ ] 認証情報・管理画面のスクリーンショット・顧客情報を、記事や共有資料に入れていない
[ ] 仮URLで、認証なし／誤った認証／正しい認証の3通りを確認した
[ ] 認証設定に漏れがあっても本体記事が出ない、仮ページの段階を設けた
[ ] 独自サブドメインのDNS設定が、配信サービスの案内と一致している
[ ] 独自サブドメインが有効になり、SSLが有効と表示されている
[ ] シークレットウィンドウで、実際に使うURLを確認した
[ ] 本体を出す前に、CONTACTなど外部リンクの遷移先を確認した
[ ] 共通パスワード方式を、個人単位の本人確認だと説明していない
[ ] 公開直前に、配信サービスとDNSサービスの公式手順を再確認した

よくある質問

Q. 共通のIDとパスワードで十分ですか。個人単位の認証が必要なのはどんなときですか？

A. 次の3つのどれかに当たるときは、共通の認証では足りません。

相手ごとに見せる内容が違う。 A社にはA社の案だけを見せたい場合、同じ認証で入れる時点で分離できていません
誰がいつ見たかを記録する必要がある。 検収や合意の証跡を残すなら、個人単位でないと記録になりません
契約で閲覧者が限定されている。 NDAなどで閲覧者を特定する義務があるとき、共通の認証情報は「知っている人は誰でも入れる」ため要件を満たしません

どれにも当たらない社内確認や、自分の最終確認なら共通の認証で足ります。 迷ったら「この認証情報が第三者に渡ったとき、何が困るか」を1つ書き出してみると判断できます。困ることが具体的に出てくるなら、個人単位に上げます。

Q. 認証をかけておけば、検索結果に出てしまう心配はありませんか？

A. 本文が検索結果に出ることは防げます。 クローラーも認証を通れないため、中身を取得できません。

ただし、防げないことが2つあります。

URLそのものが知られること。 誰かがどこかにリンクを貼れば、URLは外部に存在します。認証は中身を守るもので、URLの存在を隠すものではありません
公開に切り替えた瞬間の状態。 ここが実務でいちばん抜けます

2つ目を補足します。限定公開のあいだ、noindex を付けていても、クローラーは認証で弾かれるので noindex 自体を読んでいません。 つまり noindex は「効いている」のではなく「読まれていない」状態です。

問題は公開に切り替えたときで、認証を外した瞬間に noindex が残っていると、今度はそれが読まれて検索結果から除外されます。 限定公開の設定を外す作業と、noindex を外す作業は別物です。セットで確認してください。

Q. 認証情報を渡した相手が、外部に共有してしまう可能性は防げますか？

A. 技術的には防げません。 共通の認証情報を渡した時点で、その先は相手の運用に依存します。

代わりに、被害の範囲を時間で区切ります。

渡す前に期限を決める。 「今週の確認用」と伝え、確認が終わったら認証情報を変更します
公開前に必ず1回変更する。 制作中に渡した認証情報を、公開後もそのまま残さない
チャットに直接書かない。 履歴に残ると、期限を切っても回収できません

「漏れない前提」で設計せず、「漏れても期限で切れる」設計にします。

Q. DNSの反映を待つあいだ、何をすればいいですか？

A. 設定を重ねて変更しないことがいちばん大切です。 反映待ちと設定ミスは、待っている最中は見分けがつきません。ここで設定を触ると、後からどちらが原因か切り分けられなくなります。

待ち時間に進められるのは、DNSに依存しない確認です。

仮URLのほうで、認証の3通り（なし／誤り／正しい）をもう一度確認する
本体に切り替えたあとの確認手順を、先に書き出しておく
公開時に外す設定を一覧にしておく（認証、noindex、下書き表示の切り替えなど）

待ち時間に「外し忘れリスト」を作っておくと、公開当日の作業が確認だけで済みます。

Q. 公開後に、限定公開の設定を外し忘れると何が起きますか？

A. 外し忘れる対象によって、起きることが逆になります。

認証を外し忘れる：訪問者が認証画面に当たります。すぐ気づけます。困りますが、被害は限定的です
noindex を外し忘れる：ページは普通に見えます。誰も気づきません。 検索結果にだけ出てこない状態が続きます

危ないのは後者です。 見た目が正常なので、数週間経ってから「なぜか検索に出ない」と気づくことになります。

公開直後に見るのは、画面の表示ではなくページのソースです。noindex の記述が残っていないかを1回確認すれば済みます。

まとめ：公開に切り替える作業は、外す設定の一覧から作る

限定公開では、URL・閲覧条件・表示内容の3つを別々に確認する。URLを知られないことに頼らない
仮ページで認証を確かめてから本体を出す。 設定漏れがあっても、出る範囲を小さくできる
独自サブドメインは仮URLの確認後につなぐ。 反映待ちのあいだに設定を重ねて変更しない
最後はシークレットウィンドウで、実際に使うURLを確認する。 設定画面の「有効」表示は、閲覧結果の確認にならない
公開時にいちばん危ないのは noindex の外し忘れ。 見た目が正常なので気づけない。画面ではなくソースを見る
この記事は自社1件の実務記録で、どのサイトにも当てはまる方法ではない

この記事の情報について

出典: 本文中のリンクが出典です。
公開日: 2026年8月23日
更新方針: 出典元の公式情報が更新された場合に見直します。