“共起語”をアンカーテキストにしてランキングを大きく上昇させた手法について、以前エントリしました。 WebmasterWorldでこの話が再びスレッドに登場したことをツイートしたところ、「関心があるのでやってみたいからもう一度説明してほしい」と普段よく絡んでいるオトモダチ数名からリクエストがあったので、再度解説します。 まず「共起語」を定義しておきます。 共起語というのはSEOの業界で広く使われている言葉ではありません。 前の記事で僕が使ったのが初めかもしれません（自分が先だという人がいたらご指摘ください）。 英語の動詞の“co-occur”(一緒に起こる)と名詞の“co-occurrence”(一緒に起こること)を堅めの日本語に訳して、「共起（語）」としました。 この記事での「共起語」は、同じドキュメント（ウェブページ）のなかで頻繁に同時に使われる言葉のことです。 「同意語」ではありませ

[レベル: 上級] noindex robots meta タグ を設定したページに設置してあるリンクは、たとえ、follow robots meta タグが併用されていたとしても、Googlebot が最終的にはたどらなくなります。 つまり、 <meta name="robots" content="noindex,follow" > が記述されていたとしても、やがて <meta name="robots" content="noindex,nofollow" > と同等に扱われてしまいます。 SEO で誤解されている noindex/follow SEOのコミュニティには、“noindex, follow” に関していささか誤解があるようだ。 Google の John Mueller（ジョン・ミューラー）氏はこのように前置きして、noindex ページが設定されたページに存在するリン

[レベル: 中級] AMP ページは、対応する PC 向けページとコンテンツが1対1の関係でなければなりません。 AMP 版と PC 版が対等でない場合は、コンテンツの不一致としてみなされます。 AMP と PC 向けの URL が「1対1」対応していない たとえば次のような構成を想定してください。 ECサイトで、PC 版では概要・スペック・アクセサリなどを別々のページに分け、個別の URL を割り当てている。一方で、AMP 版では1ページにまとめていて、URL は1つ PC 版は1ページだが、AMP 版はページネーションして5ページに分けている（同じコンテンツで、PC 版は1つの URL、AMP 版は 5つの URL） 上とは逆で、PC 版は5ページに分けてページネーションしているが、AMP 版は1ページにまとめている（同じコンテンツで、PC 版は5つの URL、AMP 版は1つの UR

[レベル: 中級] ユーザーの役に立つコンテンツは必ずしも文字情報だけとは限りません。 時には、画像や動画のほうが適していることもあります。 そこでこの記事では、画像と動画のベストプラクティスについて解説します。 先週開催された ISM Spin-off #2 と Google Dance Tokyo 2017 でゲストに招かれた Google の Gary Illyes（ゲイリー・イリェーシュ）によるアドバイスです。 Q&A セッション中で語られたものに加えて、ゲイリーから直接聞いたことも含めています。 画像の最適化 画像の最適化に関しては、ヘルプ記事や公式ブログ記事ですでに説明されていることと大差ありません。 テキスト情報 何の画像なのかを Google が理解するにはテキスト情報が役立ちます。 テキスト情報とは具体的には次のようなものです。 画像周囲のテキスト 画像のキャプション a

[レベル: 中級] レスポンシブ ウェブ デザインが選択すべき構成だ (Responsive Web Design is the way to go.) Google の Gary Illyes（ゲイリー・イリェーシュ）氏は、8月22日に開催された ISM Spin-off #2 で、このようにレスポンシブ ウェブ デザインをかつてないほどに推奨しました。 これまでは、「動的な配信」と「別々の URL」を含めた3つのモバイル構成のどれを選択しても構わないと言っていました。 しかし方針を変えて、レスポンシブ ウェブ デザイン1本に絞ったのです。 動的な配信と別々のURLが抱える問題 レスポンシブ ウェブ デザイン（以下、RWD）をゲイリーが強く推奨する最大の理由は、モバイル向けサイトと PC 向けサイトに差異がないことです。 見た目は違っていたとしても、同じ HTML を配信しているので、コ

[レベル: 中級] 非 HTTPS (HTTP) のページでテキストをフォーム送信する要素を持つサイトを対象に、Google は先週末いっせいに警告メールを送信しました。 Chrome 62 から実装予定のセキュリティ警告 次のメールが Search Console 経由で届きます。 Chrome のセキュリティ警告を http://example.com に表示します http://example.com の所有者様 2017 年 10 月より、ユーザーが Chrome（バージョン 62）で HTTP ページのフォームにテキストを入力すると、「保護されていません」という警告が表示されるようになります。また、シークレット モードを使用している場合は、HTTP ページにアクセスするだけで「保護されていません」と表示されます。 貴サイトでは、たとえば以下に示す URL に、Chrome の新し

[レベル: 中〜上級] ページネーションしている一連のページの集まりで、2ページ目以降を noindex にすることに問題はない。 ただし、noindex にしてもクロールバジェットの節約には役立たない。 Google の John Mueller（ジョン・ミューラー）氏は、英語版のオフィスアワーでこのように説明しました。 ページネーションで noindex を利用可能 ページを分割している、いわゆるページネーション構成では、rel="prev" と rel="next" を用いて、分割したページの関連性を伝える設定を Google は推奨しています。 しかし、2ページ目以降をインデックスさせる（検索結果に表示させる）必要性を感じていないのであれば、noindex robots meta タグを設定することも可能です。 まったく問題ありません。 noindex はクロールバジェットの節約に

[レベル: 初級] モバイルサイトの表示速度を検証するための新しいツールを Google は公開しました。 「Test My Site」（テスト マイ サイト）といいます。 英語と日本語で、Test My Site ツールを紹介する公式アナウンスが出ています。 Fast mobile sites get more customers. Let's help get yours up to speed. Google の新ツール「Test My Site」を活用してモバイルサイトの読み込み速度を改善しましょう Test My Site でスピード状態チェック 次の4項目を Test My Site はレポートします。 モバイルでのサイト読み込み速度 読み込み中の想定離脱数 業種別平均速度との比較 速度改善の提案 読み込み速度・想定離脱数 僕のブログ（のトップページ）のモバイルでの読み込み速度

[レベル: 初〜中級] 導入時期が依然として不透明なモバイル ファースト インデックスですが、導入に備えて確実に必要になる対処がいくつかあります。 そのうちの1つが alt 属性です。 モバイル向けページで alt 属性 をもし省略しているなら、今すぐにでも設定する必要があります。 ひとたびモバイル ファースト インデックスへの切り替えが実行されれば、検索結果、特に画像検索結果に悪い影響が出るかもしれません。 alt 属性を設定していなモバイルサイトが多い モバイルサイトでの alt 属性の状況について、Google の John Mueller（ジョン・ミューラー）氏は英語版のオフィスアワーで 次のように注意を促しました。 alt 属性に関してモバイルファーストインデックス チームから特によく聞くのは、alt 属性を画像に設定していないサイトがたくさんあるということだ。 alt 属性がな

[レベル: 初・中・上級] ユーザー体験を損ねる広告を掲載しているサイトに対して、Chrome ブラウザでは広告を一切表示しなくなるようにすることを Google は発表しました。 これにあわせて、サイトに掲載している広告に問題があるかどうかを調べるツールの提供を始めました。 背景 Google が、こうした決定を今回下した背景の1つに、ユーザー体験を損ねる広告の増加が挙げられます。 いきなり大きな音楽で再生が始まる広告や記事を見る前に強制的に見せつけられる広告のような不愉快な広告は誰しもが体験したことがあるはずです。 広告そのものは悪いものではなく、健全な経済活動です。 広告閲覧者と広告発行者の双方にとってより良いオンライン広告を提供するために Coalition for Better Ads という団体が組織されています。 Coalition for Better Ads は消費者に受

[レベル: 中級] Google は、Chrome ユーザーのプライバシー保護をより一層強化することにしました。 次のどちらかの条件に当てはまるページに Chrome でアクセスした場合、URL 欄に「保護されていない通信」のラベルが付きます。 データを入力する HTTP ページ シークレットモードでアクセスする すべての HTTP ページ パスワードとクレジットカード情報だけじゃない 1月にリリースされた Chrome 56 から、パスワードまたはクレジットカード情報を HTTP 通信で送信するページ、言い換えると HTTPS ではない通信でそれらの情報を送信するページには、URL 欄に「保護されていない通信」というラベルが表示されるようになりました。 この仕様を Google はさらに一歩推し進めます。 情報を入力する すべての HTTP ページ パスワードとクレジットカード情報に限ら

[レベル: 初〜中級] モバイル ファースト インデックス（以下、MFI）関連で最も気になることの1つは、いつ導入されるのか？です。 年内には導入されず、2018年にずれ込む可能性が十分に考えられそうです。 2017年中には導入できなさそう モバイル SEO に焦点を当てた Next10x Conference というカンファレンスが米ボストンで4月5日に開催されました。 ここで、Google の Gary Illyes（ゲイリー・イリェーシュ）氏が、MFI の導入状況についてコメントしたとのことです。 参加していた人たちと、ゲイリー本人のツイートから判断すると、次のような状況になっているようです。 “エンジニアたちは年内の導入を目指しているが、ゲイリーは、年内はないだろうと考えている。（少なくとも）まだ半年以上は先。” "mobile first index will launch by

[レベル: 中級] この記事では、モバイル ファースト インデックスの導入にともなう、次のような構成のモバイルサイトの対応について解説します。 モバイル向けサイトのリストページは、アイテムの表示件数を初期状態では PC 版よりも少なくしている 「もっと見る」のような要素でアイテムを追加表示する 「もっと見る」のタップを繰り返してアイテムをさらに追加表示する モバイル UX 向上のための「もっと見る」 モバイルサイトでのリストページでは、「もっと見る」や「次の○件」のようにして、タップすることでさらに多くのアイテムを表示するユーザーインターフェイスが使われることがあります。 多過ぎるアイテムを一度に表示すると、表示速度が落ちるし見づらくなるからです。 ユーザー体験を向上させるための UI です。 ただし、モバイルサイトでこうした UI を採用していても、PC サイトではもっと多くのアイテムを

[レベル: 初・中・上級] 特にモバイル向けサイトでは、ユーザー体験改善のための最優先事項として”スピードアップ”が挙げられます。 現状のモバイルサイトがいかに遅く、遅い表示速度がどのくらい悪い影響をユーザー体験に与えているかを調査した結果を Google が公表しました。 「完全に表示されるまでに3秒以上かかると、53%のユーザーはページを離れる」「表示速度が1秒から7秒に落ちると、直帰率は113%上昇」など興味深いデータが出ています。 モバイルページは遅い、遅いとユーザーは立ち去る 新しい調査による次のような結果に Google はまず言及しています。 モバイル向けのランディングページが完全に表示されるまでにかかる時間は22秒 完全に表示されるまでに3秒以上かかると、53%のユーザーはページを離れる 全般的に、とにかくモバイルページは遅いということが明らかです。 にもかかわらず、モバイ

[レベル: 初級] 関連性に乏しく、品質が低い検索結果を発見したときはどうすればいいのでしょうか？ 特に、自分のサイトよりも明らかに劣っているサイトが上位表示している状況に遭遇したときは心穏やかではいられないでしょう。 Googleのジョン・ミューラー氏はフィードバックを送るようにアドバイスしました。 フィードバックは検索品質の改善の大きな手助けになるからです。 間違った検索結果を発見したときの対処方法 Googleのウェブ検索でマップの間違った結果が表示されている状況への指摘がヘルプフォーラムに投稿されました。 ミューラー氏は次のように説明しました。 一般的には、マップ（ローカル）とウェブ検索の結果は分離している。並べたりランク付けしたりするのに異なるアルゴリズムを使っている。 そういうことが役に立つときがあり、たとえばどちらかの結果で表示されるチャンスを小規模ビジネスに与えられる（誤っ

[レベル: 上級] Googleには少なくとも2種類のインデックスが存在しているようです。 1つは「プライマリ インデックス」で、もう1つは「ファスト トラック インデックス」です。 プライマリ インデックスは、通常の正規のインデックスです。 URLはインデックスに正式に登録され検索結果に出続けます。 一方、ファスト トラック インデックスはより速くインデックスされますが、その後もずっと検索結果に出るとは限りません。 永続性がない、いわば”即席”のインデックスです。 Fetch as Googleでインデックス送信したURLが検索結果から消えてしまうのはなぜ？ 英語版のオフィスアワーで次のような趣旨の質問が出ました。 17個のURLをFetch as Googleで送信した。それらのURLはサイトマップにも記述している。 17個のうち9個はインデックスにとどまっていたのだが、8個くらいはイ

In-house SEO Meetupが主催したGoogle MFI Nightで、Google社員にさまざまな疑問を質問するAMA with Google セッションを先週金曜日の記事でレポートしました。 日本語検索独自の品質評価アップデートがテーマでしたが、このイベントのメインテーマはモバイル ファースト インデックス (MFI) です。 当然AMAもMFI関連の質問が大部分を占めていました。 そこでこの記事では、Googleの金谷さんと長山さんを相手にしたMFIについてのQ&Aをレポートします。 MFIに関して2人のGoogle社員に何でも質問してみた [質問に答える長山さん] Q. 内部リンクの必要性 モバイル向けページではUXを考慮して、内部リンクをPC向けページよりも減らしている。 しかし、内部リンクが評価（ランキング）にも影響するなら、PC向けページと同じリンクをモバイル向け

Web担当者Forumの連載コーナー、「海外&国内SEO情報ウォッチ」を更新しました。今週取り上げた記事は次のとおりです。 今週のピックアップ グーグル「常時HTTPSでなきゃChromeでひどい目にあわすよ、まずは1つ目の罰だ」 日本語で読めるSEO/SEM情報 グーグルSEOで2016年に起きた一番のビッグニュースはやっぱり“あれ” 2016年最後のオフィスアワーは、MFI関連のQ&Aで締め！ 404エラーが急増した原因は、存在しないモバイル向けページのURLにGooglebotがクロールしてきたからだった！ モバイルサイトのコンバージョン率アップに利用したい「オートフィル」とは？ 帰ってきた#NoHackedキャンペーン 海外のSEO/SEM情報を日本語でピックアップ インタースティシャルへのペナルティ適用開始、ただし検索結果からの着地ページだけ 地域分散クロールがあっても、米国から

[レベル: 上級] Googleは、セーフブラウジングのポリシーにより厳しい項目を追加しました。 違反を繰り返すサイトと判断された場合は、30日間再審査リクエストを送ることができなくなります。 セーフブラウジングとは セーフブラウジングを簡単に説明します。 セーフブラウジングは、マルウェアや望ましくないソフトウェア、ソーシャル エンジニアリングなどユーザーに危害・損害を与えるサイトを検出するシステムです。 そういったサイトにアクセスしようとすると、ユーザーを保護するために主だったブラウザは警告画面を表示します。 セーフブラウジングが検出したサイトに関わる状況のデータを専用のサイトでGoogleは公開しています。 セーフブラウジングのガイドラインに違反した際は、その違反を解消すれば自動的に解除されます。 あるいはSearch Consoleに警告が届いた場合は、再審査リクエストによって解除を

[レベル: 中級] Googleは、AMP化したモバイル検索を日本のGoogle (google.co.jp) に導入しました。 Google日本でAMPの開発に携わっている、検索担当パートナーシップマネージャーのDuncan Wright（ダンカン・ライト）氏がGoogle Japan 公式ブログでアナウンスしています。 AMP化したモバイル検索は、通常の検索結果で、⚡マークが付いたAMPラベルをAMP対応したページに付与します。 そしてモバイル向けページではなくAMPページへユーザーを着地させます。 モバイル検索のAMP化は、1か月前に米国 (google.com) で始まっていました。 日本でも、一部のユーザーに対してテストが行われていましたが、いよいよ全ユーザーに対する正式公開です。 AMP化した日本のモバイル検索 日本のGoogle検索で、通常のモバイル検索結果にAMPページを表