静的という構成名だけで、SEOの有利不利は決められません。Google検索の最低技術要件には、静的か動的かという方式名は含まれていないからです。Googlebotが対象URLへアクセスでき、正常なページがHTTP 200を返し、そのページにインデックス登録可能な内容があることが出発点です。
採用前に確かめたいのは、候補の仕組みで必要な公開状態を作れるかどうかです。採用後に更新を担う人が変更を反映し、問題があれば元へ戻せるところまで試します。判断には本文更新、URL変更、テンプレート変更の三つを使います。
三つとも採用後に想定する体制で完了できれば「採用」です。追加の権限や技術支援があれば実現できる場合は「条件付き採用」、必要な公開状態を作れない場合は「見送り」とします。環境や権限が足りず、できない理由を判定できない場合は「保留」です。最初からこの四つを分けておくと、不具合が一度出ただけで候補を外したり、根拠がないまま採用したりせずに済みます。
静的か動的かだけでは検索上の有利不利を決められない
「静的サイト」と呼ばれる構成にも幅があります。静的サイトジェネレーターでファイルを作ることもあれば、headless CMSで内容を管理し、公開時にHTMLを事前生成することもあります。動的CMSでもキャッシュや事前生成を使えるため、静的と動的のどちらか一方へきれいに分けられるものではありません。
検索側から見れば、製品の分類よりも対象URLの最終的な応答が問題になります。主要な本文が公開結果に含まれ、必要なページへ通常のリンクで移動できる状態なら、生成方法だけを理由に検索対象から外れるとは言えません。
GoogleはJavaScriptを実行し、レンダリング後のHTMLも処理します。この挙動はJavaScript SEOの基本で確認できます。JavaScriptを使っているという理由だけで判断せず、処理後の本文とリンクを見てください。
静的方式を選べば、速く安全なサイトになるとは限りません。表示速度は配信環境や画像の実装にも左右されます。安全性を判断するときは、フォームなどの外部接続に加えて、依存パッケージと公開設定も確認する必要があります。
保守のしやすさも、更新する人と支援体制によって変わります。方式名から利点を推測するより、自社が使う構成で確かめた方が採用後の食い違いを減らせます。
Googleの要件と採用時の判断を分けて考える
Googleが示しているのは、検索対象になるための技術要件です。検索エンジンへURLの状態を伝える方法も案内しています。一方で、CMSを選ぶために何を試すかまでは定めていません。この二つを混ぜると、公式要件を確認しただけで自社の運用まで成立すると考えてしまいます。
Google検索の技術要件に照らすと、正常なページではHTTP 200が返る必要があります。Googlebotが取得できる内容には、インデックス登録可能な情報も必要です。
ページ間の移動には、解決できるURLを href に持つリンクを使います。
本番公開したいページに noindex が残っていないことも確かめます。Googleが noindex を認識するには、そのURLをクロールできる必要があります。robots.txt でクロールを止めると、metaタグやHTTPヘッダーの noindex は検出されません。どれも静的サイトだけに求められる条件ではありません。
ここから先の採用前リハーサルは、AdRegionが採用判断のために置く実務上の手順です。Googleが定めた標準手順ではありません。候補の仕組みを使う予定の担当者が作業し、必要なところだけ提供会社や技術担当の支援を受けます。自社だけで担える範囲と、支援が必要な範囲を結果として残すためです。
本文更新で一ページを正しく公開できるか確かめる
最初のリハーサルでは、実際に運用する可能性が高いサービスページか記事を一つ選びます。その本文を、採用後に更新を担う人が普段使う編集方法で変更してください。技術担当だけが特別な手順で成功させても、日常の更新を続けられる証拠にはなりません。
変更前に、どの文章とリンクがどう変わるはずかを決めておきます。公開後は画面の見た目だけで成功と判断しません。対象URLのHTTP応答を調べ、ソースHTMLとレンダリング後のHTMLに主要な本文があるかを見ます。必要なリンクが入り、公開対象のページから noindex が外れていることも、この段階で確かめます。
意図どおりに変わらなければ、まず止まった工程を切り分けます。編集内容が生成物に入っていない場合と、生成物が公開先へ届いていない場合では、対応する人が変わるからです。原因が分からないまま別の担当者に成功させても、採用後の責任範囲は曖昧なままです。修正後は同じ箇所をもう一度検査し、採用後に想定する体制で正常な出力へ戻せたかを記録します。
URL変更後に旧URLから新URLへ正しく移行できるか確かめる
二つ目は、試作環境にある代表的なURLを一つ変更します。日常的な作業ではありませんが、ページの統合や名称変更が起きれば避けて通れません。設定方法を覚えることより、候補の仕組みと採用後の担当体制で移転後の状態を完成させられるかが判断材料になります。
恒久的な移転を想定するなら、旧URLから新URLへのサーバー側リダイレクトが機能するかを調べます。新URLが正常なページとして応答し、旧URLへ戻る循環や途中で切れる転送がない状態にしてください。Googleのリダイレクトに関する説明では、恒久的な移転に301や308などの恒久リダイレクトが推奨されています。
移転先だけが正しくても、サイト内の案内が旧URLのままでは作業を終えられません。関連する内部リンクは新URLへ直します。canonicalとサイトマップを使う構成なら、そこでも同じ新URLを示しているかを見てください。
永続的なリダイレクトとcanonicalは、正規URLを伝える強いシグナルです。ただし、どちらもGoogleへの命令ではなく、指定したURLが必ず正規版に選ばれる保証もありません。サイトマップはより弱いシグナルで、掲載したURLのクロールやインデックス登録を保証しません。ここでは用語を覚えるのではなく、URLに関する信号が食い違っていないことを確かめます。
試験を終えたら、試作前の正常な状態へ戻します。URLや転送設定の一部だけが残ることもあるため、復旧後も応答とリンクを再検査してください。変更と復旧の両方を完了できて、初めてURLを扱える候補だと判断できます。
テンプレート変更で影響範囲と復旧を確かめる
三つ目は、複数ページに反映されるテンプレートを一か所変更します。一ページだけの更新とは違い、小さな誤りが広い範囲へ出る可能性があります。変更前に影響するページを挙げられるかどうかも、検査の準備ができているかを見る手がかりです。
生成後は、変更対象のページと対象外のページをそれぞれ調べます。狙った箇所が変わり、対象外のページには意図しない変更が出ていない状態が必要です。全ページを目視する前提にせず、影響範囲をどう検査するかは提供会社や技術担当と決めておきます。
問題が見つかったら、直前の正常な生成物か設定へ戻します。再生成や再公開が必要になった場合は、採用後に更新を担う人がどこまで対応できたかを記録してください。どこから技術支援を受けたかも残します。
候補環境に、直前の正常な生成物や設定が保存されていないこともあります。戻した後の状態を検査できない場合や、担当者だけでは判断できない場合もあるでしょう。どちらも採用前に得られた重要な証拠です。
三つの結果を一件の記録へまとめる
本文更新とURL変更、テンプレート変更では波及範囲がそれぞれ異なります。三件を別々の作業記録で終わらせず、候補の採否を決める一件の記録へまとめます。成功したかどうかだけでなく、誰がどこまで担当できたかも重要です。試作環境と本番環境の違いが、結果に影響していないかも残してください。
次の記録は空欄のまま使います。候補製品の評価や所要時間を先に書かず、リハーサルで確認できた事実だけを残してください。
採用前リハーサル記録
基本情報
候補方式:
確認環境:
本番環境との違い:
採用後の更新担当者:
技術支援の担当と範囲:
本文更新
対象:
期待した公開結果:
実際の公開出力:
検査結果:
復旧結果:
残課題:
URL変更
変更前と変更後のURL:
期待した移転結果:
実際の公開出力:
検査結果:
復旧結果:
残課題:
テンプレート変更
対象と想定した影響範囲:
期待した公開結果:
実際の公開出力:
検査結果:
復旧結果:
残課題:
採用判断
未確認事項:
判断:
判断理由となる証拠:
条件がある場合の担当と再確認時期:
不具合が出たことだけで、候補を直ちに見送る必要はありません。初期設定を補えば直るのか、製品上実現できないのかを分けます。採用後に想定する体制で復旧できるかも別の判断です。試作環境や権限が足りずに原因を区別できない場合は、推測で欄を埋めず未確認事項として残します。
採用できる条件と見送る条件を分ける
ここまでの結果を使い、冒頭で示した四つの判断のどれに当たるかを決めます。見るのは検索順位の予測ではありません。自社に必要な公開状態を、その候補の仕組みと予定体制で繰り返し作れるかどうかです。
三つの変更で必要な公開出力を作り、検査と復旧まで行えたなら「採用」と判断できます。この結果は予定した運用が成立することを示しますが、検索順位が上がることまで保証するものではありません。基本要件を実現できても追加の権限や技術支援が必要なら「条件付き採用」とします。その条件には担当者と再確認の時期を付け、公開前に同じ箇所を再試験できる形にしてください。
必要な公開出力を作れない場合や、更新と復旧を担う体制を現実的に用意できない場合は「見送り」です。一方で、試せる環境や必要な権限が足りないために判定できないこともあります。提供会社から回答を得られず、復旧元も確認できない場合は「保留」です。証拠不足と、候補の仕組みが要件に合わない状態を同じ扱いにしないためです。
候補の構成や公開方法が変われば、以前のリハーサル結果をそのまま使えないことがあります。採用後の更新担当者が変わった場合も同じです。採用判断に迷ったら方式名の比較へ戻らず、どの変更の証拠が足りないのかを記録から探します。次に行うことは、その一件を採用後に想定する体制で試し直すことです。