inSiteに関する100の質問

記事の変更を毎日のクロールで自動検出し、リライト前後28日のクリック数比較で効果を客観判定する機能です。「いつ・何を変えて・効果がどうだったか」が手入力ゼロで蓄積されます。詳細はリライト記録機能ページを参照してください。

いいえ。inSiteは記事を毎日自動クロールしており、タイトル・ディスクリプション・本文・見出し・画像・内部リンクのいずれかに変更があれば自動でリライト記録として残します。管理表への手入力は不要です。

次の6種類の変更を自動検出します。

• タイトル
• ディスクリプション
• 本文
• 見出し
• 画像
• 内部リンク

どれが変更されたかはタグで識別できるので、「タイトルだけリライトした記事の効果」のように切り口別に振り返れます。

リライト検知日を起点に、前28日と後28日のURL全体クリック数を比較します。判定条件は次の通り。

• 割合: +15%以上 の増減
• 実数: +5クリック以上 の増減

両条件を満たすと「流入改善」/ 「流入悪化」と判定。さらに主要クエリ（前28日のクリック上位10クエリ）のCTR・順位を裏付け指標として使い、変更内容と整合していれば「リライト影響あり」と判断します。

28日後の最終判定では、次の6種類のいずれかが自動で確定します。

• 流入改善 リライト影響あり
• 流入改善 影響不明
• 変化なし
• 流入悪化 リライト影響あり
• 流入悪化 影響不明
• 判定不能

「影響不明」はマイナス評価ではなく、主要クエリの裏付けが限定的という意味で、新規クエリや拡張クエリで流入が増えた可能性も残しています。

リライト後28日まで待たずに、効果の方向性を早期に把握するためです。リライト後7日／14日／21日の各タイミングで次のいずれかを自動表示します。

• 流入改善のきざし
• 様子見
• 流入悪化のきざし
• データ待ち

いいえ。AIは判定を決めません。判定ロジックはルールベースで動作し、AIは確定した判定結果とGSCの数値変化、変更差分をもとに「変更内容と数値変化がどう整合しているか」という解釈の仮説を生成します。原因の断定や成功/失敗の断定は行いません。

プロジェクト内の全記事に対応します。2,000記事規模まで対応可能。記事数が増えても、リライト記録の自動集計は変わらず続きます。

サイト内のページ同士を線で結んだマップで、サイト全体の内部リンク構造を1画面に可視化する機能です。被リンク数に応じて記事の表示サイズが変化するため、ハブ記事と孤立記事が一目でわかります。詳細は内部リンクグラフ機能ページを参照してください。

用途が異なります。

• マトリクス表: 「どのページからどのページへリンクしているか」を行と列で詳細確認
• グラフ表示: サイト全体のリンク構造の俯瞰、ハブ記事や孤立記事の即時発見、視覚的な傾向把握

両方を組み合わせると構造把握と詳細確認の両方ができます。

各ページへの内部被リンク数に応じて自動でサイズが変化します。被リンクが多い記事ほど大きく描画されるため、サイト内で参照されている回数の多いハブ記事が瞬時にわかります。

はい。記事数が多くても、関連性の高い記事は近くに集まる形で自動的に配置されるため、視覚的に整理された状態で表示されます。2,000記事規模まで対応します。

Claude をはじめとする最新の大規模言語モデル（LLM）と、文章の意味を数値ベクトルに変換するEmbeddingモデルを組み合わせています。単純なキーワードマッチではなく、コンテンツの意図と文脈で関連性を判断します。

提案の方向が異なります。

• 発リンク提案: 「いま開いている記事から、どこへリンクを張ると良いか」を提案。新しく書いた記事を既存記事の文脈に組み込みたいときに役立ちます
• 被リンク提案: 「いま開いている記事に、どの記事からリンクを集めると良いか」を提案。ハブ記事として強化したい記事や、内部被リンクが少ない記事をテコ入れするときに役立ちます

提案はあくまで参考なので、必ず最終判断はユーザー側で行ってください。AIは現在の類似度スコアと文脈を見て、関連性が著しく低くなったリンクに削除推奨フラグを付けます。古い記事のリンクや、文脈が変わってしまったリンクの整理に役立ちます。

はい。各リンク提案には自然なアンカーテキストがセットで生成されます。「こちら」「詳しくはこちら」のようなSEO価値の低い表現を避け、リンク先記事の検索意図に合う具体的な言葉を提案します。

2,000記事規模まで対応します。新規記事追加時にも、既存全記事との関連性を分析した上で発リンク・被リンクの両方向で提案が出ます。

孤立記事を発見したら、AI内部リンク提案機能を使うと、その記事と関連性の高いページ・適切なアンカーテキスト・挿入位置を自動で提案できます。

1. グラフで見つける
2. AIで補強案を得る
3. 実装する

の流れで効率的に孤立を解消できます。

GoogleのURL Inspection APIから、各ページのインデックス判定結果・カバレッジ状態・インデックス状態・robots.txt状態を毎日自動取得する機能です。手動のURL検査ツール巡回が不要になります。詳細はインデックス状況チェック機能ページを参照してください。

Google公式のAPIには1日2,000URLまでのクォータ制限があります。inSiteはこの制限内で全ページを巡回するよう自動スケジューリングするため、ユーザー側で意識する必要はありません。2,000ページを超えるサイトでは、優先度順に分散してチェックします。

Googleが返すカバレッジ状態をそのまま保持・集計します。代表的なものは次の通り。

• noindexタグ検出
• robots.txtによるブロック
• クロール済み未インデックス
• 検出済み未インデックス
• Soft 404
• リダイレクトエラー
• サーバーエラー（5xx）
• ページが見つからない（404）
• アクセス禁止（403）
• ユーザーが指定したcanonical URLでない

はい。URL Inspection APIはgoogleCanonical（Googleが選んだcanonical）とuserCanonical（ユーザーが指定したcanonical）の両方を返します。inSiteはこの2つを並べて表示するため、Googleが意図と違うcanonicalを選んでいる記事を即座に発見できます。

コンテンツ・技術・パフォーマンスの3カテゴリで計10種類を検出します。

• タイトル要調整
• ディスクリプション要調整
• alt未設定の画像
• 画像リンク切れ
• 未インデックス
• 内部リンク不足
• 内部リンク切れ
• canonical不一致
• nofollow付き内部リンク
• 長期間更新なし

詳細はサイト改善アラート機能ページを参照してください。

各アラートにHIGH／MID／LOWの3段階で重要度を自動付与します。検索流入への影響度合いに基づいて並べ替えられるため、まず対応すべき記事から手をつけられます。

はい。修正後の次回クロールで問題が解消されれば、アラートは自動で消去されます。手動で「対応済み」フラグを付ける必要がないため、常に「いま残っている問題」だけに集中できます。

はい。インデックス状態に変化があった場合、サイト改善アラートと連動してダッシュボード上で警告として表示されます。意図せずインデックスから外れたページを翌朝に検知できます。

機能によって異なります。次の機能にはSearch Console連携が必要です。

• 記事の検索パフォーマンス取得
• URL Inspection APIを使ったインデックス状況取得
• リライト効果判定

連携はプロパティ権限のあるGoogleアカウントで認証するだけです。

いいえ。Search Console標準UIには「1日1,000行まで」の表示制限がありますが、inSiteはAPIで毎日データを取得して記事単位で集約するため、1,000件の制限を超えてサイト内全記事の検索パフォーマンスを確認できます。

記事情報・内部リンク・インデックス状況・Search Consoleデータすべて毎日自動更新されます。手動でクロールリクエストを実行する必要はありません。

次の情報を毎日のクロールで自動取得します。

• タイトル・ディスクリプション
• 見出し構成（h1〜h6の階層）
• 本文文字数
• 公開日・更新日
• 構造化データの有無
• 内部リンク（リンク先URLとアンカーテキスト）
• 外部リンク
• 画像（altと壊れリンク検知）

詳細はコンテンツ管理機能ページを参照してください。

初期設定で本文を囲んでいる要素のclass名（例: article-body）を指定します。WordPressのSWELL・SANGOなどメジャーテーマや、独自CMSでも該当のクラス名を指定するだけで本文を取得できます。設定後は自動で本文文字数・見出し構成が抽出されます。

記事の本文・見出し・内部リンクなどの構造化データをJSON形式で出力し、Claude・ChatGPTなどのAIに渡してリライト・要約・分析させる用途に使えます。詳細はJSONエクスポート機能ページを参照してください。

はい。次の項目まで含めて出力可能です。

• タイトル・ディスクリプション
• 見出し構成
• 本文
• 内部リンク（リンク先URLとアンカーテキスト）
• 外部リンク
• 画像情報

あります。AIにリライトを依頼するとき、その記事から外向きに伸びている内部リンクのアンカーテキストとリンク先URLがあると、関連トピックを踏まえた文章を生成できます。「他の記事と被らない切り口で書き換えて」のような指示も効きます。

次の3プランがあります。

• スタンダードプラン9,800円/月: 1プロジェクト・1ユーザー
• プロプラン24,800円/月: 3プロジェクト・3ユーザー・権限管理
• マックスプラン69,800円/月: 10プロジェクト・10ユーザー・権限管理

詳細は料金プランページを参照してください。

はい。プロプランのすべての機能を14日間無料でお試しいただけます。クレジットカードの登録は不要で、期間満了後に自動課金されることもありません。

いいえ。クレジットカード登録不要・期間満了で自動課金なしのため、14日間で課金されることは絶対にありません。継続したい場合のみ、トライアル終了後に支払い情報を登録してください。

無料トライアル開始時は不要です。トライアル終了後に有料プランへ移行する場合のみ、支払い方法の登録が必要になります。

はい、いつでも変更可能です。スタンダード → プロ → マックスへのアップグレード、およびその逆のダウングレードも、管理画面から即時切り替えできます。

はい、いつでも解約可能です。解約手数料はかかりません。管理画面から数クリックで解約手続きが完了します。

かかりません。長期契約の縛りもなく、月単位で自由に解約できます。

次のクレジットカードに対応しています。

• Visa
• Mastercard
• JCB
• American Express
• Diners

マックスプランをご契約の法人向けに、請求書払いに対応します。お問い合わせフォームからご相談ください。

現時点では月払いのみの提供です。年払いプランの提供は今後のアップデート情報でご案内します。

はい。プラン上限を超える場合は、上位プランへのアップグレードでプロジェクト数・ユーザー数を増やせます。マックスプランでも足りない場合はお問い合わせください。

支払い方法が未登録の場合、自動的にアクセス制限がかかります（自動課金は発生しません）。継続したい場合は、トライアル期間中またはトライアル終了後に管理画面から支払い情報を登録してください。

URLとclass名を入力するだけなので、数分で始められます。Googleアカウントで3分でサインアップでき、複雑な設定は不要です。初回クロール完了まではサイト規模により数分〜数時間かかります。

次の3つだけです。

• Googleアカウント
• 管理したいサイトのURL
• Search Console連携を使う場合は該当サイトのSearch Consoleプロパティ権限

サーバーへのインストールは不要、ノーコードで導入できます。

はい。inSiteへのサインアップ・ログイン・Search Console連携にGoogleアカウントを使います。組織のGoogle Workspaceアカウントでも個人のGmailアカウントでも問題ありません。

はい。inSiteはサイトのHTMLをクロールして情報を取得するため、WordPress以外のCMS（Astro、Next.js、Hugo、Jekyll、MovableType等）や独自実装のサイトでも利用できます。本文を囲んでいる要素のclass名を指定するだけで動作します。

はい。inSiteは最終的にブラウザで表示されるHTMLをクロールするため、SSG・SSR・ヘッドレスCMSの方式に関係なく動作します。Astro・Next.js・Nuxt・Gatsby・Hugo等のSSG／SSRフレームワークでも問題ありません。

はい。サブドメインも独立したサイトとして登録できます。例えば blog.example.com と media.example.com を別々のプロジェクトとして管理可能です。

はい。次のように管理できます。

• プロプラン: 3プロジェクトまで
• マックスプラン: 10プロジェクトまで

複数メディア運営やSEOコンサルティングで複数クライアントを抱える場合に便利です。

Search Consoleにログインし、該当サイトのプロパティで「設定 → ユーザーと権限」から、inSiteで認証に使うGoogleアカウントに「フル」または「制限付き」権限を付与してください。サービスアカウントを使わず、通常のユーザー権限で連携できます。

ブラウザで該当ページを開き、本文部分を右クリック → 「検証」（またはInspect Element）でDOMツリーを表示。本文を含む親要素のclass属性を確認してください。WordPressのSWELL・SANGO・JIN等のメジャーテーマでは、設定UIに代表的なclass名のガイドが表示されます。

サイト規模により次の目安です。

• 100記事程度: 10〜30分
• 500記事程度: 1〜2時間
• 1,000記事以上: 数時間

完了まで作業を待つ必要はなく、翌日にダッシュボードを開けばすべてのデータが揃っています。

次の5ステップが最短ルートです。

1. Search Consoleを連携する
2. 本文class名を設定して初回クロール
3. 翌日ダッシュボードで「サイト改善アラート」を確認
4. 重要度HIGHから順に改善着手
5. 内部リンクグラフで全体構造を俯瞰

サイト改善アラート（重要度HIGH順）から見るのが最も効率的です。SEOへの影響が大きい問題が並ぶため、リソース配分を間違えません。定番フローは次の通り。

1. サイト改善アラートで重要度HIGH順を確認
2. 内部リンクグラフで全体構造を把握
3. Search Console連携で記事別の検索パフォーマンスを確認

Search Console連携で「順位11〜30位×表示回数の多い記事」を抽出するのが最優先ゾーンです。優先順位は次のように判断します。

• 最優先: 順位11〜30位の表示回数が多い記事（コンテンツの質改善で10位以内を狙う）
• 高: 順位1〜10位だがCTRが低い記事（タイトル・ディスクリプション改善）
• 中: 順位31〜50位の表示回数が多い記事（検索意図のズレを修正）

重要度HIGHのアラート × 検索流入の多い記事の交差点から着手します。流入の少ない記事のアラートを直しても効果は限定的なので、流入のある記事の問題を優先しましょう。アラートビューで「重要度HIGH」でフィルタすれば一括確認できます。

次のフローが定番です。

1. 翌日のクロールで取り込まれるのを待つ
2. インデックス状況チェックで「インデックス済み」を確認
3. 内部リンクグラフで新規記事の位置を確認
4. 孤立していたらAI内部リンク提案で被リンク先を探す
5. 公開後7日でSearch Console連携のクリック推移を確認

詳細は新規記事公開直後のモニタリングユースケースを参照してください。

次の3パターンが効果的です。

1. 新規記事公開直後: 被リンク候補を抽出して既存記事から内部リンクを集める
2. 孤立記事の発見時: 補強リンクを抽出する
3. リライトのタイミング: 発リンクを追加する

Search Console連携で記事単位のクリック・表示・CTR・順位が1画面に集約されるため、前期間比較を期間指定でそのままレポートに転記できます。次の要素をスクショで貼り付けるだけでレポートが完成します。

• 順位分布グラフ
• 記事別の伸び・落ちトップ10
• 今月実施したリライト一覧（リライト記録カレンダー）

次の3ステップで対応します。

1. Search Console連携で「アプデ前28日vs後28日」の記事別クリック減少量を確認
2. インデックス状況チェックでアプデ後にインデックスから外れた記事を特定
3. リライト記録カレンダーでアプデと重なったリライトを切り分け

次の順序が効果的です。

1. 流入の大きい記事から関連性の高い記事へのリンク（評価を流せる、最効率）
2. 孤立記事への被リンク補強（次点）
3. 順位11〜30位の記事から関連の上位記事へのリンク（上位記事をさらに強化）

3層構成が定石です。

• 管理者（オーナー）: 1名（プロジェクト設定変更可）
• 編集者: リライト・改善実行担当を数名
• 閲覧者: 数値確認のみのメンバーを数名

プロプラン以上で権限管理機能を使えるので、メンバーの役割に応じて権限を絞ることで誤操作も防げます。

役割が異なります。

• Search Console: Google公式の検索データを「見る」ツール
• inSite: それを「サイト管理に使える形に整理する」ツール

Search Consoleの1,000件制限・記事単位集計の手間・期間比較の煩雑さを、inSiteが解消します。両者は競合せず、inSiteはSearch ConsoleのAPIを叩いてデータを取得・整理します。

守備範囲が異なります。

• Ahrefs: 競合分析・被リンク調査・キーワード調査に特化（「外向き」=競合・市場）
• inSite: 自社サイトの状態管理・運用自動化に特化（「内向き」=自社）

両方併用するチームも多いです。

使い方が異なります。

• Screaming Frog: クロール時点のスナップショットを取るデスクトップツール（単発の監査向き）
• inSite: 毎日継続的にクロールしてダッシュボードに蓄積するクラウド型ツール（日常的な運用向き）

SE Ranking・Semrushは競合キーワード調査・順位追跡・被リンク調査・サイト監査のオールインワンツールです。inSiteは競合分析やキーワード調査機能を持たず、代わりに「自社サイトの記事を毎日自動管理する」専門ツールとして深く作り込まれています。

取り扱うデータが異なります。

• GA4: サイトに訪れた後のユーザー行動（CV・滞在・離脱）を分析（「検索後」）
• inSite: サイトに訪れる前段階のSEO状態（インデックス・順位・内部リンク・リライト）を管理（「検索前」）

Lighthouse・PageSpeed Insightsは個別ページのパフォーマンス監査に特化しています。inSiteはパフォーマンス監査機能は持ちませんが、「長期間更新なし」のような運用観点のSEO問題検出を担当します。両者は守備範囲が異なるので併用が現実的です。

主に次の5点です。

• 更新情報の手入力ゼロ（毎日自動取得）
• 内部リンクの全体像をグラフで一目把握
• インデックス状態を全URL自動チェック
• リライト前後28日のクリック比較を自動判定
• チームでの権限管理共有

競合しません。役割が異なります。

• Yoast・Rank Math: 記事単位のオンページSEO支援（タイトル文字数チェック・スコア表示等）
• inSite: サイト全体の運用管理

Yoast/Rank Mathで個別記事を整備、inSiteでサイト全体を俯瞰、という使い分けが自然です。

はい。inSiteのJSONエクスポート機能で記事の本文・見出し・内部リンクを構造化データとして出力し、ChatGPT・Claude等のAIに渡してリライト・要約・分析を依頼できます。AI内部リンク提案機能もClaude等のLLMを内部で活用しています。

次の3点が他にないユニークな機能です。

• リライト前後28日のクリック比較で効果を自動判定する機能
• AI内部リンク提案で発リンク・被リンクの両方向を分析する機能
• 10種類のSEO問題を毎日自動検出するアラート機能

「自社サイトの運用サイクルを丸ごと自動化する」という設計思想で作られています。

現時点では日本語のサイトを主な対象としています。サイト管理機能自体は言語非依存で動作しますが、サイト改善アラートやAI内部リンク提案の最適化は日本語サイトを前提に調整されています。

英語サイトでも基本機能は動作します。

• 記事情報取得
• 内部リンク可視化
• インデックス監視

ただし、AI内部リンク提案・本文文字数判定など、一部の機能は日本語向けに最適化されているため、海外サイト本格運用は今後のアップデートで対応予定です。

2,000記事規模まで対応しています。それ以上の規模については個別にお問い合わせください。サイト改善アラート・内部リンクグラフ・AI内部リンク提案すべて2,000記事スケールで動作確認済みです。

サイト追加日以降に取得したデータは継続的に保持されます。Search ConsoleのAPIから取得できる検索パフォーマンスデータの上限が過去16ヶ月なので、検索データは過去16ヶ月分が利用可能です。

クロールは適切な間隔をあけて分散実行されるため、通常のサイト運用に影響しません。ユーザーエージェントを明示しており、robots.txtの設定にも従います。

現時点で外部向けAPIは提供していません。ただし、JSONエクスポート機能でAI連携用の構造化データを取り出すことは可能です。API提供は今後のロードマップにあります。

はい。次の方法でエクスポート可能です。

• JSONエクスポート機能（記事情報・本文・内部リンクなどの構造化データ）
• Search Console連携データ・リライト記録のCSVダウンロード（ダッシュボード上から）

次のセキュリティ対策を講じています。

• 全通信SSL化
• Google認証によるサインイン
• プロジェクト単位の権限管理（プロプラン以上）

Search Console連携はGoogle公式のOAuthフローを使用するため、パスワード等の認証情報をinSiteに渡す必要はありません。

次の順序で原因を確認してください。

1. robots.txtでクローラーがブロックされていないか
2. サーバー側のレートリミット・WAF設定でブロックされていないか
3. Cloudflareのチャレンジページなどでブロックされていないか（IPホワイトリスト設定が必要な場合あり）

原因がわからない場合はお問い合わせフォームからご相談ください。

次の順序で確認してください。

1. 連携に使うGoogleアカウントがSearch Consoleプロパティ権限を持っているか確認
2. プロパティが「ドメインプロパティ」か「URLプレフィックス」かを確認（どちらも対応していますが設定方法が異なる）
3. ブラウザの拡張機能・広告ブロッカーを一時無効化して再試行

それでも解決しない場合はお問い合わせください。

2つのラグがあります。

• inSiteのクロールは1日1回のため、最大24時間のラグ
• Search Consoleデータ自体も通常2日前後の遅延あり

リライト直後のクリック数変化は数日待つ必要があります。即時反映が必要な場合は、手動再クロール機能（管理画面）をご利用ください。

問い合わせ先は次の通りです。

• お問い合わせフォーム（一般的な質問・要望）
• 不具合報告フォーム（バグ・障害報告）

営業時間（平日10:00〜18:00）内に順次返信します。