何が起きたか:「順位を守りながら更新する」14ステップの公開
記事が提示しているのは、劣化したSEOコンテンツを診断し、既存の順位を保持したまま(preserving existing rankings)更新するための14ステップのワークフローです。そして記事は、その手作業のプロセスをClaude Codeを使って自動化し、大規模なページ群(a large portfolio)へ横展開した方法を解説しています。
リライトの現場で最も怖いのは、良かれと思って全面的に書き直した結果、それまで取れていた流入まで失うことです。この記事の骨子は、その事故を構造で防ぐところにあります。すなわち、更新前にベースライン(基準値)を固定し、ページ内のセクションを「残す」「直す」「消す」「足す」に仕分け、残すと決めた部分には手を触れない。書く前に何を守るかを決めてしまう、という順序です。
なお、以下で紹介する数値やスキル名はすべてSearch Engine Landの記事が報告している内容です。Scale Basics編集部が第三者として検証したものではなく、同じ手順を踏めば同じ結果が出ることを保証するものではない点は先に申し添えておきます。
詳細①:ステップ1〜7――ベースラインを固定し、セクションを4分類する
前半のステップは、書き始める前の診断と下ごしらえに充てられています。
ステップ1〜2は診断とタグ付けです。まずGoogle Search Console(GSC)の56日間のウィンドウを使ってベースラインを固定(a locked baseline)します。そのうえで、パフォーマンスデータに基づいて、ページ内の各セクションを「Keep(残す)」「Fix(直す)」「Remove(消す)」「Add(足す)」のいずれかにタグ付けしていく、という流れです。
ここは編集部の解釈ですが、56日という区切りは7の倍数、つまり8週間ちょうどです。曜日ごとの需要の波を均せる長さで、かつ季節要因を抱え込みすぎない範囲に収まります。加えて「locked(固定した)」という表現が使われている点も重要で、更新のたびに集計期間を変えてしまうと前後比較そのものが成立しなくなります。
ステップ3〜7は、更新方針を決めるためのリサーチです。競合分析、キーワードリサーチ、ペルソナの構築が更新戦略の材料になり、そこにローカル知識(local knowledge)の更新が加わります。そして実際に書き始める前に、そのページ固有の切り口(a specific page angle)を定義する、と記事は説明しています。順番として「切り口を決めてから書く」がステップに明示されていることが、このワークフローの性格をよく表しています。
詳細②:ステップ8〜14――差分だけを書き、URLとメタタイトルとスキーマは守る
後半は執筆と保護、そして計測です。
ステップ8〜12では、必要な変更点だけを指定するデルタブリーフ(delta brief／差分ブリーフ)を作ります。新しいセクションはこのブリーフに沿って書き起こす一方で、「Keep」と判定したセクションには手を触れないまま残します。さらに記事は、URL、成績の良いメタタイトル(high-performing meta titles)、そして構造化データ(schema)を保護する、と明記しています。
この「保護対象の明示」は、実務では見落とされがちな部分です。リライトのついでにURLを整理したり、タイトルを今風に書き換えたり、テンプレート更新でスキーマの出力が変わったりすることは珍しくありません。更新の効果測定をしたいのに、同時に複数の変数を動かしてしまうと、順位が動いた原因が本文なのかタイトルなのか分からなくなります。
ステップ13〜14はコンポーネントと計測です。UIコンポーネントはClaudeを使って生成し、すべての更新はSEOTestingを通してベースラインに対する影響を測定します。その際に使う指標は、GSCの指標と、GA4の購入(purchases)などのイベントの両方だとされています。検索の指標だけで終わらせず、売上に近いイベントまで見て初めて1件の更新が完了する、という設計です。
Claude Codeへの落とし込み:8つのスキルとStrapi CMS連携
記事の後半は、この手作業のプロセスを相互に連携するスキル(interconnected skills)へ写した部分の説明に充てられています。記事が挙げているスキルは次のとおりです。
| スキル名 | 担当する役割（記事の説明） |
|---|---|
| hoppa-intelligence | 56日間のベースラインを取得する |
| Audit Skill | セクションを自動でタグ付けする |
| Competitor-Gap Skill | 競合との差分から機会を特定する |
| Editorial Intelligence | ペルソナとローカル知識を検証する |
| hoppa-editorial | 既存のトーンに合わせて差分コンテンツを書く |
| hoppa-scientific-refiner | すべての主張をファクトチェックする |
| Image-Auditor | ビジュアルを検証する |
| Component Generator | 新しいUI要素を生成する |
加えて、Strapi CMSとの連携によって、検証チェック付きの自動デプロイが可能になっているとしています。診断から執筆、ファクトチェック、画像の点検、公開までが一本の流れとしてつながっている構成です。
ここから先は編集部の補足です。スキル名を見ると、「hoppa」という接頭辞が付いたものと、AuditやComponent Generatorのように汎用的な名前のものが混在しています。自社固有の文脈を持つ処理と、どのサイトでも共通の処理を意図的に分けているとうかがえる構成で、この切り分け方はAIツールを使わない運用マニュアルの設計にもそのまま応用できます。
報告された成果と、記事が強調する原則
記事は、個別ページのテスト結果とポートフォリオ全体の集計値を報告しています。
| 対象 | 報告されている数値 |
|---|---|
| Antalya空港(Antalya Airport)のページ | クリック数が23.88%増加 |
| 同ページ | 平均掲載順位が14.89位から10.87位へ改善 |
| 同ページ | CTRが1.49%から1.79%へ上昇 |
| 完了した59件のテスト | 70%のページでオーガニッククリックが増加 |
| 同(全テスト合計) | オーガニッククリックが2,284増加 |
| 同 | オーガニックの購入が24.9%増加 |
| 同 | オーガニック売上が20.1%増加 |
裏を返せば、70%が増加したということは、残りの3割は増えなかったということでもあります。全打席ヒットではない前提で、増えた分と増えなかった分を合算して評価する運用になっていると読めます。
そのうえで記事は、システムの位置づけについて明確な原則を置いています。このシステムは人間の判断を置き換えるのではなく、人間の判断を強制する(enforces human judgment rather than replacing it)ものであり、検証済みのペルソナとローカル知識が揃っていなければ次に進めないハードゲートが設けられている、としています。
もうひとつ実務者として見逃せないのが処理方式の指摘です。品質を保つために更新は1件ずつ逐次で実行し、並列処理は出力の質を落とす(parallel processing degrades output)と明言しています。そして人間の監督は依然として不可欠であり、優先順位付け、最終承認、ベースラインの計測は人間が決めることだと述べています。
実務への影響:ツールが無くても持ち帰れる考え方
ここからは、記事の内容を踏まえたScale Basics編集部の整理です。Claude CodeやStrapi、SEOTestingを導入していなくても、この14ステップの骨格は既存のリライト運用にそのまま移植できます。
核になるのは、記事を「1本」ではなく「セクションの集合」として扱う視点です。多くの現場では、リライトの単位が記事単位になっています。順位が落ちた記事を丸ごと書き直し、丸ごと差し替える。しかし記事が示す方法では、判断の単位は見出し単位のセクションで、それぞれにKeep・Fix・Remove・Addのラベルが付きます。Keepが付いた箇所は、たとえ文章が古く感じられても触りません。そこが評価されている可能性があるからです。
次に効くのが、保護対象を先に宣言しておくことです。URL、成績の良いメタタイトル、構造化データ。この3つを「今回の更新では動かさない」と決めてから作業に入れば、更新後に順位が変動したときの原因究明が一段楽になります。逆に、本文もタイトルもURLも同時に変えてしまうと、良くなっても悪くなっても学びが残りません。
そして計測です。リライトの効果を「順位が上がったかどうか」だけで判断してしまう現場は少なくありませんが、平均掲載順位が改善してもクリックが伸びないケース、逆にクリックが増えても購入につながらないケースは普通に起こります。記事がGSCの指標とGA4の購入イベントの両方でベースラインと比較しているのは、この取りこぼしを防ぐためだと読めます。なお、順位計測ツールが表示する順位とGSCの平均掲載順位は別物で、数字が一致しないのが通常です。ベースラインを固定するなら、どちらか一方に統一しておくことをおすすめします。
今日からできる確認手順
この章もScale Basics編集部による実務上の補足です。ツールの導入を待たずに着手できる順に並べています。
- GSCで、直近56日間とその前の56日間を比較できるように期間を決める。以降のリライト評価では、この期間の取り方を固定して変えない。
- クリックが減少している既存ページを抽出し、更新候補リストを作る。この時点では順位ではなくクリックの減少幅で並べる。
- 候補ページを1本選び、見出し単位でセクションを書き出す。各セクションにKeep・Fix・Remove・Addのいずれかを付ける。迷ったらKeepにしておく。
- そのページの「今回は動かさないもの」を明文化する。最低限、URL、メタタイトル、構造化データの3点を決めておく。
- FixとAddの箇所だけを対象にした差分の指示書を作る。全文リライトの指示書は作らない。
- 公開日を記録し、GSCの指標とGA4のコンバージョンイベントの両方で、公開前後を同じ長さの期間で比較する。
- 1本の結果が出るまで、同じテンプレートで大量に横展開しない。効果のあった判断基準だけを次の1本へ引き継ぐ。
最後の項目は、記事が「並列処理は出力の質を落とす」「1件ずつ逐次で実行する」と述べている点に対応します。AIを使う場合でも使わない場合でも、検証されていない手順を一括で流すと、失敗も一括で広がります。
所感
ここからは記事本文にはない、Scale Basics編集部の見解です。この記事で本当に価値があるのは、Claude Codeでスキルを組んだ部分ではなく、そもそも人間が何を判断していたのかを14ステップに言語化した部分だと考えます。自動化できたのは、判断基準が言葉になっていたからです。順序が逆ではありません。
リライトが空回りしやすい理由も、だいたいここに集約されます。「なんとなく古いから」という感覚で全面改稿に踏み切り、何が効いたのか分からないまま次の記事へ移る。ベースラインが固定されておらず、保護対象も決まっていない状態では、何本書き直しても学習が積み上がりません。記事が置いているハードゲート、つまり検証済みのペルソナとローカル知識が揃うまで先に進ませないという発想は、AIの制御手法であると同時に、人間のチーム運用のルールとしても有効です。
もうひとつ強調しておきたいのは、記事が「優先順位付け、最終承認、ベースライン計測は人間が決める」と明言している点です。生成AIをコンテンツ運用に組み込む議論は「どこまで書かせるか」に寄りがちですが、実際に品質を左右するのは、どのページを触るかを選ぶ判断と、公開してよいと決める判断です。ここを機械に渡した瞬間に、量は増えても成果は増えない構造になります。まずはKeep・Fix・Remove・Addの仕分けを人の手で1本やってみる。そこで自分たちの判断基準が言葉にできたなら、そのときが自動化の入口です。
まとめ
・Search Engine Landが2026年7月29日付でAlex Galinos氏の記事を公開し、劣化したSEOコンテンツを既存の順位を守りながら更新する14ステップのワークフローと、それをClaude Codeで大規模化した方法を解説した
・ステップ1〜2ではGSCの56日間のウィンドウでベースラインを固定し、パフォーマンスデータに基づいて各セクションをKeep・Fix・Remove・Addにタグ付けする
・ステップ8〜12では必要な変更だけを指定するデルタブリーフを作り、Keepのセクションには手を触れず、URL・成績の良いメタタイトル・構造化データを保護する。ステップ13〜14ではSEOTestingを通し、GSCの指標とGA4の購入などのイベントでベースラインと比較する
・hoppa-intelligence、Audit Skill、Competitor-Gap Skill、Editorial Intelligence、hoppa-editorial、hoppa-scientific-refiner、Image-Auditor、Component Generatorの各スキルとStrapi CMS連携で、診断から検証チェック付きの自動デプロイまでをつないだとしている
・報告値はAntalya空港のページでクリック23.88%増・平均掲載順位14.89位から10.87位・CTR1.49%から1.79%、59件のテスト全体で70%のページがクリック増、累計2,284クリック増、オーガニック購入24.9%増、オーガニック売上20.1%増
・記事はシステムが人間の判断を置き換えないことを原則とし、更新は1件ずつ逐次で実行し(並列処理は品質を落とすため)、優先順位付け・最終承認・ベースライン計測は人間の判断だとしている
よくある質問
Q1: この14ステップのワークフローは何を目的にしているのですか?
Search Engine Landの記事によれば、成果が落ちてきた既存のSEOコンテンツを診断し、いま持っている順位を保持したまま更新することが目的です。そのために、Google Search Consoleの56日間のウィンドウでベースラインを固定したうえで、ページ内の各セクションをKeep(残す)、Fix(直す)、Remove(消す)、Add(足す)に仕分け、必要な変更だけを記したデルタブリーフに沿って更新します。Keepと判定したセクションは書き換えず、URL、成績の良いメタタイトル、構造化データも保護対象とされています。記事は、この手作業のプロセスをClaude Codeで自動化し、大規模なページ群へ展開したと説明しています。
Q2: 記事ではどのような成果が報告されているのですか?
個別のテストとして、Antalya空港のページでクリック数が23.88%増加し、平均掲載順位が14.89位から10.87位へ改善、CTRが1.49%から1.79%へ上昇したと報告されています。ポートフォリオ全体では、完了した59件のテストのうち70%のページでオーガニッククリックが増加し、全テスト合計でオーガニッククリックが2,284増加、オーガニックの購入が24.9%増、オーガニック売上が20.1%増だったとされています。いずれも記事が自社の取り組みとして報告している数値であり、Scale Basics編集部が独立に検証したものではありません。同じ手順で同じ結果が出ることを保証するものではない点にご注意ください。
Q3: Claude Codeを導入していなくても、この方法は使えますか?
記事はツール未導入の読者向けの手順を示していないため、以下はScale Basics編集部による一般的な実務上の補足です。14ステップの骨格自体はツールに依存しないため、既存のリライト運用へ移植できます。具体的には、更新前に集計期間を固定してベースラインを取り、記事単位ではなく見出し単位でKeep・Fix・Remove・Addを判定し、URL・メタタイトル・構造化データを今回は動かさないものとして明文化してから、FixとAddの箇所だけの差分指示書を作る、という流れです。効果測定は検索側の指標とサイト内のコンバージョンイベントの両方を同じ期間で比較します。記事自身も、優先順位付け、最終承認、ベースライン計測は人間の判断だと述べており、自動化はあくまで判断基準を言語化できた後の工程だと位置づけられています。
出典:How to scale SEO content updates with Claude Code(Search Engine Land、Alex Galinos氏、2026年7月29日)https://searchengineland.com/scale-seo-content-updates-claude-code-483862
