成功したSEO移行の管理

成功したSEO移行の管理

【Google翻訳】
SEOの専門家として、私たちは移民と彼らがもたらす可能性のあるさまざまなレベルのボラティリティを知らないわけではありません。

移行は、テクノロジーとビジネスの両方の目標が進むにつれて、デジタルビジネスのライフサイクルで自然に発生するイベントです。

移行にはさまざまな形式がありますが、一般的なものには次のものがあります。

●URLの再構築。
●プロトコルの変更（HTTPからHTTPS）。
●ホスティングプロバイダーの変更。
●新しいプラットフォームへの移行。
●ドメイン名の変更。
●複数のドメインプロパティを結合します。
リスクと変数のレベルは、さまざまな移行タイプと、クライアントの技術スタックの変数とニュアンスの間で劇的に変化します。つまり、「既製」の範囲を提供することはほとんど不可能です。

業界では、移行がうまくいかないこと、つまり、SEO以外の世界に影響が出始めたときに耳にします。

一部のトラフィックといくつかのランキングを失うことはニュースではありませんが、店舗を閉鎖し、スタッフをレイオフする企業はニュースです。

この例には、Homebase HTTPS移行（ここでは近江シドが詳しく説明します）、および最近のLogojoy to Lookaのブランド変更が含まれます。これは、サードパーティツールの目で見ると、ランキングキーワードが25,000（150k 125kまで）。

SEO移行の範囲

私にとって、移行のスコープを正しくすることは、移行プロセス全体を成功させるために不可欠であり、次のような状況を回避します。

スコーピングと仕様の重要な部分は、開発者と幅広い利害関係者の両方にとって実行可能である必要があることです。

「なぜ」を減らす
そして、「方法」にもっと焦点を合わせます。
あいまいさはリスクを生み出します。 誤解の余地が少ないほど良い。

スコーピングドキュメント内では、以下を確立することが不可欠です。

移行が行われる理由（クライアントから）。
一次および二次利害関係者。
各関係者の活動と責任の範囲（トラフィックとランキングの維持は責任ではなく、目的です）。
アクティビティのスケジュール、および移行後のリソース。
（すべての関係者による）移行の目的に同意しました。
レポートの頻度と深さ。
これから、可能な限りリスクを減らすために、アクティビティのスケジュールを作成し始めることができます。

リスク軽減

ほとんどの場合、移行中のリスク軽減は、多くの一般的な移行アクティビティの目的を実行しています。

ただし、各アクティビティは、リスクの要素を減らし、合意された目標の達成に向けて取り組むように設計されています。

リダイレクト
リダイレクトがほとんどすべての移行の一部であることは当然です。

ただし、移行後のトラフィックドロップの監査を何度も実行したため、リダイレクトの範囲を定めて実装するときによくあるエラーがいくつかあります。

JS、CSS、パラメーター、メディアファイルがリダイレクトされない

多くの場合、移行が実行されると、人々はURLのリダイレクトに集中しますが、それらはランクですが、必要に応じてJSファイル、CSS、パラメータURL、およびメディアファイル（画像、ビデオ）のリダイレクトも検討する必要があります。

多くの人が画像のリダイレクトの価値に疑問を持っていますが、URLはURLであり、Googleはそれをクロールします。 Googleは、画像URLをリダイレクトすることを推奨しています。

環境の変化

新しいプラットフォームに移行するとき、テンプレートを再設計するとき、またはサイト構造を更新するときは、新しい「環境」が少なくとも以前のSEOの品質を反映するようにすることが重要です。

多くの場合、新しいプラットフォームが公開され、JavaScript拡張可能領域の背後に多くのコンテンツが隠され、NoScriptまたはJSが無効になっている場合、隠されているか、他の重要な要素が欠落しているため、新しい環境を監査して確認することが重要です：

メタデータは正しく引き継がれています。
構造化データが実装され、検証されています。
Canonicalsは正しいです。
ページネーションのマークアップは正しいです（Bingも存在します！）。
内部リンクが引き継がれ、200のURLがポイントされます。
XMLおよびHTMLサイトマップが存在します。
Hreflangが正しく設定されている（国際的なWebサイトの場合）。
リダイレクトがテストされています。
404ページは404応答コードを返します。
ステージング環境や運用前環境がミラースタック上にない場合（同じパフォーマンスをエミュレートできる場合）、サイトの速度などの一部のサイトではライブサイトテストが必要になりますが、多くの場合、パフォーマンス指向のサーバーではありません。

移行がうまくいかない理由を理解する

多くの場合、移行がうまくいかない場合、次の7つの理由の少なくとも1つにピンポイントで特定できます。

●誤ったSEO戦略/不明な目的。
●リソースとタイムラインの不十分な計画と範囲。
●コンテンツまたはコードに影響を与える予期しないUX /設計変更。
●SEO機関の関与が遅すぎる/重要な決定が既に確定している後。
●不十分なテストまたは十分なテストの欠如。
●移行後のバグ修正に対する応答が遅く、開発の優先度が低い。
●制御できない変数（例：Google更新）。

貧弱な戦略
「成功」の測定可能なベンチマークを設定するためには、移行が行われている理由と望ましい結果を理解することが重要です。

ほとんどの移行の目的は、SEOのパフォーマンスを向上させ、その安定性を成長の基盤として使用することです。

ただし、各移行タイプには独自のリスクがあります。これらは、クライアントや幅広いステークホルダーに伝達される必要があります。

ホスティングまたはプラットフォームを移動しているがURL構造を維持している場合はシームレスでなければなりませんが、ブランド名を変更してドメイン名を変更する場合は、ある程度の混乱が予想されます。

不十分な計画とスコーピング
早い段階で詳細な範囲とプロジェクト計画を考案することで、SEOプロセスとタスクにかかる時間の予想を設定することで、途中での遅延を回避できます。

これにより、プロジェクトの範囲内にあるものとそうでないものを考慮することができるため、リソースを適切にスケジュールして割り当てることができます。

計画を立てることで、祝日やピーク販売期間などの潜在的な障害を特定することもできます。

たとえば、オンラインショップの場合、サンクスギビングまではウェブサイトを立ち上げることはできません。大きなバグがブラックフライデー/サイバーウィーク/クリスマスの期間を脅かす可能性があるためです。

後期関与
SEOの移行は一晩では発生しません。

しかし、SEOのサポートは、オーガニック検索のパフォーマンスに影響を与える多くの重要な決定が事前に行われているため、ロードマップでは遅すぎることがしばしば求められます。

タイムラインに変更を加える余地がある限り、後の関与が救いの恵みになることもありますが、それはめったにないことであり、あなたは死後を監視し準備することしかできません。

これは、十分なテストが行​​われていないことも意味します（SEOの観点から）

遅い開発応答時間
これは多くの場合、ビジネス自体の問題ではなく、SEOの専門家が管理できるものでもありません。

私は、移行開発リソースがビジネスの別の部分に完全に再配分された直後に、緊急またはアドホックなバグ修正のための時間を残さない状況にありました。

たいていの場合、これは開発者のせいではなく、意思決定の利害関係者による不十分な計画の徴候です。

以前に、サイト全体でnoindex（間違ったバケットがデプロイされていたため）でウェブサイトが公開されたことを確認しました。これは、すぐにフラグを立てたものです。リソースの削除に4日かかります。

制御不能な変数
最適な計画とリソースの割り当てにもかかわらず、Googleの更新やCDN / DNSの停止など、予期せず完全に避けられない何かに左右されることがあります。

SEOコンサルタントのまとめ

Search Engine Journalの記事です。