畳んだのは、登録者0人のまま終わった登録ページ
2026年10月24日に、登録ページ /lead/ を含むリード導線を本番に出しました。流れは、登録、確認メール、3分診断、無料本、ステップメール0〜2日目です。1時間ごとの見回り処理もつけました。
投入時の検証では、自動テストが122件中122件通過しています。わざと壊す検査は、リード系で23通り、診断ページで15通りあり、すべて検出できました。
登録ページへ直接送る導線は、作っていなかった
/lead/ へリンクしていたのは、本のページ /dl/book/ だけでした。10月24日からLINEのメニューに、特典一覧から診断と無料本へ進む経路はありました。登録ページへ人を直接送る導線は作っていません。
11月1日に販売LPへ一本化した
11月1日に、この導線を畳んで販売LP /pebblemint/offer に一本化しました。その時点で、データベースの4表（登録者・ステップ送信・診断・リンク使用）はすべて0行でした。登録者は0人です。
転送した12行と、200のまま残した3種類のURL
転送先は、畳んだページすべてを /pebblemint/offer にしました。転送規則は1行ずつ書いています。内訳は次のとおりです。
- /lead、/lead/、/lead/confirmed、/lead/confirmed/ の4行
- 旧登録ページ /newsletter-ai について、/newsletter-ai、/newsletter-ai/、/pages/newsletter-ai、/pages/newsletter-ai/ の4行
- 旧登録ページ /newsletter-ec について、同じ形の4行
合計12行です。末尾スラッシュの有無は、両方とも書いています。
丸ごと転送にしなかった理由
3分診断 /lead/diagnosis/ は生かしました。LINEの特典一覧、本のページ、ニュースレターの確認メールから使われているためです。
/lead/ 配下をまとめて転送する書き方にすると、診断ページも巻き込まれます。そこで /lead/* のような規則は作らず、畳むURLだけを1行ずつ並べました。
登録後に使う /newsletter-ai/thanks、/newsletter-ai/confirmed と、EC側の同じ2つも、301に巻き込まず200のままにしています。
301で転送した（12行）
- 旧登録ページ /lead と完了ページ /lead/confirmed（末尾スラッシュの有無で各2行）
- 旧登録ページ /newsletter-ai と /newsletter-ec（各4行）
- 転送先はすべて販売LP /pebblemint/offer
200のまま残した
- 3分診断 /lead/diagnosis/（特典一覧・本のページ・確認メールから使う）
- 登録後の thanks ページ
- 登録後の confirmed ページ
テストで固定している内容
転送の規則は、テストに書いて固定しています。この記事の制作ではテストを再実行していないので、書かれている内容だけを挙げます。
- 畳んだURLが301で転送先に着き、転送先が200であること
- /lead/diagnosis/ が200のままで、どの規則にも当たらないこと
- /lead 配下を丸ごと転送する規則が無いこと
- 畳んだページの実体が残っていないこと
- サイト内の /lead/ への入口が診断ページだけであること（検査が空振りしないよう、診断への入口があることも確かめます）
- thanks と confirmed が301にならないこと
消す順番は、デプロイ、確認、数え直し、削除の4段
消したものは、登録・確認・ステップ送信・配信停止の処理とページ、見回りのスクリプト、購入照合（既定で止めてありました）、配信サービスの連絡先への一度きりの追加と点検のスクリプト、「確認待ちに回す」処理です。
順番は次の4段です。
- コードをデプロイする
- 本番で登録と診断が動くことを確かめる
- 流す直前に、4表が0行であることを数え直す（11月1日の実測は4表とも0）
- 表を消すSQLを1回だけ流す
SQLの手順の冒頭には、消さない2つの表を明記しました。
- デプロイ登録・確認・ステップ送信・配信停止の処理とページを外したコードを本番へ出す
- 本番で確認残す登録と診断が本番で動くことを確かめる
- 数え直し消す直前に、登録者など4表が0行であることを数える
- 削除表を消すSQLを1回だけ流す。消さない2つの表は手順の冒頭に明記する
見回りの時計を止める
見回り処理の時計も止めました。止めないと、毎時、消えた口を呼び出して404を記録し続けます。
認証用の鍵2つと手元の控えは、消すかどうかを判断事項にしていったん保留し、その後に削除しました。ここまでの後片付けは、11月1日に完了と記録しています。時計の登録ファイルが残っていないかは、この記事の制作では確かめていません。
名前だけで判断すると壊れる表
受信箱ごとの送信枠を持つ表には、畳んだ導線の名前が付いていました。ところが実際には、ニュースレター登録、問い合わせ、代行の事前ヒアリングの3つの口が使っています。名前で判断して消すと、この3つが壊れます。
そこで、部品は共有の場所へ切り出し、表は名前のまま残しました。残したものは次のとおりです。
- 3分診断（答えはその場で採点して見せるだけで、保存しない形に変えました）
- 本のページ
- メール形式チェックと、受信箱ごとの送信枠
- ニュースレターの列の開始台帳
- 配信サービス側の連絡先の項目
転送先のLPから旧URLへリンクが残っていた
2日後の11月3日に、堂々巡りが見つかりました。
サイトの無料の入口（「無料で整理する」のボタンなど）は、旧 /newsletter-ai を指したままでした。旧 /newsletter-ai は、/pebblemint/offer の先頭へ301で転送します。そのため、読み手は販売LPから無料の入口へ進むと、来たLPの先頭へ戻されました。登録フォームには直接着きません。
- LPを読む読み手が販売LP /pebblemint/offer を開く
- 入口を押す「無料で整理する」のリンク先は、閉鎖した旧 /newsletter-ai のまま
- 301で転送旧URLの規則どおり、販売LPの先頭へ転送される
- 先頭に戻る読み手は来たページの先頭に着き、登録フォームには直接着かない
- 直した後入口を販売LP内の登録フォームの節（#free-gift）へ直接向けた
301は正しく動いていた
転送の動きは設計どおりでした。問題だったのは、転送先へ人を送る入口が、転送元の旧URLを指していたことです。
12行の規則と転送の検査だけを見ていても、この状態は見つかりません。転送は旧URLにアクセスしたときの動きを決めるもので、ページの中のリンクがどこを指しているかは別の話だからです。
直し方
無料の入口を、/pebblemint/offer?…#free-gift に直接向けました。#free-gift は、販売LPの中の登録フォームの節です。
ヘッダーとスマホメニューの入口をすべて差し替え、テストでは入口を100件以上拾えていることを下限として確かめています。あわせて、次の2点も固定しました。
- 販売LPの中に、自分の先頭へ戻すリンクが0件であること
- 販売LPのヘッダーはロゴだけの専用のものにして、無料の入口が差し込まれないこと
ページの役割も同じ日に分けた
同じ11月3日に、ページの役割も分けました。販売LPと紹介ページは、どちらも全部入りで同じことを書いていて、読み手が今どこにいるのか分からない状態でした。そこで次のように分けています。
- 販売LP: 気づいて、無料特典に登録するページ。料金・申込み・相談は置かない。最後に紹介ページへ1本だけリンクする
- 紹介ページ: 中身を知って買うページ。料金は1回だけ。販売LPや無料特典へ戻るリンクは置かない
- 買うページ: 紹介ページからだけ行く
この分け方もテストで固定しています。販売LPに申込み・料金・相談の入口が無いこと、紹介ページから販売LPと無料特典へ戻る入口が無いことです。
旧URLの検査が届いていない場所と、残っている課題
旧URLへのリンクが0件であることを確かめる検査は、コラム以外のページだけが対象です。
コラム本文の中ほどと記事末にある登録リンクは、今も旧URLのままです。コラムの生成スクリプトが、登録先の照合にこのURLを使っているためです。
つまり、コラムから来た人は、登録フォームではなく販売LPの先頭に着きます。コラムからLPへ進むので堂々巡りにはなりませんが、フォームへ直接は着きません。この点は、まだ直していません。
確かめていないこと
次の点は確かめていません。検索順位、流入、登録数の変化も測っていません。
- /lead/ が検索結果に出ていたか
- 301でクエリ文字列（utmなど）が引き継がれるか
LPを閉鎖するときに確かめる点
今回の実例から、確かめる点をまとめます。
- 閉じるURLを末尾スラッシュの有無まで書き出し、生かすURLを巻き込まない形で転送する
- 閉じるページと名前が同じでも、他の機能が使っている部品やデータがないか調べる
- データは、コードを出して本番の動作を確かめた後、直前に数え直してから消す
- 止まった処理を呼び出す定期実行が残っていないか確かめる
- 転送の規則だけでなく、サイト内のリンクを旧URLの一覧で検索する