検索で見つけてもらうWebアプリのサーバーレンダリング

判断の意味を明確にする

まず公開情報と非公開の作業を分けます。製品説明、公開一覧、記事は検索で見つけてもらう対象になり得ますが、顧客画面や個人記録にはアクセス制御が必要です。すべてをサーバーで描画しても、公開するURLや最初の応答内容は別途決めなければなりません。

役割と選択肢

安定した公開情報は事前にHTMLを生成でき、頻繁に変わる情報はリクエスト時の生成が候補です。どちらにもブラウザーの操作機能を加えられます。Googleの説明ではクロール、描画、インデックス登録は別工程で、適切なステータスも必要です。主要説明と通常のリンクを最初のHTMLに含める方針が実務的です。

変更を追ってみる

公開の仕入先紹介と非公開の購買画面があるディレクトリを考えます。紹介URLへの直接アクセスでは名前、説明、リンクを返し、購買画面には認可を要求します。存在しない仕入先にもアクセスし、空の成功画面ではなく不在として応答するか確認します。開発用ブラウザーだけでなく本番相当のHTTP応答を見ます。

失敗する経路を確かめる

描画データや共有キャッシュに非公開情報を入れないでください。サイトマップは、たどれるリンクの代わりにはなりません。canonicalは実際の公開ページと一致させ、読込中、一時利用不可、存在しない状態を分けます。描画方式だけで検索順位や登録は保証されません。

描画方式より先にURLを分類する

対象者、内容の情報源、必要な更新頻度、アクセス条件の四列でURL一覧を作ります。確認済みの公開紹介は反映を待てても、顧客の注文画面は最新の非公開情報が必要かもしれません。同じアプリ内でも描画とキャッシュを分ける理由になります。全体設定一つでページごとの判断を置き換えたり、変化する値をすべて公開したりしないでください。

公開ページは前画面を通らず直接取得し、ステータス、タイトル、canonical、本文、リンクを確認します。リンク先と不正なIDも開きます。ページ送りや絞り込みは、有用な公開先と一時的な表示条件を分けます。空のフィルターを無限に組み合わせても内容方針にはなりません。URL一覧、サイトマップ、通常の案内をそろえます。

同じ境界でキャッシュも調べます。公開文を再利用しても個別の応答が他人へ渡ってはいけません。未ログインと二つの別アカウントで、実際の配信設定を試します。検索登録の指示は認可にも非公開情報の保護にもなりません。削除時は本当の後継先があれば移し、なければ適切な不在にします。成功する汎用の空画面で判断を隠さないようにします。

直接取得で集める証拠

合意しておくルール

検索流入を受けたいページはどれか。直接のHTTP応答に主要内容があるか。キャッシュや前画面へのアクセスなしでも成立するか。URL一覧を用意し、アクセス権、本文、メタデータをまとめて確認します。