サイトを作るとき、「WordPressにするか、Drupalにするか、静的サイトにするか」という話になりがちです。
僕は、そこから考える必要はないと思っています。
先に決めるのは、何を更新するのかです。
更新しないものは静的HTML、増え続けるものはCMS。
当社のサイトは、この考え方で1つのドメインの中に静的HTMLとDrupalを共存させています。
当社のサイトは、2つの仕組みが1つのドメインで動いています。
会社案内やサービス紹介は静的なHTML、ブログはDrupalというCMSです。
訪問される方から見れば同じ1つのサイトですが、中身は別物が並んでいます。
なぜこうしたのか。何が良くて、何が面倒なのか。
実際に運用してみて分かったことを以下に書きました。
静的HTMLとDrupalをどう配置しているか？
URLで見ると、こうなっています。
/、/company.html、/service/… 静的HTML/blog/配下 … Drupal
ドメインは1つ、サーバーも1台です。
別々のサービスに分けているわけではありません。
サーバー上の置き方が少し変わっています。
Drupalの本体は公開ディレクトリの外に置き、そこから public_html/blog へシンボリックリンクを張っています。
こうすると、Web経由で見えるのは /blog だけになり、CMSのプログラム本体は公開領域に出てきません。
なぜ静的HTMLとDrupalを分けているのか？
理由は単純です。
更新頻度がまったく違うからです。
会社概要や事業内容は、年に数回しか変わりません。
一方、ブログは週に何本も増えていきます。
性質の違うものを同じ仕組みに載せると、どちらかに無理が出ます。
会社案内をCMSに載せると
更新しないページのために、本体とプラグインのアップデートが定期的に発生します。
更新していないのに保守だけが続くという状態です。
表示のたびにプログラムが動き、データベースを読みに行くので、静的なHTMLより遅くもなります。
ブログを静的HTMLで書くと
10記事までは手作業で足ります。
しかし記事が増えると、一覧ページ、カテゴリページ、タグページ、関連記事を全部手で作ることになります。
共通部分を1箇所直したいとき、全ファイルを開くことになる。
この作業を自動化する仕組みが、そもそもCMSです。
それぞれに向いた道具を使う。ただそれだけの判断です。
静的HTML側はSSIで共通部分を管理
会社案内側は、素のHTMLです。ただし共通部分だけはファイルを分けています。
ヘッダーとフッターを別ファイルにして、各ページから読み込む形です。
ApacheのSSI（Server Side Includes）という仕組みを使っています。
<!--#include virtual="/included/header.html" -->
この1行で、その場所にファイルの中身が展開されます。
処理はサーバー側で完結するので、訪問者のブラウザには普通のHTMLとして届きます。
JavaScriptで読み込む方法もありますが、今回はクライアント側で処理する必要がないSSIを選びました。
サーバー側でHTMLを展開してから返せるため、静的HTMLと同じ感覚で扱えるのが理由です。
SSIならその心配がありません。
Drupal側はブログ運用をCMSに任せる
ブログはDrupalです。
記事の投稿、カテゴリ分類、タグ、関連記事の表示、サイトマップの生成を任せています。
ここで一工夫しているのがデザインの扱いです。
Drupal用にテーマを自作していますが、CSSは本体サイトのファイルをそのまま読み込んでいます。
Drupal側に独自のCSSをほとんど持たせていません。
こうすると、本体のデザインを変えたときにブログも一緒に変わります。
デザインの管理場所が1つで済みます。
逆に、2箇所で別々に管理すると、片方だけ古いデザインのまま残る事故が必ず起きます。
静的HTMLとDrupalをどう連携させているか？
分けたものは、つながないと1つのサイトになりません。3つの方法でつないでいます。
デザインの共有
先ほどの通り、CSSは本体のものを共有しています。
ヘッダーとフッターの見た目も揃えているので、訪問者は境目を意識しません。
最新記事の自動反映
トップページに最新記事を3本表示しています。
これは手で書き換えていません。
記事を公開・更新・削除すると、DrupalがHTMLの断片を書き出し、静的側の共通ファイル置き場に保存します。
トップページはそれをSSIで読み込むだけです。
記事を書けば、トップページは自動で最新になります。
そしてサーバー側で展開されるので、クローラーからは通常のHTMLに見えます。
構造化データの相互参照
会社情報や著者情報を、機械が読める形式（JSON-LD）で記述しています。
このとき、記事側から会社概要ページの記述を識別子で参照しています。
会社と著者と記事が、別々の情報ではなくひとつながりの情報として認識される状態を作るためです。
詳しい実装は構造化データで、サイト全体を一つの情報として繋ぐに書いています。
この構成のメリット
運用して実感している利点を挙げます。
- 会社案内が速い
静的HTMLなので、プログラムもデータベースも動きません。
表示までの待ち時間が短く、アクセスが増えても重くなりにくい。
- 会社案内が壊れない
アップデートで表示が崩れることがありません。プラグインの相性問題も起きません。
触らなければ、そのまま動き続けます。
- 障害の切り分けが楽
ブログが不調でも、会社案内とお問い合わせは無事です。逆も同じです。
全部が同時に止まることがありません。
- ブログの運用が楽
記事の追加、分類、関連記事の表示は全部CMSがやります。手作業はありません。
- 評価が1つのドメインに集まる
ブログを別ドメインにする方法もありますが、それだと評価が分散します。
同じドメインのサブディレクトリなら、記事が増えるほどサイト全体の評価につながります。
- 捨てやすい
将来ブログをやめても、会社案内はそのまま残ります。
逆に会社案内を作り直しても、記事は影響を受けません。
片方の判断が、もう片方を巻き込みません。
7.静的HTMLとDrupalを分けるデメリット
良いことばかりではないので、正直に書きます。
ヘッダーとフッターが二重管理になる
静的側はSSI、Drupal側はテンプレートに直書きです。
ナビゲーションを変えるときは両方を直す必要があります。
片方だけ直す事故が起きやすい部分で、当社もまだ解消できていません。
仕組みで解決できる見込みはありますが、現時点では手作業です。
CSSの共有が裏目に出ることがある
本体のCSSをそのまま読み込んでいるため、本体側の指定がブログ記事にも効いてしまいます。
実際に起きた例を挙げると、本体サイトのナビゲーション用に書かれていた指定が、記事本文の箇条書きにも当たり、「・」が表示されなくなりました。
デザインの管理を1箇所にできる代わりに、こうした干渉は避けられません。
トレードオフとして受け入れています。
結局、CMSの保守は残る
ブログ側にはCMSがあるので、本体のアップデートは必要です。
保守がゼロになるわけではありません。
減らせたのは「更新しないページのための保守」であって、CMSそのものの保守ではありません。
構成を理解している人が必要
シンボリックリンク、SSI、テーマの自作。
一般的な構成ではないので、引き継ぎには説明が要ります。
「WordPressです」と言えば通じることの価値は、技術的な優劣とは別のところにあります。
この構成が向いているサイト・向いていないサイト
この構成が合うのは、次の条件が揃っている場合です。
- 会社案内はほとんど更新しない
- ブログや事例など、増え続けるコンテンツがある
- その2つを同じドメインで運用したい
- サーバーの設定をある程度触れる
逆に、更新するものが1種類しかないなら分ける意味がありません。
全部CMSか、全部静的で構いません。
分けるのは、性質の違うものが混在しているときだけです。
何を更新するのかを先に決める、という話はWordPressをやめるべきかにも書いています。
まとめ
静的HTMLとCMSは、どちらかを選ぶものだと思われがちです。
両方使う選択肢もあります。
更新しないものは静的に、増え続けるものはCMSに。
それぞれに向いた道具を当てて、1つのドメインでつなぐ。
特別なことはしていません。
ただ、この判断ができるかどうかは、作り始める前に「何を更新するのか」を確認したかどうかで決まります。
そこを飛ばすと、全部を1つの仕組みに載せることになり、後から重くなります。
サイト全体の構造をどう設計するかについては、サイト設計とSEO・AEO にまとめています。
あわせてご覧ください。