CF7・Benchmark Email・Stripeをつないだ自動化導線が、ひとまず動く状態になりました。詰まったのは「コードの仕組みが分からない」という技術的な壁と、「読者の体験を途切れさせない」という設計上の判断でした。この記事では、successurlが動かない問題からStripe決済後の教材配布まで、詰まった箇所と判断の全記録を整理しています。前の2記事（アカウント停止とDOI仕様の記録・CloudflareとMakeで失敗した記録）の続きです。
前の記事までで、2つの問題が解決しました。
Benchmark Emailのアカウント停止を解除し、DOI仕様の誤認を修正し、「無料PDFはメールではなく認証後ページで渡す」という設計方針が決まりました。
ここからは実装の話です。設計は決まった。あとは動かすだけ——そう思っていたんですが、また詰まりました。
CF7とBenchmark Email——フォーム送信後のページ遷移が動かなかった理由
successurlを設定したのに遷移しない
Contact Form 7（CF7）でフォームを送信したあと、仮サンクスページへ遷移させたかったんです。
最初に試したのは successurl の設定です。ChatGPTに聞いてコードを出してもらい、そのまま貼り付けました。しかし動きませんでした。
正直に言うと、このコードが何をしているのか、当時はよく分かっていませんでした。「ChatGPTが出してくれたから合っているはず」と思って貼り付けたんですが、それが動かなかったんですよね。
なぜ動かなかったのか
原因を探るうちに、CF7はフォーム送信を fetch（非同期通信）で処理していることが分かりました。fetch ではページ遷移が発生しません。successurl の設定だけでは、思った通りに動かない場合があるようです。
ただしこれは後から理解したことで、詰まっている最中は「コードが間違っているのか、設定が足りないのか」の判別もできていませんでした。
functions.phpの経験を活かしました
ここで思い出したのが、以前 functions.php でページ遷移の処理を組んでいた経験です。
「あの仕組みを固定ページのJSに移せばいいのでは」と考え、ChatGPTに相談しました。
返ってきた答えは「functions.php はPHPで書かれているので、JavaScriptに書き直す必要がある」というものでした。
PHPで書かれたコードをそのままJavaScriptのファイルに貼り付けても動きません。言語が違うので当然なんですが、コードの中身が読めないと気づきにくいですよね。「同じような処理をしているコードのはず」という思い込みが、余計な時間を生んでしまいます。
ChatGPTにPHPコードをJavaScriptへ書き直してもらい、window.location.href でページ遷移を制御する実装に変更しました。これで動きました。
「さすがAI！」と思った瞬間でした（笑）。コードの仕組みは理解できていなくても、問題を言語化してAIに投げることで解決できましたよ。これは再現性のある判断だと思っています。
CF7送信後のページ遷移が動いているか
→ NOなら successurl だけでなく `window.location.href` を使ったJS実装を検討してみてください
固定ページのJSにPHPのコードを貼り付けていないか
→ YESなら ChatGPT等でJavaScriptへの書き直しを依頼しましょう
コードの仕組みを理解していなくても「何が起きているか」を言語化できているか
→ NOならまず「何をしたくて何が動いていないか」を1文で書いてからAIに投げてみましょう
サンクスページ設計——読者の体験を途切れさせない
最初は問い合わせ後のページに飛んでしまいました
遷移処理が動くようになった後、次の問題が出てきました。
フォーム送信後に遷移するページが、既存の「お問い合わせ完了ページ」になっていたんです。メルマガ登録フォームを送信したのに、問い合わせ完了の文言が表示される。これは読者にとって明らかに違和感がありますよね。
「登録したのに何かおかしい」と感じた読者は離脱してしまいます。離脱した読者は認証メールを確認しません。認証されなければ、設計した導線が機能しないんです。
この違和感を放置するコストは、専用ページを作るコストより高いと判断して、メルマガ登録専用の仮サンクスページを別途作成しました。
仮サンクスページで「これだけ」を伝える
仮サンクスページに置くべき要素を決めるとき、削ぎ落とすことを先に考えました。
「登録が完了しました」という事実だけを伝えます。「届いているかな」という不安を残さないことが大切です。装飾や余分な説明は入れません。 判断基準：「読者が次に何をすべきか、1秒で分かるか」を確認してください。
次の行動は「認証メールを確認してクリックする」の1つだけです。リンクも他のCTAも置きません。選択肢が増えると読者は迷ってしまいますよ。 判断基準：「このページで2つ以上の行動を促していないか」を確認してください。
無料PDFを目的として登録してきた方に、この時点で有料サービスを見せません。無料が目的の人に最初から売り込むと、信用を失ってしまいます。信頼関係は段階的に作るものです。 判断基準：「登録直後の読者との関係性を考えたとき、今このCTAを見せる必要があるか」を問いかけてみてください。
PDF受け取りページの役割
認証完了後に遷移するPDF受け取りページも、同じ考え方で設計しました。
役割は2つだけです。
- 無料PDFを渡す
- ステップメールが届くことを伝える
それ以外は入れません。売り込みもしません。有料教材への誘導もしません。
この段階で売り込みをするのは、まだ早いと思います。読者と信頼関係ができていない状態でコンバージョンを求めても機能しません。誘導はステップメールの中で段階的に行う設計にしました。
Stripe決済の組み込み——ステップメール完成後に一気に実装しました
なぜこのタイミングで組み込んだか
Stripeを組み込んだのは、ステップメールの設計が完成した後です。
理由はシンプルで、「忘れないうちにやってしまおう」という判断でした。
ステップメールの中で有料教材を紹介する流れを作った以上、決済ページが存在しなければ導線が途切れてしまいます。ステップメールと決済ページはセットで完成させる必要がありますよね。このタイミングを外すと、また後回しになる可能性がありました。
決済後の体験設計——メールに依存しない
Stripe決済が完了したあと、購入者をサンクスページへ遷移させ、そのページで有料教材を配布する設計にしました。
このとき、無料PDF配布と同じ問いが浮かびました。「ステップメールで教材を送る設計にしてもいいのでは」という考えです。
結論はNOでした。
理由は2つあります。
理由①：ステップメールの発火タイミングが掴めていない
ステップメールがいつ届くかのタイミングが正確に把握できていない状態でした。決済してから数分〜数十分後にメールで教材が届く設計は、購入直後の読者の期待に応えられない可能性があります。
理由②：決済完了自体が意思確認として機能している
クレジットカードで購入するという行為は、自分の意志で情報を入力して完了した行動です。DOI認証と同じ「自分の意志による確認」の役割を、決済行為が代わりに担っていると考えました。メール認証のプロセスを重ねる必要はないと判断しました。
「購入直後に教材を手に入れられる」という体験は、読者の期待と一致します。ステップメールの遅延リスクをここでも排除しました。
完成した全体構造
現時点で動いている導線の全体像はこちらです。
LP（ランディングページ）
↓
CF7フォーム送信
↓ ※ window.location.href でページ遷移
仮サンクスページ（認証を促す・売り込みなし）
↓
Benchmark Emailから認証メール送信（DOI）
↓ ※ 読者がクリックして認証
無料PDF受け取りページ（教材渡し・売り込みなし）
↓
ステップメール配信開始（Benchmark Email）
↓ ※ ステップメール内で有料教材を紹介
有料教材LP
↓
Stripe決済
↓
購入者向けサンクスページ（有料教材を即時配布）
↓
コンサル提案（未完成・今後実装予定）
使用ツールと役割の整理：
| ツール | 役割 |
|---|---|
| Contact Form 7（CF7） | 登録フォームの表示・送信処理 |
| Cloudflare Workers | APIキーをサーバー側に閉じ込める中継 |
| Benchmark Email | ステップメール配信・リスト管理 |
| WordPress（SWELL） | 全ページの管理・JS実装 |
| Stripe | 有料教材の決済処理 |
この後どうなったか
現時点では、登録者はまだいません。
LP自体がGoogleにインデックスされていない状態のため、流入がありません。導線の検証は、アクセスが来てからになります。
ただし「アクセスがないから設計は後回し」という判断はしませんでした。アクセスが来たときに取りこぼさない構造を先に作ることが、正しい順番だと考えています。
コンサル提案の部分はまだ未完成です。この部分の設計については、また別の記事で記録していく予定です。
- コードの仕組みが分からなくても自動化導線を作れますか
-
今回の実装はほぼすべてChatGPTのコードをコピペして解決しました。コードを完全に理解していなくても、「何が起きているか」「何をしたいか」を言語化してAIに投げることができれば、動く状態までは作れると思います。ただし何かが壊れたときに原因を特定しにくい点は理解しておく必要がありますよ。
- Stripeと無料PDF配布は同時に設計した方がいいですか
-
今回の判断では、ステップメールが完成した後にStripeを追加しました。この順番は、今回の設計における「ステップメール→有料教材紹介→決済」という導線の流れを先に確認してからStripeを組み込む、という意味で合理的だったと考えています。ただし設計段階から「決済後に何を渡すか」は決めておく方が、実装時に迷いが少なくなりますよ。
まとめ
今回の実践から得た判断基準を整理します。
コードが分からなくても「何が起きているか」を言語化する
successurlが動かなかった原因は、仕組みを理解していないまま実装したことにあります。ただし「何をしたくて何が動いていないか」を言語化してAIに投げることで解決できました。コードの理解よりも、問題の言語化の方が先に必要だと感じましたね。
読者の体験を途切れさせないページ設計
仮サンクスページが問い合わせ完了ページになっていた段階では、読者が「何かおかしい」と感じて離脱する可能性があります。体験の途切れは、その後の導線全体を機能不全にしてしまいます。専用ページを作るコストより、離脱のコストの方が高いですよ。
今回の設計ではメールへの依存を減らすことを一貫させました
無料PDFでも有料教材でも、配布のタイミングをメール到達に依存させませんでした。「読者が今すぐ受け取れる」という体験を優先しています。この判断基準は今回の導線全体を通じて一貫しています。
アクセスがない状態でも導線を先に完成させる
インデックスされていなくても、訪問者が来たときに取りこぼさない構造を先に作ります。設計を後回しにするほど、実装のコストは上がってしまいますよね。
今日できる一歩
自分のサイトの登録フォーム送信後の遷移を確認してみてください。専用のサンクスページが存在するか、そこで読者に求めている行動が1つに絞られているかを見直してみましょう。
関連記事
- 記事100本書いても成果ゼロだった理由【実践ログ】
- Benchmark Email メルマガ自動化が動かない原因｜アカウント停止とDOI仕様の誤認から設計を変えた記録
- ロングテールキーワードの見つけ方｜成果に繋がる複合検索設計
この実践記録を読んで、自分が今どの段階にいるかを確認してみてほしいですね。
Jogtimeは、設計によって変わりました。
では、あなたは今どの段階でしょうか？
- まず全体像を整理したい
- 構造を整えて伸ばしたい
- 設計から見直したい
今の状態に合わせて、次の一手を選んでください
コメント