404を直したら、行き先を間違えた｜旧サイト移行の301で、自分の最大の流入ページを殺していた話

TRYZMは、もともとWordPressで書いていた技術メモのサイトを、Next.jsで作り直したものです。その移行のときに、このサイトで一番読まれているページを、自分の手で殺していました。

今日それに気づいて直したので、何が起きていたのか、どう直したのかをそのまま書きます。効果がどうだったかは、まだ書けません（理由は最後に書きます）。

何をやっていたか

next.config.ts に、こういうリダイレクト設定が入っていました。

const oldPaths = [
  "/7zip_cmd",
  "/cmd-copy",
  "/cmd-dir-folderlist",
  "/mklink_for_dropboxuser",
  "/send-pdf-to-kindle",
  "/category/kindle",
];
return oldPaths.map((source) => ({
  source,
  destination: "/", // ← すべてトップページへ
  permanent: true,
}));

旧サイトの記事URLを、全部トップページへ301リダイレクトしていました。

そしてTRYZMのトップページは、格安SIMの比較コンテンツです。つまり 「7za.exe コマンド」で検索した人が、格安SIM比較のページに着地していた。 そのまま戻るボタンを押すに決まっています。

実測値：一番読まれているページが、そこにあった

Search Consoleの直近6週間の数字です。

URL	表示	平均掲載順位
`/7zip_cmd/`	122	11.5
`/mklink_for_dropboxuser/`	4	6.2

放置していた8年前の技術メモが、サイト内で最も上位にいました。同じ期間、力を入れて書いた格安SIM記事は15〜23位、一般的なキーワードでは80位台です。勝てていた唯一の場所を、リダイレクトで潰していたことになります。

サイト全体のCTRは 0.7% でした。掲載順位が11位で表示122なら、本来もう少しクリックされてよいはずの数字です。

なぜこうなったか：「404を消す」が目的になっていた

該当のコミットメッセージが残っていました。

旧URL /7zip_cmd の301リダイレクト追加（唯一の漏れ・GSC最上位URLが404だった）

404は正しく検知していたし、正しく消していました。 GSCで「最上位URLが404だ」と気づいて、その日のうちに直している。ここまでは悪くありません。

抜けていたのは、そのあとです。「どこに送るか」を考えていない。 「404を出さないこと」がタスクになった瞬間に、「その読者は何を求めて来たのか」という問いが消えました。行き先がトップページなのは、それが一番手近だったからです。

これは技術の問題ではなく、問題の立て方の問題でした。「404を消す」ではなく「7za.exeを調べに来た人に7za.exeの話を返す」と立てていれば、トップページという選択肢は最初から出てこなかったはずです。

Googleも明示的に止めている

あとから確認したら、Google Search Centralのサイト移行のドキュメントに、そのままの注意書きがありました。

Don't redirect many old URLs to one irrelevant single URL destination

— Google Search Central「Site moves with URL changes」

「新サイトのホームページのような、内容の対応しない1つのURLへ大量の旧URLを集約するな。ユーザーを混乱させるし、ソフト404として扱われる可能性がある」という趣旨です。ソフト404扱いになると、そのURLは検索結果から落ちていきます。

書いてある通りのことを、書いてある通りにやってしまっていました。

直し方：リダイレクトをやめて、元のURLで記事を返す

方針はシンプルで、リダイレクトを全部やめて、旧URLでそのまま記事を配信することにしました。順位はすでにあるので、URLを変える理由がありません。

ここで問題になったのが、記事の中身が手元に無いことです。旧サイトのWordPressはとっくに畳んでいて、エクスポートも残っていませんでした。

まずWayback Machineを見る → ほぼ無かった

archive.orgに残っていないか確認しました。1本ずつ調べる公式APIがあります。

curl "http://archive.org/wayback/available?url=tryzm.com/7zip_cmd"

返ってきたのは archived_snapshots: {} — 一番助けてほしい /7zip_cmd のスナップショットが、1枚も無い。 7本の記事のうち、個別ページが保全されていたのは1本だけでした。

ここで諦めると、「復元不能だから、内容の近いページへ301するしかない」という結論になります。実際そう書きかけました。

諦める前に、ドメイン全体を棚卸しする

available が返すのはそのURL単体の有無でしかありません。ドメイン単位で「何が保全されているか」を一覧できるCDX APIがあります。

curl "https://web.archive.org/cdx/search/cdx?url=tryzm.com&matchType=domain\
&fl=original,timestamp,statuscode&collapse=urlkey&limit=300"

これを見たら、記事ページは無いのに sitemap-posttype-post.2018.xml と /feed/ が保全されていることが分かりました。ここから道が開けます。

① sitemapで「そもそも何本あったか」を確定させる

まずsitemapのスナップショットを取ります。URLに id_ を挟むと、Waybackのツールバー等が付かない素のオリジナルが落ちてきます。

curl -sSL "https://web.archive.org/web/20250714102157id_/https://tryzm.com/sitemap-posttype-post.2018.xml"

ここで想定外のことが分かりました。旧サイトの記事は7本あり、そのうち2本（/xcopy_directory_copy と /findstr-cmd）は、リダイレクトのリストにすら入っていなかった。 つまりトップに飛ばされてすらおらず、素の404を返し続けていました。自分が把握していた「移行した記事の一覧」自体が間違っていたわけです。

移行の点検は、記憶や設定ファイルではなく、旧サイトのsitemapから始めるべきでした。

② RSSフィードから本文を回収する

そして本命がこれです。WordPressの /feed/ は、既定で直近記事の全文を <content:encoded> に入れて配信します。1つのURLに複数記事の本文がまとまって入るので、記事ページより保全されている確率が高い。

curl -sSL "https://web.archive.org/web/20250714082311id_/https://tryzm.com/feed/" -o feed.xml

65KBのXMLが落ちてきました。中身を開いたら、7本すべての本文が丸ごと入っていました。

import xml.etree.ElementTree as ET

ns = {"content": "http://purl.org/rss/1.0/modules/content/"}
root = ET.parse("feed.xml").getroot()

for item in root.find("channel").findall("item"):
    link = item.findtext("link")
    slug = link.rstrip("/").split("/")[-1]
    body = item.find("content:encoded", ns).text
    open(f"{slug}.html", "w").write(body or "")

個別ページのスナップショットがゼロだった /7zip_cmd も、これで本文が戻りました。

消えたサイトを復元するときの探索順

今回の教訓をそのまま手順にすると、こうなります。

CDX APIでドメイン全体を棚卸し（matchType=domain）— 何が残っているかを先に把握する
sitemap*.xml のスナップショット — 旧サイトの全URLを確定させる。「何本あったか」の記憶は当てにしない
/feed/・/feed/atom/ — content:encoded から本文を一括回収する
個別記事ページのスナップショット — 最後。無いことのほうが多い
カテゴリ一覧・検索結果ページ — 抜粋だけでも手がかりになる

取得はどれも https://web.archive.org/web/<timestamp>id_/<URL> の形で、id_ を忘れないこと。

復元しただけでは、誤情報になった

本文が戻ったので、そのまま公開しようとして止めました。8年前・5年前の記事です。当時正しかったことが、今は間違いになっている。

実際に2件ありました。

7-Zip：記事にあったダウンロード先 sevenzip.osdn.jp が消滅していました。今の配布元は 7-zip.org（実体はGitHubのリリース）です。ついでに、記事の主役である 7za.exe が現行版にも同梱されているかを確認するため、Extraパッケージ（26.02）を実際にダウンロードして中身を見ました。7za.exe は今も入っていて、x64とarm64も同梱されています。

Send to Kindle：対応ファイル形式が変わっていました。記事に書いてあった MOBI（.MOBI / .AZW）とWord（.DOC / .DOCX）は、現在サポート対象外です。代わりにEPUBが追加され、ブラウザから200MBまで送れるウェブ版が主役になっています。Amazon公式ヘルプで確認しました。

昔の記事をそのまま復活させていたら、「Wordファイルが送れます」と嘘を書いたページが公開されるところでした。復元は、内容の正しさを保証しません。

実装

やったことは3つです。

旧URLのまま記事を配信する。 content/legacy/*.mdx に本文を置き、ルート直下の動的ルート（src/app/[legacySlug]/page.tsx）で返す。Next.jsの dynamicParams = false を付けて、登録した7本以外のパスは確実に404にしています。ルート直下に動的セグメントを置くと何でも拾いかねないので、ここは閉じておく
トップページへの301は全撤去。 唯一 /category/kindle だけは復元対象の記事が無いので、内容が最も近い記事（KindleでPDFを読む方法）へ送りました。トップには投げません
sitemapと記事一覧に載せる。 内部リンクが1本も通っていない状態だったので、そこも繋ぎました

復元した記事はこの7本です。

効果は、まだ分かりません

ここが一番大事なところです。

この記事を書いている時点で、直した効果は測れていません。 復元したのは今日（2026年8月4日）で、Search Consoleに数字が出るのはこれからです。

なので、「流入が回復しました」「CTRが改善しました」とは書きません。 書けるのは「事故を見つけて、直した。効果はこれから測る」までです。

記録として、直す前の数字だけ置いておきます。

指標	復元前（直近6週）
`/7zip_cmd/` 表示	122
`/7zip_cmd/` 平均掲載順位	11.5
`/mklink_for_dropboxuser/` 平均掲載順位	6.2
サイト全体のCTR	0.7%

2週間後（8月18日頃）に同じ指標を取って、この記事に追記します。見る順番も決めてあります。

復元した7つのURLが200を返し、表示を得ているか（ソフト404から抜けたかの確認。これは少ない標本でも判断できる）
サイト全体のCTRの方向
クリック数の絶対値

ただし、もともと6週間で9クリックというサイトです。2週間で統計的に意味のある差は出ない可能性が高い。 数クリックの増減を「改善しました」と言うつもりはありません。改善が見えなかった場合の解釈も、あらかじめ3つ用意しています——再評価に数週間から数か月かかっている／期間が短くて検出できていない／そもそも診断が間違っていた。

「やってみたら3倍になりました」と書けたら記事としては強いのでしょうが、まだ測っていないものを成果として書いた時点で、この記事の主張と矛盾します。

残った教訓

自分に向けて3つ書いておきます。

リダイレクト先は「404にならないか」ではなく「着地した人の検索意図が満たされるか」で選ぶ。 満たせないなら、トップではなく内容が最も近いページへ。それも無いなら、素直に404を返したほうがマシです。内容の対応しない301は、ユーザーにとっても検索エンジンにとっても嘘になります。

移行の点検は、記憶ではなく旧サイトのsitemapから始める。 「移行した記事の一覧」を自分の設定ファイルから作っていたせいで、2本が404のまま何か月も放置されていました。正解を持っているのは自分ではなく、旧サイトが残したデータのほうです。

「無い」という一次情報の範囲を、勝手に広げない。 available APIが返した「無い」は、そのURL1本の話でしかありませんでした。それを「復元不能」と読み替えていたら、一段劣る対処で終わっていました。諦める前に、探索の範囲がまだ狭くないかを疑う。

TRYZMは、こういう失敗と訂正を消さずに残していきます。うまくいった話だけを並べたほうが読み物としては気持ちいいのですが、それは自分が読みたいものではないので。

8月18日に、この記事の続き（数字）を追記します。