記事情報を自動で収集＆一覧管理
サイト内の全記事をクロールして情報を自動取得・一覧表示。変更があった記事は毎日自動で最新情報に更新されます。
About
inSiteの記事情報管理機能とは
inSiteの記事情報管理機能とは、サイト内の全記事を毎日自動クロールしてタイトル・ディスクリプション・見出し・本文文字数・公開日／更新日・構造化データ・内部リンク・外部リンク・画像・canonicalまでをまるごと自動取得・差分更新するSEO記事資産管理の基盤機能です。
ユーザーが行うのは、初回プロジェクト作成時にサイトURLと本文エリアのclass名を指定するだけです。inSite はサイトマップから全URLを検出し、本文クラスを基準にコンテンツを精度高く抽出します。サイドバー・フッターのテキストを本文文字数に含めないなど、SEO分析に必要な正確性を担保します。
毎日の自動クロールでは、HTMLの差分で変更を検知。変更があった記事だけを再取得して最新化するため、サイトへの負荷を抑えつつ管理データは常に実態と同期した状態を保ちます。変更があった記事はそのままリライト記録機能に渡され、その後の検索パフォーマンス追跡が自動で始まります。
この機能で取得された記事情報は、内部リンクマトリクス・内部リンクグラフ・AI内部リンク提案・サイト改善アラート・リライト記録など、inSite のすべての分析・改善機能の基盤データとして使われます。「SEO に必要な記事情報の正確な集約」が、inSite のすべての出発点です。
Why it matters
なぜ「記事情報管理」が大事なのか
SEO の改善判断は、すべて「現在の記事の状態」を正確に把握することから始まります。タイトルが何文字か、内部リンクが何本あるか、見出しがどう構成されているか。これらが正確に集約されていなければ、リライトもリンク補強も改善アラートも、的外れな判断になります。
記事情報管理は単独の機能というより、inSite のすべての機能の基盤です。ここの精度が高いほど、上に乗る分析機能の精度も高くなります。
管理データが古いと、判断も古い
「リライトしたつもりの記事」が管理表で旧バージョンのままだと、その上で行うすべての分析が間違った前提に立ちます。データの鮮度が、判断の鮮度を決めます。
スプレッドシート管理は必ず止まる
手動メンテに頼ったコンテンツ管理表は、忙しい時期に必ず止まります。例外なく、3ヶ月で実態と乖離が始まります。これは真面目さの問題ではなく、設計の問題です。
「変更があった記事」を見逃さない
どの記事が直近で更新されたかは、リライト効果の測定にも、改善優先度の判断にも直結します。変更検知が自動化されていることが、改善サイクル全体の前提条件になります。
Tracked data
自動で取得する記事情報
SEO 改善判断に必要な記事情報を10種類、毎日のクロールで自動取得します。
タイトル
title タグの内容と文字数
ディスクリプション
meta description の内容と文字数
見出し構成
h1 〜 h6 の階層構造とテキスト
本文文字数
本文エリアの実テキスト文字数
公開日 / 更新日
HTMLメタデータから取得
構造化データ
JSON-LD の有無と種類
内部リンク
リンク先 URL とアンカーテキスト
外部リンク
サイト外へのリンク URL
画像
img タグ・alt 属性・broken 検知
canonical URL
rel=canonical の指定値
What you can do
できること
本文クラス指定で必要な情報だけを正確抽出
記事本文エリアの class名 を指定するだけで、サイドバーやフッターを除いた純粋なコンテンツ情報を抽出。文字数やリンク情報のノイズを排除します。
毎日の自動クロールで差分更新
全記事を毎日クロールし、変更があった記事だけを再取得・最新化します。サイト負荷を抑えつつ、管理表は常に実態と同期した状態を保ちます。
タイトル / ディスクリプション / 見出しの重複検出
カニバリゼーションの原因となるタイトル・ディスクリプション・見出しの重複を自動検出。重複が検出された記事はサイト改善アラートにも反映されます。
公開日 / 更新日 / 文字数で自由ソート
更新が古い記事を見つけてリライト候補に、文字数が少ない記事を強化対象に。一覧のソートとフィルタで改善優先度の判断が一瞬で済みます。
CMS / 実装形態を選ばない
WordPress でも、Astro / Next.js / Hugo / Jekyll / MovableType / 独自実装でも、HTMLをクロールできるサイトであれば利用可能。CMS のロックインがありません。
他機能の基盤データ
inSite の内部リンクマトリクス / 内部リンクグラフ / AI内部リンク提案 / リライト記録 / サイト改善アラート など、すべての分析機能がこの記事情報を基盤に動作しています。
How it works
記事情報取得の仕組み
サイトマップから全URLを自動検出
プロジェクト作成時にサイトURLを入力すると、sitemap.xml を読み込んでサイト内の全URLをリスト化します。
本文クラスを基準にコンテンツ抽出
指定された本文エリアの class 名を基準に、HTMLからタイトル・ディスクリプション・見出し・本文・リンク・画像・構造化データなどを正確に抽出します。
差分検知で変更があった記事のみ更新
HTMLのハッシュベース差分検知で、前回クロールと比較。変更があった記事だけを再取得して最新化します。
変更はリライト記録に自動連携
変更が検知された記事は自動的にリライト記録に追加され、その後の検索パフォーマンス変化が追跡されます。
他機能の基盤データとして提供
内部リンクマトリクス・グラフ・AI内部リンク提案・サイト改善アラートなど、他のすべての機能がこの記事情報を基盤に動作します。
Why we built it
なぜこの機能を作ったのか
inSite のすべての機能は、「サイトの現在の記事情報を正確に把握できている」ことを前提に動いています。そのため、最初に手を入れる必要があったのが、この記事情報管理機能でした。
SEOの現場では、コンテンツ管理表をスプレッドシートで作るのが伝統的なやり方です。でも、それが3ヶ月以上維持されているチームを、僕はほとんど見たことがありません。新しい記事を書くたびに行を追加し、リライトのたびに更新する。この運用は、忙しい時期に必ず止まります。
止まった管理表は、すぐに実態と乖離します。そして乖離した管理表をもとに「リライト候補は文字数2000以下の記事」みたいな判断をすると、当然ながら的外れな結論に至ります。データが間違っているのではなく、データの鮮度が間違っているのです。
鮮度の問題は、人間が頑張って解決できる問題ではありません。機械が毎日サイトを見に行って、変更を検知して、最新化する仕組みがないと、絶対に解決しません。
だから、毎日のクロールで記事情報を自動収集・差分更新する基盤を inSite の中に作りました。サイトURLと本文クラス名を指定するだけで、SEO に必要な10種類の情報が毎日最新化されていく。手作業のメンテはゼロです。
そして、この基盤データの上に 内部リンクマトリクス・グラフ・AI内部リンク提案・サイト改善アラート・リライト記録 など、すべての分析機能が乗っています。地味な機能ですが、inSite の他の全機能の精度を決める、最も重要な土台です。
Problem & Solution
こんな課題を解決します
スプレッドシートの手動管理が限界
人によってフォーマットが異なり、新規記事を追加するたびの更新が止まり、最終的には「実態と乖離した管理表」だけが残ります。記事数が増えるほど、メンテにかかる時間も増えていきます。
クロールで自動取得 + 差分更新
URLと本文クラス名を指定するだけで、毎日のクロールで自動取得・差分更新。スプレッドシートのメンテ作業がゼロになります。
記事数が増えて全体把握ができない
100記事を超えてくると、どの記事がいつ更新されたか・どの記事がリライト候補かを記憶で管理するのは不可能です。
全記事を一覧 + ソート・絞り込み
公開日・更新日・文字数で自由にソート/絞り込み。リライト優先順位の判断が一瞬で済みます。
タイトル / 見出しの重複に気づけない
同じトピックで重複した記事を書くと、カニバリゼーションが起きて順位が下がります。サイト規模が大きくなると、手動チェックは非現実的です。
重複を自動検出 + 改善アラートと連動
タイトル・ディスクリプション・見出し構成の重複を一覧で発見。改善アラート機能とも連動して、カニバリ防止のリライト判断ができます。
記事情報の自動収集を始める手順
本文エリアの class 名を指定
コンテンツ領域の class 名(例: .article-content / .post-content)を指定します。これにより本文文字数・本文中のリンクが正確に抽出されます。
初回クロール → 全記事の情報が一覧表示
サイト規模により数分〜数時間で全ページのタイトル・見出し・文字数・リンク情報が一覧表示されます。ソート・フィルタで改善候補をすぐに洗い出せます。
毎日自動で差分更新
以降は毎日自動でクロール。変更があった記事だけが最新化され、変更内容はリライト記録機能で自動追跡されます。
よくある質問
WordPress以外のCMSでも使えますか？
はい。inSite はサイトのHTMLをクロールして情報を取得するため、WordPress以外のCMS(Astro / Next.js / Hugo / Jekyll / MovableType / Movable Type / 独自実装サイトなど)でも利用できます。CMS による制約はなく、HTML が返るサイトであれば対応可能です。
記事情報はどのくらいの頻度で更新されますか？
毎日自動で全ページを再クロールし、変更があった記事の情報を最新化します。手動で更新ボタンを押す必要はありません。変更検知は HTML の差分で行うため、URL は同じでも内容が変わった記事は確実に最新化されます。
何記事規模まで対応していますか？
2,000記事規模まで対応しています。それ以上の規模については個別にお問い合わせください。
本文エリアの指定はどう設定しますか？
初回プロジェクト作成時に、本文を含む要素のclass名(例: .article-content / .post-content / .entry-content)を1つ指定するだけです。一度設定すれば毎日のクロールに反映され、サイドバーやフッターの文字を本文文字数に含めないなどの正確な集計ができます。
取得する項目をカスタマイズできますか？
基本項目(タイトル / ディスクリプション / 見出し構成 / 構造化データ / 公開日・更新日 / 文字数 / リンク情報 / 画像情報 / canonical)は標準で取得します。それ以外のカスタム項目が必要な場合はJSON出力機能でデータをエクスポートし、後段で自由に加工できます。
クロールがサイトに負荷をかけませんか？
1日1回・分散実行のスケジューリングで、本番環境への影響を最小化しています。サイトの robots.txt の設定にも従い、Disallow されたパスはクロールしません。
変更があった記事だけを把握できますか？
はい。HTMLの差分で変更検知しているため、「タイトルを変えた」「本文を書き直した」「内部リンクを追加した」記事はすべてリライト記録に自動で追加されます。リライト記録機能がその後の検索パフォーマンスを追跡します。
Goodbye spreadsheets
管理表は、
サイトそのものでいい
記事を書き終えるたびにスプレッドシートを更新する。リライト後に行を直す。新しいメンバーに「ここをこう書いて」と運用ルールを伝える。この終わりのないメンテ作業から、もう解放されていいはずです。
inSite の記事情報管理機能は、サイトURLと本文クラス名を1回指定するだけ。あとは毎日のクロールで、タイトル・見出し・文字数・リンク・画像・構造化データ・canonicalまでが自動で最新化されていきます。「サイトそのものが管理表」になります。
そしてこの基盤の上で、内部リンクマトリクス・改善アラート・リライト記録などすべての分析が動きます。データが常に最新だから、分析結果も常に正確。「鮮度のずれた判断」が起こりえません。
コンテンツ管理を、属人化させない。
その第一歩を、今日から始めてみませんか。
この機能を、まずは
無料で試してみませんか？
14日間すべての機能が無料。クレジットカード登録不要、自動課金もありません。
登録は3分で完了 · 自動課金なし · いつでも解約OK
