SEOプロセス構築に役立つ3つのポイント
この記事の内容はすべて筆者自身の見解であり(ありそうもないことだが、筆者が催眠状態にある場合を除く)、SEOmozの見解を反映しているとは限らない。
SEOに関してWeb担当者が抱えている最大の課題の1つは、正しいSEOプロセスをきちんと構築し、問題があれば深刻化する前に原因を突き止められるようにすることだ。
今回は、サイトの技術的基盤をより強固なものにするためのプロセス合理化を図る際に考慮すべき3つのポイントを紹介したい。
どれも「手っ取り早く」できるものとは思えないだろうし、必ずしも簡単にメリットが得られるわけでもなく、最初は相当な時間がかかるが、長い目でみれば、サイトのSEOをより効率的にモニタリングするのに役立つだろう。それによって、サイトの問題を特定し修復するのにかかる時間が短縮され、リンク構築やコンテンツ戦略など、SEOの他の側面に集中する時間が増える。時間が経つにつれ、その効果がサイトに現れて、大きな見返りが得られるはずだ。
① Googleアナリティクスのアノテーションをうまく使う
今のところ、Googleアナリティクスのアカウントを持つ顧客の多くは、そのアノテーション(注釈)機能をまったく利用していない。利用している場合でも、せいぜい電子メールやリスティング広告、ソーシャルキャンペーンに注釈を付けたり、検索エンジンのアルゴリズム変更(パンダアップデートなど)を追跡したりするのに使う程度だ。
しかし、サイトに技術的な変更を加えた際に、Googleアナリティクスのアノテーション機能で記録しておけば、より効率的な内部プロセスを策定できる。
シナリオ1たとえば、トラフィックの急な増加や減少を通知するように、Googleアナリティクスのアラートを設定しているとしよう。その場合、技術的な変更についてGoogleアナリティクス内で注釈をつけていくようにしておけば、後になってアラートが発せられた際にトラフィックの増加や減少の原因特定に何時間も費やすことなく、より迅速に、しかも簡単に原因をはっきりと把握できる。それに、何か重大な技術的問題が(SEOの観点から見て)不適切に持ち込まれてしまうリスクが生じるのは、単に考慮すべき問題が多すぎるからだ。
Googleアラートの設定方法に関するさらに詳しい情報は、こちらを参照していただきたい。
シナリオ2開発チームにとってSEOが技術的優先事項にならないことは多々あるが、その大きな理由は、往々にして相当な時間と労力を要する割に、その投資利益率(ROI)を測定するのが困難だからだ。だが、Googleアナリティクスのアノテーション機能を利用すれば、このプロセスが楽になる可能性がある。
たとえば、トラフィックの急激な増加が起きたとして、それがサイトに加えた技術的変更のおかげであることを何らかの方法で示すことができれば、開発チームが変化の原因を作ったということが正しく評価されるかもしれない。
② サイトマップ ―― グーグルやBingのウェブマスターツール
SEO担当者は、少なくとも月1回はGoogleウェブマスターツールをチェックし、サイトマップの処理やロボットのクロールに大きな問題がないことを確かめる内部プロセスを作るべきだ。サイトマップが役立つのは唯一、最新の状態に保たれ、きちんと整備されている場合に限られる。
なぜこれが重要なのか? Bingの上級製品マネージャを務めるデュアン・フォレスター氏は以前、こんなことを語っていた。
サイトマップはきれいにしておかなければならない。
サイトマップ内にあっても許されるゴミは、全体の1%までだ。
フォレスター氏が定義する「ゴミ」には、404や500のようなステータスコード・エラーやリダイレクトが含まれている。フォレスター氏はさらに次のようにも続けて語っている。
1%レベルを超えるゴミがあると、われわれはそのサイトマップへの信頼を失い始める。
ベストプラクティスとしては、新しいサイトマップを定期的に作成することが考えられる。そのペースは、サイトに新しいコンテンツが加わる頻度による。ニュース系サイトなら数時間ごと、Eコマースのサイトなら毎週、比較的変更の少ないサイトなら毎月、サイトマップを更新する必要があるだろう。
サイトマップは、最低でも月に1度ウェブマスターツールでチェックし、そこに問題がないことを確認しておくべきだ。
確認する内容には以下のものがある。
- エラーメッセージのチェック
- 公開されたページとインデックス化されたページの数をチェック
- マルウェアのチェック(見つかったら、すぐに対処すること!)
- クロールエラー(4XX系や5XX系の問題)のチェック
Screaming Frogを利用する
SEOスパイダーツール「Screaming Frog」のアカウントを持っているなら、それを使ってGoogleウェブマスターツールのエラーを検証するといい。何しろ、Googleウェブマスターツールは、常に自らのエラーをアップデートして修復するわけではないのだから。誰だって、すでに修正済みの404エラーを探し回りたくないだろう。
Screaming Frogを使えば、サイトマップをチェックしてエラーを見つけることも可能だ。Screaming FrogにXMLサイトマップをアップロードし、クロールさせるだけでいい。Distilledのクレイグ・ブラッドフォード氏は、Screaming Frogを使ってこうしたタスクを実行する方法などをテーマとしたすばらしいブログ記事を書いている。
Googleウェブマスターツールを定期的にチェックしていないと、エラーの数がとんでもないことになる可能性がある。Googleウェブマスターツール内で見つかる圧倒的な数のエラーの修正法については、ジョー・ロビソン氏がSEOmozですばらしい記事を書いてくれている。
ソーシャルもやってます!