エンタープライズ SEO: 「ベスト プラクティス」では解決できない理由と代わりに何をすべきか

公開: 2023-07-03

多くの SEO 専門家は、SEO の取り組みにおいて「ベスト プラクティス」に頼っています。

しかし、JavaScript ベースの企業 Web サイトのサイト速度を最適化する場合、「ベスト プラクティス」以上のものが必要です。

ここでは、標準ソリューションがエンタープライズ サイトに必ずしも適用できるとは限らない理由と、代わりに何ができるかを説明します。

サイト速度の向上: サーバーサイド レンダリングへの移行が常に正しい答えであるとは限りません

CEO (または上級幹部の誰か) のところに行って、「Web サイトをサーバーサイド レンダリング (SSR) に変更する必要があります」とアドバイスするところを想像してみてください。

彼らはあなたに「なぜ?」と尋ねます。 そして、あなたが彼らに与えることができる唯一の答えは、「サイトの速度を向上させることがベストプラクティスだからです」です。 おそらく、文字通り部屋から笑い出されるでしょう。

SSR の移行に関連するビジネスへの影響とコストは、多大な労力と影響が少ないほど価値がありません。

企業 Web サイトがサーバー側でレンダリングされるように最初から構築されている場合、またはすでに Web サイトの移行を行っている場合を除き、SSR に移行する理由はほとんどありません。

それに伴うソフトコストとハードコストのいくつかを考えてみましょう。

  • すべてのシステムと API をレビューして互換性を確認します。おそらくすべてが文書化されているわけではありません (数千ではないにしても、おそらく数百)。
  • Web サイト全体のリファクタリング、QA、アクセシビリティのレビューに何千もの工数がかかります。
  • 新しいフレームワークに関する既存のスタッフ (組織全体で数百人ではないにしても数十人) のトレーニング。
  • 新しいフレームワークに意欲がないか、仕様を満たしていない開発者やエンジニアを雇用または解雇する。
  • サーバー料金に費やすお金が増えます。

このような時間とリソースを大量に消費するプロセスに耐える代わりに、企業 Web サイトの速度を向上させる、より効果的な方法が他にあります。

以前、企業で働いていたとき、私はまさにこのシナリオを上級システム エンジニアの 1 人と遊び半分で話しました。

これには 1 年半、専任のアジャイル部族 (通常約 70 人)、そして少なくとも 200 万ドル (オーストラリアドル) がかかると見積もっていました。 そしてそれはおそらく控えめな見積もりでした。

それでは、前進するために代わりに何をすればよいでしょうか?

他のチームを知り、彼らを助けましょう

エンタープライズレベルでは、SEO はカメレオンである必要があります。優先順位を付けて仕事を完了してくれるのは他のチームに依存しているからです。

ウェブサイトをライブで変更するための王国への鍵を持っていないのには十分な理由があります。 つまり、SEO は単なる SEO ではありません。

SEO とは、「サイトの速度が向上する/アクセシビリティ要件を満たすのに役立つ/など」です。 SEOがすべてです しかしSEO。

Tom Critchlow は、SEO MBA コースと私のポッドキャスト「Engage: On Enterprise SEO」でこれを述べています。

エンタープライズ SEO としての人生を非常によく要約しています。

多くの時間を費やして他の人が何をしているのかを聞き、注意を払い、彼らの行動がウェブサイトの自然な可視性をどのように向上させたかを示す必要があります。

支持者を作成すれば、彼らは Web サイトで何を行っているのか、何が変化しているのかについての安定したレポートを持ってあなたに戻ってきてくれるでしょう。 ここで戦いは半分です。

後半では、開発者、デザイナー、アナリストと協力して作業を完了します。 人はそれぞれ独自の考え、感情、目標を持っているということを理解すると、これは通常、はるかにスムーズになります。

好奇心旺盛で、彼らの生活を楽にする手助けをしたいと思う人であることは、数週間ごとに彼らの生活にやって来て、妥協のない要求を突き付ける陶器店の雄牛と一緒に働くよりもはるかに魅力的です。

開発者やプロデューサーとの連携

最近の多くの企業では、サイトの速度がコンバージョン率を促進する (または妨げる) 要因であることが知られています。

社内の開発チームの多くはサイトのスピードをKPIにしているでしょう。 それを活用してください。

あなたは両方とも同じことを目指しており、開発者の方があなたよりもコードベースをよく知っているでしょう。 そしてうまくやれば、二人ともボーナスを得ることができるかもしれません。

開発者がサポートできる一般的なサイト速度向上の機会としては、次のようなものが挙げられます。

コードのサイズ/重量

チームに技術負債のスプリントや割り当てがある場合、チームが通常この作業を行う時間を把握しておくと、リファクタリングの影響を理解するのに役立ちます。

それを彼らに反映し、彼らの努力を認めてください。

画像の読み込みと累積レイアウト シフト (CLS)

CLS は、JS ベースの大規模なエンタープライズ Web サイトの読み込み時間に大きな影響を与える可能性があります。 これの実装方法に応じて、プレースホルダー JS ライブラリを使用して画像の位置を効果的に「保持」すると、画像のロード時にページが移動しないため、ページの知覚的なロード時間を短縮できます。

リダイレクト管理

当社のリダイレクト管理は大幅に断片化されていたため、これは私には実現できませんでした。

ただし、システムがもう少し集中化されている場合は、リダイレクトを管理し、ホップを削除し、ルールを正規表現に統合し、技術的負債を改善することで、かなり役立つ可能性があります。

一部のサーバー展開では、ページを読み込む前に各リダイレクト ルールを読み取る必要があるため、初期読み込み時間にかなりの時間 (ミリ秒以上) が追加される可能性があります。

<a href> の代わりに <button>

これはもう少し微妙ですが、JS 開発者がデフォルトで ahref リンクをボタンとして含めていることによく気づきました。

これは通常、時間がないことが原因であり、これは作業しているフレームワークのネイティブのデフォルトです。

新しいページ テンプレートの QA を行っていたとき、私はよくこれにフラグを立てて <a href> に更新しました。


マーケティング担当者が頼りにする毎日のニュースレター検索を入手します。

処理中…お待ちください。

規約を参照してください。


デザイナーと協力する

企業 Web サイトでサイト速度を向上させる最大の要因の 1 つは、画像のサイズと重さです。

内部標準は、特にチームが機敏である程度分散化されている場合、時間の経過とともに誤訳されたり失われたりする可能性があります。

私がエンタープライズ側を始​​めたとき、いくつかの主力製品の製品ページに 10MB もの画像があったのを覚えています。 衝撃を受けました。

ウェブ上の画像は 10MB である必要はありません。 フルストップ。

そこで私はデザイナーと慎重に話し合い、約 8 か月かけて画像サイズを縮小することに協力しました。

100 KB は私にとって死ぬほどの丘ではなかったので、見出しバナーやフレームに 100 KB をデザイナーに伝えて、300 KB にしてくれたとしても、それでも改善です。

エンタープライズ SEO は多くの場合、段階的な勝利を目指します。

アナリストとの連携

アナリストが会話に加わってくるのは、おそらくアナリストがタグ付けシステムと Web サイト上のすべてのサードパーティのタグを管理することになるからです。

これらは、この特定のタグが重要かどうか、または代替手段があるかどうかについて、タグの所有者と会話するための入り口となります。

なぜなら、サードパーティのスクリプトによって Web サイトが大幅に肥大化する可能性があるからです。

したがって、サイト上の 250 以上の広告スクリプトについて話し合っているときに、それらがすべて必要な場合は、次のような短期的な妥協点を見つけることができるかもしれません。

  • アクティブにヒートマップまたは追跡されているページで、HotJar、Fullstory、または別のユーザー エクスペリエンス監視スクリプトのみを実行します。
  • 実装の重複を監査します (これは想像以上に頻繁に起こります)。
  • ページの読み込み時ではなく、クリック時にどのチャットボットまたはカスタマー サービス タグを起動できるかを確認します。

QAチームとの連携

このパートナーシップはあなたにとって秘密兵器となる可能性があります。 一般的な SEO だけでなく、JavaScript SEO にも、次のような 2 つのはい/いいえの要件やベスト プラクティスがたくさんあります。

  • メタデータは、ページ ソースとクライアント側でレンダリングされるページ間で同じである必要があります
  • Canonical はクライアント側でレンダリングされたページに存在する必要があります
  • リンクは <button> ではなく <a href=””> の形式にする必要があります。
  • フォントのプリロード
  • 大規模なリソースへの事前接続

QA チームと一緒に優れた書籍を入手し、(トレーニングを含む) 協力して、これらを一般的な日常の QA プロセスの一部として組み込みます。 どこにでも目を向けることができ、マイクロ擁護者の大規模なネットワークができる可能性があります。

Web サイトの SEO 全体を改善するために協力できるチームは他にもたくさんありますが、実装のより技術的な側面に関しては、これらのチームが最も協力することになるでしょう。

一緒に働く他のチームを擁護する

人々が人間であることを思い出したときに、人々と協力することがどのように起こるかについて、私が前に述べたことを覚えていますか? それを行動に移したいのです。

エンタープライズレベルでこれを行うための非常に強力な方法が 2 つあります。

彼らの時間を尊重する

「サーバーサイド レンダリングに移行すべきだ」といった大きなアイデアがあるとします。

この場合、PO に行って「これを全部やってもいいですか?」と言うのではなく、PO と協力して概念実証を作成し、「簡単な」バケツに該当することを検証し、その影響を追跡します。 。

それがうまくいかなかったとしても、この大規模なプロジェクトを完了するために 20 のスプリントを無駄にしたわけではありません。

それがうまくいけば、ビジネスケースを財務チームに持ち込んで資金を提供し、プロジェクトの残りの部分に優先順位を付けてウェブサイト全体に展開し、献身的なチームを獲得する必要があります。完了までに 200 万ドルと 1 年半かかります。 。

彼らの努力を拡大する

SEO が苦手なことで有名なのは、コミュニケーションと成功の共有です。

「ねえ、私がやったこの素晴らしいことを見てください」と言うのではなく、「ねえ、この素晴らしいことを見てください、私が緊密に協力していた他のチームがこの素晴らしいことを成し遂げました、そしてこれがどのように行われたかです」と位置付けると、少し楽になるかもしれません。サイトのエクスペリエンスが大幅に向上しました。」

SEO 担当者であるあなたはもはや注目の的ではありません。 実際に作業を行ったのはチームです。

コラボレーション、擁護、そして漸進的な勝利

この記事では、JavaScript とサイトの速度の微妙な違いについて、実際にはあまり話していないことに気づいたかもしれません。

なぜなら、大企業では、問題や解決策の形について相談できる、本当に賢い人材が一緒に働いているはずだからです。

これらは、SEO 出版物の記事よりも効果的に目的地に到達するのに役立ちます。

企業レベルで物事を成し遂げるには、「何を」というよりも「どのように」が重要です。

したがって、これらのガイドラインを使用して、JavaScript ベースの Web サイトのサイト速度を改善するための「方法」を理解すると、「何を」するかがよりスムーズになります。


この記事で表明された意見はゲスト著者の意見であり、必ずしも Search Engine Land とは限りません。 スタッフの著者はここにリストされています。