無料ツールから始める、SEO・GEOを継続改善するサイトづくり

チャットから製品サイト、行動分析、検索データがつながり、レポートとカレンダーが定期的な振り返りを表す

概念図：チャットでの依頼をサイトの公開と定期分析につなげるイメージです。製品の画面や成長実績を示すものではありません。

製品サイトを公開しても、チームの仕事は続きます。ページが開くか、クリックが記録されるか、訪問者はどこから来るか、次に何を改善するかを確認する必要があります。

その情報は、ホスティングサービス、分析ツール、検索の管理画面に分かれています。サイトを更新するには、これらの情報をまとめて判断につなげる作業が必要です。

Leina を使うと、チームは Slack で仕事を依頼し、必要なアプリを連携して、同じ会話で結果を受け取れます。サイト作成の依頼を、実績の分析、合意した範囲での修正、結果の報告という継続的な仕事へと広げられます。

Vercel がデプロイを担い、PostHog がサイト内の行動を記録し、Google Search Console が検索パフォーマンスのデータを提供します。Leina がこれらを一つのワークフローにつなぎます。

この記事は、録画された Leina の事例を Slack の利用シーンに置き換えて紹介しています。元の実演では飛書（Feishu）が使われており、以下の実装結果はその実演に基づきます。

無料ツールで抑えられる費用

PostHog には無料枠があり、Google Search Console は無料です。Vercel Hobby は個人の非商用利用に限定されるため、商用サイトには対応プランが必要です。無料ツールから始めるとは、条件に合うサービスや無料枠を活用することです。Leina、ドメイン、超過利用の費用は別途確認してください。

サイトと計測の要件を一緒に伝える

まず Leina で Vercel、PostHog、Google Search Console を連携します。そのうえで、必要なページと計測対象を Slack で伝えます。

Leina の製品紹介サイトを作成してください。トップ、料金、機能、ブログの各ページが必要です。連携済みの Vercel で公開し、PostHog で主な操作を計測するレポートを作成してください。継続的な SEO 分析のため、Google Search Console も連携してください。

この依頼には、ページ構成、使用するアプリ、公開後に必要なデータが含まれています。サイトにアクセスできること、重要な操作が記録されること、分析に使うデータソースが明確であることを確認できます。

録画の事例では、Vercel のドメインで製品デモサイトが公開されました。機能や料金は公式情報を正とすることも、サイト内で明示されています。

三つのアプリで異なる側面を確認する

それぞれのアプリが、サイトの状態を別の角度から示します。

アプリ	ワークフローでの役割	確認できること
Vercel	サイトの公開とデプロイ状況の確認	ページが公開され、変更が反映されたか
PostHog	ページ閲覧、ボタンのクリック、読了状況の記録	どのページを訪れ、どこで次の操作に進んだか
Google Search Console	サイトの確認、検索やインデックス情報の参照	検索データが利用できるか、注目すべきページはどれか

アプリ連携によって、Leina は仕事に必要なツールを利用できます。実行できる操作は、承認されたアカウント、プロジェクト、権限の範囲に依存します。仕組みは業務アプリの安全な連携（英語）で説明しています。

Slack の依頼からサイトとデータへ

flowchart TB
  accTitle: Slack の依頼からサイトとデータへ
  accDescr: チームが Slack で依頼し、Leina が承認済みの接続で Vercel、PostHog、Google Search Console を利用して、結果を Slack に返します。
  C("Slack
依頼と結果"):::channel <--> L("Leina"):::agent
  L --> A("承認済みのアプリ接続"):::gateway
  A --> V("Vercel
サイト公開"):::resource
  A --> P("PostHog
サイト内の行動"):::resource
  A --> G("Google Search Console
検索パフォーマンス"):::resource

Slack で依頼と結果をやり取りし、Leina が承認済みの接続を通じて公開、行動分析、検索データを扱います。

確認できる結果とともにサイトを引き渡す

録画の完了報告では、Leina は 8 ページを公開し、すべてが HTTP 200 を返すことを確認したと報告しています。その後、実際に開ける製品ページと、Ready と表示された Vercel のデプロイが示されました。

報告には、ページのタイトルと説明、正規 URL、共有用メタデータ、構造化データ、robots.txt、サイトマップ、記事間の内部リンクといった検索の基礎設定も含まれていました。

これらは次回の更新でも使えるチェック項目です。チームはページの URL、デプロイ記録、設定一覧を確認し、変更後に同じ項目を検証できます。

ページと一緒に計測も確認する

実演には PostHog のダッシュボードも登場します。Leina は、訪問数、ページ別の閲覧、行動を促すボタン（CTA）、内部リンク、記事の読了状況、FAQ の操作、流入元、デバイスなどについて、11 個のレポートを作成したと報告しました。ブラウザーで閲覧やクリックを行い、イベントが届くことも確認しています。

ページが動くことと、操作を計測できることを、一緒に確認します。

「料金を見る」をクリックした後、対応するイベントは届くでしょうか。閲覧した記事とその読み進め方を識別できるでしょうか。こうした確認が済んで初めて、データを分析に使う準備が整います。

実演の初期データは受け入れ確認の操作から得られたものです。イベント収集の動作は確認できますが、顧客の行動を評価するには運用開始後のデータが必要です。

サイト所有者による確認も手順に含める

Google Search Console の設定では、所有者の操作が必要になりました。実演時は所有権の確認が未完了で、付与されていた権限だけでは直接完了できなかったためです。

Leina は残っている手順を説明しました。Search Console で HTML の確認タグを取得し、サイトに挿入するために渡し、再デプロイ後に Google の画面で確認を完了します。

会話の中で担当が明確になり、ユーザーは次の操作を把握できます。後の画面では Search Console がデータを処理中で、一部のレポートは十分な利用データがない状態でした。

この段階で得られたのは、データを収集して確認するための基盤です。検索データの蓄積には時間やアクセスが必要です。初期の報告には、使えるデータと不足している情報の両方を記載します。

定期的な分析を具体的なタスクにする

サイトの公開後、Slack で次の依頼を追加できます。

月に 2 回、SEO とクリックの分析レポートを作成してください。合意した範囲でサイトを改善してください。目標は、訪問者から有料顧客への転換を増やすことです。

続いて、どのデータを分析するか、どこへ報告するか、どの変更を Leina に任せるかを決めます。

実演の最後には、SEO とコンバージョンのレポートタスクが有効になった画面が示されました。実際の予定は毎月 1 日と 15 日の午前 10 時です。これは月 2 回の実行です。厳密に 14 日ごとの実行が必要なら、その間隔とタイムゾーンを明示します。

設定された仕事には、次の手順が含まれていました。

Search Console と PostHog の関連データを取得する。
対象期間の実績と分析結果を PDF レポートにする。
事前に定めた条件を確認し、承認された範囲で限定的に変更する。
デプロイ後に対象ページとイベント収集を確認し、変更を記録する。
短い報告とレポートを元の会話へ返す。この紹介では Slack が返却先となる。

タスク画面から分かるのは、定期実行が設定されたことです。複数回の実行成功や、数値で確認できる改善効果までは実演に含まれていません。

定期分析から次の改善へ

flowchart TB
  accTitle: 定期分析から次の改善へ
  accDescr: 定期タスクが検索と行動のデータを取得し、不足時は理由を報告します。十分な場合は分析して変更条件を確認し、変更を検証して Slack に報告した後、次回を待ちます。
  T("定期実行"):::channel --> D("検索と行動の
データを収集"):::resource
  D --> Q{"データは十分？"}:::gateway
  Q -->|いいえ| N("不足と理由を説明"):::restricted
  Q -->|はい| R("実績を分析
レポートを作成"):::agent
  R --> J{"変更条件を満たす？"}:::gateway
  J -->|はい| E("範囲内で変更
1 回につき最大 2 か所"):::agent
  E --> V("公開と検証
変更と復元手順を記録"):::resource
  J -->|いいえ| H("報告とレポートを
Slack に返す"):::channel
  V --> H
  N --> H
  H --> W("次回を待つ"):::channel
  W -.-> T

データ不足は理由とともに報告し、合意した条件を満たす場合だけ変更します。

改善の範囲を明確にする

この事例では、各回の変更は最大 2 か所に制限されています。対象はタイトル、説明、CTA の文言、内部リンク、共有用メタデータなどです。各変更に理由、期待する効果、検証方法を残します。

料金、機能、対応プラットフォームといった製品情報は公式情報に従い、所有権の確認タグや流入元を識別するパラメーターは保持します。デプロイの確認と、元に戻す方法の説明もタスクに含まれていました。

こうしておくと、どのタイトルを変えたか、なぜボタンを修正したか、次回はどの指標を見るかを確認しやすくなります。

録画内のしきい値は、このタスク固有の設定です。別のサイトでは、アクセス数、ページの目的、データ量に合わせて条件を決め、テスト操作と顧客の訪問を区別して判断します。

有料転換の追跡をサイトの先までつなぐ

目標は有料顧客への転換ですが、製品サイトで直接確認できるのは閲覧、クリック、外部への移動が中心です。登録と支払いは別の業務システムで行われます。

Leina の完了報告では、CTA のリンクに UTM パラメーターを付け、流入元とボタンの位置を識別できるようにしたと説明しています。これにより、トップ、機能、料金、ブログのどこから来たかを追跡する手がかりが残ります。

どの入口が有料顧客につながったかを判断するには、移動先のシステムがパラメーターを保持し、登録や支払いのイベントと関連付ける必要があります。録画で確認できるのはその準備であり、支払いまでの追跡完成や転換率の向上ではありません。

チームは段階的に検証できます。まず閲覧とクリック、次に業務システムへ届く流入元情報、最後にその流入元に関連付いた登録と支払いを確認します。

定期的な SEO 改善を GEO へ広げる

SEO は検索での可視性を扱います。GEO（生成エンジン最適化）は、AI の回答で内容が正確に理解、言及、引用されるかに注目します。両者は一部の基盤を共有し、Google の説明でも、基本的な SEO は同社の AI 検索機能に有効とされています。

追加する手順として、顧客の質問に沿ってページを改善し、確認できる製品情報と出典を補い、固定した質問群についてブランドへの言及、引用ページ、回答の正確性を定期的に記録する方法が考えられます。サイト内の行動と併せて検討し、次の修正を決めます。

これは設計・検証が必要な拡張案です。録画は SEO、クリック分析、定期タスクの設定を示しており、GEO の監視や AI 引用の増加は示していません。評価には追加のデータソースと確認手順が必要です。

まず一度、確認できる形で仕事を完了する

この流れは、サイト作成、公開の確認、分析、定期的な振り返りを、チームが普段使う会話にまとめます。Slack で目標を伝え、認証や所有権確認で必要な操作に協力し、同じ場所で結果を受け取れます。

最初は、次のように依頼できます。

製品サイトのデプロイ、主要ページ、イベント計測を確認してください。承認済みの検索データと行動データから初回レポートを作成し、情報源、不足データ、優先すべき二つの課題を示してください。内容を確認した後、変更範囲と検証手順を明確にして、合意した頻度で実行してください。

一度の結果を確認できるようにしてから、機能した手順を定期実行にします。同じページ、指標、事業目標に基づいて、次の改善を進められます。

チームでの利用については、Leina チーム AI エージェントの概要（英語）と権限管理（英語）も参照してください。