静的サイトという理由だけで、SEOに不利になるとは言えません。公開したページをGoogleが読み取れ、内容を更新した後もその状態を保てるなら、検索流入を得るためのサイトとして候補になります。採用時に差が出るのは、本文を書けるかだけでなく、公開後に必要な変更を続けられるかという点です。

ここでいう静的サイトは、あらかじめ生成したHTMLを配信する方式です。ただし、「静的CMS」という名前でも、サーバー上のプログラムが記事ファイルを読み込んでページを返す構成があります。名称から検索への適性を決めるより、実際に何が公開され、誰がどう更新するかを見るほうが判断しやすいかと思います。

編集できることと検索に届くことは別です

Googleが示す最低限の技術要件は、クローラーがアクセスできること、ページが正常応答のHTTP 200を返すこと、インデックス可能な内容があることです。これを満たしても、検索への登録や上位掲載が保証されるわけではありません。Google検索の技術要件は、CMSの方式名で優劣を付けるための基準ではありません。

たとえば、編集画面では新しいサービスの説明が入っていても、公開ページに反映されていなければ検索者には届きません。本文に合うタイトルが出力されていることや、一覧からそのページへたどれることも、公開結果で見る必要があります。管理画面に「SEO設定」という欄があるだけでは、その先の出力までは分かりません。

また、JavaScriptを使っているだけで検索に載らなくなるわけでもありません。GoogleはJavaScriptを実行してページを処理します。ただし、必要なファイルを取得できない場合や処理が失敗した場合には、意図した内容を読み取れないことがあります。候補環境を見る際は、JavaScriptの有無を合否にするより、本文が処理後のページに残るかが問題になります。JavaScriptとGoogle検索の説明でも、この処理の条件が示されています。

日常の更新で、関連する表示まで直せるか

所在地が移転した事業所の案内ページを更新する、という仮の例で考えます。本文の住所を変更できても、事業所一覧に古い住所が残れば、訪問者は異なる案内を目にします。記事を編集する方法に加えて、一覧の情報がどこから作られるのかまで分かると、一回の更新を最後まで終えられるかが見えてきます。

同じURLに案内ページを残すなら、住所の修正だけを理由にURLを変える必要はありません。既存のリンクから更新後の情報へ到達できる状態を保てます。反対に、保存するたびに別のURLができて古い案内も残る構成なら、どの案内を公開するのかを整理する仕組みが必要です。

一覧や関連記事からのリンクにも違いがあります。Googleが通常のリンクとして読み取れるのは、href 属性に行き先のURLを持つ a 要素が基本です。画面上でクリックできるというだけでは、同じようにたどれるとは限りません。クロール可能なリンクの要件を満たした出力になるかは、制作側が候補環境で確かめる部分です。

自社の担当者が本文と一覧を更新できるなら、日常の変更はその体制で続けられます。一覧だけ制作会社への依頼になる場合も、それだけで不採用とはなりません。依頼する頻度や反映までの時間が実際の運用に合うかによって、採用条件が変わります。

URLを移すときは、本文の修正とは違う機能が必要です

同じ仮の案内ページを、サイト構成の変更で別のURLへ移す場合はどうでしょうか。新しいページが表示されるだけでは、古いURLを使っている人がそこへたどり着けるとは限りません。恒久的な移転なら、対応する新URLへ301や308などの恒久リダイレクトを設定し、内部リンクやサイトマップの参照先も揃えます。canonicalを指定している場合は、移転先の正規URLと整合させます。関係のないトップページへの一括転送では、元の案内を探す人の目的を満たせません。GoogleのURL変更を伴う移転ガイドが、この対応関係を説明しています。

この操作は、本文の編集とは別の権限や設定を必要とすることがあります。普段は担当者が記事を直し、URL移転だけ制作側が担う構成も選択肢です。候補のCMSで転送を設定できなくても、公開先のサーバーで対応できるなら、その担当と対応範囲を含めて評価できます。

canonicalという正規URLの指定も、転送の代わりに何でも解決する設定ではありません。同じ内容や非常に似た内容が複数のURLにあるとき、検索で代表にしてほしいURLを伝えるためのものです。指定したURLが必ず選ばれるわけではなく、内容が異なるページを一つへまとめる用途にも適しません。正規URLの指定方法と、訪問者を新しい行き先へ送るリダイレクトは役割が違います。

戻せる範囲まで含めると採用条件が見えてきます

本文の修正が容易でも、共通テンプレートの変更で各記事へのリンクが消えれば、影響は一ページに収まりません。以前の記事ファイルを戻すだけでは、テンプレート側の不具合は直らないこともあります。公開する操作と、不具合が起きた箇所を正常な状態へ戻す操作は、別に評価する必要があります。

記事本文の復元は自社で行い、共通部分の修復は制作会社が担うという分担も考えられます。その範囲が明確なら、日常の更新と障害時の対応を両立しやすくなります。逆にファイルは受け取れても、公開し直す方法が分からず対応先もなければ、更新を続ける前提が不足しています。復旧の担当範囲については、静的CMSの保守を考える記事で詳しく扱っています。

公開出力が検索の技術要件を満たし、想定する更新と復旧を実行できるなら、静的サイトは採用候補になります。転送だけ外部へ依頼するなど対応方法が明確なら条件付きで選べますが、必要な更新ができず継続可能な代替手段もなければ見送りです。出力や復旧方法をまだ確かめられないなら、判断は保留です。要件を満たさないと分かった場合の見送りとは分けます。

この選定で確かめられるのは、検索する人へ情報を届ける状態を維持できるかです。公開の仕組みが整った後は、そのページが検索者の疑問に答えているかが問われます。更新しやすい環境には、その答えを事業の変化に合わせて直し続けられる価値があります。