検索除外と非公開を混同しない。robots・閲覧権限・SNS配信を分ける設計

編集部の実務提案

1. 読める・検索に出る・外へ配信できるを分ける

記事がブラウザーで開けても、検索結果に出るとは限りません。反対に、検索から除外したページでも、URLを知る人が内容を読める状態はあり得ます。編集部の提案は、閲覧できる人、検索エンジンでの扱い、SNSなどへ転載してよい範囲を、別々の確認欄にすることです。画面に本文が見えたという一つの事実から、三つの判断をまとめて済ませないようにします。

たとえば架空の広報チームが、新しい解説記事を先に公開し、検索での告知は後日にするとします。この運用が承認されていても、社内向け資料まで同じ扱いにしてよいわけではありません。対象記事の識別子と公開先、承認された配信先をひも付け、全体設定と記事ごとの判断を区別します。

一次情報から

2. noindexは、検索結果での扱いを指示する

Googleの公式資料は、noindexを検索結果にページなどを表示しないための指示として説明しています。nofollowについては、そのページのリンクをたどらない指示と説明しています。[1] ここで扱うのは検索エンジンへの指定です。すべての閲覧者を認証する機能や、あらゆるクローラーへの強制的な遮断機能として読み替えません。

運用では、指示がサイト全体に入っているのか、特定の記事にだけ付いているのかも確認します。全ページ共通の検索設定と、誤りが見つかった記事を個別に保留する状態は、同じ目的とは限りません。ただし、検索設定を理由に保留を勝手に解除するのではなく、元の設定意図と記事の公開権限を確認してから配信条件を決めます。

出典：[1]

一次情報から

3. データを読める権限は、別の層で確かめる

Supabaseの公式資料は、テーブルへの操作を許す権限と、その操作をどの行へ適用するかを決めるポリシーを分けて説明しています。[2] これは同製品のPostgresを使う場合の仕組みです。検索結果から除外したことを、データベースでアクセスを制限した証拠にはしません。公開用の記事データと、問い合わせなどの非公開データも同じ条件で扱わないことが大切です。

引き継ぎでは、どの利用者・実行担当が、どの操作を、どのデータへ行える想定かを短い表にします。確認が失敗したら、検索用の設定や認証情報を変えて通す前に、対象と権限の対応を調べます。権限の変更は担当者の判断と承認に従い、調査のために秘密の値や利用者の本文を共有表へ貼り付けないようにします。

出典：[2]

編集部の実務提案

4. 自動配信には、公開済みである正の証拠を渡す

編集部の設計例では、配信候補へ記事ID、正規の公開URL、確認したタイトル、承認済み画像、出典の確認時刻、許可された投稿先を渡します。robotsの文字列だけで配信可否を決めず、正規の公開記録と実際のページを照合する構成です。ログイン画面や下書きが取得できたことを、記事公開の成功とは数えません。

一方で、個別記事に編集上の保留、非公開指定、権限不足がある場合は、その状態を維持します。サイト共通の検索設定について例外を設けるとしても、対象の媒体と公開記録を限定し、本文・画像・出典を確認できた記事だけにします。取得できない情報を推測で補い、すべての媒体へ例外を広げる方法は取りません。

編集部の実務提案

5. 検索設定と公開状態を組み合わせて検証する

受け入れ確認では、検索に出す公開記事、検索から除外する承認済み公開記事、下書き、個別の編集保留、権限のない閲覧という組合せを用意します。それぞれで、誰が読めるべきか、外へ配信してよいか、何を成功の証拠とするかを先に決めます。影響のない検証環境を使い、本番への試験投稿を増やして確認することは避けます。

配信の結果も、候補に入った、予約を受け付けた、投稿IDが確定した、画像と本文を見て確認した、という段階を分けます。検索の設定を直しただけで、過去の未投稿が自動的に解決したとは扱いません。既存の予約や送信履歴を読み戻し、結果不明の投稿を別のIDで重ねない手順まで確かめます。

編集部の実務提案

6. 設定の意図と、確認した経路を一緒に残す

運用台帳には、媒体名、正規URL、記事の読取元と書込先、検索設定の意図、公開承認の範囲、配信先、最後に確認した時刻を残します。ここまでの項目は編集部の実務提案です。名称が似たテスト環境と本番環境を混ぜず、保存先にデータが入ったことと、本番のページが更新されたことも区別します。

VERSAROCへ運用を相談する際は、現在の設定、止まった段階、実際に確認できた公開URLや識別子を整理すると、調査対象を絞りやすくなります。認証情報そのものを渡す前に、既存の権限で確認できる経路を共有します。検索、閲覧、配信の責任を分けて説明できることが、日々の確認をチームへ任せる出発点になります。