タグ: SEO

今のSEOには、E-A-Tが重要と言われています。

今まで上位にきていたアフィリエイトブログがどんどんぶっ飛んでいる理由がここにありそうで、いったいE-A-Tとはなんなのか、どうしたら対策できるのかということを考えてみたいと思います。

今までのSEOの知識だけでは上位表示させるのは難しいかもしれません。

E-A-Tってなに？

E-A-Tとは、Googleの造語で、「専門性（Expertise）」「権威性（Authoritativeness）」「信頼性（Trastworthiness）」の略です。

専門性、権威性、信頼性のあるコンテンツ作りが重要ということです。

なぜE-A-Tが重要なのか

まぁ当たり前のことなんですが、「その分野において、検索したユーザーがしっかり信用できる内容」を書いている記事が上位に出るよってことですよね。

そりゃそうよ。

どこの馬の骨が書いたかわからないような適当な知識、トンデモ医療だったりを全世界の人間が信じると、Googleとしてもまずいわけですよ。

だから、適当な知識で、誰が書いたかわからないような記事は軒並み順位が下がっていますよね。

特に、医療関係なんかは顕著で、ちゃんとした医者や病院が書いている記事が上位に来るようになりました。

これは他の分野でももちろん当てはまることで、どっかのブログから適当に得た知識で量産していたアフィリエイトブログなんかは、吹っ飛んで当然なんですよね。
適当ばっか書くなよってことです。

というわけで、逆に、信用に値する記事は上位に上がるんですね。

Googleの検索担当副社長のベン・ゴメス氏も、「ランキングシステムは、高いE-A-Tの兆候を持ったサイトを特定するように設計されている」と実際に言っていることから、E-A-Tはランキングに深く関わっていることは明白。

どうすればE-A-Tを改善できるか

これについては、いろんな人のいろんな意見があると思いますが、僕はこちらのTipsの内容は信頼できると思いますので、支持します。

僕はSEOについては、Googleの人が言ってるなら信じます(笑)

E-A-Tに関して書いてある記事、いろいろ読んできましたが、「いやそうはならんやろ」って記事がいっぱいありました、ぶっちゃけ。それこそE-A-Tを重視しろよ。

というわけで、信頼できるこの記事によると、すぐできる改善策は大まかに２つ。

著者情報を表示する

なんか最近、どうもみんな記事に著者情報を入れたがると思ってたんですが、E-A-Tに関係することだったのかもしれないですね。

その記事を書いた人がどんな人なのか、どんな専門家なのかがわかるようにすると効果があるかもしれないとのことです。

僕はずっと、サイドメニューに自己紹介を書いて、プロフィールページにも誘導してたんですが、ちょっと実験的に表示方法を変えてみることにしました。

これで順位上がったらすごいですよね。
まぁ、サイドメニューにも元々あったので、効果が上がるかはわからないんですが、今回追加してみようと思うのは構造化マークアップです。

構造化マークアップについて

構造化マークアップとは、Google botがよりコンテンツの内容を理解できるよう記述する記法のことで、構造化マークアップを行うことで、検索時のリッチスニペットに表示されたりするんですが、僕が思うに、これからはこの構造化マークアップが超重要になってくると思うんですよ。

検索/ランキングシステムには人工知能が深く関わってますが、人工知能を発達させるには、とにかくデータが必要。
で、そのデータをどうやってとるかというと、構造化マークアップデータから引っ張ってくるんじゃないかと思うんです。

どうやって構造化マークアップするのか

まぁちょっと、自力でやろうと思うと初心者には厳しいですよね。

でもWordPressなら、テーマやプラグインのパワーで大概なんとかなります！

というわけで、今回は著者情報を表示・マークアップできるプラグイン「Simple Author Box」を使ってみようと思います。

Simple Author Box

このプラグインを有効にすると、プロフィール編集が拡張され、SNSのアイコンを登録したりできるようになります。

あと、早速この記事の一番下にもあると思うんですが、全ての記事下に著者情報が記載されるようになります。
ついでにプロフィールページへのリンクもつけてます。

もちろん、構造化マークアップ対策もばっちり。

自分のブログが構造化マークアップに対応しているかどうかは、「構造化データ　テストツール」でチェックすることができます！

僕の場合はこんな感じです。

これで、ひとまず「著者情報を表示」は簡単にできますね！

その分野に権威がある人からのリンクを得る

これについては、「その分野の権威者と仲良くなる」「頼み込んでリンクしてもらう」という手が使える人はいいかもしれませんが、そんなコミュ力ねぇよって人は、長い目で見るしかないんじゃないかと…

ただ、ひたすらに役に立つ記事を書いていれば、自然とリンクは集まります。

例えば僕のブログも、他の人のブログ記事やどっかの社内GithubのWikiから参考リンクとして貼られていたりしますからね。そういった記事は、確かにアクセスが増えたように思えます。

参考記事にもありますが、役に立つ情報やツールを提供しようねってことですね。

おわり

Googleの技術もどんどん発達していて、そのたびに「サイト吹っ飛んだ～」って言ってる人を見かけますが、そりゃ適当なこと書いてたらいつか飛ぶだろと。

Googleもそれくらいは見分けがつくようになってるってことなので、これからはしっかりと信用できる記事を書く必要があるってことですね。

僕のブログは適当なこと書いてる記事はないはずですよ！
みんな信じてね！

それじゃ、バイバイ～

「SEOのこと全然わからんからSEO業者に頼もうか」

わかります。しかしちょっと待ってください。世の中にはほとんど効果のない対策の提案で報酬を貪る業者や、確かに効果はあるかもしれないけど、バレたらペナルティを請けて大損害を被るような対策を行う業者がいます。けっこういます。

この件について、Googleがだいぶキレ気味で勧告を出しています。それが以下のページ。

こちらのページには、Googleが提唱するSEOの本質や、SEO業者の必要性、危険性、選び方などがGoogle自身によって説明されていますので、SEOを行う場合はまず読んでみてください。「え？これ効果あるって言われてめっちゃお金払ったんだけど、効果ないの？」ってことがけっこう書かれているかもしれません。SEOってそういう闇が深い世界なんです。こわいですねー

また、SEOのスタートガイドもありますので、まったくわからない人はとりあえずGoogleの推奨するSEOを実行するところから始めてみてはいかがでしょうか。読んでおくだけでも、結局SEO業者に頼んだときに「いやそれGoogleスタートガイドに書いとることそのまま言っとるだけやん」ってなりますので、余計な費用をかけずに済みますよ。

Web屋としてこんなこと言うのもなんですが、SEO業者に頼むのはほぼ無駄であることが多いです。SEOのほとんどって、Googleのガイドライン見たら書いてあるんですよね。

もちろんしっかりしたSEO業者は、ちゃんとやってくれます。

例えば、たった一つのサイトをビッグワードで上位にするため、かなり濃いメディアサイトをいくつも立ち上げて関連付けるとかやってる業者さんもいます。どのサイトも内部SEOがこれでもかというくらい充実しています。こういうのって、社内だけではなかなかできないですよね。

Googleの注意を聞いて、ちゃんとしたSEO業者を選びましょうね！

現場からは以上です。

昔から人々を夢中にさせてやまないSEO（検索エンジン最適化）ですが、Googleの技術の進歩により、最近ではコンテンツSEOが大事だよという認識がようやく浸透してきたように思えます。

しかし、だからといって技術SEOをないがしろにしていいわけではありません。

コンテンツSEOがユーザーにとって有益な情報を与えるということであれば、技術SEOはGoogleがページ内容を正しく認識できるようにするという意味合いが強いです。

今回は、その技術SEOの中でも僕が特に重要だと思うクロールにフォーカスを当て、正しく迅速にクロールを行ってもらうために使える、WordPressのプラグインの紹介をしたいと思います。

本記事の構成は以下のとおりです

それでは順に見ていきましょう。

クロールとインデックスについて

クロールはSEOにとって特に大事と冒頭で説明しましたが、なぜなのか、そもそもクロールってなんやねんという話から。

クロールとは

Google公式ガイドラインでは、クロールについて以下のように説明されています。

新しいウェブページや更新されたウェブページを検出するプロセスのことです。Google はリンクをたどる、サイトマップを読み込むなど、さまざまな手段で URL を検出します。Google はウェブをクロールして新しいページを検出し、（該当する場合は）そのページをインデックスに登録します。

新しいサイトを立ち上げたり、新しい記事を公開したとき、その時点ではまだ検索に載りませんよね。これはなぜかというと、Googleにクロールされていないためです。

Googleはクローラ（Googlebotと名付けられています）という自動プログラムを使い、ウェブ上に公開されたサイト/ページをクロールしようと日夜活動を続けていますが、基本的にとんでもない数のサイトが日々更新し続けられているため、公開してすぐのサイトに速攻でクロールしに来てくれることはまずありません。

クロールされなければまだGoogleに認識すらしてもらえていない状況というわけです。これが、公開した記事がすぐに検索に載らない理由です。

インデックスとは

こちらもガイドラインより引用

Google は認識したすべてのウェブページを「インデックス」に格納します。各ページのインデックス エントリにはそのページのコンテンツと場所（URL）が記述されています。「インデックスに登録する」とは、Google があるページを取得し、そのページを読み込んで、インデックスに追加することを指します。例文: 「今日、私のサイトの一部のページが Google のインデックスに登録されました。」

クロールされたページはGoogleによって構造を理解され、インデックスと呼ばれるデータベースに格納されます。この流れはもはや「インデックスされる」という動詞になってしまってますが、正確には「インデックスに登録される」が正しいんですね。

ユーザーが検索を行うと、このインデックスから、ユーザーが検索した語句に対し最も有益な情報が書かれているであろうページが検索結果に出されるわけです。

以上、クロールとインデックスについてざっくり説明しました。なぜSEOにおいてクロールが重要かおわかりいただけましたでしょうか。

そもそも、クロールされてインデックスに登録されなければ検索に載らないということですね。

極端な話、例えば速報系の情報を扱っているブログであれば、「速報！台風が明日上陸する！」というタイトルの記事を書いても、検索に載るのが３日後とかだったらまったく意味ないですよね。

というわけで、以降はこのクロールを促すという点に絞って、その方法と使用するプラグインを説明していきます。

Search Consoleについて

Search Consoleとは、Googleで提供しているツールの１つで、サイトを登録することでSEO上重要な様々な恩恵を受けることができます。以前は「ウェブマスターツール」という名前だったんですが、Search Consoleに変わりました。無料で使えます。

SEOを意識するのであれば、Search Consoleにサイトを登録しないと話になりません。

前述したクロールの促進のためにも重要なので、Search Consoleについて少し説明させていただきます。

Search Consoleでできること

Search Consoleに登録すると、以下のようなことができるようになります。

その他にも機能はありますが、SEO上特に重要なのはこのあたりかと思います。

検索アナリティクスとかおもしろいですよね。こんなワードで検索してんのか…ってなります。学びのためにもぜひ見てみてください。

各種通知については、登録したメールアドレス宛てにメールがきます。スパム判定とかされたら相当やばいので、Googleからのメールはこまめにチェックしましょう。

今回はこの中でも、クロールの促進方法について詳しく説明していきます。

All in One SEO Packのインストール

Search Consoleでなんやかんやする前に、まずWordPress側で少し準備をしましょう。

今回使うプラグインは「All in One SEO Pack」です。ご存知の方は多いかと思われますが、このプラグイン、名前の通りSEOに必要なことはだいたいできます。

All in One SEO PackをインストールしていればSearch Consoleへの登録もできますので、まずAll in One SEO Packをインストールしましょう。

Search Consoleへの登録

All in One SEO Packをインストールしたら、一般設定の中に「ウェブマスター認証」という項目がありますので、そこにSearch Consoleの認証コードを入力します。

これだけでSearch Consoleとの連携は完了です。Search Consoleでサイトが正常に登録されたかを確認しましょう。

さらに、All in One SEO PackではGoogle Analyticsも設定できます。

Search ConsoleとGoogle Analytics両方に登録したら、今回のメインテーマはクロールの促進なので、ひとまず他の設定はあとまわし。

サイトマップの送信

次は、Search Consoleで自サイトのサイトマップを送信します。

サイトマップを送信することで、Googlebotくんはサイトの構造を把握しやすくなります。また、どこからもリンクされていないページをクロールするのにも使われます。

サイトマップを送信するにはまずサイトマップを作らないといけないんですが、All in One SEO Packなら拡張機能でサイトマップを作れるうえ、記事が更新されるたびにサイトマップも自動で書き換わり、さらに自動で送信してくれます。

これは使わない手はないです。人によってはGoogle XML Sitemapというプラグインを使う人もいるようですが、プラグイン１個で済むならプラグイン同士の競合が発生することもないし、All in One SEO Packではサイトップ生成についても細かく設定ができて便利です。

拡張機能を有効にする

All in One SEO Packの「機能管理」を選択し、その中の「XMLサイトマップ」を有効にします。

サイトマップの設定はほとんどそのままでいいと思うんですが、僕は下記２点に注意しています。

更新を予約

サイトマップを更新し、Googleにサイトマップを送信するスケジュールです。記事を更新する頻度に合わせて設定します。

投稿タイプ

All in One SEO Packの一般設定でnofollowとしているページをここでチェックしていると、Search Consoleでエラーになります。

サイトマップに書いてるからクロールしようと思ったのに、nofollowって言われて追い返されたんやけど

ということですね。

サイトマップの生成ができたら、Search Consoleの管理画面からサイトマップを送信します。

フィードの送信

サイトマップの他にも、フィードの送信をすることも可能です。

これは僕も最近はじめて知りました。

サイトマップはサイトの構造をGoogleに伝えるのに対し、フィードを送信することで、更新したページの情報をダイレクトにGoogleに伝えることができます。

Googleも、サイトマップとは別にフィードの送信をすることを推奨しています。

自サイトのフィードのURLは、WordPressサイトであればだいたい/feed/となっているはずです。実際にアクセスして確認してみてください。

Fetch as GoogleとWebSub(PubSubHubbub)

Search Console上からFetch as Googleを行うことで、Googleにクロールを促すことができます。

クロールしてほしいURLを入力し、「取得」をクリック。ちなみに「取得してレンダリング」をクリックすると、Googlebotくんがページをどのように認識しているかを見ることができます。

「あれ、なんか実際のページと違うんだけど」ということが稀にありますので、たまに見ておきましょう。

取得すると「インデックス登録をリクエスト」というボタンが出てきますので、迷わず押しましょう。これで、クロールしてもらい、インデックスをやってくださいとお願いするわけです。

WebSub(PubSubHubbub)

Websub（ちょっと前まではPubSubHubbubという名前でした。長いし覚えにくいしどう考えても浸透しそうにないんで変わったんですかね…）とは、Googlebotくんやフィードリーダーに対し自動的にプッシュ通知を行う機能です。

上記Fetch as Googleと同じ機能ではあるんですが、記事を作るたびに毎回Fetch as Googleやるんめんどいわーという方は（普通めんどいと思います）この機能を使いましょう。

WordPressを使っている場合、WebSub/PubSubHubbubというプラグインをインストールし、有効化するだけでこの機能を使えます。

おわり

これで、クロール対策はばっちりですね。ここまでの作業をしておくことで、記事が更新されてから、Googlebotくんがクロールしてくれるまでの時間がぐっと縮まります。

えっ、もうインデックスされてる！ってなりますので、ぜひやっておきましょう。

なお、新規にサイトを立ち上げる場合はどこからもリンクされていない状態なので、Googlebotくんがサイトを見つけるのに非常に時間がかかります。

よって、新規サイト立ち上げの際は、Search Console登録からFetch as Googleまでの流れは必須となりますので、覚えておいてください。

ちなみに、本記事に書かれている内容の一部（Websub）は、以下に紹介する本で勉強しました。その他のことは前から知っていたんですが、この本にももちろん書かれています。

さらに、最近の主流であるコンテンツSEOについても「SEOってそんな大変なの！？」と思うくらいぎっしり細かく書かれていますので、SEOについてガチで勉強したい人はぜひ読んでみてください。

ぜろみやも読んだ！

現場のプロから学ぶ SEO技術バイブル(特典PDF付き)

Amazonで見る

ではでは、良いクロールライフを！

「別の業者さんに作ってもらったこのサイトがモバイルフレンドリーテストに通らないんですが、見ていただけますか？」というお仕事を請けたときのお話。

見た感じ別に悪いとこなさそうやし、まぁすぐ解決するやろとたかをくくっていたのですが、まずどこが悪いのかすらわからない時点から既にバトルはスタートしていたのだった…

なんとか解決したので、役に立つ情報かはわかりませんが、何かのヒントになれば幸いです。

viewportの記述ミス

カンマがありませんでした。

<meta name="viewport" content="width=device-width,initial-scale=1.0 maximum-scale=1.0">

いやviewportの記述が脱字っとるやんｗｗｗｗｗｗはい終わり楽勝ｗｗｗｗｗｗｗｗ

<meta name="viewport" content="width=device-width,initial-scale=1.0,maximum-scale=1.0">

結果：何も変わらず。

これで終われば平和だったのですが、世の中そううまくいかないようです。
次いってみましょう。

そもそもモバイルフレンドリーテストはページが正しく認識されるのか？

何事にも不具合はつきものなので、こういった疑問を持つことも大事です。
Page Speed InsightsがほとんどのサイトでUnavailableとなっていたのも気になっていたので…
というわけで、自分が作った他のサイトや、有名なサイトをモバイルフレンドリーテストにかけてみました。

すると、だいたい想定通りの結果となっていたので、テスト結果は信用できそうな感じです。

さらに、body内部を全部消してすぐテストしてみたところ、

このページはモバイルフレンドリーです

との結果が出ました。
この時点で、下記のようなことがわかります。

• テストはキャッシュ関係なく、現時点でのページでリアルタイムに行われる
• 原因はbody内のどこかにある

それでは次にいきましょう。

Search Consoleも見てみる

テスト結果だけではイマイチ全貌を把握できないので、Search Consoleの閲覧ができるようにしてもらいました。

検索トラフィック→モバイルユーザビリティから、エラーを確認することができます。

すると、問題のあるページが大量にあったので、これはおそらく共通部分が原因だろうと思いました。

原因のありそうな箇所を削除してテストする

一部分を削除した状態でテストしてOKと出れば、その削除した部分に問題がある、ということになります。

というわけで、共通部分のheader,footerを削除してテストしてみました。

結果：ダメ

ダメでした。えぇ…共通部分が悪いんじゃないの…

共通部分が原因じゃないとなると、つまりサイト全体的に何かがおかしいということになってきます。

もう一度原因を探るべく、部分的に削除してはテストを繰り返しました。

異変が起きた

もう何を消してもダメで、何も書かれていない状態でないとOKにならないという絶望的状況のなか、半ばヤケクソでbody内を以下のようにしてやりました。

<body>
<div id="wrapper">
<div id="">
<article class="">
<main>
<p>ああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああ</p>
</main>
</article>
</div>
</div>
</body>

だいぶ精神が崩壊気味です。いろいろ削除して枠だけにしてあるので、記述がおかしいのはちょっと気にしないでもらいたいのですが、
問題は、この状態でもNGだったということです。

これはいったいどういうことなんだ…普通に考えてそんなわけがない…

ちなみに、<p>あああ</p>だけだとエラーになりませんでした。

ただ、逆に「これだけしか書いてないのにNGになる」というのは、原因が絞りやすくなったということに他なりません。

さっぱりわかりませんが、もう少しで解決する。そう確信しました。

問題はCSSにあり

ここまで中身のない状態でもエラーが出るということは、cssに問題があるという可能性が高いです。
というわけで、上の状態で全てのcssの読み込みをはずしてみたところ…

このページはモバイルフレンドリーです

きた…！もう少しだ…！

cssを元に戻し、上記に使われている要素のスタイルを眺めてみました。
すると、怪しい記述を発見。

body {
  min-width: auto;
  padding-top: 90px;
}

min-width: auto;

おそらく、PCでの表示でmin-widthを設定していたのを、メディアクエリで打ち消したかったんだと思いますが、min-widthにautoは誤りです。

min-width:1px;となおしてテストにかけました（initialのほうが正しいかもしれないです）。

このページはモバイルフレンドリーです

やったぜ！！！

もちろんほとんど中身がない状態での通過だったので、本番環境でもcssをなおしてテストしました。
無事、通過。

よかった…。完全勝利。

おわり

モバイルフレンドリーテストは、SEOを行うにあたって避けては通れない部分ですが、これは数ある対策のうちの一つにすぎません。

更なる対策として、【集客職人 RankingCoach】などのSEOツールを使い、ホームページの集客力をアップしていくのも手段の一つです。SEOコンサルを行う際に使用するのも有効ですよね。

それでは、エレガントなSEOライフを。