Googleはクリックデータを検索結果のランキング決定に利用しているのか？⇒どーでもいい😉
[レベル: 初級] 検索結果のクリックのデータを Google はどのように利用しているのか？ もっと言えば、クリックはランキングに影響を与えるのか？ 長らくの間、論争に的になっているテーマです。 Search Engine Land の取材に対し Google があらためてコメントしました。 さまざまな目的で Google は検索結果のクリックデータを利用している Google のコメントは次のとおりです。 As we’ve commented on before, we use interactions in a variety of ways, such as for personalization, evaluation purposes and training data. We have nothing new or further to share here other th
企業情報の構造化データはサイト内のどのページに追加すべきか？
[レベル: 中級] 名称や所在地など企業の情報を表す構造化データはサイト内のどのページに追加すべきなのでしょうか？ トップページでしょうか？ 会社案内ページでしょうか？ それとも、すべてのページにマークアップしたほうがいいのでしょうか？ 結論を言うと、どのページでも問題にはなりません。 あなたが適切と考えるページに追加することができます。 企業情報の構造化データはサイト内のどのページに設置してもよい 組織・企業の構造化データ（Organization とそのサブタイプ）はどのページに追加すべきなのかという質問が英語版オフィスアワーで取り上げられました。 Google の Matin Splitt（マーティン・スプリット）氏は次のように返答しています。 どのページに設置してもたいした問題にはならないと思う。すべてのページに設置しないということのほうが、もっと大事なようにも思える。 サイトにも
モバイルファーストインデックス移行後に注意したいこと2つ――キャッシュエラーとロールバックなし | 海外SEO情報ブログ
[レベル: 中級] モバイル ファースト インデックスへ移行したサイトが続々と増え、通知がたくさん届いています。 この記事では、モバイル ファースト インデックス移行後に注意しておきたいことを2つ説明します。 キャッシュ エラー ロールバックなし キャッシュ エラー モバイル ファースト インデックスに移行したサイトのページには Google のキャッシュ表示に不具合が生じています。 キャッシュを見ようとすると 404 エラーが返されます。 僕が所属している Faber Company のコーポレートサイトは今回の一斉通知でモバイル ファースト インデックスに切り替わりました。 ところが、キャッシュページがエラーになります。 noindex meta タグや noarchive meta タグなどキャッシュを拒否する設定はしていません（ちなみこのブログは、noarchive でキャッシュ表
今月導入される Google Speed Uptate は速ければ速いほど評価が上がるアルゴリズムだった
[レベル: 中級] 【UPDATE】 この記事は事実を正しく反映していないことが判明しました。 こちらの記事で説明しています。 ページの読み込み速度をモバイル検索のランキング要因として用いる “Speed Update”（スピード アップデート）を Google は今月導入する予定です。 Speed Update は、本当に遅いページだけが影響を受けるアルゴリズムだと思われていました。 しかしながら実際には、速ければ速いほど評価が上がるアルゴリズムになっているようです。 Speed Update では、読み込み速度が速いと段階的に評価が上がる Speed Update の導入を事前アナウンスした公式ブログの記事は次のように説明していました。 The “Speed Update,” as we’re calling it, will only affect pages that delive
モバイルファーストインデックスの通知をGoogleがついに送り始める、第二陣はもっと大規模で間もなく開始
[レベル: ALL] モバイル ファースト インデックス（以下、MFI）へ移行したサイトにはついに通知を Google 送り始めました。 第一陣の MFI 移行対象になったサイトはかなり限られた数だったようですが第二陣はもっと多くのサイトが対象になり、こちらも間もなく移行が始まるようです。 移行通知が Search Console に届く MFI を開始したことを Google は1か月少し前にアナウンスしていました。 と同時に、移行の対象になったサイトには Search Console 経由で通知を送ることも伝えていました。 ところが1か月たっても通知を受け取ったという話は、国内外を問わずまったく耳にしませんでした。 よほど少ない数のサイトが対象だったのか、それとも MFI は実際にはまだ始まっていないのではないかとも疑われました。 しかし、英ブライトンで先週参加した BrightonS
Google、モバイル検索のページネーションを廃止。「もっと見る」による無限スクロールへ変更
[レベル: 中級] 無限スクロールのモバイル検索結果を Google は導入しました。 「次へ」でページネーションして2ページ目、3ページ目に移動するのではなく、「もっと見る」で続きの結果が出現します。 正式導入 「もっと見る」による無限スクロールのモバイル検索結果は昨年12月にテストしていたことが確認されています。 しかし今回はテストではなく、正式導入になります。 Google 検索の Twittere 公式アカウントがアナウンスしました。 We've launched a new “More results” button that makes it easier & faster to get more search results on mobile. Now additional listings load below the ones already being viewed,
過去にペナルティを受けたスパムサイトをリセットするボタンはGoogleには存在しない
[レベル: 中級] 過去に Google からアルゴリズム的に低評価を与えられてしまったドメイン名を、そうとは知らずに取得してしまうことがあります。 ドメイン名の所有者がまったく無関係の人になったからといって、その低評価をゼロにすることはできません。 Google にリセットボタンはない Google の John Mueller（ジョン・ミューラー）氏が、Reddit で AMA を開催しました。 Google SEO に関することを何でも質問できる掲示板です。 次のような内容の質問が投稿されました。 以前にアルゴリズム的に低評価を受けていたと思われるドメイン名をクライアントが取得してしまいました。新しいサイトのはずなのに、何をやってもうまくいきません。 過去のサイトとは異なる新規サイトであることをどうやったら Google に伝えられますか？ ミューラー氏はこう回答しました。 ドメイン
Google、モバイルファーストインデックスを本格展開、準備が整ったサイトから移行（ただしアルゴリズム更新ではないので注意！）
[レベル: All] モバイル ファースト インデックスの展開を本格的に開始したことを Google はウェブマスター向け公式ブログでアナウンスしました。 MFI のベストプラクティスを満たしているサイトが順次移行の対象になります。 日本語での翻訳記事は今日中に公開されると思われます。 【UPDATE】 公開されました: 『モバイル ファースト インデックスを開始します』 MFI おさらい まず、簡単にモバイル ファースト インデックス（以下、MFI）をおさらいしておきましょう。 MFI が何かを十分に理解していればここは飛ばして構いません。 MFI はモバイル向けページを主たるインデックスの対象にする変更です。 これまでは、PC 向けページがインデックス対象になっていました。 従来は PC 向けページの評価に基づいて検索順位が決定されました。 今後は、モバイル向けページの評価に基づいて検
Google、モバイル検索の強調スニペットにAMPリンクを掲載
[レベル: 中級] モバイル検索での強調スニペットに、AMP ページへのリンクを掲載するように Google は改良を加えました。 強調スニペットの AMP こちらが AMP ページへのリンクが掲載される強調スニペットです。 リンクをタップすると、当然のごとく AMP キャッシュでページが表示されます。 品質改善のために強調スニペットに絶えず改良を Google は加えています。 モバイル検索であれば、強調スニペットにも AMP を利用しない手はありませんね。 強調スニペットの AMP リンクは8月末あたりに登場したようです。 強調スニペットが表示されるクエリを調べるフィルタは検索アナリティクスにはないのですが、8月末にトラフィックが突然増えている AMP ページのクエリがあったとしたら、それは AMP 強調スニペットを獲得できている証かもしれません。 チェックしてみてください。 [H/T
Ajaxクロールの推奨構成のサポートをGoogleがついに終了
[レベル: 上級] Googleは、今からさかのぼること2009年に公開した、Ajaxクロールの推奨構成を終了することを公式にアナウンスしました。 以前の推奨構成を保持したままでもインデックスされ続けますが、現状に即した技術を利用するように促しています。 ごく限られたJavaScriptしか実行できなかった当時、GoogleはAjaxによって生成されるコンテンツを確実にクロール、インデックスするために特殊な構成をウェブマスターに提唱しました。 この構成を、ざっと簡単に説明すると次のようになります。 ウェブページのレンダリングをすませた、いわゆる“スナップショット”を事前に作成しておき、AjaxページにGooglebotがアクセスしたときには準備済みのスナップショットを返す。 Googlebotにスナップショットを取得させるために、AjaxページのURLに含まれる「#」（ハッシュ、フラグメン
CSSとJSファイルをブロックしているサイトに警告メッセージをGoogleが一斉送信
[レベル: 中級] CSSとJavaScriptのファイルへのアクセスをrobots.txtでブロックしているサイトに対して、Search Console経由で警告メッセージをGoogleは一斉に送信し始めました。 CSSおよびJSファイルにGooglebotがアクセスできません Google Search Console Teamから次のようなメッセージが届きます。 http://example.com/ の CSS および JS ファイルに Googlebot がアクセスできません http://example.com/ のウェブマスター様 Google のアルゴリズムによるコンテンツのレンダリングとインデックス登録に影響を及ぼす問題が貴サイトで発生していることが Google のシステムにより判明しました。具体的には、robots.txt ファイルでの制限のために Googlebot
HTTPS移行後に外部リンクのURLを https:// に変更する必要はない
[レベル: 上級] 常時HTTPSへ移行した際に、外部サイトから張られているリンクのURLを https:// で始まるURLにわざわざ更新する必要はありません。 GoogleのGary Illyes（ゲイリー・イリーズ）氏は、Twitterユーザーからの質問に次のように答えています。 @pip_net if your redirects are properly implemented, the benefit from doing that is so minimal that IMO it's not worth it. — Gary Illyes (@methode) 2015, 7月 7 HTTPSへ移行するとき、可能であれば、重要な外部リンクをSSLに変更したほうがいいと思いますか？ リダイレクトが適切に実装されているなら、そうすることでプラスになるのはごくわずかだ。僕の考えで
ウェブマスターツールの検索アナリティクスがすべてのユーザーに公開
[レベル: 中級] Googleは、一部のユーザーに試験提供していた「検索アナリティクス」をすべてのユーザーに提供開始したことを発表しました。 「検索アナリティクス」は、従来の「検索クエリ」の置き換わりになるツールです。 これまでは、Googleが選んだテスターだけが利用可能でした。 テスターから全ユーザーへ 検索アナリティクスは、アルファ版のときはテスターに申請したなかから選ばれたユーザーだけが利用できていました（僕は運良くアルファテスターに選ばれていた）。 その後ベータ版にバージョンアップしたタイミングで、ランダムに選んだ一部のユーザーがテスターとして追加されました。 しかし現在は、すべてのユーザーの標準のクエリレポートとして設定されています。 ウェブマスターツールにログインすると、ダッシュボードには「検索クエリ」ではなく「検索アナリティクス」が表示されています。 日本版ブログでのアナ
モバイルフレンドリーアップデート始動、公式情報【海外＆国内SEO情報ウォッチ】
Web担当者Forumの連載コーナー、「海外&国内SEO情報ウォッチ」を更新しました。 今週取り上げた記事は次のとおりです。 今週のピックアップ お待ちかね、モバイルフレンドリーアップデートがついに始動 グーグルだけど、モバイルフレンドリーアップデートについて質問ある？ 日本語で読めるSEO/SEM情報 モバイルフレンドリーの疑問をグーグル社員に直で聞いてみた モバイルフレンドリーだけじゃない、App Indexingもランキングシグナルに App Indexingがランキング要因になった今、すぐにアプリを開発すべきか 海外のSEO/SEM情報を日本語でピックアップ モバイルフレンドリー更新を悪用した業者にご注意 モバイルフレンドリー更新は完了までに数週間かかるかも 大画面スマホからの検索はモバイル扱い？ PC扱い？ Googleアナリティクスのメモにモバイルフレンドリー更新を記録しておこ
Google、パンくずリストとサイト名をURLの代わりにモバイル検索結果で表示。構造化データで指定可能
[レベル: 中級] Googleはモバイル検索で、すべての結果にURLの代わりにパンくずリストを表示するように仕様を変更しました。 また、ドメイン名の代わりにサイト名を表示することがあります。 Official Google Webmaster Central Blog: Better presentation of URLs in search results モバイル検索結果ではパンくずリストを表示 下のモバイル検索結果では、URLのところがすべてパンくずリストで表示されています。 とはいえ、もともとPCからの検索でもパンくずリスト表示だったのなら、モバイル検索特有の機能とはいえません。 比較してみましょう。 こちらのPCからの検索結果では、通常どおりにURLがそのまま表示されています。 スマートフォンから検索するとこのようになります。 少々わかりづらいのですが、パンくずリストっぽく変
事前レンダリングでウェブページの表示時間を高速化
[対象: 上級] 事前レンダリングと呼ぶ技術を使って、ウェブページの表示時間を高速化する方法をこの記事では解説します。 事前レンダリングとは 事前レンダリング (Prerendering)とは、その名のとおり、ページの読み込み（正確にはレンダリング）を前もって実行する仕組みです。 Google検索で採用されている「インスタントページ」には事前レンダリングが使われています。 下のキャプチャは、Googleで「Amazon」を検索したときのChromeのタスクの状況をタスクマネージャで確認したものです。 「事前レンダリング」でAmazon.co.jpが出ています。 「Amazon」で検索したユーザーはかなり高い確率で（1位に出てきた）Amazonのホームページをクリックするはずです。 Chromeは先回りして、ユーザーがクリックしなくてもAmazonのホームページを取得および描画、つまりレンダ
レスポンシブ・ウェブデザインは上位表示に有利ではない、デメリットもある
[対象: 中〜上級] Googleが推奨するモバイルサイト構成はレスポンシブ・ウェブデザイン Googleは3つのタイプのモバイルサイト構成をサポートしています。 レスポンシブ・ウェブデザイン（同じURLと1つのHTML/CSS） 動的な配信（同じURLと別々のHTML/CSS） モバイル専用のURL（異なるURLと別々のHTML/CSS） このなかで、Googleがもっとも推奨する構成が1つ目のレスポンシブ・ウェブデザインです。 レスポンシブ・ウェブデザインには大小さまざまなメリットがあります。 なかでも、URLが1つ、リダイレクト設定が不要というのがいちばん大きなメリットでしょう。 重複コンテンツを生まないし、リダイレクトによるミス（Googleの人によれば非常に多いらしい）も発生しません。 検索エンジンにとっても都合がいいのがレスポンシブ・ウェブデザインになります。 レスポンシブ・ウ
スマホ向けサイトのユーザビリティとランキングを低下させる12個のマイナス要因
[対象: 中〜上級] さまざまなモバイル向けサイトの研究中に出くわした、ユーザビリティを大きく損ねる12個の要素をE-consultancyがブログで解説しました。 ユーザビリティの悪化だけではなく、なかにはGoogleのランキングを下げる原因にも繋がるスマートフォンサイトの構成ミスも含まれています。 モバイル対応が必須になっている現在のサイト運営において、とても参考になる記事なので紹介します。 なお直訳ではなく、僕なりの言葉で要点を説明します。 英語がわかる方は原文も読んでください。 モバイルサイトのユーザビリティを損ねる12個の欠陥 1. 突然デスクトップ向けサイトに切り替わる モバイル向けのページを閲覧していたのに、デスクトップ向けページに突然移動させられてしまうサイトは確かにありますね。 モバイル向けのデザインだったのに、ページを移動したら何の前触れもなくPC向けのデザインに切り替
Googleアナリティクスでバックリンクを調べる方法
[対象: 中〜上級] Googleアナリティクスのソーシャルレポート機能を使ってサイトに張られている被リンクを調べる一風変わった方法をこの記事では解説します。 【UPDATE】 レポートへのアクセス方法が変わりました。 現在のやり方はこちらの記事を参照してください。 Googleアナリティクスのトラックバックで被リンクを簡単チェック まず左ナビゲーションのメニューから [トラフィック] − [ソーシャル] − [参照元ソーシャルネットワーク] を選択します。 そうするとFacebookやTwitter、はてなブックマークなど自分のサイトのコンテンツが共有されたソーシャルネットワークの一覧が出てきます。 どれでもいいので、どれか1つのソーシャルメディアを選択します。 「ソーシャルメディアを経由した訪問数」のグラフが表示されます。 グラフの上にあるタブでは「ソーシャルメディアからの参照」が初期
JavaScriptの読み込みを最適化してページの表示速度を高速化する6つの方法
[対象: 中〜上級] 僕のブログではてブ数がいちばん多いのはウェブページを高速化するTIPSを解説した記事です（まだ読んでない人はぜひ読んでください！）。 その記事では高速化全般を扱っていましたが、今日の記事ではJavaScriptに的を絞って表示速度をスピードアップできる施策を6つ紹介します。 もともとはSearch Engine PeopleブログのOptimizing JavaScript for Better Web Performanceで説明されていたものです。 記事作者のJoydeep Deb（ジョイディープ・デブ）氏に僕のブログでの転載許可をもらえました (Thanks, Joydeep!)。 逐一の翻訳ではなく、書かれている内容をもとに僕の言葉で解説していきます。 1. HTTPリクエスト削減のためにJavaScriptファイルを1つに統合する ウェブページの表示を高速化
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
