千のメタによる死
単一の技術的問題が
記事を殺すことはない。でも複数なら話は別。
弱いタイトル、欠けたメタ、3回前の編集で意味があった見出し構造、廃止されたページへの内部リンク。どれも少しずつコストがかかる。300記事、4年でその少しが積もり積もって検索クリックの1%未満しか届かないページ2へと続く[SEO consensus]。
積み重なったもので、誰かのミスではない
コンテンツの技術的負債は誰かのミスではなく、300記事が何年も異なる手で編集されることで起こる現象だ。
クローラーのレーダーの下にある問題
サイト監査は壊れたページを見つけますが、記事のタイトルが今のランキングに合っているかは判断しません。
誰の担当でもない問題
2022年の記事のメタ欠落は誰の仕事でもないため放置され、記事が落ちて初めて気づかれます。
記事ごとに何がチェックされるか
ライブラリ内のすべての記事を毎回監査 - 四半期ごとのクロールではありません。
メタデータ層：タイトルタグの質とクエリ適合、メタディスクリプションの有無と適合、正しいcanonical URL、不要に非インデックス化するrobots指示。
構造層：H1の有無と独自性、見出し階層（編集を経たH2/H3の論理）、クエリに見合う文字数と読解深度、スキーママークアップの有無。
接続層：内部リンクの入出、孤立記事、廃止・リダイレクトページへのリンク、外部リンクの健全性、記事全体の画像altカバー。
すべての発見は記事ごとの具体的な項目として示され、修正方法も明記。サイト全体のスコアではありません。
これはサイトクローラーではなく、代替にもなりません。
Screaming Frogやサイト監査はページの動作をチェックしますが、これは記事同士の競合をチェックします。.
コンテンツレベルのテクニカルチェック（Draftcamp）
- 記事ごとに文脈を踏まえて評価：このタイトルはこのページのランキングに合っているか？
- パフォーマンス、ICP、ブランドチェックと並行して継続実行されます。
- 発見は直接記事のブリーフに反映され、修正はリライトと一緒に行われます。
- アルファベット順ではなく、記事の機会に基づいて優先順位付け。
- トラフィックを生むコンテンツライブラリに限定。
サイト全体のクローラー
- URLごとに文脈なしで評価：タイトルあり／なし
- 誰かがクロールをスケジュールした時に実行。
- 発見はレポートにまとめられ、修正は別プロジェクトになります。
- エラータイプ別に優先順位付け、テンプレートやシステムページを横断。
- 重要でない4,000URLを含むすべてを対象に。
別チケットは不要
修正は同じブリーフに反映され、
同じドラフトに落とし込まれる。
技術的な指摘は別のバックログに行きません。記事がフラグ付けされると、その技術的修正は記事のブリーフに含まれ、更新されたドラフトは他のすべてと同様にあなたの承認待ちで適用されて出荷されます。
ワークフローは一つ、評価軸は四つ
パフォーマンス、ICP適合、ブランド基準、技術的健全性を一つのレビュー済みリライトでまとめて修正。四つのツールやチケットは不要です。
退出時に再チェック済み
すべてのドラフトはあなたのキューに届く前に技術的SEOレビューを通過し、指摘はテキスト横に提案として表示され、あなたの判断が可能です。
必ずあなたの承認を経て
技術的修正もコンテンツの変更です。名前付きの承認なしに出荷されることはありません—製品の他の部分と同じルールです。
技術チェックの仕組み
率直な答え。