制作中のサイトを検索に出さずにクライアントへ見せる方法｜アクセス制限とnoindexの役割分担と、公開時の解除手順
制作中のサイトを検索に出さずにクライアントへ見せる方法｜アクセス制限とnoindexの役割分担と、公開時の解除手順
制作途中のサイトをクライアントに見てもらいたい。でも検索結果には絶対に出したくない。この2つを同時に満たす正しいやり方は、アクセス制限とnoindexを両方かけることです。どちらか一方では足りません。
先に結論を表で示します。
| やること | 使うもの | 何を防ぐか |
|---|---|---|
| 人が開けないようにする | Basic認証・IP制限 | URLが漏れても第三者が中を見られない |
| 検索結果に載らないようにする | noindexメタタグ | 万一クローラーが到達しても検索結果に出ない |
| クローラーの巡回を減らす | robots.txt | あくまで補助。単独では隠せない |
robots.txtだけで塞ぐのは、この用途では不正解です。robots.txtは「入らないでください」という紳士協定であって、アクセス制限ではありません。URLを知っている人は普通に開けますし、しかも遮断してしまうとnoindexが読まれなくなるため、URLだけが検索結果に残るという逆の事故が起こり得ます。
制作中サイトで本当に必要なのは、人にもクローラーにも「届かせない」ことです。だからアクセス制限が主役で、noindexはその保険という役割分担になります。
なぜ二重にかけるのか
「Basic認証をかけたのだからnoindexは不要では」と思うかもしれません。実務では不要になりません。理由は3つあります。
1つ目は、認証が意図どおりに効いていない可能性があるからです。 後述しますが、設定を書いたのに一部のURLだけ素通りする、という現象が現実に起こります。認証が効いているという前提だけで運用すると、その一部が外に出ます。
2つ目は、認証を解除する瞬間があるからです。 公開当日はBasic認証を外します。このときnoindexの解除手順が別に用意されていないと、「認証を外した瞬間、まだ調整中のページも含めて全部がクロール対象になる」という状態が生まれます。逆に、noindexを先に外して認証だけ残す運用にしておけば、公開作業を段階的に進められます。
3つ目は、確認用URLがどこかに漏れるからです。 確認用URLはメッセージやメールでやり取りされ、社内チャットにも貼られます。そこから外部サービスのプレビュー機能などを経由してクローラーに拾われる経路は、想定しきれません。二重にしておくと、片方が崩れてももう片方が残ります。
「認証をかけた」と「認証が効いている」は別のこと
ここが最も事故になりやすい場所です。
サーバーに設定ファイルを置いて認証をかけたあと、その効きを確認するとき、管理画面のログインURLだけを開いて「認証ダイアログが出たので大丈夫」と判断してしまうことがあります。これは危険です。
実際に、認証を設定した直後のサイトを複数URLで測ると、次のような結果になることがあります。
/wp-login.php → 401（認証がかかっている）
/ → 200（誰でも読める）トップページだけが公開されたまま、という状態です。これはサーバー構成に原因があります。レンタルサーバーの中には、表示を速くするために本体の前段にページキャッシュを置いている環境があります。キャッシュに保存済みのページは、本体の設定ファイルを読まずにそのまま返るため、そこに書いた認証が評価されません。
そしてトップページは、最もキャッシュされやすいページです。つまりいちばん見られたくないページが、いちばん素通りしやすいという構造になっています。
切り分けは簡単で、キャッシュに載っていないURLを叩けば判定できます。
/?nocache=12345 → 401
/does-not-exist-xxx → 401これで401が返るなら、「認証設定そのものは正しいが、キャッシュ経由だけ素通りしている」と確定できます。この場合の対処は、制作期間中だけサーバー側のキャッシュを無効にすることです。
このとき大事なのが、元のキャッシュ設定を消さずにコメントとして残し、「納品時に戻す」と書き添えておくことです。消してしまうと、公開後も高速化の恩恵を失ったまま誰も気づきません。制作中の一時設定は、必ず「戻し方」とセットで残します。
確認は必ず複数URLで測る
以上を踏まえて、認証の確認は最低限これだけのURLで行います。
- トップページ（最優先。最もキャッシュされやすい）
- 管理画面のログインURL
- 管理画面のディレクトリ
- 主要な下層ページ（会社概要・料金など、実際に作ったページ)
- 存在しないパス
- CSS・画像などの静的ファイル
1つのURLで確認して報告すると、「確認したつもり」が成立してしまいます。制作中サイトの外部流出はクライアントの信用に直結するので、ここは手数を惜しまない場所です。
実際の運用では、認証を入れた直後に主要URLをまとめて叩き、全部が401であることを一覧で確認してから「塞げました」と報告する形にしています。1ページずつ手で開く方式は、ページが10を超えると必ず抜けます。
設定ファイルは「上書き」ではなく「追記」する
WordPressで制作している場合、もう1つ落とし穴があります。
WordPressはパーマリンク（URLの形）を成立させるための記述を、サーバーの設定ファイルに自動で書き込んでいます。認証の記述をここに書くとき、ファイルを丸ごと置き換えてしまうと、その自動生成部分が消えます。結果、トップページ以外の全ページが404になります。
正しい手順はこうです。
- 既存の設定ファイルをダウンロードして手元に保存する
- 既存の記述を保持したまま、認証の記述を先頭に追記する
- アップロード後、トップページと下層ページの両方が正しく応答するか実測する
3を省くと、「認証はかかったがサイトが壊れている」状態に気づくのが、クライアントが見た瞬間になります。設定ファイルを触ったら必ずページを開いて確かめる、という順序を固定してください。
認証をかけられない構成のときの代替策
すべてのサイトにBasic認証をかけられるわけではありません。
たとえば、編集用のWordPressを裏側に置き、表示側は静的サイトとして書き出す構成（ヘッドレス構成）では、裏側に認証をかけるとサイトの書き出し処理自体が失敗します。書き出し処理はWordPressのAPIから記事データを取りに行くため、そこに認証が挟まると取得できなくなるからです。
この場合の代替策は次の組み合わせです。
- WordPress側の設定で検索エンジンの巡回を拒否する（noindexが全ページに配信される状態にする）
- サーバーに物理ファイルとしてのrobots.txtを置く
2つ目の「物理ファイル」という点が実務的なポイントです。WordPressは実体のないrobots.txtを動的に生成しますが、プラグインや設定の影響を受けやすく、意図どおりの内容が出ているとは限りません。実ファイルを置いておけば、そちらが確実に配信されます。
なお、この構成でもURLを知っている人は中を見られます。あくまで「検索に出さない」ための措置であって、「見せない」ための措置ではありません。認証をかけられない構成では、確認用URLの取り扱いに注意が必要だと、あらかじめクライアントにも伝えておくのが安全です。
一部だけ公開したい場合の注意
サイトの一部（採用ページだけなど）を先に公開し、残りは隠したいケースもあります。このとき「robots.txtで全部を遮断し、公開したいページだけ許可する」という設定が必要になります。
一見すると遠回りですが、これには理由があります。robots.txtで丸ごと遮断すると、クローラーはHTMLを読みに来ないため、そこに書いたnoindexが永久に読まれません。読まれないと「載せるな」という指示が届かず、URLだけが検索結果に残ることがあります。公開動線に載っているページは、クロールさせたうえでnoindexを読ませる方が、結果的に確実に消えます。
塞ぐことと消すことは別だ、という原則はここでも同じです。
公開時の解除手順をチェックリストにする
制作中の措置は、必ず解除がセットになります。そして解除漏れは、事故として最も多い部類です。特にnoindexの解除を忘れると、公開したのに検索に一切出ないという状態が数週間続きます。しかも見た目は正常なので、誰も気づきません。
そこで、案件を始めた時点で解除項目を一覧にしておきます。実際に使っているチェックリストがこれです。
- [ ] Basic認証を解除する
- [ ] サーバー側のキャッシュ設定を元に戻す（制作中に無効化した分）
- [ ] noindexを解除する
- [ ] 管理画面とFTPのパスワードを別々の値に変更する
- [ ] 構造化データの検証結果を取得する
- [ ] サーチコンソールに登録し、読み取られているか確認する
- [ ] 更新マニュアルを納品する
この2つは別々のスイッチだと考えてください。認証を外す＝人が見られる状態になる、noindexを外す＝検索に載り得る状態になる。片方だけ外した中途半端な状態を放置しないことが要点です。
実務上いちばん多いのは、認証だけ外して公開した気になり、noindexが残るパターンです。サイトは普通に見えていて、クライアントも見られるので、誰も異常だと思いません。それでいて検索には出ません。だから最終確認が終わったタイミングで両方をまとめて外し、その場でHTMLを見て両方が外れたことを確かめる、という形にしておくのが確実です。
パスワードの変更が入っているのは、制作中は運用の都合で管理画面とFTPに同じパスワードを設定することがあるためです。制作中は守るべき中身がないので許容できますが、公開後は別です。ここも「制作中の一時措置」の1つとして、解除項目に並べておきます。
解除できたかの確認方法
解除したあとは、実際に配信されているHTMLを見て確かめます。ここで1つ、地味ですが確実に引っかかる罠があります。
WordPressが出力するnoindexのタグは、シングルクォートで書かれています。
<meta name='robots' content='noindex, nofollow' />ダブルクォート前提で検索すると1件もヒットせず、「noindexは消えている」と誤った結論が出ます。逆に、消えていないのに消えたと判断すればそのまま公開してしまいます。タグの有無を確認するときは、クォートの種類に依存しない書き方で調べてください。
同じ理屈で、解除の確認は「管理画面の設定が変わったか」ではなく、公開されているHTMLに何が入っているかで判断します。設定画面上はチェックが外れているのに、キャッシュされた古いHTMLが配信され続けている、というケースがあるためです。設定を変えたら、キャッシュを消したうえで実際のページを取得して確認します。
この段取りが効くのは、公開前だけ
制作中にサイトを塞ぐ話をしてきましたが、この期間にはもう1つ別の価値があります。公開前は、URLの構造を無害に変えられる唯一の時期だということです。
たとえば、記事や事例ページのURLが自動生成で長い日本語文字列になってしまうことがあります。これは検索エンジンにとっても、AIによる引用にとっても不利です。公開後に直すと、旧URLから新URLへの転送設定が必要になり、設定が1つ増えます。公開前なら、ただ書き換えるだけで済みます。
同様に、トップページの指定、タイトルの形式、パンくずの構造といった「後から変えると転送が必要になるもの」は、塞いでいるうちに固めておくのが得です。
つまり、制作中サイトを正しく塞ぐことは、単に隠すための作業ではありません。外に影響を出さずに構造を直せる期間をつくるための作業です。ここを雑にすると、その期間を失うことになります。
まとめ
制作中のサイトを検索に出さずにクライアントへ見せるための要点を、もう一度整理します。
- アクセス制限とnoindexを両方かける。robots.txt単独では隠せない
- 認証をかけたら複数URLで実測する。トップページを真っ先に確認する
- サーバーのキャッシュ層は認証を素通りすることがある。キャッシュに載っていないURLで切り分ける
- 設定ファイルは上書きせず追記し、変更後は下層ページまで開いて確かめる
- 認証をかけられない構成では、noindexと物理robots.txtで代替する。ただしURLを知る人は見られる前提で扱う
- 解除項目を案件開始時にチェックリスト化する。noindexの解除忘れは公開後しばらく気づけない
- 解除の確認は設定画面ではなく、配信されているHTMLの実物で行う
制作中サイトの流出も、公開後のnoindex解除漏れも、原因は同じです。「設定した」で終わらせて、「効いているか」「戻したか」を測っていないことです。設定を1つ入れたら実測を1つ、一時的な措置を1つ入れたら解除項目を1つ。この対応関係を崩さなければ、どちらの事故も起きません。