3年前のことです。あるクライアントから木曜日の午後、私に絶望的なパニック状態で電話がありました。DrupalからWordPressへの移行を安い開発業者に任せたところ、サイトは金曜日にライブになり、月曜日には有機トラフィックが67%も低下していました。なくなってしまったのです。6年間のSEO資産が、ただ消えてしまいました。リダイレクトなし。壊れたURLは数千。Googleのクロールバジェットは完全に消費されていました。
重要なポイント：Drupal から WordPress へのマイグレーションが失敗する原因は CMS の切り替え自体ではなく、URL マッピングと分類法の翻訳にあります。完全なリダイレクトマップを用意し、メタデータを移行させることでランキングを維持しましょう。
そうした惨状の復旧は数え切れないほど経験している。Seahawk Mediaで12,000件以上のマイグレーションに携わってきた身として自信を持って言える。DrupalからWordPressへの技術的な移行は実は簡単な部分だ。SEO保全こそが問題の所在であり、本来なら回避できるはずなのだ。
これが私が毎回従うプレイブックです。
---
なぜDrupalからWordPressへの移行はSEO地雷原なのか
DrupalとWordPressはURLを異なる方法で生成する。Drupalのデフォルトパスシステムは、Pathautoのようなモジュールと組み合わせると、WordPressがそのまま生成するものと全く重複しないURL構造を生成することが多い。Drupalのノード/content/our-services/web-designはWordPressでは/our-services/web-designになったり、パーマリンク設定によっては/web-designになったりする。これらは異なるURLだ。Googleはそれらを異なるページとして認識する。リダイレクトがなければ、古いURLは終わりだ。
そもそも問題はURLだけではない。DrupalのタクソノミシステムはWordPressのカテゴリーおよびタグにマップされるが、完全には対応しない。DrupalのカスタムコンテンツタイプはWordPressのカスタム投稿タイプになるが、マイグレーション前にそのCPTを構築していなければ、コンテンツは完全に違うバケットに落ちてしまう。かつてDrupal運用のニュースサイトで、800個の「記事」ノードがすべて標準的なWordPress投稿としてインポートされ、内部リンク構造が依存していたカスタムアーカイブが上書きされたケースを見ている。
ほとんどの開発者が見落とすポイントがあります。移行前にWordPressで下すすべての構造的決定は、移行後に必要になるリダイレクトに直接影響します。まずアーキテクチャを正しく設計しましょう。リダイレクトはパッチであり、計画ではありません。
---
ステップ1：マイグレーション前監査、移行前に何を動かすかを把握する
Drupalのインストールには手を付けるな。まず本番サイトの完全なクロールを取得してからにしろ。私はScreaming Frogを使用して500,000個のURLまでクロールする設定にしている(有料版)。すべてをエクスポートしろ。URL、ステータスコード、タイトルタグ、メタディスクリプション、H1、canonical タグ、インバウンド内部リンク、単語数だ。
Google Search Consoleのデータも取得する。過去16ヶ月間のクリック数でフィルタリングする（3ヶ月でも6～16ヶ月でもなく、季節的なコンテンツを捕捉したいから）。最低1クリック以上を受けたURLをすべてエクスポートする。これらがあなたの保護すべきURLだ。これらのランキングを失えば、クライアントが気づく。
具体的に確認すべきことは：
- Drupalサイトに既に存在する重複コンテンツ(マイグレーション後ではなく、前に修正しろ)
- 200語未満のシンコンテンツページで、検索流入がないもの。これらはマイグレーションするのではなく、統合または削除が可能
/node/1234のような非標準URLパターン。Pathautoがアクティブな場合でもDrupalが時々公開するURL。- ランクしているタクソノミーアーカイブページ。
/tags/、/category/、/topic/パスで実際にSearch Consoleのインプレッションを持つもの
これが常に人々を引っかかる。Drupalのタクソノミータームページはロングテールクエリに対してランクしていることが多い。同等のWordPressタクソノミーアーカイブを再作成してリダイレクトを設定しなければ、受動的なトラフィックを捨てているのと同じだ。
---
ステップ2：URLマッピング、誰も作りたくないスプレッドシート
つまらない？そうだ。避けられない？それもそうだ。
Google Sheetsでやる(またはAirtableでやっても良い、両方使っている)。URL マップを構築しろ。列Aはすべてのdrupal URL。列Bはそれが解決するWordPress URL。列Cはステータスだ。exact match、redirect needed、consolidate、deleteのいずれかだ。
300ページのサイトなら半日で済む。Seahawk Mediaが2021年に対応した高等教育機関クライアントの8,000ページサイトなら、3人のチームで約4営業日、そして非常に退屈な金曜夜が必要だ。毎回の価値がある。
私が従うルールをいくつか：
- 可能な限りスラッグを保持する。Drupalが
/blog/how-to-fix-crawl-errorsを持っていれば、WordPressに同じスラッグを使わせる。ほとんどの場合できる。WordPress Settings → Permalinksのパーマリンク設定により、Drupalが使用していたパターンに一致させることができる。 - ホームページへのリダイレクトは絶対にしない。怠け者の開発者がやることだ。リンク評価が失われ、ユーザーも混乱する。古いURLはすべて特定の宛先に向ける。
- ページネーション付きURLに注意。Drupalのページネーションは
?page=1の形式だ。WordPressは/page/2/を使う。これをマップするか、さもなくば404で放置するか（通常は問題ないが、ページネーションページは意味のあるリンク価値をほぼ持たない。ただしGSCで確認を）。 - クエリ文字列は別々に扱う。
/search?keys=wordpressのようなものはリダイレクトが不要だ。/events?date=2023-06は、そのページがランクしているかどうかによって必要になるかもしれない。
---
ステップ3：コンテンツマイグレーション、FG Drupal to WordPressと実際の動き
FG Drupal to WordPress プラグインがほとんどのマイグレーションの重い部分を担う。Drupal データベースに直接接続し、ノード、ユーザー、タクソノミーターム、メディアを取得する。Drupal 7 では完璧に動作する。Drupal 9/10 では、プレミアム版が必要だ。前回確認したときは約€99 だった。手動マイグレーションと比べればすべての費用の価値がある。
プラグインがうまく処理すること：
- ノードのボディコンテンツ（メディアパスを正しく設定すれば埋め込み画像を含む）
- WordPressのカテゴリー・タグにマッピングされたタクソノミーターム
- プレミアム版を利用している場合、基本的なカスタムフィールド
手作業で修正が必要な項目:
- Drupal Views。カスタムページレイアウト・クエリだ。WordPressではWPGridBuilderのようなプラグインか、単純なWP_Queryループを使ってこれらを再構築する
- ウェブフォーム。Gravity Forms または WPForms に手動でマッピングしてください。ロジックは転送されません。
- 複雑なフィールドグループ。Drupal の Field API は本当に変わったデータ構造をサポートしています。これらを CSV にエクスポートして WP All Import でインポートする必要があります。
- ブロックコンテンツ領域。Drupal のブロックシステムは WordPress のウィジェット/FSE ブロックと全く異なります。移行タスクではなく、設計判断です。
FG Drupal to WordPressが完了した後、私がいつもすることは行数をカウントすることです。Drupalに何個のノードがありましたか？WordPressに何個のポスト/CPTエントリがありますか？意図的に除外したもの以外は一致するはずです。5,000ノードのサイトで3%の不一致は150ページがなくなっているということです。見つけてください。
---
ステップ4: サーバーを破壊しないリダイレクトの実装
URL マップが作成され、コンテンツが WordPress ステージング環境でライブになったら、リダイレクトの時間だ。2 つのツールがある。小規模サイト（約 1,000 リダイレクト以下）には Redirection プラグイン、Apache 上のより大規模なサイトには .htaccess ルール、Nginx には nginx.conf ブロックを使う。
なぜこの分割か？RedirectionプラグインはリダイレクトをPHPを経由して処理するため、リダイレクトチェックのたびにサーバーヒットが発生します。5,000リダイレクトで1日50,000ページビューの場合、これは実際のオーバーヘッドです。サーバーレベルのリダイレクトは1桁以上速くなります。
大規模なマイグレーションでは、Google Sheets から URL マップをエクスポートして、RewriteRule ブロックを生成するクイックスクリプトを書き、ゴーライブ前に .htaccess に入れ込む。20 分かかる。ゴーライブ後のサイト速度低下のデバッグに何時間も費やすことを避けられる。
人が考えていないこと：リダイレクトチェーンだ。Drupal が既にリダイレクトを設定していた場合（多くの成熟した Drupal サイトが Redirect モジュール経由で行っている）、それらを見つけてチェーンを折りたたむ必要がある。A → B → C は A → C になる必要がある。Google 独自のドキュメントでは、チェーンが PageRank の転送を遅くすることは明確だ。排除しないにしても。
---
ステップ 5: ローンチ後、72 時間のウィンドウ
火曜日か水曜日にライブにしてください。金曜日は絶対にダメです。私は 2018 年のクライアント案件でこれを身をもって学びました。1,200 ページの移行を金曜日の午後にローンチして、午後 6 時にパーマリンク構造の設定ミスが発覚しました。月曜日までに Google は既に壊れた URL の波をクロール・インデックスしていました。
最初の72時間で監視する内容は以下の通りです:
- GSC カバレッジレポート。404 のスパイクを監視してください。いくつかは予想されます（古い Drupal システムのパス）。収益ページ全体でのスパイクは問題です。
- Screaming Frog の再クロール。ローンチの翌朝に WordPress サイトをクロールしてください。URL 数を移行前のベースラインと比較します。
- リダイレクトのスポットチェック。GSC から上位 20 件のトラフィック Drupal URL を手動テストしてください。ブラウザに貼り付けます。正しい場所にランディングしていますか？
- canonical タグ。すべてのページで WordPress が正しい canonical を出力していることを確認してください。Yoast と Rank Math は両方とも自動的にこれを行いますが、確認してください。
- XML サイトマップ送信。新しいサイトマップを GSC に即座に送信してください。Google が見つけるのを待たないでください。
ほとんどの人がスキップすることで、私が実施していることの一つは、ローンチ後にGSCで古いDrupal XMLサイトマップも送信することです。一時的に古いドメインまたはサブドメインを保持していた場合はそこを指定してください。これにより、Googleに対して正確にどの古いURLをクロールするか、リダイレクトをたどるか、インデックスをより速く更新するかを指示できます。
---
ステップ6：30日間のSEO健全性チェック
マイグレーションはゴーライブで終了ではありません。インデックスの更新には時間がかかります。30日目の時点で私が確認する内容は以下の通りです：
- ランキングポジションの変動を確認する場合は、AhrefsやSemrushを使ってミグレーション前30日間と後30日間のキーワード順位を比較してください。一部の用語では軽微な変動（5～10ポジション）が予想されます。プライマリキーワードで30ポジション以上の低下が見られる場合は、調査が必要です。
- バックリンクターゲットについて、特定のDrupal URLを指すバックリンクがある場合は、それらのURLがクリーンにリダイレクトされているか確認してください。Ahrefsの「Lost Backlinks」レポートでこれを確認できます。リダイレクト設定されていないバックリンクターゲットは、あなたが失いつつあるリンク評価です。
- ページ速度の低下に注意してください。WordPressサイトはチューニングが十分なDrupalサイトよりも遅くなることがあります。最も重要な5ページでLighthouse監査を実行し、ミグレーション前のベースラインと比較してください。
- インデックス率を確認してください。投稿したURLの何パーセントがインデックスされていますか？ミグレーション30日後の時点で、メインのコンテンツページの少なくとも80%がインデックスされていることが望ましいです。60%未満の場合はクロール可能性に問題がある可能性があります（robots.txtを確認し、WordPress設定の「表示設定」でGooglebotを誤ってブロックしていないか確認してください）。
Seahawk は去年、フィンテック クライアントを抱えていて、30 日のチェックで 340 の製品ページが、マイグレーション中に Yoast の誤設定されたバルク アクションで誤って noindex に設定されていることが判明した。30 日で捕捉：午後で修正可能。6 か月で捕捉：おそらくまだ埋めようとしているランキングの穴だ。
---
よくある質問
Drupal から WordPress への移行には実際どのくらい時間がかかりますか？
サイトサイズとコンテンツの複雑さに完全に依存します。50ページのブロシュアサイトの場合：QAを含めて2～3日。5,000ページのニュースアーカイブ（カスタムコンテンツタイプ付き）の場合：6～10週間。SEO監査、URL マッピング、リダイレクト実装、ローンチ後の監視などのSEO作業は、通常、コア開発見積もりの30～40%を追加します。誰がなんと言おうとそれは変わりません。
Drupal から WordPress に移行した後、ランキングを失いますか？
短期的な変動は正常であり、ほぼ必然です。URLマッピング、リダイレクト、canonicalタグを正しく実装していれば、ほとんどのランキングは6～12週間以内に安定します。私が見た永続的な損失を被ったサイトはすべて同じ問題を持っていました：リダイレクトがない、またはホームページへの一括リダイレクト。作業をしてください。ランキングは戻ってきます。
すべての Drupal コンテンツを移行するべきか、それとも一から始めるべきか？
コンテンツが何をもたらしているかに完全に依存します。Google Search Consoleのデータを取得してください。過去16ヶ月間でゼロクリックかつバックリンクがないコンテンツは、ミグレーションするのではなく削除の候補です。薄くて価値の低いコンテンツをミグレーションするとWordPressサイトが肥大化し、クロール予算が分散される可能性があります。徹底的に検討してください。ただし、ページ自体がひどい場合でも外部バックリンクがあるURLを削除することは決してしないでください。関連のあるページにリダイレクトしてください。
Drupal 移行後に使用するのに最適な WordPress テーマはどれですか？
正直なところ、テーマの選択は、適切に構造化された HTML を使用していて、ページ速度をチェックしている場合、SEO への影響はほぼない。私は GeneratePress をそのクリーンなマークアップと最小限のオーバーヘッドのために、あるいはクライアントがより多くの設計の柔軟性を望む場合は Kadence をデフォルトにしている。ページビルダーが重いテーマは避ける。毎回のページロードで 400KB の未使用 CSS を出力するからだ。
開発者が必要ですか、それとも自分でできますか？
50ページ以下の小規模サイトでシンプルなコンテンツかつカスタムポストタイプがない場合は、FG Drupal to WordPressとRedirectionプラグインで管理できる可能性があります。それより大きなサイト、またはCPT、複雑なタクソノミー、または有意なSEO足跡がある場合は、開発者を雇ってください。不適切なミグレーションを修正するコストは、常に最初から正しく実行するコストよりも高くなります。
---
ミグレーション自体は仕事の40%に過ぎません。残りの60%は、ミグレーションの周りに構築するSEOインフラストラクチャ、マッピング、リダイレクト、監視、30日間データを注視してから勝利を宣言する忍耐強さです。美しく構築されたWordPressサイトが検索で失敗するのを見たことがありますが、それはリダイレクト作業が不正確だったからです。また、ほぼテーマがないスクラッピーなWordPressインストールがすべてのランキングを保持するのを見たことがありますが、それはURLマップが細心の注意で作成されていたからです。
つまらない部分を正しくやってください。残りはたいてい後からついてきます。