WordPress から静的サイトへ、社名で検索1位を守ったまま移行した全手順

WordPress から静的サイト（HTML のファイルを置くだけのサイト）へ移す時に検索の順位を守る要は、古い URL を1つも取りこぼさずに 301 リダイレクト（恒久的な転送）で新しい URL へつなぐことと、表示を止めない順番で切り替えることです。私たちは、新しいサイトを先に置き、WordPress を最後に退避する順番で、どの段階からでも元に戻せるように進めました。

アステロイドテクノロジーの公式サイトを、WordPress から、手で書く静的なサイト（HTML のファイルを置くだけのサイト）に移しました。 社名で検索した人が、いつものように1番上で私たちのサイトにたどり着けること。それを崩さないことを、移行のいちばんの条件にしました。

この記事は、その移行で実際に使った手順書と、作業の記録から書いています。作ったのはオーナーと Claude（AI）です。手順書を Claude が書き、オーナーとチャットの Claude が確かめてから、2026年10月11日の夕方に、オーナーが手順書を見ながらサーバーで実行しました。

なぜ WordPress をやめて静的サイトにしたのか

正直に言うと、このサイトはずっと手を付けられないままでした。最後の記事は2022年。古くなりすぎて、どこから直せばいいのか分からず、更新すること自体を諦めていました。

作り直そうと決めた時、オーナーにはもう1つ、はっきりした考えがありました。これからは、サイトの更新も Claude に指示を出して進めていきたい。そうなると、管理画面を開いて、ボタンや入力欄を手で操作して直していく WordPress は合いません。ページを HTML のファイルとして持ち、Claude が直接書き換えられる形にしよう。WordPress はもう使わない、と決めました。

それでも、捨てたくないものがありました。

1つは、社名で検索すると一番上に出てくる、今のサイトの評価です。何年もかけて付いたもので、作り直したせいで消えてしまっては困ります。もう1つは、アプリの中から開いているプライバシーポリシーや利用規約の URL です。アプリはすでに利用者の手元にあり、その中のリンクは簡単には変えられません。

WordPress はやめたい。けれど、この2つは手放したくない。この記事の手順は、ほとんどがこの2つを守るためのものです。

ちなみに、作り直す前のサイトに載っていたのは、2021年と2022年の記事が4本（どれも制作実績の紹介）と、会社概要やお問い合わせなどの固定ページが数枚で、移す中身は多くありませんでした。

検索の評価は URL に付いている

移行でいちばん怖いのは、検索の順位が落ちることです。私たちがまず確かめたのは、「評価はどこに付いているか」でした。

検索エンジンは、ページを URL ごとに覚えています。WordPress のページの URL が変わったり消えたりすると、その URL は「見つかりません（404）」になり、それまでの評価をつなぐ先が無くなります。

そこで、次の2つを決めました。

• 同じ URL で続けられるページは、URL を変えない。トップ、/privacy/、/terms/、/tokushoho/ は、同じ URL のまま中身だけを新しくする
• URL が変わるページは、すべて 301 で新しい URL へ転送する。一時的な転送（302）は使わない

あわせて、新しいサイトには全ページの正規URL（canonical）と sitemap.xml を入れ、検索エンジンに「これが新しい住所です」と伝えられるようにしました。

何を残して、何を転送したか

古いURLを、1つ残らず洗い出す

転送の一覧（redirect-map.txt）は、今の公開サイトから作りました。WordPress が自動で作る wp-sitemap.xml と、トップページのリンクを curl で読み取り、載っている URL をすべて書き出しています。

$ curl -s https://あなたのドメイン/wp-sitemap.xml
$ curl -s https://あなたのドメイン/wp-sitemap-posts-post-1.xml | grep -o '<loc>[^<]*'

出てきた URL を、行き先ごとに分けました。

記事の URL には、末尾に /feed/ や /amp/ が付いたものもあります。これも同じ行き先へ送るように、転送の書き方を「その下も含めて」にしました。

この表は、切り替えた時点の行き先です。切り替えた日の夜、Google の検索結果で古い「ブログ」と「公式HP刷新のお知らせ」のページが目立つ場所に出ていたので、この2つは、中身のより近い行き先へ変えることにしました。/ブログ/ は新しいブログ（/astech-blog/）へ、「公式HP刷新のお知らせ」はこの記事へ、どちらも 301 で送ります。

ホームページ制作WordPress が黙って行っていた転送を、止める前に洗い出す方法「x-redirect-by: WordPress」は、WordPress が PHP の中で転送した時に付く応答の見出しです。.htaccess に転送の行が無いのに古い URL が転送されていたら、正体は WordPress 自身。止めると全部消えるので、curl で見分けて .htaccess に書き直した手順です。

公開フォルダの中身を、3つに分ける

公開フォルダ（public_html）には、WordPress のほかにも、アプリの紹介ページや、アプリが使うファイル、サブドメインの実体のフォルダが同じ場所に入っていました。中身を1つずつ確かめて、「残す」「置く」「退避する」の3つに分けました。

新しい .htaccess を、Mac で試してから使う

転送の規則は、新しい .htaccess に書きました。作っている途中で、気をつけることが3つ見つかりました。

1つ目は、public_html の .htaccess が、その下にあるサブドメインのフォルダにも効くことです。何も考えずに転送を書くと、サブドメインで動いているアプリまで転送してしまいます。そこで、転送と 404 のページは、本体のドメインへの接続だけに効くように条件を付けました。

2つ目は、Xserver では、前にある nginx が https を受けてから、うしろの Apache へ渡していることです。Apache から見ると http の接続に見える場合があるので、https の判定には X-Forwarded-Proto という見出しも見るようにし、転送先は https:// から始まる完全な URL で書きました。

3つ目は、.htaccess を UTF-8 で保存することです。/会社概要/ のような日本語の URL を、そのまま書いているためです。

# www 付きを www なしへ（WordPress がしていた転送を書き直したもの）
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

# 本体のドメイン以外（サブドメイン）は、ここから下の転送を使わない
RewriteCond %{HTTP_HOST} !^example\.com$ [NC]
RewriteRule ^ - [L]

# http から https へ（前の nginx が https で受けた接続は除く）
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

# 日本語のURLも、そのまま書ける（ファイルは UTF-8 で保存）
RewriteRule ^会社概要/?$ https://example.com/astech-company/ [R=301,L]

この .htaccess は、いきなりサーバーには置きませんでした。Mac の Apache で、転送、https、404、サブドメインへの影響を試してから使っています。

バックアップを取り、照合する

作業の前に、サーバーのファイルとデータベースを Mac に保存しました。

• 公開フォルダ全体を固めたファイル
• 元の .htaccess の写し
• WordPress のデータベースの書き出し

それぞれの指紋（SHA-256 の値）を記録したファイルも作り、保存した中身が壊れていないことを照合してから、次へ進みました。今回の移行ではデータベースに一切触らないので、データベースのバックアップは「万一の最後の手段」という位置づけです。

本番と同じ環境で、誰にも見せずにリハーサルする

新しいサイトは、本番と同じサーバーの中に確認用のサブドメインを作り、そこに置いて試しました。Mac の上で動いても、Xserver の上で同じように動くとは限らないからです。

確認用のサイトには、次の3つを設定しました。

• サーバーパネルの「アクセス制限」で、ID とパスワードを入れないと開けないようにする
• すべての応答に「X-Robots-Tag: noindex, nofollow」を付け、検索エンジンに載せない
• 確認用のフォルダの .htaccess に RewriteEngine On を書き、親（本番の public_html）の WordPress の書き換えが効かないようにする

リハーサルは、オーナーが手順書どおりに行い、次の項目がすべて合格でした。

• パスワード無しで開くと 401（開けない）
• 全13ページが 200 で開く
• WebP の画像が image/webp という正しい種類で返る
• 存在しない URL で、新しい 404 のページが出る
• ページと画像と 404 の応答に、X-Robots-Tag: noindex が付く
• お問い合わせのページに Cache-Control: no-store, private が付き、2回開くと「券」の値が毎回違う
• 手元で試すための仕組み（試験用の切り替え）が、サーバーの上では無効になっている
• お問い合わせから実際に送ったメールが、会社の受付のアドレスに届く

お問い合わせのフォームには、Xserver のサーバーキャッシュならではの落とし穴があり、これも別の記事にまとめています。

ホームページ制作Xserver のサーバーキャッシュで、お問い合わせフォームが送れなくなる理由と対処Xserver のサーバーキャッシュに PHP のお問い合わせフォームが載ると、全員に同じ CSRF トークン（送信を確かめる「券」）が配られて送れなくなります。対処は Cache-Control: no-store, private を毎回返すこと。session_start の落とし穴と、本番で curl で確かめる方法まで。

表示を止めない切り替えの順番

いちばん考えたのが、切り替えの順番です。古いファイルを先に片付けてから新しいファイルを置くと、その間はサイトが表示されません。そこで、逆の順番にしました。

この順番で表示が途切れないのは、WordPress の書き換えの規則が「実在しないファイルとフォルダ」だけを WordPress に渡す作りだからです。新しいサイトの privacy フォルダを置いた瞬間から、/privacy/ は新しいページが表示されます。まだ置いていないページは、今までの WordPress のページが表示されます。

1. 新しいサイトを、公開フォルダの外に上げる

   公開フォルダの1つ上の階層に置き場所を作り、そこへ送ります。この時点では、公開中のサイトに何の影響もありません。送る前に Mac 側の権限（フォルダ 755、ファイル 644）を確かめ、送ったあとは中身を照合します。

   Macで実行

   $ find public -type d ! -perm 755; find public -type f ! -perm 644
   $ rsync -avn --exclude='.DS_Store' -e 'ssh -p ポート番号' \
     public/ ユーザー名@あなたのサーバー:/home/ユーザー名/ドメイン/site-new/
   $ rsync -av --exclude='.DS_Store' -e 'ssh -p ポート番号' \
     public/ ユーザー名@あなたのサーバー:/home/ユーザー名/ドメイン/site-new/

   1行目で何も出ないことを確かめてから、2行目の試し送り（-n。何も送らずに一覧だけを出す）で、送るファイルの数と送り先を確かめます。--delete は使いません。

2. 新しいサイトを、公開フォルダへ1つずつ移す

   CSS と画像（assets、img）を最初に、トップの index.html を最後に移します。index.html を先に置くと、新しいトップのリンク先（まだ置いていないページ）が、WordPress の「見つかりません」になってしまうからです。

   サーバーで実行

   $ mv -n /home/ユーザー名/ドメイン/site-new/assets /home/ユーザー名/ドメイン/public_html/assets
   $ ls -la /home/ユーザー名/ドメイン/public_html/

   移すのは名前を書いて1つずつ。* のような「全部」を指す書き方は使わず、mv には -n（移し先に同じ名前があれば上書きしない）を付け、1つ移すたびに ls -la で確かめます。

3. .htaccess を差し替える

   今の .htaccess の写しを、退避用のフォルダに取ってから差し替えます。差し替えた瞬間から、古い URL の転送が始まります。

   サーバーで実行

   $ cp -p /home/ユーザー名/ドメイン/public_html/.htaccess /home/ユーザー名/ドメイン/wp-retired/htaccess.orig
   $ mv /home/ユーザー名/ドメイン/site-new/htaccess.new /home/ユーザー名/ドメイン/public_html/.htaccess
   $ chmod 644 /home/ユーザー名/ドメイン/public_html/.htaccess

   差し替えたら、すぐに Mac から curl で、トップが 200 になること、http の転送が1回で終わることを確かめます。転送が止まらない、500 になる、という時は、すぐに写しで戻します。

4. WordPress を公開フォルダの外へ退避する

   WordPress のファイルとフォルダ20個を、1つずつ退避用のフォルダへ移します。消しはしません。index.php は最初に移します。

5. サーバーキャッシュを消して、確かめる

   サーバーパネルでサーバーキャッシュを消し、Mac から curl で、ページ・転送・404 を1つずつ確かめます。

実際の切り替え

2026年10月11日の夕方、オーナーが手順書を見ながら、Mac とサーバーの2つのターミナルを開いて実行しました。新しいサイトを先に置き、.htaccess を差し替え、最後に WordPress を退避する。この順番どおりに進み、表示は一度も途切れませんでした。

ただ、途中で2回、ひやりとしたことがあります。どちらも被害は無かったのですが、同じ原因でした。

すぐ元に戻せる作り

切り替えでは、何も消していません。WordPress は公開フォルダの外へ移しただけで、データベースにも触っていません。そのため、どの段階で問題が起きても、進んだところから逆の順にたどれば、WordPress の状態に戻せます。

• WordPress を戻す時は、index.php を最後に戻す（ほかの19個がそろう前にトップが WordPress になると、エラーになるため）
• .htaccess は、取っておいた写しで戻す
• 新しいサイトのファイルは、index.html を最初に外へ戻す

切り替えたあとに確かめたこと

切り替えのあと、オーナーが Mac から curl で、ページと転送を1つずつ確かめました。結果は、すべて合格でした。

• 新しいサイトの全14ページが 200 で開く
• http から https、www 付きから www なしへの転送が、どちらも1回で終わって 200 になる
• 古い URL の11件が、すべて予定どおりの行き先へ 301 で転送される
• お問い合わせのページを開くたびに、「券」の値が違う（サーバーキャッシュに載っていない）

検索の順位も確かめました。2026年10月11日18時12分、切り替えた当日の時点で、オーナーが Google で「アステロイドテクノロジー」と検索し、asteroid-technology.com が1位のままであることを確かめています。

この記事を書く前に、Claude がもう一度確かめた結果の一部です。

$ curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' https://www.asteroid-technology.com/
301 https://asteroid-technology.com/
$ curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' http://asteroid-technology.com/
301 https://asteroid-technology.com/
$ curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' https://asteroid-technology.com/talklens/privacy/
301 https://asteroid-technology.com/privacy/#talklens
$ curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' 'https://asteroid-technology.com/?p=268'
301 https://asteroid-technology.com/talklens-support/
$ curl -s -o /dev/null -w '%{http_code}\n' https://asteroid-technology.com/wp-login.php
404

公開前の点検には、自分たちで作った道具も使いました。サイトの中のリンク切れや、検索エンジンに載せない設定の消し忘れを調べるものと、スマホ・タブレット・パソコンの3つの幅で全ページを撮影し、横のはみ出しを調べるものです。

やってみて分かったこと

振り返ると、時間をかけたのは新しいページを作ることよりも、「今のサイトが何をしているか」を調べることでした。WordPress は、私たちが書いた覚えのない転送まで黙って行っていて、それは止めた瞬間に消えます。

もう1つは、すべての手順を「1つずつ、名前で、確かめながら」にしたことです。まとめて消す・まとめて移すという操作を手順書から外したので、途中で何かが起きても、どこまで進んだかがはっきり分かり、戻し方もはっきりしていました。

そして、実際にやってみて一番危なかったのは、コマンドの中身ではなく「どの画面で打つか」でした。今回の2回の取り違えは、たまたま何も起きない形で失敗してくれました。コマンドごとに Mac かサーバーかの印を付け、打つ前に行頭の表示と見比べる。地味ですが、2つの画面を使う作業では、これが一番効きます。

同じように WordPress のサイトを作り直そうとしている方の参考になればうれしいです。