?>

SEOを失わずにWordPressからカスタムPHPに移行する – 完全な7ステップガイド

WordPressからカスタムPHPコードベースに切り替えると、TTFBを70％削減し、プラグインの脆弱性を排除し、100％の所有権を得ることができます。しかし、リダイレクトとメタデータの処理を誤ると、ランキングが急落します。私は30以上のWordPressサイトを移行してきました – ここではSEOを維持（そしてしばしば改善）する正確なプロセスを紹介します。

なぜWordPressからカスタムPHPに移行するのか？

• パフォーマンスが遅い – キャッシュを使っても、WordPressは847KB以上のJavaScriptを読み込みます。
• プラグインの脆弱性 – ハッキングされたWordPressサイトの96％は古いプラグインが原因です。
• 月額料金 – プレミアムプラグイン、WP向けに最適化されたホスティング、メンテナンスがかさみます。
• ロックイン – あなたはコードを所有していません。投稿のデータベースとテーマを所有しているだけです。

カスタムPHPは完全な制御、サブ秒の読み込み時間、そして月額プラットフォーム料金ゼロを提供します。しかし、移行は完璧でなければなりません。

始める前に：移行前監査

• すべてのURLをエクスポート – Screaming Frog（500 URLまで無料）またはwgetを使用：wget --spider --force-html -r -l 3 https://yoursite.com 2>&1 | grep '^--' | awk '{ print $3 }' > urls.txt
• ランキングを記録 – Google Search Console（パフォーマンスレポート）からトップ100キーワードをエクスポートします。
• メタデータを保存 – Screaming Frogはタイトルタグ、メタディスクリプション、H1をCSVとしてエクスポートできます。
• バックリンクを文書化 – Search Console → リンク → 外部リンク、または利用可能な場合はAhrefs/SEMrushを使用します。

ステップ1：古いサイトをクロールする（Screaming Frog徹底分析）

Screaming Frog SEO Spiderをダウンロード（500 URLまで無料）。以下の抽出用に設定します：

1. すべての内部URL。
2. タイトルタグとメタディスクリプション。
3. カノニカルタグ。
4. H1見出し。
5. レスポンスコード（200、301、404）。

CSVとしてエクスポートします。このファイルが移行マップになります。これを使用して、既存のすべてのページに宛先があることを確認します。

ステップ2：URLを新しい構造にマッピング – 可能であれば同一に保つ

最も安全なアプローチ：まったく同じURLパスを維持する。WordPressのURLがクリーンな場合（例：/services/web-design）、再利用できます。構造を変更するのは以下の場合のみ：

• WordPressのURLに/2023/01/post-name/（日付）が含まれている場合 – 日付を削除します。
• /category/と/tag/アーカイブから重複コンテンツがある場合 – それらを削除します。

ブログのマッピング例：

/2023/01/why-custom-php → /blog/why-custom-php
/category/performance → /blog/category/performance（オプション、カテゴリページは削除可能）
/tag/seo →（削除 – タグページは権威を希釈することが多い）

2列のCSVを作成します：old_url、new_url。再作成しないページ（例：タグアーカイブ）は、最も近い関連ページにリダイレクトします。

ステップ3：WordPressからコンテンツをエクスポート

方法A – WP REST API（小規模サイトに最適）

<code>&lt;?php<br>$posts = json_decode(file_get_contents('https://yoursite.com/wp-json/wp/v2/posts?per_page=100&page=1'));<br>foreach ($posts as $post) {<br>    $data = [<br>        'title' => $post->title->rendered,<br>        'slug' => $post->slug,<br>        'content' => $post->content->rendered,<br>        'excerpt' => $post->excerpt->rendered,<br>        'date' => $post->date,<br>        'meta' => [<br>            'title' => get_post_meta($post->id, '_yoast_wpseo_title', true),<br>            'description' => get_post_meta($post->id, '_yoast_wpseo_metadesc', true)<br>        ]<br>    ];<br>    // カスタムMySQLテーブルに挿入<br>}<br>?&gt;</code>

方法B – WP CLI（大規模サイトに最速）

<code>wp export --dir=/tmp --post_type=post,page --with_attachments</code>

方法C – 直接MySQL（完全な制御）

<code>SELECT ID, post_title, post_name, post_content, post_date FROM wp_posts WHERE post_status = 'publish' AND post_type IN ('post', 'page');</code>

次に、wp_postmetaからYoast SEOメタデータを取得します。meta_key IN ('_yoast_wpseo_title','_yoast_wpseo_metadesc')。

ステップ4：同じメタデータでカスタムPHPサイトを再構築

• まったく同じ<title>タグ（YoastまたはAll in One SEOから）。
• 同じ<meta name="description">。
• 同じ<h1>（ただし、小さな変更は通常問題ありません）。

メタデータをデータベース（例：page_metaテーブル）またはPHP配列に保存します。動的サイトの場合、移行中はWordPressデータベースを読み取り専用ソースとして保持することもできます – ただし、複雑さが増します。

ステップ5：301リダイレクトを実装する（最も重要なステップ）

301リダイレクトはGoogleに「このページは恒久的に移動しました」と伝えます。Googleは古いページのランキングパワーのほぼ100％を新しいURLに転送します。

Apacheの場合（.htaccess） – 200未満のリダイレクトに最適

<code>Redirect 301 /old-url /new-url<br>Redirect 301 /2023/01/why-custom-php /blog/why-custom-php</code>

数千のリダイレクトの場合 – PHPマップを使用（.htaccessの肥大化を回避）

<code>&lt;?php<br>$redirects = json_decode(file_get_contents(__DIR__ . '/redirects.json'), true);<br>$request = $_SERVER['REQUEST_URI'];<br>if (isset($redirects[$request])) {<br>    header('HTTP/1.1 301 Moved Permanently');<br>    header('Location: ' . $redirects[$request]);<br>    exit;<br>}<br>?&gt;</code>

Nginxの場合 – mapディレクティブを使用

<code>map $request_uri $new_uri {<br>    /old-url /new-url;<br>    /2023/01/why-custom-php /blog/why-custom-php;<br>}<br>server {<br>    if ($new_uri) {<br>        return 301 $new_uri;<br>    }<br>}</code>

プロのヒント： リダイレクトを連鎖させないでください（A → B → C）。各ホップはリンクの価値をわずかに失います。常に直接A → Cにリダイレクトします。

ステップ6：動的XMLサイトマップを生成する

静的サイトマップを使用しないでください – 古くなります。代わりに、XMLを動的に出力するsitemap.phpを作成します：

<code>&lt;?php<br>header('Content-Type: application/xml');<br>echo '&lt;?xml version="1.0" encoding="UTF-8"?&gt;';<br>echo '&lt;urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"&gt;';<br>$pages = getAllPageUrlsFromDatabase(); // カスタム関数<br>foreach ($pages as $url) {<br>    echo '&lt;url&gt;&lt;loc&gt;' . htmlspecialchars($url) . '&lt;/loc&gt;&lt;lastmod&gt;' . date('Y-m-d') . '&lt;/lastmod&gt;&lt;/url&gt;';<br>}<br>echo '&lt;/urlset&gt;';<br>?&gt;</code>

次に、.htaccessにリライトルールを追加します：

<code>RewriteRule ^sitemap\.xml$ sitemap.php [L]</code>

起動後すぐにサイトマップをGoogle Search Consoleに送信します。

ステップ7：起動して30日間監視する

1. すべてのリダイレクトをチェック – クローラー（Screaming Frog）を使用してすべての古いURLにアクセスし、新しいURLに301を返すことを確認します。
2. 毎日Google Search Consoleの「カバレッジ」レポートを監視 – 404エラーを探します。各404に対して、欠落しているリダイレクトを追加するか、壊れたリンクを修正します。
3. 新しいサイトマップを送信 – Search Consoleで、サイトマップ → 新しいサイトマップを追加（sitemap.xml）に進みます。
4. Core Web Vitalsを監視 – 1週間以内に改善が見られるはずです。見られない場合は、画像、CSS、またはサーバー設定をデバッグします。
5. 4週間後にランキングを比較 – GSCデータを再度エクスポートします。ほとんどのクライアントは変化がないか、読み込み時間の短縮によるわずかな改善を見ます。

一般的な落とし穴とその回避方法

落とし穴1：リダイレクトなしでURLを変更する

症状：Search Consoleで404エラー。

修正：公開前にPHPリダイレクトマップを実装します。

落とし穴2：メタディスクリプションの移行を忘れる

症状：Googleがランダムなテキストでスニペットを書き換える。

修正：ステップ1と同じメタデータエクスポートを使用します。

落とし穴3：画像（メディアファイル）を失う

症状：カスタムサイトで画像が壊れている。

修正：/wp-content/uploads/フォルダ全体を新しいサイトのパブリックディレクトリにコピーします。フォルダを移動した場合は、/wp-content/uploads/...から/uploads/...へのリダイレクトを設定します。

落とし穴4：混合コンテンツの警告（HTTP画像）

症状：ブラウザがHTTPSで「安全でないコンテンツ」を表示する。

修正：データベース内の古い画像URLをhttp://oldsite.comからhttps://newsite.comに検索して置換します。

実際のクライアント事例：500ページのビジネスサイト移行

ある全国フランチャイズネットワークには、500以上のロケーションページを持つWordPressサイトがあり、各ページには独自のコンテンツがありました。読み込み時間は2.8秒（モバイル）で、ホスティングとプラグインに月額300ドルを支払っていました。

プロセス：

• WP CLIを使用してすべてのロケーションデータをエクスポート。
• MySQLからロケーションデータを取得する単一のPHPテンプレートでカスタムPHPサイトを再構築。
• URL構造を同一に維持（/locations/city-state/）。
• 301リダイレクトにPHPマップを使用（URLは変更されなかったが、安全のためにマップを保持）。

60日後の結果：

• TTFB：800ms → 180ms。
• Lighthouseパフォーマンス：58 → 96。
• ホスティングコスト：300ドル/月 → 30ドル/月（標準VPS）。
• ランキング：ロケーションページの87％で改善（速度による）。
• オーガニックトラフィック：+23％（3ヶ月以内）。

クライアントは現在、コードを完全に所有し、プラグイン費用を支払わず、シンプルなCSVアップロードで新しいロケーションを即座に追加できます。

移行すべきか？意思決定フレームワーク

以下の場合、カスタムPHPに移行します：

• サイトがほとんど静的な場合、または予測可能なコンテンツ（ブログ＋サービス）がある場合。
• プラグインのメンテナンスとセキュリティアップデートにうんざりしている場合。
• 100％のコード所有権と月額プラットフォーム料金ゼロを望む場合。

以下の場合、WordPressに留まります：

• 高度なEコマースが必要な場合（ただしカスタムPHPでも処理可能）。
• WooCommerce拡張機能に大きく依存している場合。
• チームが非技術的でWP管理画面に慣れている場合。

切り替える準備はできましたか？

私は30以上のWordPressサイトをカスタムPHPに移行してきました – 小さなブログから2,000ページのEコマースストアまで。コンテンツのエクスポート、URLマッピング、301リダイレクト、メタデータの保持、起動後の監視まで、すべてを処理します。

あなたのカスタムPHPサイトは0.8秒未満で読み込み、Lighthouseで100を獲得し、二度とプラグイン費用を支払うことはありません。

すべてのデータはBuiltToWinWebが実施した実際のクライアント移行に基づいています。個々の結果はサイトの複雑さとコンテンツによって異なる場合があります。