SEOにはプロダクト思考を活用する

最近友人とチャットしていたとき、私たちは二人とも、SEO 業界には、固定された規範や基準が欠如しているという致命的な問題があると感じました。非常に完全な公式マニュアルがある Python や PHP などのプログラミング言語とは異なり、本当に理解できない場合は、小さなプログラムを作成して実行するだけで、正確な答えがすぐに得られます。 SEO に関しては、まったく基準がないため、次のような状況がよく発生します。2 人がキーワード密度について議論し、一方が 3 ～ 7% が良いと言い、もう一方が 4 ～ 9% が良いと言い、2 人はほぼ喧嘩になりそうになりますが、最終的にはどちらも相手を納得させることができません (通常はナンセンスです)。

なぜ

大企業では、このような SEO は非常に危険です。なぜなら、大企業では、リーダーを説得したり、製品や研究開発部門の協力を得たり、BI や検索からのサポートを得たりといった、あらゆるリソースを獲得するためには、一定のコストがかかるからです。ようやくすべてのプロセスが完了したら、誰もがトラフィックの増加を期待します。その結果、運が良ければ何らかの効果が見られますが、ほとんどの場合はまったく効果がなく、トラフィックが後退する可能性も高くなります。たとえば、鶏肉が厨房に送られ、みんなはそれがチキンスープや大きな鶏肉の皿にされるのを待っているのに、出てくるのはチキンナゲットの皿か、野菜炒めの皿です。シェフに何が起こっているのか尋ねると、彼は頭を掻きながら何が悪かったのかわからないようでした。
このような制御不能な SEO は危険であり、大企業では徐々にその地位を失っていきます。 （SEO は ROI が高いと言われているにもかかわらず、ほとんどの上司が依然として SEM を好むのもこのためです。多くの SEO は制御できず、投資が成果をもたらすことを保証できません。）したがって、SEO は制御可能でなければなりません。 1 ペニーを投資すれば、必ず同じ結果が得られます。運命に任せて、生計を運に頼ることはできません。

何

では、SEO を制御可能にし、煩わしさを軽減するにはどうすればよいでしょうか?
まず第一に、私たちは科学的な考えに導かれなければなりません。科学的思考には 3 つの側面があります。1. すべての結論には根拠とデータによる裏付けがあるか、検索エンジンや公式文書の基本理論から来ている (ここでの基本理論はキーワード密度などではありません)。2. すべての計画は、予想される効果とリスクを考慮する必要があります (完全に正確である必要はありませんが、少なくとも予測される効果の方向は一貫しています)。3. 最終的な効果を監視し、以前の結論や計画と比較します (失敗は問題ではなく、成功か失敗かが重要です)。

どうやって

第二に、SEO プロジェクトでは Wei Zhe の 3+1 製品思考法を参考にすることができます。 Wei Zhe の 3+1 製品思考法は、私がこれまでに見た中で最も完成度が高く論理的な製品アイデアです。その後、この方法は SEO にも適用できることが分かりました (製品マネージャーはユーザーの視点から Web サイトを改善し、SEO は検索エンジンの視点から Web サイトを改善します。この 2 つには多くの類似点があります)。 SEO 3+1 思考法は次のとおりです。

質問 1: 需要はどこから来るのか、ターゲット顧客は誰なのか?

需要はどこから来るのか、そしてターゲット顧客は誰なのか？これが最も重要な質問だと思います。 SEO は通常、データや理論的な裏付けなしにこれを実行し、完全に独自の感情的な考慮に基づいて Web サイトを調整します。たとえば、URL が気に入らない場合は、新しい URL を作成します。この種の要求には通常、明確な目標がないか、目標が不明確であり、ただ単にそれを実行するためだけに行われます。これらの要件は直接削除する必要があります。
論理的に思えるが、その根底にある理論に問題がある別のタイプの要求もあります。たとえば、キーワード密度が低すぎるためにランキングが高くないと思われる場合は、キーワード密度を上げるようにリクエストできます。しかし、疑問は、ランキングが低いのは本当にキーワード密度が低いことが原因なのか、そしてキーワード密度を上げると本当にランキングが上がるのかということです。 NLP の観点からは、キーワード頻度 TF だけでなく、逆ドキュメント頻度 IDF も考慮する必要がありますが、これはそれほど単純ではありません。次に、検索エンジン ゲームの観点から見ると、キーワード密度は操作が非常に簡単で、SEO によってランキングを制御するために常に使用されてきたため、検索エンジンによって長い間脇に追いやられてきた可能性があります。

第二に、SEO のニーズは検索エンジンまたはユーザーから来るもので、つまり、検索エンジンまたはユーザーの特定の問題を最適化することです。たとえば、サイトマップを生成して送信し、検索エンジンのクローラーのクロール効率を向上させたり、メインコンテンツを最初の画面に配置してユーザーエクスペリエンスを向上させたりします。特定の需要が検索エンジンやユーザーにとってメリットがなく、SEO の観点からのみ考慮される場合、前述のキーワード密度のように、通常は効果がありません。

質問 2: それを行わなかった場合、どのような結果になりますか?このニーズは緊急ですか?

前の質問では、要求が必要かどうかを調べ、この質問では、要求の重要性と緊急性を調べます。この質問は、この需要を緊急に処理する必要があるか、または後で処理するためにキューに入れる必要があるかを判定するために使用できます。

質問3: 彼らの痛みは何ですか?シナリオは何ですか（最適化前/後）

この質問は、需要が前の問題を解決できるかどうかを調べるためのものです。元々の問題は何でしたか? 要件を実装した後、その問題は解決できますか?

+1: 解決策が解決された後、Web サイトのデータはどうなるのでしょうか?

この質問は需要の影響を調べるためのものです。最終的な結果が成功するかどうかに関わらず、結果を検証する必要があります。期待通りの効果が得られれば素晴らしいことです。期待とは程遠い場合や効果がない場合は、自分自身を分析して問題の核心を見つけ出す必要があります。これは「清らかな心で死ぬ」ことであり、将来の教訓とすることです。

例

以前、パフォーマンス最適化の依頼をしたことがあります。効果は明ら​​かではなく、厳密にはSEOとは直接関係ありませんが、プロダクト思考で考えることはできます。一般的な状況は次のとおりです。

背景

同僚が検索カンファレンスに参加したところ、専門家がウェブサイトの速度が SEO に与える影響について言及していました。戻ってきてツールを実行したところ、自分のウェブサイトが競合他社のウェブサイトよりも遅いことがわかったので、私に分析を依頼しました。私は主に PageSpeed、Yslow、WebPagetest を使用して Web ページのいくつかの重要なページをテストし (これらのツールは Google のウェブマスター向けガイドラインで推奨されています)、12 個の最適化項目をリストした予備計画を立てました。ただし、これらの項目は Web サイトのアーキテクチャに関係しており、私自身が専門家ではないため、R&D の同僚に対する最適化の提案としてしか考えられません。

質問 1: 需要はどこから来るのか、ターゲット顧客は誰なのか?

表面的には、同僚に分析を依頼しただけでしたが、結局はウェブサイト自体の問題でした。
速度の最適化の恩恵を受けるのは、一般的に検索エンジンとユーザーです。ウェブサイトの速度が上がると、検索エンジンのクローラーのクロール効率が向上し、ユーザーエクスペリエンスも必然的に向上するからです。しかし、フロントエンドや開発の同僚と話し合った結果、実装の難しさを考慮して、最初のフェーズでは静的ファイルのキャッシュの最適化と CSS と JS のマージに重点を置くことにしました。そのため、検索エンジンのクローラーとは関係ありません (検索エンジンのクローラーは、検索エンジンにリクエストを送信し、返された結果を保存するだけです。返された Web ページ コード内の JS や CSS などの静的ファイルについては、読み込まれて保存されます。これは、Google 管理者ツールの Google クロール方法を参照してテストできます)。

質問 2: それを行わなかった場合、どのような結果になりますか?このニーズは緊急ですか?

速度の最適化が行われていない場合、Web ページを開く速度に影響します。この要件は比較的重要ですが、緊急ではありません。この要件は、エラー修正ではなく最適化と見なされます。 (私は SEO のニーズを、その目的に応じてエラー修正と最適化の 2 つのカテゴリに分類しています。エラー修正は、複数の列に個別のタイトルが付いていないなど、Web サイト自体の基本的な SEO 最適化であり、最適化は、この速度最適化などのボーナス項目です。)

質問3: 彼らの痛みは何ですか?シナリオは何ですか（最適化前/後）

最適化の要件なので、それほど苦痛ではありません。最適化される前は、ユーザーは Web ページを開くたびに静的ファイルを再ダウンロードする必要があり、JS と CSS を 1 つずつダウンロードする必要があり、JS は依然として 1 行でダウンロードされていました。最適化後、古いユーザーが Web ページを開くと、一部の静的ファイルは再ダウンロードせずにキャッシュから直接取得されます。さらに、統合後の JS ファイルと CSS ファイルの数の削減により、HTTP リクエストの数が大幅に削減されます。このようにして、ユーザーが Web ページを開くときの速度は 100 ミリ秒以上高速になります。
また、フロントエンドではリストページでも遅延読み込みが実行されるため、Web ページは 32 枚の写真がすべて読み込まれるまで待機せずに表示されます。代わりに、最初に最初の画面が表示され、マウスが下にスクロールすると、それ以下の写真が読み込まれて表示されます。

+1: 解決策が解決された後、Web サイトのデータはどうなるのでしょうか?

ページが最適化された後のデータは次のとおりです。
ある列では主に画像の遅延読み込み、背景画像のマージ、CSS のマージなどを行います。
JS ファイルの数は 3 個増加し (業務上必要)、サイズは 30KB 減少しました。CSS ファイルの数は 3 個減少し、50% 減少しました。CSS 背景画像の数は 11 個減少し、61.1% 減少しました。ファースト スクリーン画像の数は 27 個減少し、56.25% 減少し、ファースト スクリーン画像のサイズは約 200KB 減少しました。
リクエスト総数は 38 件減少し、減少率は 41.3% でした。サイズは 277 KB 減少し、減少率は 30.1% でした。以下は最適化前と最適化後のウォーターフォール チャートです。

注: この結果はフロントエンドの同僚によって提供され、最適化後の直接データです。GA の Web ページの開く速度、ユーザーの滞在時間、直帰率などの後続データが存在する可能性があります。これらの後続データはまだ記録されていません。

プラス

1. この記事をずっと前に書きたかったのですが、あまりにも理論的すぎて意味不明に聞こえるだろうと感じていたので、先延ばしにしていました。最近まで衝動的な要求に耐えられなかったので、書き留めておきました。遠慮なく批判してください。
2. 記事で言及されている要件は、私が入社したばかりの頃に作られたものです。朝、バスを待っている間にパフォーマンス最適化に関する動物の本を読んでいたのを覚えています。今では、私は年老いたキツネのようで、進歩する意欲がありません。私はこれが本当に好きではありません。
3. キャプション.漫画のセリフ:「簡単に言えば、これを行うと、Web サイトのランキングが向上します。」 SearchEngineJournal.com からのコミック。

元のタイトル: 製品思考を使用して SEO を行う

キーワード: seo