Optistreamは、1,000件の公開ページのSEOを一切損なうことなく、12個のカスタムWordPressプラグインを単一のコードベースに統合しました。

なぜ統合が必要だったのか

一般的なWordPressサイトは数個のプラグインで構成されますが、大規模なサイトになると、まるでコードが絡まり合った作業場のように、それぞれが動作していてもどれも簡単に取り外せない状態になります。Optistreamのサイトでは、ストリーマーのプロフィール、eスポーツチーム、ゲームデータを処理する12個の特注プラグインが稼働していました。これらのプラグインは1,000件のインデックス可能なページを生成していました。これらのURLを維持することは譲れない条件でした。わずかな変更でも、移行作業を台無しにする恐れがあったからです。

旧構成の状況

12個のプラグインはそれぞれ独自のフォルダに存在し、独自のカスタム投稿タイプを登録し、WordPressの異なるポイントにフックしていました。問題が山積みでした。

  • フックやアセットが分散しており、どのコードがいつ実行されるかを予測するのが困難でした。
  • ルーティングロジックが多くの別々のファイルに存在していたため、単一のURLが複数のプラグインの影響を受ける可能性がありました。
  • CSSファイルが予測不可能な順序で読み込まれ、スタイルの競合が発生していました。
  • デバッグの際、12個の異なるディレクトリを開く必要があり、開発者にとって大きな時間の浪費となっていました。

目標はファイル数を減らすことではなく、システム全体に単一のライフサイクルと、依存関係を管理するための単一の場所を提供することでした。

移行計画の立て方

チームは、公開インターフェース（URL、テンプレート、メタデータ）を、決して破ってはならない「契約」として扱いました。フロントエンドに何らかの変化が生じることは、失敗を意味します。このルールに基づき、各ステップの後に実行するためのチェックリストを作成しました。

1. 公開契約のリストアップ

すべてのURLパスを、投稿タイプ、リライトスラッグ、テンプレートファイル、および依存するメタキーとともに書き出しました。このスプレッドシートがルールブックとなりました。モジュールの移動後にURLが変更された場合、移行はロールバックされました。

2. シンプルなローダーの構築

小さなブートストラップファイルを作成しました。以前の各プラグインは、予測可能な関数名を通じて、単一の「コンテンツドメイン」を登録するようになりました。ローダーは複雑なことはせず、必要なときに適切なモジュールをWordPressに読み込むだけの役割を果たします。シンプルであることで、失敗がすぐに判明するようになります。

3. データの保護

メタキーの名前を変更すると、コードの変更がデータ移行へと発展し、不必要なリスクを招くことになります。古いキーはそのまま維持し、新しいヘルパー関数でそれらをラップすることで、データベーススキーマの安定性を保ちました。

4. CSSの所有権の修正

スタイルの競合は、以下の3つの対策で解決しました。

  • モジュールのCSSファイルを高い優先度でエンキューし、最後に読み込まれるようにしました。
  • すべてのセレクターを、各モジュール固有のラッパークラスにスコープ化しました。
  • スタイルシートが変更された場合にブラウザキャッシュを回避できるよう、エンキュー時に filemtime() を使用しました。

5. 安全なループの実行

移行は一度に1つのモジュールずつ進められました。モジュールを移動した後、チームは次のモジュールに手を付ける前に、投稿タイプの登録、ルーティング、およびモバイルレイアウトを確認しました。元のプラグインはインストールされたまま非アクティブ状態で保持され、即座にロールバックできる経路を確保しました。

本番環境のチェックリスト

各モジュールの入れ替え後、チームは以下を確認しました。

  • すべてのコンテンツタイプのURLが 200 HTTPステータスを返すこと。
  • canonical URLヘッダーが元のURLと一致していること。
  • ページタイトルとメタディスクリプションに変更がないこと。
  • すべての画像がリンク切れなしで読み込まれること。
  • モバイル画面で横方向のオーバーフローが発生していないこと。
  • ブラウザのコンソールにJavaScriptまたはCSSのエラーが表示されないこと。

チェックリストをすべてクリアして初めて、チームは古いプラグインを恒久的に停止しました。

新しいプラグインがもたらすもの

完成した単一のプラグインは、コードベースを縮小させたわけではありません。単に境界線を可視化したのです。12個の機能領域すべてが、単一のライフサイクル、単一のフックセット、および単一の依存関係管理場所を共有するようになりました。新しいプラグインはシステムを小さくしたのではなく、境界線を明確にしました。それは、プラグインの数を減らすことよりも有用であることが証明されました。

リスクと反論

Optistreamの事例は、規律ある「契約第一（contract-first）」のアプローチと段階的な展開によって、リスクを抑制できることを示しています。

次に注目すべき点

同様の統合を検討している場合は、まず以下の2つの柱から始めてください。

  1. URLの安定性 – コードを1行も書く前に、すべての公開パスをマッピングしてください。
  2. データの安定性 – 完全なデータ移行の準備ができていない限り、データベースフィールドの名前変更は避けてください。

そこから、小さなローダーを構築し、CSSをスコープ化し、厳格な本番チェックリストを実行しながら、モジュールを一つずつ移動させていきます。