「転送を設定した」と「転送が効いている」は、別のことでした――愛媛・松山のホームページ制作会社が、自社サイトのリニューアル後に見つけた2つの落とし穴

結論から言うと、リニューアルのときに設定した「転送」は、設定した時点では何も保証してくれません。 私たちW-UPは自社サイトで、転送にまつわる落とし穴を2つ、続けて踏みました。

1つ目は、転送は生きているのに、飛ばした先にページが無かったというもの。2ヶ月半、気づきませんでした。
2つ目は、転送を正しく作ったのに、それが一度も発火していなかったというもの。原因はサーバーに残っていた1本の古いファイルでした。

どちらも、管理画面の上では「設定済み」と表示されていました。画面が映すのは「やったこと」であって、「効いていること」ではありません。 今回は、この2つをどう見つけて、どう直したのかを、そのままご報告します。最後に、社長ご自身が3分でできる確認手順も載せます。

そもそも「転送（リダイレクト）」とは何か

ホームページをリニューアルしたり、ドメインを変えたりすると、古いURLはこの世から消えます。 ところが、消えたことを知らないまま古いURLを開こうとする人が残ります。名刺、パンフレット、他社サイトからのリンク、そして検索エンジンです。

そこで「古いURLに来た人を、新しいURLへ自動的に送る」仕組みを入れます。これが転送（リダイレクト）です。恒久的な引っ越しを示す番号を付けて「301リダイレクト」と呼びます。ここまでは、リニューアルを担当した会社なら必ず設定します。私たちも設定していました。

問題は、設定したあとに誰も確かめないことです。

落とし穴①：転送は生きていた。行き先のほうが無かった

私たちの旧サイトは w-up.jp という別ドメインで、中身は静的なHTMLファイルでした。2026年5月末に現在の ehime-web.jp へ移行し、旧ドメインからの転送を設定しました。

この転送は、確かに生きていました。生きてはいたのですが、パスをそのまま引き継ぐ形になっていたのです。

新しいサイトに services.html というページはありません。あるのは /services/ です。つまり、古いURLを開いた人は、行き先の無い場所へ丁寧に案内されて、そこで「ページが見つかりません」に突き当たっていたことになります。

転送そのものは動いている。だから設定画面を見ても異常はありません。「リダイレクトを設定した」と「リダイレクト先が存在する」は、別の話でした。

どうやって見つけたか――Search Consoleの404レポート

見つけたのは2026年8月12日です。前回までの記事（#32）で、Google Search Consoleの「ページ」レポートを開き、未登録の理由の内訳を1行ずつ確認していたときでした。

その中に「見つかりませんでした（404）」が7件ありました。数が動いていなかったので「昔のURLだろう」と後回しにしていたのですが、行をクリックして中身を開いたところ、4件が旧サイト時代のURLでした。

残る3件はURLに *（アスタリスク）を含むもので、これはrobots.txtの記述をGoogleがURLとして拾ってしまったものです。実在しないので直しようがありません。7件のうち、対処すべきは4件だった、ということです。

ここで正直に書いておくと、この4件がいつから404だったのかは、この画面からは分かりません。一覧に並んでいる日付は「前回のクロール」であって、初回ではないからです。分かるのは、2026年5月末の移行から8月12日に見つけるまで、2ヶ月半ほど放置されていたということだけです。

直し方：まとめ転送に頼らず、1本ずつ対応表を作る

対処は同じ日に済ませました。WordPress側に転送を管理するプラグインを入れ、旧URLと新URLの対応を1本ずつ登録しました。

news.html（旧お知らせ）は現在のコラム一覧へ、faq.html はよくある質問がトップページにまとまっているのでトップへ。対応する新ページが無い場合でも、とりあえずトップへ全部流すのではなく、いちばん内容が近いページへ着地させるのが原則です。せっかく来てくれた人に、探し直しをさせないためです。

まとめて転送する設定は、一見すると楽で、実は一番危ない。旧サイトのURL一覧を作り、1本ずつ行き先を決める。 これが移行作業の本体だと考えたほうが、結果的に早く済みます。

ついでに見つかった、もう1件

同じ画面で、旧ドメインとは無関係の404も1件ありました。/recruitment-hp-operation-strate というURLで、これは私たちのコラム#27の正しいURL .../recruitment-hp-operation-strategy から、末尾の2文字が欠けた形です。

Search ConsoleのURL検査で調べると、参照元のページも参照元のサイトマップも「検出されませんでした」。つまりサイトの外側の誰かが、途中で切れたURLをどこかに貼っているということです。自社のファイルを全部検索しても、この切れたURLは1件も見つかりませんでした。

こうなると発生源は追えません。追う意味もありません。切れたURLから正しいURLへ301を1本足して着地させる。 それで終わりです。自分のサイトに原因が無い404もある、という例として書き添えておきます。

落とし穴②：301を作った。それでも旧ページが出続けた

ここからが、8月20日に踏んだ2つ目です。こちらのほうが厄介でした。

きっかけは、まったく別の作業でした。Microsoft Bing側の管理ツールで、自社サイトのURL一覧を眺めていたときのことです。並んでいる中に /contact.html という見覚えのないURLがあり、しかもページの容量が、他のページの5分の1しかありません（他が15〜22万バイトのところ、31,115バイト）。

開いてみると、旧サイト時代のお問い合わせページが、そのまま表示されました。 5月末の移行から2ヶ月20日ほど、旧サイトのページが1枚、生きたまま残っていたことになります。

①と同じ要領で、/contact.html → /contact/ の301をその場で登録しました。

それでも、旧ページが出続けました。

設定画面には、登録した転送がきちんと並んでいます。書き方も間違っていません。それなのに、実際に開くと古いページがそのまま表示される。「設定は正しいのに効かない」は、いちばん気持ちの悪い状態です。

原因は、サーバーに残っていた1本のファイルだった

原因はこうでした。contact.html が、サーバー上に実ファイルとして残っていたのです。

Webサーバーには順番があります。リクエストが来たとき、そのファイルが実在すれば、サーバーはWordPressを通さずにそのまま返します。 転送を管理するプラグインは、リクエストがWordPressに渡って初めて動きます。つまり、実ファイルがある限り、転送はそもそも呼び出されない。

正しく作った転送が、正しく作られたまま、一度も出番をもらえていなかった、ということです。

警告は、最初から画面に出ていました

さらに情けない話があります。転送プラグインの画面の下のほうに、こう書いてありました。

一部のサーバーがファイルリソースを直接処理するように設定されている可能性があります。これにより、リダイレクトが妨げられています。

まさにこの状態を指す警告が、最初から表示されていたのです。 エラーの赤い表示ではなく、注意書きの調子で書かれていたので、読み飛ばしてしまいました。

原因を探して1時間ほど画面をにらんだあとで、この一文を見つけたときの気分は、あまり良いものではありませんでした。設定画面の注意書きは、困ってから読むのではなく、設定した日に読むべきでした。

直し方：削除ではなく、リネームする

対処は簡単でした。ファイル管理のプラグインで、contact.html を contact.html.bak という名前に変えるだけです。その名前のファイルは存在しないことになるので、リクエストはWordPressに渡り、作っておいた転送が初めて動きます。

削除ではなくリネームにするのは、戻せるようにするためです。 何かを消す作業は、消した瞬間は快適で、あとで困ります。名前を変えるだけなら、間違っていたら戻せます。

なぜ1本だけ漏れたのかも、はっきりしています。8月12日に旧サイトの静的HTMLを整理したとき、index.html・news.html・services.html の3本はファイルごと消してから転送を作っていました。contact.html だけ、ファイルが残ったのです。同じ日に、同じ人が、同じ作業をして、1本だけ手順が違っていた。 そして8月12日の時点では、残っていること自体に気づいていませんでした。

おまけ：残っていた旧ページは、名乗りまで古かった

リネームする前に、contact.html の中身を見てみました。旧デザインのお問い合わせページで、ナビゲーションも旧構成のまま。そして、ロゴの表記が今と違っていました。

会社名の書き方が、旧サイト時代のものだったのです。ナビには今は無いメニューが並び、今はあるメニューが無い。電話番号のバーもありません。

これは見た目の問題ではありません。AIや検索エンジンから見ると、「この会社はこう名乗っている」という情報を、古いページが供給し続けていたということです。AI検索で会社名や事業内容が微妙にずれて紹介される、という現象の材料になり得ます。

今回は容量の小ささが手がかりになりましたが、中身が古いかどうかは、容量を見ても分かりません。 開いてみるまで分かりませんでした。この話は長くなるので、次回あらためて書きます。

2つの落とし穴に共通していたこと

並べてみると、①も②も、失敗の形は同じでした。

どちらも、設定画面の上では何の問題もありませんでした。 設定画面が映すのは「こちらが何をしたか」であって、「その結果どうなったか」ではありません。

そして、見つけ方も違いました。①は「404になっている」という異常なので、404のレポートを開けば出てきます。ところが②は、404のレポートには一生出てきません。 旧ページがちゃんと表示されている以上、サーバーは正常に応答しているからです。異常として通報される種類の不具合ではないのです。

②が見つかったのは、検索エンジンが持っているURLの一覧に、「そんなページ、うちにあったか？」という1行が混ざっていたからでした。残骸は、サイトの中を見て回っても出てきません。 どのメニューからもリンクされていないからです。外側から見たURLの一覧か、サーバーのファイル一覧か。その2つにしか映りません。

3分でできる確認手順――社長ご自身でできます

専門知識は要りません。ホームページをリニューアルしたことのある会社なら、今すぐ試せます。

1. 古いURLを思い出す。 名刺、パンフレット、封筒、旧サイトの印刷物に載っているアドレスです。分からなければ、会社名で検索して出てきた古そうなリンクでも構いません
2. ブラウザで「シークレットウィンドウ」（Chromeの場合）を新しく開く。 普段のウィンドウだと、以前見たときの記録が残っていて正しく判断できません。毎回、新しく開き直すのがコツです
3. そのURLを貼り付けて開く

結果は3通りです。

3つ目がいちばん気づきにくく、いちばん実害があります。古い料金、古い電話番号、無くなったサービスが、今日も誰かに読まれているかもしれないからです。

もし2つ目・3つ目に当てはまったら、制作を頼んだ会社に「このURLがこうなっています」と伝えれば通じます。責める必要はありません。 私たちも自分でやって自分で見落としました。移行作業は本数が多く、1本だけ手順が抜けることが実際に起こります。

追記：直したことは、Googleが見に来るまで数字にならない

8月12日に4本の転送を登録したあと、Search Consoleで「修正を検証」を申請しました。「直したので、もう一度見に来てください」とGoogleに伝えるボタンです。押さない限り、Googleは自分のペースでしか再訪しません。

この記事を書いている8月21日の時点で、検証のステータスは「開始」のまま。9日経っても、まだ結果は出ていません。

ただし、404の件数そのものは動いていました。7件から6件へ（データの最終更新日は8月17日）。

消えたのは /index.html の1本でした。この1本だけ、前回のクロール日が8月8日と新しかった。もともとGoogleがよく見に来ていたページだから、転送を作ったあとに早々ともう一度見に来て、解消として処理されたと考えられます。

では残りはどうか。/faq.html・/services.html・/news.html の3本は、一覧に残ったままです。前回のクロール日を見ると、5月4日・5月3日・5月2日。転送を作った8月12日から、一度も見に来られていません。

つまりこの3本は、「まだ直っていない」のではありません。直したことを、まだ知られていないのです。画面には「404」と表示され続けますが、その表示は5月に見たときの記憶で書かれています。

転送を1本作るのに、かかる時間は10秒です。それが数字に反映されるまでには、Googleの都合で数週間かかります。「設定した」と「効いている」が別だったのと同じように、「直した」と「直ったと認識された」も、また別のことでした。

だから「修正を検証」を押します。押しても順番が早くなる保証はありませんが、押さなければ列にすら並べません。

教訓：設定画面は「やったこと」しか映さない

最後に、今回いちばん身に沁みたことを書いておきます。

私たちは、①を直した日に「これで旧URLの問題は片付いた」と思っていました。実際には、同じ種類の問題がもう1本、手の届くところに残っていました。「対処した」という記憶が、次の確認をしない理由になっていたわけです。

作業の完了は、作業した本人が決めるものではありません。実際に開いてみて、着地したかどうかで決まります。 リニューアルの見積書に「リダイレクト設定」と書いてあったら、その隣に「公開後の着地確認」も書いてあるか。無ければ、確認まで含めてお願いしたほうがいい。手間としては、1本あたり10秒です。

私たちW-UPが松山のホームページ制作をお引き受けするときも、この10秒を工程表に入れています。愛媛のホームページ制作・愛媛のWEB制作を、作って納めて終わりではなく、公開後に検索へ載り、表示され、選ばれるところまでを数字で確認しながらお引き受けしています。「昔のURLがどうなっているか分からない」という方は、その確認からお手伝いします。

愛媛・松山のホームページ制作サービスの内容と料金はこちら

よくあるご質問