Cloudflare Pages の静的アプリに SEO 導線と D1 監視を足して公開運用へ寄せた実装

2026年07月19日

CraftMargin は、handmade-profit-calculator リポジトリで運用している、ハンドメイド販売者向けの利益計算アプリである。この週の変更で一番再利用しやすかった知見は、Cloudflare Pages に載せた静的アプリを「計算できるだけのツール」から、「検索流入を受け取り、監視し、収益化の安全確認までできる運用可能なアプリ」へ段階的に寄せた実装だった。

静的アプリは公開自体は簡単でも、公開後に困る点は別にある。どの検索導線が効いたか分からない、広告やアフィリエイト設定を安全に扱いづらい、配信後に最低限何を確認すべきかが属人的になりやすい、といった問題である。この記事では、Cloudflare Pages Functions と D1、静的 SEO ページ生成、production check を組み合わせて、その隙間をどう埋めたかを整理する。

この記事で解決すること

Cloudflare Pages に置いた静的アプリへ、重いバックエンドを増やさずに最低限の監視基盤を足したい。
SEO ページ、計算フォーム、収益化導線を別々に増やすのではなく、1 つの流れとしてつなぎたい。
実装だけでなく、テスト、build、deployment、release 前確認まで含めて変更境界を整理したい。

実装の要点

この週に扱った変更は、CraftMargin の公開運用を支える 3 つの層に整理できる。1 つ目は、.env.example、affiliateLinks.ts、check-production-seo.mjs を使った収益化設定の安全化である。広告 ID やカテゴリ別アフィリエイト URL を「入れれば出る」だけの状態にせず、未設定や危険な URL を弾きながら、本番確認を pnpm verify:production に寄せた。

2 つ目は、seo-pages.json と generate-seo-pages.mjs を中心にした検索流入の拡張である。ロングテール検索向けの静的ページを build 時に生成し、/?marketplace=...&sample=... の query を使ってトップの計算体験へ最短で着地させた。検索入口とアプリ本体を別物にせず、流入意図を計算開始まで引き継ぐ構造に変えた。

3 つ目は、Cloudflare Pages Functions と D1 を使った監視基盤の追加である。/api/events で匿名イベントを受け、/api/metrics/summary で集計し、/monitor/ の静的ダッシュボードで比較表示とランキングを見られるようにした。公開アプリ本体へ管理 UI を混ぜず、運用画面だけを分離したのがポイントである。

得られた知見

成果は、集客、計測、収益化確認がばらばらの施策ではなく、同じリポジトリ内で接続されたことにある。検索流入ユーザーは SEO ページから適切な marketplace と sample が入った計算フォームへ到達し、その後の calculation_completed や paid_interest_clicked のような匿名イベントは D1 に残せるようになった。これで「流入は増えたが使われたか分からない」という状態から一歩進める。

実装面でも、責務の分離が進んだ。収益化リンク構築は affiliateLinks.ts、検索可視化は searchConsole.ts、監視 API は functions/api/metrics/summary.ts、監視 UI は public/monitor/index.html と分かれており、UI、集計、配信確認を別々に変更しやすい。単に機能を足したのではなく、あとから直せる形に寄せた点が大きい。

検証の根拠として確認できたのは、ユニットテスト、E2E、build、production check の導線がこの週の変更に合わせて更新されていることだった。pnpm check、pnpm test:e2e、pnpm build、pnpm verify:production、pnpm exec wrangler d1 migrations apply ...、pnpm exec wrangler pages deploy ... まで手順がコードやドキュメントに落ちているため、少なくとも「どう検証して反映するか」は再現可能な状態に近づいている。

一方で、source material から本番 deployment や release の成功ログをすべて確認できたわけではない。そのため、ここでの成果は「本番運用へ寄せる実装と確認導線が揃ったこと」であり、「すべての本番反映が完了したこと」ではないと切り分けておく必要がある。

実装プロセス

最初に手を入れたのは、収益化設定の安全化だった。広告やアフィリエイトは、画面が動いていても設定ミスに気づきにくい。そこで .env.example のダミー値を減らし、カテゴリ別 URL を buildAffiliateLinks で正規化し、危険な外部 URL をテスト付きで弾く構成に変えた。さらに check-production-seo.mjs を用意し、本番 URL の HTML、robots.txt、sitemap.xml、ads.txt を HTTP レベルで見られるようにした。

次に、検索流入を受ける入口を増やした。ただし、記事ページだけ増やして終わると、流入とアプリ体験が分断される。そこで seo-pages.json のページ定義を build で静的 HTML へ変換しつつ、各ページの CTA が query param 付きで calculator に飛ぶよう generate-seo-pages.mjs を拡張した。これにより、minne、アクセサリー、梱包費のような検索意図を、トップページ上の入力初期値へそのまま受け渡せる。

最後に、施策結果を観測するための監視基盤を足した。Search Console だけではアプリ内行動が見えないため、Pages Functions 経由で匿名イベントを D1 へ保存し、/monitor/ で期間比較や販売先別ランキングを描画する構成を追加した。SEO 導線とアフィリエイトクリック計測を先につないでおいたことで、監視画面は単なるアクセス集計ではなく、改善施策を評価する場所として機能する。

つまり、この週の流れは「安全に公開できる設定を作る」「検索入口を増やす」「その結果を監視できるようにする」の順だった。機能追加を日付順に積んだというより、公開運用で詰まりやすいボトルネックを外側から順に潰していった形で理解すると分かりやすい。

利用した技術

対象アプリは CraftMargin、対象リポジトリは handmade-profit-calculator。フロントエンドは Vite + React + TypeScript、配信先は Cloudflare Pages である。
アプリ変更では src/App.tsx、src/components/Monetization.tsx、src/components/affiliateLinks.ts、src/lib/searchConsole.ts、src/lib/analytics.ts、src/styles.css を更新し、計算導線、収益化導線、可視化ロジックを分離した。
実装では src/content/seo-pages.json と scripts/generate-seo-pages.mjs を使って静的 SEO ページを build 時に生成し、index.html、public/llms.txt、public/llms-full.txt の入口も拡張した。
監視基盤では functions/api/events.ts、functions/api/metrics/summary.ts、migrations/0001_events.sql、wrangler.jsonc を使い、Cloudflare Pages Functions + D1 の最小構成で匿名イベント収集と集計を実装した。
テストは Vitest の affiliateLinks.test.ts、searchConsole.test.ts、seoPages.test.ts、App.test.tsx、Monetization.test.tsx と、Playwright の e2e/calculator.spec.ts を使っている。
build 導線は pnpm build と pnpm check、配信確認は pnpm verify:production、D1 migration と Cloudflare Pages 反映は pnpm exec wrangler d1 migrations apply ... と pnpm exec wrangler pages deploy ... が前提になっている。
release 運用としては、README と監視設計文書に migration、binding、再デプロイ、監視 URL 確認まで残しており、手順だけ口頭に残さない形にしている。

アーキテクチャ

アーキテクチャは、流入層、体験層、監視層の 3 段に分けると理解しやすい。流入層は静的 SEO ページ群で、検索意図ごとに作った HTML が入口になる。体験層は src/App.tsx の calculator 本体で、query param から marketplace や sample を受け取り、到着直後から計算できる状態を作る。監視層は Pages Functions と D1 で、利用中に発生した匿名イベントを保存し、運用者だけが /monitor/ から見られる。

flowchart LR
  A["静的 SEO ページ<br/>seo-pages.json + generate-seo-pages.mjs"] --> B["トップの calculator<br/>App.tsx"]
  B --> C["匿名イベント送信<br/>/api/events"]
  C --> D["Cloudflare D1<br/>events テーブル"]
  D --> E["集計 API<br/>/api/metrics/summary"]
  E --> F["監視 UI<br/>/monitor/"]

この構成で重要なのは、公開ユーザー向け UI と運用者向け UI を混ぜなかった点である。監視画面は public/monitor/index.html の静的 HTML と DOM 操作で完結しており、React バンドルへ管理機能を持ち込まない。そのため、利用者向けの初回表示を重くせずに監視を足せる。

また、配信確認の責務も別にした。アプリ内部に「本番確認ロジック」を埋め込むのではなく、check-production-seo.mjs が外側から公開 URL を検査する。アプリ本体、静的ページ生成、運用確認スクリプトが分かれているので、変更箇所と失敗箇所を切り分けやすい。

選定理由

Cloudflare Pages Functions と D1 を選んだ理由は、既存の静的配信構成から大きく外れずに、最小限のサーバー機能だけを足せるからである。別のバックエンドや認証基盤を増やすより、既存ホスティングの近くで完結させた方が、初期運用の複雑さを抑えやすい。

監視イベントを allow-list と短い文字列へ制限したのは、個人情報や無制限な payload を持ち込まないためである。行動分析を始める段階で、何でも集める構成にすると後で消す方が難しい。page_view、calculation_completed、paid_interest_clicked のような公開運用に必要な最低限から始めた判断は妥当だった。

SEO ページ生成を CMS 追加ではなく seo-pages.json と build script 拡張で進めたのは、運用対象を増やしすぎないためである。静的アプリのままページを増やし、同じ build で再生成できる形なら、deployment と release の単位も崩れにくい。

トップページへの導線を query param ベースにした理由も同じで、新しい状態管理や専用ルーターを追加せず、既存の calculator 体験を再利用できるからである。入口だけ増えて着地点が別物になると、テストと保守の境界が急に難しくなる。

production check を script 化したのは、SEO や収益化の確認を「担当者のブラウザで見る」から「同じコマンドで再実行する」へ変えるためである。実装後の release 品質は、コードだけでなく確認手順を固定できるかでかなり変わる。

導入手順

まず静的アプリの build / deployment / release 導線を確認し、どのコマンドで build し、どこへ配信し、公開 URL を何で確認するかを先に固定する。
収益化設定を安全にするため、.env.example のダミー値を見直し、カテゴリ別リンク生成や外部 URL 検証を独立関数へ切り出してユニットテストを付ける。
公開 URL を外側から検査する script を追加し、robots.txt、sitemap.xml、ads.txt、主要 HTML の存在確認を package script として実行できるようにする。
検索流入を増やしたいテーマを seo-pages.json のようなデータ層へ切り出し、build 時に静的ページを生成する。各ページの CTA は query param 付きで同じ calculator へ着地させる。
App.tsx 側で marketplace や sample を読み取り、検索入口ごとに初期入力を変えられるようにする。入口ページだけ増えても、到着後にすぐ試せなければ効果が薄い。
次に Pages Functions と D1 を追加し、匿名イベント受信 API、集計 API、migration、binding 設定を最小構成で用意する。個人情報を避けるため、イベント名と detail の schema は最初から厳しく絞る。
public/monitor/index.html のような別 URL で監視画面を作り、比較表示、日別集計、ランキングなど、次の施策判断に使う最小指標だけを表示する。
実装後は Vitest、Playwright、pnpm build、pnpm verify:production を回し、必要なら wrangler d1 migrations apply と wrangler pages deploy を release 手順へつなぐ。source material で成否未確認の項目は、未確認のまま明記する。

導入時の課題

最初の課題は、SEO、監視、収益化がそれぞれ別の話に見えやすいことだった。実際には、検索流入が calculator に着地し、その結果を監視し、必要なら収益化導線も改善するという 1 本の流れで考えないと、施策同士がつながらない。

次の課題は、静的アプリに監視を足すときに、すぐ管理画面を React 本体へ入れたくなることだった。しかし、それをやると利用者向け体験と運用者向け体験が結合し、バンドルも責務も重くなる。今回は /monitor/ を別にしたことで、この問題を避けている。

また、イベント計測は増やしすぎるとノイズになる。特に detail_json のような自由度の高いフィールドは、後で何でも入れられる一方で、制約が弱いと運用しづらい。allow-list、文字列長制限、カテゴリ単位の最小メタデータに留めた点は、導入初期の制約として重要だった。

最後に、deployment や release の成否が source material で全部確認できない場面がある。こういうときに実施済みと書かず、build 済み、手順整備済み、反映成否未確認を分けて書くことが、週次記事でも技術記録でも精度を保つ。

次に検討した方が良いこと

source query param ごとの計算完了率や有料導線クリック率を /api/metrics/summary へ載せ、どの SEO 入口が実際に強いかを数値で見られるようにする。
verify:production に構造化データや静的 SEO ページ群の存在確認を足し、公開後確認をさらに自動化する。
detail_json 依存の集計が増えるなら、カテゴリ別の派生集計や古いデータの圧縮方針を早めに決める。
SEO ページは増やし続けるより、Search Console と監視データを見て、残すページと削るページを選別する運用へ進めた方がよい。
D1 migration、binding 設定、Pages 再デプロイを CI/CD にどこまで組み込むかを決め、release 手順の手動部分を減らしていく価値がある。

Back to posts