【2026年10月20日時点の情報です】
このブログでは、古い記事のURLの転送に、WordPressのプラグイン「Redirection」を使っています。
2026年10月15日、前に410（もうないページ）にしていた古い記事を、新しく書いた記事へ301で転送しようとしました。ところが、301のルールを足しても、確かめると410のままでした。
原因は、同じURLに古い410のルールが残っていて、そちらが先に使われていたことでした。この記事では、そのときに確かめたことと、直し方をまとめます。
場面1：古い記事を、410にしていた
10月8日に、古いシリーズの記事を整理しました。そのうちの1本「VSCode「Remote-SSH」で自宅サーバーを直接開発する」（/vscode-remote-ssh-almalinux/）は、Redirectionのルールで410を返すようにしていました。
| No. | 番号 | 意味 |
|---|---|---|
| 1 | 301 | このページは別のURLへ移った（転送する） |
| 2 | 410 | このページはもうない（転送しない） |
その後、同じ内容を新しいシリーズで書き直した記事（/embedded-to-web-extra-remote-ssh/）を公開しました。そこで、古いURLに来た人を新しい記事へ送るために、410を301に変えることにしました。
場面2：301のルールを足しても、410のままだった
最初は、410のルールを画面で転送に変えようとしましたが、確かめると410のままでした。
curl -sI https://softdev-learn.cc/vscode-remote-ssh-almalinux/ | grep -iE "^(HTTP|location)"結果の例：
HTTP/2 410- curl -sI：
ページの中身は取らずに、返事の見出しだけを出す - grep -iE “^(HTTP|location)”：
返事の番号の行（HTTP〜）と、転送先の行（location）だけを出す
次に、この記事だけの301のルールを新しく足しました。Redirectionのルールは「位置」（Position）の数字が小さい順に調べられるので、位置に0を入れて、ほかのルールより先に効くようにしたつもりでした。それでも、結果は410のままでした。
場面3：SQLでルールを並べて、原因を見つけた
画面では分かりにくかったので、Redirectionのルールが入っているテーブル（wp_redirection_items）を、SQLで直接見ました。
sudo mysql wordpress -e "
SELECT id, position, status, action_type, action_code, regex, LEFT(url, 120) AS url, LEFT(action_data, 80) AS target
FROM wp_redirection_items
WHERE url LIKE '%remote-ssh%' OR action_data LIKE '%remote-ssh%'
ORDER BY position, id;"結果の例：
+----+----------+---------+-------------+-------------+-------+-------------------------------+------------------------------------+
| id | position | status | action_type | action_code | regex | url | target |
+----+----------+---------+-------------+-------------+-------+-------------------------------+------------------------------------+
| 12 | 4 | enabled | error | 410 | 0 | /vscode-remote-ssh-almalinux/ | NULL |
| 40 | 19 | enabled | url | 301 | 0 | /vscode-remote-ssh-almalinux/ | /embedded-to-web-extra-remote-ssh/ |
+----+----------+---------+-------------+-------------+-------+-------------------------------+------------------------------------+- position：
ルールの位置。小さいほうから順に調べられる - status：
enabled なら有効、disabled なら無効 - action_type：
error ならエラー（410など）を返す、url なら別のURLへ転送する - action_code：
返す番号（410、301など） - regex：
1 なら正規表現のルール、0 ならURLそのもののルール - LEFT(url, 120)：
対象のURLを、長いときは先頭の120文字だけ出す - WHERE url LIKE ‘%remote-ssh%’ OR action_data LIKE ‘%remote-ssh%’：
対象のURLか転送先に「remote-ssh」を含むルールだけを出す - ORDER BY position, id：
位置の小さい順（同じならIDの小さい順）に並べる。この順番が、ルールが調べられる順番になる
同じURL（/vscode-remote-ssh-almalinux/）に、ルールが2つありました。
| No. | ID | 位置 | 中身 |
|---|---|---|---|
| 1 | 12 | 4 | 10月8日に作った410のルール |
| 2 | 40 | 19 | 今回足した301のルール |
入れたはずの位置の0は保存されておらず、19になっていました。そのため、位置4の古い410のルールが先に当てはまり、301のルールまでたどり着いていませんでした。
場面4：古い410のルールを消して、301になった
410のルールはこの記事だけのものだったので、ID 12 のルールを消しました。
画面で消すときは、「ツール」→「Redirection」で vscode-remote-ssh を検索し、「410」と出ているほうのルールにマウスを合わせて「削除」を押します。SQLで消すときは、次の形です。
sudo mysql wordpress -e "DELETE FROM wp_redirection_items WHERE id = 12 AND action_code = 410 AND url = '/vscode-remote-ssh-almalinux/'; SELECT ROW_COUNT();"- DELETE FROM wp_redirection_items WHERE id = 12：
ID 12 のルールを消す - AND action_code = 410 AND url = ‘…’：
IDだけでなく、番号とURLも条件に入れて、別のルールを消してしまわないようにする - SELECT ROW_COUNT()：
消えた行の数を出す。1 なら1行だけ消えている
消したあとに、もう一度確かめました。
curl -sI https://softdev-learn.cc/vscode-remote-ssh-almalinux/ | grep -iE "^(HTTP|location)"結果の例：
HTTP/2 301
location: /embedded-to-web-extra-remote-ssh/301になり、新しい記事へ転送されるようになりました。
まとめ
Redirectionでは、同じURLにルールが2つあると、位置の小さいほうが先に使われます。410にしていたURLを301に変えたいときに、301のルールを足すだけでは、古い410のルールが残って効いたままになることがあります。
転送が思ったとおりにならないときは、そのURLのルールをSQLで位置の順に並べると、どのルールが先に当てはまっているかが一目で分かります。
SQLの書き方（SELECT や DELETE の意味）は、データベースのコマンドの記事で1つずつ説明しています。SQLで記事の状態を変えたときに起きたことは、SQLで下書きに戻したら空のカテゴリーが残った記事にまとめました。WordPressのプラグインのほかの記事は、Plug-inのカテゴリーにあります。
コメント