3年前のことです。あるクライアントから木曜日の午後、私に絶望的なパニック状態で電話がありました。DrupalからWordPressへの移行を安い開発業者に任せたところ、サイトは金曜日にライブになり、月曜日には有機トラフィックが67%も低下していました。なくなってしまったのです。6年間のSEO資産が、ただ消えてしまいました。リダイレクトなし。壊れたURLは数千。Googleのクロールバジェットは完全に消費されていました。Drupal-to-WordPress migration to a cheap dev shop, the site went live on a Friday, and by Monday their organic traffic had dropped 67%. Gone. Six years of SEO equity, just... evaporated. No redirects. Thousands of broken URLs. Google's crawl budget torched.
重要なポイント：Drupal から WordPress へのマイグレーションが失敗する原因は CMS の切り替え自体ではなく、URL マッピングと分類法の翻訳にあります。完全なリダイレクトマップを用意し、メタデータを移行させることでランキングを維持しましょう。Drupal to WordPress migrations fail on URL mapping and taxonomy translation, not the CMS swap; ship a complete redirect map and transport metadata to keep rankings.
私はそうした壊滅的な状況を数え切れないほど修復してきた。Seahawk Mediaで12,000件以上のマイグレーションを行ってきた経験から言えば、DrupalからWordPressへの技術的な移行は実はそこまで難しくない。SEOの保持がすべてを台無しにする部分であり、かつそこは絶対に失敗する必要がない場所だ。Seahawk Media, I can tell you with some confidence: the technical move from Drupal to WordPress is actually the easy part. The SEO preservation is where everything goes wrong -- and where it absolutely doesn't have to.
これが私が毎回従うプレイブックです。
---
なぜ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は終わりだ。/content/our-services/web-design becomes/our-services/web-design or even/web-design on WordPress, depending on how you set permalinks. Those are different URLs. Google sees them as different pages. Without a redirect, the old one is dead.
しかもURLだけではない。DrupalのタクソノミーシステムはWordPressのカテゴリーとタグにマップされるが、完全ではない。DrupalのカスタムコンテンツタイプはWordPressではカスタム投稿タイプになるが、マイグレーション前にそれらのCPTを構築しないと、コンテンツはまったく異なる場所に入ってしまう。私が見たあるDrupalベースのニュースサイトでは、800件の「記事」ノードが標準的なWordPress投稿としてインポートされ、内部リンク構造が依存していたカスタムアーカイブ構造を上書きしてしまった。
ほとんどの開発者が見落とすポイントがあります。移行前にWordPressで下すすべての構造的決定は、移行後に必要になるリダイレクトに直接影響します。まずアーキテクチャを正しく設計しましょう。リダイレクトはパッチであり、計画ではありません。every structural decision you make in WordPress before the migration directly affects which redirects you'll need after it. Get the architecture right first. Redirects are a patch, not a plan.
---
ステップ1：マイグレーション前の監査 -- 移行前に何を移行するのかを把握する
Drupalのインストールには手を付けるな。まず本番サイトの完全なクロールを取得してからにしろ。私はScreaming Frogを使用して500,000個のURLまでクロールする設定にしている(有料版)。すべてをエクスポートしろ。URL、ステータスコード、タイトルタグ、メタディスクリプション、H1、canonical タグ、インバウンド内部リンク、単語数だ。Screaming Frog set to crawl up to 500,000 URLs (the paid version). Export everything: URLs, status codes, title tags, meta descriptions, H1s, canonical tags, inbound internal links, word counts.
Google Search Consoleのデータも取得する。過去16ヶ月間のクリック数でフィルタリングする（3ヶ月でも6～16ヶ月でもなく、季節的なコンテンツを捕捉したいから）。最低1クリック以上を受けたURLをすべてエクスポートする。これらがあなたの保護すべきURLだ。これらのランキングを失えば、クライアントが気づく。protected URLs. Lose rankings on any of these and the client will notice.
具体的に確認すべきことは：
- Drupalサイトに既に存在する重複コンテンツ(マイグレーション後ではなく、前に修正しろ) already existing on the Drupal site (fix it before migrating, not after)
- 200語未満の薄いコンテンツページで何もランクしていないもの -- これらはマイグレーションするのではなく、統合または削除できる under 200 words that rank for nothing -- these can be consolidated or deleted rather than migrated
- /node/1234のような非標準URLパターン。Pathautoがアクティブな場合でもDrupalが時々公開するURL。 like
/node/1234URLs that Drupal sometimes exposes even when Pathauto is active - ランクしているタクソノミーアーカイブページ -- /tags/、/category/、/topic/パスで実際のSearch Consoleインプレッションを持つもの that rank --
/tags/,/category/,/topic/paths that have actual Search Console impressions
これが常に人々を引っかかる。Drupalのタクソノミータームページはロングテールクエリに対してランクしていることが多い。同等のWordPressタクソノミーアーカイブを再作成してリダイレクトを設定しなければ、受動的なトラフィックを捨てているのと同じだ。and redirect the old paths, you've just thrown away passive traffic.
---
ステップ2：URLマッピング -- 誰もが作りたくないスプレッドシート
つまらない？そうだ。避けられない？それもそうだ。
Google Sheetsでやる(またはAirtableでやっても良い、両方使っている)。URL マップを構築しろ。列Aはすべてのdrupal URL。列Bはそれが解決するWordPress URL。列Cはステータスだ。exact match、redirect needed、consolidate、deleteのいずれかだ。exact match,redirect needed,consolidate, or delete.
300ページのサイトであれば、これは半日かかる。8,000ページのサイト -- Seahawk Mediaが2021年に高等教育クライアント向けに対応したもの -- なら3人のチームで約4営業日とそれはもう本当に退屈な金曜夜がかかる。毎回の価値がある。
私が従うルールをいくつか：
- 可能な限りスラッグを保持する。Drupalが/blog/how-to-fix-crawl-errorsを持っていれば、WordPressに同じスラッグを使わせる。ほとんどの場合できる。WordPress Settings → Permalinksのパーマリンク設定により、Drupalが使用していたパターンに一致させることができる。If Drupal has
/blog/how-to-fix-crawl-errors, make WordPress use the same slug. Most of the time you can. The permalink settings in WordPress Settings → Permalinks let you match whatever pattern Drupal was using. - ホームページへのリダイレクトは絶対にしない。怠け者の開発者がやることだ。リンク評価が失われ、ユーザーも混乱する。古いURLはすべて特定の宛先に向ける。Lazy devs do this. It kills link equity and confuses users. Every old URL gets a specific destination.
- ページネーションURLに気をつけろ。Drupalのページネーションは?page=1のように見える。WordPressは/page/2/を使う。これらをマップするか、404のままにするか（通常は問題ない -- ページネーションページはめったに有意なリンクエクイティを保有しないが、GSCで確認してから）。Drupal pagination looks like
?page=1. WordPress uses/page/2/. Map these or leave them as 404s (which is usually fine -- paginated pages rarely hold meaningful link equity, but confirm in GSC first). - クエリ文字列は別々に扱う。/search?keys=wordpress のようなものはリダイレクトが不要だ。/events?date=2023-06 は、そのページがランクしているかどうかによって必要になるかもしれない。Things like
/search?keys=wordpressdon't need redirects./events?date=2023-06might, depending on whether those pages rank.
---
ステップ3：コンテンツマイグレーション -- FG Drupal to WordPressと実際に起こること
FG Drupal to WordPress プラグインがほとんどのマイグレーションの重い部分を担う。Drupal データベースに直接接続し、ノード、ユーザー、タクソノミーターム、メディアを取得する。Drupal 7 では完璧に動作する。Drupal 9/10 では、プレミアム版が必要だ。前回確認したときは約€99 だった。手動マイグレーションと比べればすべての費用の価値がある。FG Drupal to WordPress plugin does the heavy lifting for most migrations. It connects directly to your Drupal database, pulls nodes, users, taxonomy terms, and media. For Drupal 7, it works brilliantly. For Drupal 9/10, you'll need the premium version, which is about €99 last time I checked. Worth every penny versus manual migration.
プラグインがうまく処理すること：
- ノードのボディコンテンツ（メディアパスを正しく設定すれば埋め込み画像を含む）
- WordPressのカテゴリー・タグにマッピングされたタクソノミーターム
- プレミアム版を利用している場合、基本的なカスタムフィールド
手作業で修正が必要な項目:
- Drupal Views――これらはカスタムページレイアウト/クエリです。WordPress では WPGridBuilder などのプラグインを使うか、単純にカスタム WP_Query ループで再構築します -- these are custom page layouts/queries. You'll rebuild these in WordPress using plugins like WPGridBuilder or just custom WP_Query loops
- Webforms――Gravity Forms または WPForms に手動でマッピングします。ロジックは転送されません -- map these to Gravity Forms or WPForms manually; the logic doesn't transfer
- 複雑なフィールドグループ――Drupal の Field API は本当に変わったデータ構造をサポートしています。これらを CSV にエクスポートして WP All Import 経由でインポートする必要があります -- Drupal's Field API supports some genuinely weird data structures. You'll need to export these to CSV and import via WP All Import
- ブロックコンテンツリージョン――Drupal のブロックシステムは WordPress のウィジェット/FSE ブロックとは全く別物です。移行タスクではなく、設計上の判断です -- Drupal's block system is nothing like WordPress widgets/FSE blocks. Design decision, not a migration task
FG Drupal to WordPressが完了した後、私がいつもすることは行数をカウントすることです。Drupalに何個のノードがありましたか？WordPressに何個のポスト/CPTエントリがありますか？意図的に除外したもの以外は一致するはずです。5,000ノードのサイトで3%の不一致は150ページがなくなっているということです。見つけてください。
---
ステップ4: サーバーを破壊しないリダイレクトの実装
URL マップが作成され、コンテンツが WordPress ステージング環境でライブになったら、リダイレクトの時間だ。2 つのツールがある。小規模サイト（約 1,000 リダイレクト以下）には Redirection プラグイン、Apache 上のより大規模なサイトには .htaccess ルール、Nginx には nginx.conf ブロックを使う。Redirection plugin for smaller sites (under ~1,000 redirects) and.htaccess rules for anything larger on Apache, or nginx.conf blocks on Nginx.
なぜこの分割か？RedirectionプラグインはリダイレクトをPHPを経由して処理するため、リダイレクトチェックのたびにサーバーヒットが発生します。5,000リダイレクトで1日50,000ページビューの場合、これは実際のオーバーヘッドです。サーバーレベルのリダイレクトは1桁以上速くなります。
大規模なマイグレーションでは、Google Sheets から URL マップをエクスポートして、RewriteRule ブロックを生成するクイックスクリプトを書き、ゴーライブ前に .htaccess に入れ込む。20 分かかる。ゴーライブ後のサイト速度低下のデバッグに何時間も費やすことを避けられる。RewriteRule blocks, and drop them into.htaccess before go-live. Takes 20 minutes. Saves hours of debugging a sluggish site post-launch.
人が考えていないこと：リダイレクトチェーンだ。Drupal が既にリダイレクトを設定していた場合（多くの成熟した Drupal サイトが Redirect モジュール経由で行っている）、それらを見つけてチェーンを折りたたむ必要がある。A → B → C は A → C になる必要がある。Google 独自のドキュメントでは、チェーンが PageRank の転送を遅くすることは明確だ。排除しないにしても。redirect chains. If Drupal already had redirects in place (many mature Drupal sites do, via the Redirect module), you need to find those and collapse the chain. A → B → C needs to become A → C.Google's own documentation is pretty clear that chains slow down PageRank transfer, even if they don't eliminate it.
---
ステップ 5: ローンチ後――72 時間ウィンドウ
火曜日または水曜日にライブに移行します。金曜日は絶対に避けてください。2018 年のクライアント案件でこれを身をもって学びました――1,200 ページの移行を金曜日の午後にローンチしたところ、午後 6 時にパーマリンク構造の設定ミスが発見されました。月曜日までに Google がすでに壊れた URL の波をクロールしてインデックスしていました。
最初の72時間で監視する内容は以下の通りです:
- GSC カバレッジレポート――404 のスパイクを監視してください。一部は予想されるもの（古い Drupal システムパス）です。マネーページ全体のスパイクは違います。 -- watch for a spike in 404s. Some are expected (old Drupal system paths). A spike across your money pages is not.
- Screaming Frog の再クロール――ローンチの翌朝にライブ WordPress サイトをクロールします。URL 数を移行前のベースラインと比較します。 -- crawl the live WordPress site the morning after launch. Compare URL count to your pre-migration baseline.
- リダイレクトの抜き取り検査――GSC から上位 20 番目までのトラフィック Drupal URL を手動でテストします。それらをブラウザに貼り付けます。期待した場所にランディングしていますか？ -- manually test your 20 highest-traffic Drupal URLs from GSC. Paste them into a browser. Do they land where they should?
- カノニカルタグ――WordPress がすべてのページで正しいカノニカルを出力していることを確認します。Yoast と Rank Math の両方が自動的にこれを行いますが、いずれにしろ確認してください。 -- confirm WordPress is outputting the right canonical on every page. Yoast and Rank Math both do this automatically, but check anyway.
- XMLサイトマップ送信 — GSCで新しいサイトマップをすぐに送信してください。Googleが見つけるのを待たないでください。 -- submit the new sitemap in GSC immediately. Don't wait for Google to find it.
ほとんどの人がスキップすることで、私が実施していることの一つは、ローンチ後にGSCで古いDrupal XMLサイトマップも送信することです。一時的に古いドメインまたはサブドメインを保持していた場合はそこを指定してください。これにより、Googleに対して正確にどの古いURLをクロールするか、リダイレクトをたどるか、インデックスをより速く更新するかを指示できます。submit the old Drupal XML sitemap in GSC as well, after launch, pointing at the old domain or subdomain if you kept it up temporarily. This tells Google exactly which old URLs to crawl, follow the redirects, and update its index faster.
---
ステップ6：30日間のSEO健全性チェック
マイグレーションはゴーライブで終了ではありません。インデックスの更新には時間がかかります。30日目の時点で私が確認する内容は以下の通りです：
- ランキング位置の変動 — AhrefsまたはSemrushを使って、マイグレーション前30日間と後30日間のキーワード順位を比較してください。一部のキーワードで軽微な変動（5～10位）は予想されます。主要キーワードで30位以上の下落が見られた場合は調査が必要です。 -- use Ahrefs or Semrush to compare keyword positions 30 days pre-migration vs. 30 days post. Expect minor fluctuation (5-10 positions) on some terms. A drop of 30+ positions on a primary keyword needs investigation.
- バックリンク対象 — 特定のDrupal URLを指す外部バックリンクがあった場合、それらのURLが正しくリダイレクトされているか確認してください。Ahrefsの「Lost Backlinks」レポートでこれが表示されます。壊れたバックリンク対象は、あなたが積極的に失っているリンクエクイティです。 -- if you had external backlinks pointing to specific Drupal URLs, check that those URLs are redirecting cleanly. Ahrefs' Lost Backlinks report surfaces this. Broken backlink targets are link equity you're actively haemorrhaging.
- ページスピードの低下 — WordPressサイトは、よくチューニングされたDrupalサイトよりも遅くなることがあります。最も重要な5ページについてLighthouse監査を実行し、マイグレーション前のベースラインと比較してください。 -- WordPress sites are sometimes slower than well-tuned Drupal sites. Run a Lighthouse audit on your 5 most important pages and compare to your pre-migration baseline.
- インデックス率 — 送信したURLのうち、何個がインデックスされていますか？30日目の時点で、メインコンテンツページの少なくとも80%がインデックスされていることが目標です。60%未満の場合はクロール可能性の問題を示唆しています（robots.txtを確認し、WordPress設定の「表示設定」でGooglebotを誤ってブロックしていないか確認してください）。 -- how many of your submitted URLs are indexed? At 30 days, you want at least 80% of your main content pages indexed. Anything under 60% suggests a crawlability problem (check robots.txt and make sure you didn't accidentally block Googlebot in WordPress Settings → Reading).
Seahawk は去年、フィンテック クライアントを抱えていて、30 日のチェックで 340 の製品ページが、マイグレーション中に Yoast の誤設定されたバルク アクションで誤って noindex に設定されていることが判明した。30 日で捕捉：午後で修正可能。6 か月で捕捉：おそらくまだ埋めようとしているランキングの穴だ。noindex by a misconfigured Yoast bulk action during migration. Caught at 30 days: fixable in an afternoon. Caught at 6 months: probably a ranking hole you're still trying to fill.
---
よくある質問
Drupal から WordPress への移行には実際どのくらい時間がかかりますか？
サイトのサイズとコンテンツの複雑性に完全に依存します。50ページのブロシュアサイト：QAを含めて2～3日。5,000ページのニュースアーカイブでカスタムコンテンツタイプ使用：6～10週間。SEO作業 — 監査、URLマッピング、リダイレクト実装、本番後の監視 — は通常、コア開発見積もりの30～40%を追加します。これ以外のことを言う人の話は聞かないでください。
Drupal から WordPress に移行した後、ランキングを失いますか？
短期的な変動は正常であり、ほぼ必然です。URLマッピング、リダイレクト、canonicalタグを正しく実装していれば、ほとんどのランキングは6～12週間以内に安定します。私が見た永続的な損失を被ったサイトはすべて同じ問題を持っていました：リダイレクトがない、またはホームページへの一括リダイレクト。作業をしてください。ランキングは戻ってきます。
すべての Drupal コンテンツを移行するべきか、それとも一から始めるべきか？
コンテンツが何をしているかに完全に依存します。GSCデータを取得してください。16ヶ月間でゼロクリック、バックリンクもないコンテンツは、マイグレーションするより削除する候補です。薄い、価値の低いコンテンツをマイグレーションするとWordPressサイトが肥大化し、クロールバジェットが分散される可能性があります。厳しく判断してください。ただし、ページ自体がどんなに悪かったとしても、外部バックリンクがあるURLは決して削除しないでください — 関連のあるものにリダイレクトしてください。
Drupal 移行後に使用するのに最適な WordPress テーマはどれですか？
正直なところ、テーマの選択は、適切に構造化された HTML を使用していて、ページ速度をチェックしている場合、SEO への影響はほぼない。私は GeneratePress をそのクリーンなマークアップと最小限のオーバーヘッドのために、あるいはクライアントがより多くの設計の柔軟性を望む場合は Kadence をデフォルトにしている。ページビルダーが重いテーマは避ける。毎回のページロードで 400KB の未使用 CSS を出力するからだ。GeneratePress for its clean markup and minimal overhead, or Kadence if the client wants more design flexibility. Avoid page-builder-heavy themes that output 400KB of unused CSS on every page load.
開発者が必要ですか、それとも自分でできますか？
50ページ以下の小規模サイトで、シンプルなコンテンツとカスタムポストタイプがない場合？FG Drupal to WordPressとRedirectionプラグインで、上記のステップに従うことで対応可能です。それより大規模なサイト、CPT、複雑なタクソノミー、または意味のある既存のSEOフットプリントがあるもの — 開発者を雇ってください。失敗したマイグレーションを修正するコストは、最初から正しく実施するコストより常に高くなります。
---
マイグレーション自体はジョブの40%です。残りの60%は、あなたが構築するSEOインフラストラクチャ です — マッピング、リダイレクト、監視、勝利を宣言する前にデータを30日間見守る忍耐力。美しく構築されたWordPressサイトが検索で沈んだのを見ました。理由はリダイレクト作業がずさんだったから。そして、URLマップが細心だったから、ほぼテーマなしのWordPressインストールがすべてのランキングを保持したのを見ました。
つまらない部分を正しくやってください。残りはたいてい後からついてきます。