WordPressからAstroへ引っ越し 古いリンクから来た人は どこへ着く？

ブログを引っ越すと、前のブログのリンクから来た人は、どこへ着くのでしょうか？

私は、ブログをWordPress（ワードプレス）から、Astro（アストロ）という新しい作り方へ引っ越しました。

WordPressは、ブログを作るための有名なソフトです。

引っ越したあとも、古いリンクから来た人を、新しい記事へ案内したいと考えました。

ところが、何もしないと、古いリンクの一部は記事に着かず、トップページに着いてしまいました。

しかも、よくある直し方を試すと、トップページが関係のない記事に化けてしまいました。

この記事では、何が起きたのかと、どう直したのかを書いています。

お館様

引っ越しても、古いリンクから来た人は、そのまま記事に着くものではないのかのう？

ジライヤ

拙者もそう思っていたでござる。ところが、そのままでは記事に着かないリンクがあったでござる

こんな方におすすめ

• ブログを別のサービスへ引っ越そうとしている方
• 引っ越したあとの古いリンクが、どうなるのか気になる方
• 古い記事のリンクを、新しい記事へつなぎたい方

全体像

この記事でやったことの流れです。

古いリンクには困りもののリンクが混ざっていました

記事の名前がついたリンクは、引っ越したあともそのまま使えます。

困ったのは、番号がついたリンクでした。

WordPressは、記事ごとに番号つきのリンクも自動で作っています。

たとえば、ブログのアドレスの後ろに「?p=3113」とつく形です。

この番号つきのリンクは、何もしないと新しいサイトでは記事に着かず、トップページが表示されます。

引っ越し前の約1年4か月分を、Googleの無料の道具（Search Console）で調べました。

検索結果に出ていた古いリンクのうち、約4分の3が番号つきのリンクでした。

一番よく出ていたリンクの形だったので、番号つきのリンクも新しい記事へ案内することにしました。

転送の一覧表に書くとトップページが記事に化けました

番号つきのリンクを一覧表に書いて試すと、トップページまで記事に飛んでしまいました。

転送の一覧表は、引っ越しの郵便の転送届のようなものです。

古い住所と新しい住所を、1行ずつ書いておきます。

ところが、この転送届は、リンクの後ろの番号の部分を見分けられません。

公式の説明でも、リンクの後ろの部分は対応していない項目です。

そのため、手元で試すと、トップページへの転送届として動いてしまいました。

試したのは、手元のパソコンでCloudflare Pages（クラウドフレア ページズ）の動きをまねる道具です。

Cloudflare Pagesは、私のサイトを置いている無料のサービスです。

本番のサイトには、この書き方を入れていません。

書いたのは、次の1行です。

/?p=3113 /amazon-domestic-maker/ 301

「古いリンク 新しい記事 301」の順に書きます。

301は「引っ越しました」という合図の番号です。

結果は、トップページを開いても、記事に飛びました。

存在しない番号でも、同じ記事に飛びました。

別々の記事へ飛ばす3行を書いても、すべて1行目の記事に飛びました。

ただし、行き先のリンクには、番号が付いたままでした。

小さなプログラムに対応表を持たせると記事ごとに案内できました

アクセスのたびに動く小さなプログラムに、古い番号と新しい記事の対応表を持たせると、記事ごとに案内できました。

この仕組みは、Cloudflare Pagesの「Pages Functions（ページズ ファンクションズ）」です。

転送の一覧表が読めない番号の部分を、プログラムなら読めます。

案内係のように、番号を見て、対応表にある記事へ案内します。

対応表になければ、いつもどおりのページを表示します。

対応表は、引っ越す前に旧サイトを1件ずつ調べて記録した一覧から作りました。

2026年9月22日の手元の確認でも、全部の記事がその一覧と一致しました。

const ID_TO_SLUG = {
	53: "low-risk",
	105: "opening-of-account",
	3113: "amazon-domestic-maker",
	// …全部で38件
};

export async function onRequest(context) {
	const url = new URL(context.request.url);
	const id = url.searchParams.get("p");

	if (id && Object.hasOwn(ID_TO_SLUG, id)) {
		return Response.redirect(`${url.origin}/${ID_TO_SLUG[id]}/`, 301);
	}

	return context.next();
}

別のAIにレビューしてもらうと、対応表の判定に穴が見つかりました。

3つのやり方を、同じ試験用のサイトで比べました。

表の見方は次のとおりです。

• トップを開いた時：そのまま表示されるのが正解
• 古いリンクで来た時：新しい記事に着くのが正解
• 一覧表は転送の一覧表、プログラムは小さなプログラムのことです
• 記号：○は正解、×は不正解

対応表にない番号は、案内されずにトップページが表示されました。

転送の一覧表に書いた他の案内も、小さなプログラムと同時に動きました。

公式の説明には、プログラムが応えたものには一覧表が使われない、とあります。

私のプログラムは、対応表になければ次の仕組みへ回す書き方なので、両方が動きました。

この比べる試験の途中でも、しくじりがありました。

本番のサイトでも全部の記事に正しく着きました

2026年10月10日に本番のサイトで1件ずつ確かめると、全部の記事で、古いリンクから正しい記事に着きました。

正しい記事とは、引っ越す前に旧サイトで記録した転送先です。

リンクの後ろに、アクセス解析用の印（UTM）が付いていても、同じ記事に着きました。

引っ越した2026年9月26日にも、旧サイトのリンク162件を確かめました。

行き先がなくなったものは、ありませんでした。

この日付も、別のAIのレビューで直しています。

お館様

では、古いリンクは、全部つながったのじゃな。

ジライヤ

全部の記事で確かめたでござる

再現手順

1. 旧サイトの記事番号と記事名の一覧を作ります。WordPressの管理画面で記事の編集画面を開くと、アドレスのpost=のあとの数字が記事番号です。
2. サイトのフォルダにfunctions/_middleware.jsを作り、上のプログラムの対応表に書き写します。
3. サイトをビルドして、functionsフォルダのある場所でnpx wrangler pages dev distを実行します。distは、Astroでビルドした公開用のフォルダです。
4. ブラウザで/?p=番号を1件ずつ開きます。トップページ（/）と、対応表にない番号も開いて、飛ばないことを確かめます。確かめ終えたらwranglerを止めます。
5. 公開したら、本番へも同じ確認をします。curl -I "https://自分のサイト/?p=3113"で、転送の合図（301）と行き先が見えます。

デメリット・注意点

• 対応表にない番号は、エラーの表示ではなく、トップページが表示されます。
• アクセスのたびに、小さなプログラムが動きます。公式文書では、無料プランは1日10万回までです。
• このサイトには、プログラムを動かす範囲を絞る設定（_routes.json）を置いていません。
• 手元の確認は、パソコン内で動きをまねる道具の結果です。転送の一覧表に番号つきのリンクを書いた版は、本番に入れていません。
• 対応表は手で保つ一覧です。旧サイトの記事は増えないので、作り直しは要りません。

最後に

古いリンクから来た人を新しい記事に着かせるには、番号つきのリンクだけ、小さなプログラムで案内します。

引っ越しを考えている方は、まず自分のブログの古いリンクが、検索結果にどれくらい出ているかを見てみてください。

私のブログでは、番号つきの古いリンクが、全部の記事でつながりました。

詳しい書き方は、Cloudflareの公式文書にあります。

Cloudflare Pages: Redirects