SEO プロダクト管理: 主要なフレームワークと基礎
公開: 2023-03-15優れた SEO プロダクト マネージャーの核となるのは、次の 2 つの資質です。
- 適応性。
- 批判的思考。
この記事では、SEO プロダクト管理の次の分野で批判的かつ創造的に考える方法について説明します。
- SEO プロダクト マネージャーの基礎。
- SEO ロードマップと SEO バックログの優先順位付けの方法論。
- 効果的なSEOチケットの書き方。
SEO プロダクト マネージャーの基礎
これらの基本的なヒントは、SEO プロダクト マネージャー (PM) が将来の戦略を立てながら日々のタスクを遂行するのに役立ちます。
信頼するが確認する
コードで行われた技術的な SEO 作業を検証するときは、すべてが正しく実装されていると想定しないでください。
時間をかけて自分の目で確かめてください。 これが、デモとショーケースがアジャイル プロセスにとって重要な理由です。
修正が公開されたときのドキュメントを保持する
内部機能リリースのクイック リファレンス ドキュメントは、新しいものがいつ実稼働に移行したかをすばやく確認するのに役立ちます。
そこからのステップアップ (忍者レベル) は、ビジネスに対する内部/外部の影響力のある更新を参照するためのタブを作成することです。これらの更新は、業界または取り組んでいるドメインの種類に関連する顧客体験またはアルゴリズムの更新に影響を与える可能性があります。
リリースするすべての機能と改善について、18 ~ 24 か月先のことを考えるように自分自身を訓練します
その時間内に、次のことができるようになります。
- イニシアチブの最初のバージョンを開始します。
- その成功を方向的に測定するために、インプットとフィードバックの収集を開始します。
- 改善の次のフェーズを調査します。
SEO は長期的なプロセスです。 予測された指標を持てると、あなたのハードワークの結果にイライラするかもしれない同僚や上司にこれを説明できます。
最新のマーケティング、テクノロジー、SEO に遅れずについていきますが、視野に入れておく必要があります
いつでも新しいコンセプトを試すことができますが、SEO の基礎を調整することを犠牲にして、それらに過剰に投資したり、ロードマップ全体をピカピカの新しいオブジェクトに専念させたりしないでください。 (あなたを見て、AIとChatGPT。)
組織向けの SEO プレイブックを作成して配布する
SEO PM として、技術的な SEO 要素に関するガイダンスを提供します。 できるだけ早く、以下を含むすべてを文書化した組織の SEO プレイブックを作成してください。
- サイトが置かれている環境の種類。
- 移行の履歴。
- ページネーションまたは URL 構造の設定。
このようにして、開発者やその他の PM が SEO 要素に関連して参照できる信頼できる情報源が得られます。
明確で簡潔な SEO チケットを作成する能力を向上させることをやめないでください。 チケットが明確でない場合、それは混乱を招きます。
混乱したエンジニアは行動を起こしません。 エンジニアリングおよびプロジェクト コーディネーターの見栄えを良くし、物事を成し遂げるチームメイトになりましょう。 (これについては以下で詳しく説明します。)
検索マーケティング担当者が頼りにしている毎日のニュースレターを入手してください。
条件を参照してください。
SEO ロードマップと SEO 作業のバックログに優先順位を付けるための方法論
SEO ロードマップを作成する 1 つのアプローチは、運用フレームワークを参照することです。
ここでは、「SEO の柱」は、ビジネスの重要性と、Web サイトの技術的およびコンテンツの機会の観点から優先されます。 これは、SEO のパフォーマンスに大きな影響を与える投資分野を概念化したものです。
次に、既知のメンテナンス期間または計画されたコード フリーズからさかのぼって、四半期ごとの時間枠に作業を重ねることができます。 (前述のように、18 ~ 24 か月後のプロジェクトの計画に関するもう 1 つの重要なポイントです。)
どのような問題を優先するか
ほとんどの SEO ツールは、次の 3 つの主要なバケットの重大度に基づいて修正と改善を優先するサイト監査を返すと言っても過言ではありません。
- エラー: サイトの適切なクロールとインデックス作成を妨げる重大なブロッカー。
- 警告:リソースが許す場合に認識し、修正を優先する問題。
- 通知: 注意すべき問題ですが、サイトに意味のある影響はありません。
Googlebot が実際にサイトをどのようにクロールしているかは言うまでもなく、ビジネスにとって何が重要かを必ずしも考慮していないため、これは限定的な見方です。
SEOの作業は、カテゴライズされたときに完了し、理解しやすく実行しやすくなります.
これは、100 万のページが 404 エラーを返しているとツールが言っているからではなく、ビジネスに対する結果を示しているのです (すべてまとめて、「信頼するが検証する」ようにします)。
SEO PM にとって、検索の最適化は製品です。 したがって、優先分野には次の改善が含まれます。
- サイトのクロールとインデックス作成。
- 内部リンク。
- サイトのパフォーマンス/速度。
- 最適化されたコンテンツの量。
- ランキングと可視性。
リストの一番上に「ランキング」を入れなかった理由を不思議に思うかもしれません. ランキングはリーダーシップを示す素晴らしい視覚的な結果ですが、オーガニックトラフィックや収益と比較した方向性の指標です.
エンタープライズ レベルでは、SEO のパフォーマンスは 2 つの主要な KPI に要約されるため、トラフィックと収益です。 これらの KPI は、大規模な e コマース サイトの生命線であり、収入を生み出し、新規顧客とリピーターの健全な組み合わせを成長させます。
大規模なサイトでは、SEO の改善を大規模に実行する必要があります。 SEO の重大度のインプットとビジネス イニシアチブのバランスを取るフレームワークは、大規模な優先順位付けを導くために使用される基準の出発点です。
EST(東部基準時。 トラフィックへの影響 / リスク | 既存の URL を改善すると、オーガニック トラフィックが 1 ~ 5% 増加すると推定されます。 あるいは、トラフィックの 5% 以上を失うとはどのようなものでしょうか? |
EST(東部基準時。 収益への影響 / リスク | トラフィック x CRO x AOV という式を使用して売上を見積もります。 投資収益率。 |
EST(東部基準時。 SEOへの影響 | この修正または改善は、SEO パフォーマンス (低、中、高) にどのように影響しますか? |
EST(東部基準時。 投資レベル/サイジング | 必要な開発時間の見積もり (小、中、大) |
さらに、層ごとに時間を分類することで、SEO チームは集合的に検討し、針を動かす層 1 のイニシアチブを決定することができます。
ティア 2 と 3 はバックログの開始点として機能し、トラフィックと収益の影響によってイニシアチブに優先順位を付けます。
優先順位付けの機敏性
階層化された SEO イニシアチブのフレームワークから始めることもできますが、既存のロードマップ項目に対する影響に基づいて、アドホックな作業と修正に常に対応する必要があります。
新しいクロールが生成されるたびに、リグレッションの問題から新しいサイト エラーまで、さまざまなものを拾うことができます。 さらに、新しいコード リリースが公開されるたびに、サイトやコードの他の側面が壊れる可能性があります。
SEO PM は、サイトで見つけた問題を検証するために多くの事前作業を行う必要があります。 重要なのは、エラーの再現を文書化できることです。 エンジニアのために再現できない場合、問題が実際に修正される可能性は低いです。
これは主に SEO の仕組みであるため、SEO ロードマップの優先順位を付けるときは、機能と既知の問題のバランスに対処するための計画を立てることが不可欠です。
これは基本的に、プロアクティブおよびリアクティブな戦略です。 特定の暦年では、トラフィックを獲得してユーザー獲得を促進するイニシアチブと、技術的負債に取り組むイニシアチブを組み合わせる必要があります。
スプリント時間に基づいて機能に優先順位を付ける
一般的に言えば、SEO PM は、暦年の早い段階で機能作業 (つまり、ユーザーまたは内部チームのための機能の構築) を優先したいと考えるでしょう。 これは、特定の四半期までに機能を提供できるかできないかの違いを意味します。
前に、アジャイル スプリントは 1 週間または 2 週間の期間で編成できると述べました。 そして、その時間枠内で多くのことが起こります。
たとえば、特定の四半期で、会社のスプリント ケイデンスが 1 週間 (水曜日から水曜日) である場合、エンジニアリング リソースが 1 ~ 2 の SEO 修正を含む可能性のあるスプリント作業のピックアップに専念する場合、最大 12 週間を見ていることになります (サイズにもよります)。 2 週間に 1 回の場合、約 6 週間の作業に相当します。
専任のエンジニアリング チームがない限り、SEO の作業は、バックエンドまたはフロントエンドの作業を担当する部門横断的なチームに割り当てられる可能性が高くなります。
すべてのチームには、チケットのグループに取り組むためのベロシティ キャパシティがあります。 速度は、スプリント内のすべてのイニシアチブが元の見積もりに対して完了するまでにかかる時間を計算するメトリックです。
これは、9 月に大規模なイニシアチブを持ってテーブルに着くことはできないことを意味し、e コマースの世界では、チームが終了までのコード凍結期間の準備をしている 11 月までにそれが完了すると考えることはできないことを意味するため、これを認識することが重要です。 - 年末年始のショッピング シーズン。
ストーリーの教訓は、最も大きく、最も影響力があり、時間のかかるイニシアチブを最初に優先することです。 そうすれば、彼らはそれらを実装するための戦いのチャンスがあります.
効果的なSEOチケットの書き方
このフレームワークは、次の SEO Jira チケットに何を含めるかのガイドラインとして作成し、問題の内容と取るべきアクションを明確にします。
明確にするために、別のチームメイトにレビューしてもらいます。 これを印刷してオフィスの壁に貼ってください。
チケットの種類を特定し、タイトルに含める | バグ: 要素は以前は機能していましたが、現在は機能していません。 機能強化:改善により、検索エンジンがページをよりよく理解し、インデックス付けおよび/またはランク付けするのに役立ちます。 基本的な修正:この機能を構築/有効化することは、強力な SEO プログラムのコア コンピテンシーです。 |
ユーザー ストーリー: 問題 / 問題の説明 | ユーザー ストーリーは通常、次のように記述されます。 製品の機能について: 「SEO マネージャーとして、X を見たいと思います...」 技術的なバグの場合: 「GoogleBot として、X を見たいです...」 人間のユーザー/顧客の場合: 「ユーザーとして、私は X を見たいと思います...」 問題/問題の説明 問題は、リンク モジュール URL の KPI 測定が行われていないことでした。 KPI データ パイプラインを設定してパフォーマンスを監視すると、 そうすれば、すべてのページでのリンク モジュールの実際のトラフィックと収益への影響を確認できるようになります。 その結果、現在および将来の機能強化 (つまり、関連性) を推定し、それに応じて優先順位を付けることができます。 技術的な SEO 強化をテストしている場合、これは仮説として書くこともできます。 |
サイズと範囲 | 影響を受ける URL の数は? サイト全体? URL は 1 つですか? グループ? 情報を記載したスプレッドシートを添付してください。 |
ビジネスへの影響前提/リスク | ビジネスのリスクまたは損失 (収益、訪問、時間など) を強調する 「X を修正しないと、Y (収益、訪問数) を失うリスクがあります。」 |
デバイス | モバイルウェブ、デスクトップ、タブレット |
ユーザータイプ | 影響を受ける新規訪問者と再訪問者。 |
イラスト | 問題を説明するために、矢印または強調表示された領域のあるスクリーンショットを含めます。 |
SEO の要件または推奨事項 | どの技術的な SEO 要素を修正または対処する必要があるかを概説します (開発チームがその方法を定義できるようにします)。 推奨事項には、大まかなアプローチと LOE を含めることができます。 他のチームとの依存関係を呼び出します。 |
緊急性: SEO の影響または機会の規模 | ページの種類とビジネスに対するその重要性 (オーガニック トラフィックの量)、またはボリューム (サイトで影響を受ける URL の量) の観点から定量化されます。 |
AC / 合格基準 | QAチームがSEOリードを検証および/または提携してテスト基準を作成できるように、非常に明確なACを用意するようにしてください。 チケットのショーケースまたはデモが発生したら、SEO チームによる承認を Jira チケット (メールや Slack ではなく) で行う必要があります。 |
有効な Jira チケットと無効な Jira チケットの例
ウェイターは、ステーキをどのように調理するかについての詳細、特に料理人が理解できることを知っている詳細が含まれていない顧客の注文を料理人に与えることは決してありません.
コードを編集するエンジニアに SEO 要件を提供することも例外ではありません。
以下は、「ゴルディロックスと 3 匹のくま」のおとぎ話に似た SEO チケットの 3 つの例です。 無効なチケットを見つけることができますか?
効果的なチケットとは、開発者が問題をすばやく把握し、すぐに対応できるチケットです。
これには、行動を起こすのに十分な情報がありません:
これには、コンテキストと情報が多すぎます。 何をどうするかは不明です。
さて、これはちょうどいいです。
チケットを明確にする必要があるのはなぜですか?
<暴言>
私が「効果的」という言葉を選んだのは、これらの基本原則に従わないと、混乱を招き、迅速に対応できない、標準以下の一連の指示を別のチーム メンバーに書くリスクがあるためです。 これは、SEO 監査をエンジニアに電子メールで問題のリストとともに送信し、それ以上のコンテキストを提供しないのと同じくらいひどいことです。
SEO の皆さん、チケットを書いているときに思い出させてください。聴衆は開発者であり、その後に QA (品質保証) テスターが続きます。 彼/彼女は自分のワークステーションの前に座って、指定されたスプリント中に作業するために数日、場合によっては数時間かかるチケットを引き上げています。
彼らはチケットを読んで行動できる必要があります。
その時点で、彼らは SEO について教育を受けるつもりはありません。 彼らは SEO の歴史の教訓を望んでおらず、チケットに記載されている URL リストへのリンクを見つけるために 90 ページの SEO 監査を掘り下げることに満足していないことは確かです。
エンジニアリングの時間は貴重で費用がかかります。それを無駄にする責任を負うチーム/人にならないでください。
効果的な SEO チケットにより、エンジニアと QA チームは、問題を明確にし、SEO 要件をリストし、特定の受け入れ基準を提供することで、正確かつ効率的に作業を行うことができます。これにより、作業が QA に合格し、「生産準備完了」のゴーサイン ステータスが得られます。 "
</rant>
SEOプロダクトマネージャーとして批判的に考える
クリティカル シンキング スキルは筋肉のようなものです。 使えば使うほど強くなります。 ジュニアレベルでは難しいかもしれないので、自分自身を適用し続けることが重要です.
自分の仮定や仮説を精査できることは、クリティカル シンキングの非常に貴重な特性です。 「私が使用しているデータは顧客のニーズを真に検証しているか、それとも私の意見を裏付けているか」と自問してください。
客観的にすべてのシナリオを評価し、望ましい結果へのバイアスをできるだけ少なくすることが不可欠です。
アーサー・コナン・ドイル卿はかつて、「健全な懐疑論はすべての正確な情報の基礎である」と言いました。
これは、データ、消費者の行動、および日の目を見る製品機能の間の点を結び付けるために必要な批判的思考スキルを開発するための優れたアプリケーションです.
この記事で表明された意見はゲスト著者のものであり、必ずしも Search Engine Land ではありません。 スタッフの著者はここにリストされています。