最新のJavaScript技術を使ったウェブサイトを検索向けにする方法 #ChromeDevSummit | 海外SEO情報ブログ
[レベル: 上級] この記事では、11 月 12 〜 13 日に米サンフランシスコで開催された Chrome Dev Summit 2018 に参加した際のセッションをレポートします。 セッションテーマは、JavaScript を多用したサイトを検索で発見されやすくするためのベストプラクティスと注意点です。 セッションスピーカーは、Google チューリッヒの Martin Splitt（マーティン・スプリット）氏と Google シドニーの Tom Greenaway（トム・グリーンアウェイ）氏です。 最新の JavaScript 技術で構成されたウェブサイトを検索フレンドリーにするための秘訣をマーティンとトムの2人がどんなふうに解説したのかを一緒に見ていきましょう。 JavaScript コンテンツの処理プロセス 1. クロール ⇒ 2. レンダリング ⇒ 3. インデックス 静的な
ページのダウンロード時間が1000ミリ秒を超えると、Googlebotがクロールに制限をかける可能性あり
[レベル: 上級] Googlebot がページをクロールするときにかかるダウンロード時間が 1,000 ミリ秒を超えると、クロールに支障をきたすかもしれません。 一応の目安として、100 〜 500 ミリ秒以内を考慮しておくとよさそうです。 ページのダウンロード時間は 100 〜 500 ミリ秒が理想、1,000 ミリ秒は遅すぎ （旧）Search Console のクロールの統計情報レポートでは、ページのダウンロード時間の情報を確認することができます。 ページのダウンロード時間は、Googlebot がリソースを純粋にリクエストするのにかかった時間を示すデータです。 PageSpeed Insights のようにユーザーが使うブラウザの表示にかかる時間ではありません。 リソースは、HTML のほか画像や CSS、JavaScript、PDF なども含みます。 ダウンロード時間の目安に関
モバイル向けページの画像にはalt属性を必ず設定すること。MFIへの切り替えで検索順位に悪影響が出る可能性あり
[レベル: 初〜中級] 導入時期が依然として不透明なモバイル ファースト インデックスですが、導入に備えて確実に必要になる対処がいくつかあります。 そのうちの1つが alt 属性です。 モバイル向けページで alt 属性 をもし省略しているなら、今すぐにでも設定する必要があります。 ひとたびモバイル ファースト インデックスへの切り替えが実行されれば、検索結果、特に画像検索結果に悪い影響が出るかもしれません。 alt 属性を設定していなモバイルサイトが多い モバイルサイトでの alt 属性の状況について、Google の John Mueller（ジョン・ミューラー）氏は英語版のオフィスアワーで 次のように注意を促しました。 alt 属性に関してモバイルファーストインデックス チームから特によく聞くのは、alt 属性を画像に設定していないサイトがたくさんあるということだ。 alt 属性がな
モバイルファーストインデックスについてGoogleに何でも聞いてみた #inhouseseo ―― 内部リンクの評価は? 導入時期は? 分割数が異なるページネーションは? など
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向けページと同じリンクをモバイル向け
4人のGoogle社員にSEOについてなんでも聞いてみた at #GoogleDanceTokyo
[レベル: 初・中・上級] スイスGoogleのGary Illyes（ゲイリー・イェーシュ）氏が訪日しているのに合わせて、Google Dance Tokyoというイベントが、Google東京オフィスで5月25日に開催されました。 この記事では、このイベントで行われたQ&Aセッションの内容を紹介します。 僕たちウェブマスターからのSEOに関するさまざま質問に4人のGoogle社員が本音で答えてくれました。 Google社員との SEO Q&A まとめ Q. 検索結果のランキングにおいて今後Googleが重視していこうと考えていることは何か？ A. まず品質評価ガイドラインを見ることから始めてほしい。これを読めば、Googleが何を重視しているかがわかるし、ユーザーが何を探しているかがわかる。基本的にはコンテンツの質を見ている。 最も適切な結果を検索ユーザーに返すことがGoogleの目的。
Googleがウェブマスター向けガイドラインを大幅改定 ―― いったい何が変わったのか？
[レベル: 初・中・上級] Googleは、ウェブマスター向けガイドラインを大幅に改定しました。 この記事では、主だった変更点を抽出して解説します。 認識しておきたい変更点が数多くあります。 新しいウェブマスター向けガイドラインの主だった変更点 セクション分け 以前は、次の3つのセクションに大きく分かれていました。 デザインとコンテンツに関するガイドライン 技術に関するガイドライン 品質に関するガイドライン 現在は、2つに分かれています。 一般的なガイドライン 品質に関するガイドライン 内容が減ったわけではなく、「デザインとコンテンツに関するガイドライン」と「技術に関するガイドライン」の2つが、「一般的なガイドライン」にまとめられた感じになっています。 「一般的なガイドライン」はさらに次の3つのサブセクションに分かれています。 Google がページを検出できるよう手助けする Google
Google、アプリダウンロードのインタースティシャルを設置しているページはモバイルフレンドリーとみなさないことを決定。モバイル検索で順位ダウンも
[レベル: すべて] Googleは、モバイル検索結果から移動したときにアプリのダウンロードを促すインタースティシャルがページの大部分を占めている場合、そのページをモバイルフレンドリーではないとみなすことを発表しました。 僕たちがよく知るように、インタースティシャルの利用に対して以前からGoogleは否定的でした。 11月1日からランキング要因に 検索結果から移動したページの大部分がアプリのインタースティシャルで覆われていると「モバイルフレンドリーではない」とみなされ、11月1日からはモバイル検索での評価が下がることがあります。 つまり、モバイルフレンドリーアルゴリズムのネガティブ要因にインタースティシャルが追加されます。 下のキャプチャは、公式アナウンスでGoogleが示した悪いインタースティシャルと良いインタースティシャルのイメージです。 左のインタースティシャルは悪い例で、スクリーン
Google、8/14にインタースティシャルをモバイルユーザービリティのエラー項目に追加か？
[レベル: 中級] 全画面のインタースティシャル広告が、Search Consoleのモバイルユーザービリティ レポートのエラー対象に近いうちに追加されるかもしれません。 モバイルユーザービリティ レポートは、モバイル向けページで発生しているユーザビリティを低下させる問題を指摘するレポートです。 次の6種類のエラーを現在は通知します。 Flash が使用されています ビューポートが設定されていません 固定幅のビューポート コンテンツのサイズがビューポートに対応していません フォントサイズが小です タップ要素同士が近すぎます 7つ目のエラーとして、全画面インタースティシャルの追加がSearch Consoleのヘルプ記事に掲載されていました。 ただし現在は取り下げられています。 8月14日にインタースティシャルをレポート項目に追加 Search Consoleに発生したデータ異常を通知するヘ
低品質ページを大量生産しても検索エンジンの評価は上がらない、高品質コンテンツだけを作る
[レベル: 初〜中級] たとえば、自動生成でページ数を大量に増やしてもすべてのページがインデックスされることはないし、検索エンジンの評価は上がりません。 コンテンツの品質が高いページだけを作り、反対に、品質が低いページを減らすことが重要です。 ヘルプフォーラムでのQ&A 次のような内容の質問がGoogleのウェブマスター向け公式ヘルプフォーラムに投稿されました。 160万ページ以上あるのに、site:で調べると120万ページしかインデックスされていない。 Search Consoleでも120万だ。 どうしたら全ページをインデックスさせられるか？ ミューラー氏からのアドバイスはこうでした。 On the one hand, the site:-query results weren’t meant to be used as a metric — they’re a very rough
AjaxクロールのガイドラインのサポートをGoogleがまもなく終了予定
[レベル: 上級] Ajaxで生成されたコンテンツを確実にクロール、インデックスするためのガイドラインをGoogleは公開しています。 このガイドラインで推奨している構成のサポートをGoogleは近いうちに終了するとのことです。 先日、米サンノゼで開催されたSMX WestでGoogleのGary Illyes（ゲイリー・イリーズ）氏が明らかにしました。 GooglebotにAjaxをクロールさせるための構成 AjaxコンテンツをGooglebotにクロール、インデックスさせるには、”#!“や”?_escaped_fragment_=“、”HTMLスナップショット“などの独特な仕様に従う必要があります。 Googleが推奨するこの構成のサポートを近々終了するらしいのです。 サポート終了の詳細は不明 ガイドラインのサポートを打ち切ることとその後はどうすればいいのかなど、詳しいことは早ければ”
タブや展開ボタンにコンテンツを隠してもモバイルサイトならSEO的に問題なし
[対象: 中級] タブ切り替えや展開ボタン、展開リンクなどによって、重要なコンテンツを初期状態で非表示にしておくデザインをGoogleは推奨していません。 しかしこれはPCサイトにいえることです。 モバイルサイトではコンテンツを隠しても通常は問題ありません。 GoogleのJohn Mueller（ジョン・ミューラー）氏が明確にしてくれました。 PC向けページをGoogleは評価対象にする 12月24日に開催された、英語版のウェブマスター向けオフィスアワーでミューラー氏は次のように説明しました。 私たちはPC版を見ている。PC向けとモバイル向けが別々のページで、互いを結びつけているならPC向けが正規化されたほうだから、PC向けページを私たちは見ることになるだろう。 そしてPC向けページをインデックスする。 だから、PC向けで見えるのであればそのままにしておいても構わないだろう。モバイル向け
[続報] 重要なコンテンツならタブや展開ボタンで隠さないほうがいい
[対象: 中級] 展開ボタンやタブを利用したデザインで、標準状態では表示されないコンテンツをGoogleは検索結果の対象にしないかもしれないことを昨日の記事で取りげました。 もう少し詳しい内容を、その次のオフィスアワーでJohn Mueller（ジョン・ミューラー）氏が説明していました。 そのコンテンツが重要なら隠さないほうがいい 一般的に言えば、もしそのコンテンツが本当に見えなかったとしたら、そのコンテンツを重視することに意味があるかどうかを言うのは私たちには難しいということだ。それ（隠されているコンテンツ）が、動画だろうがリンクだろうが画像だろうが関係ない。 基本的にはずっと前からやってきたことだ。 本当に重要で関連性があるコンテンツなら、必ず実際に見えているようにしたほうがいい。 「隠れているんだったら、ユーザーにとっては本当はそんなに大切なことではないんじゃないか？ だったら重要視
XMLサイトマップとRSSフィードの両方を送信することをGoogleが公式に推奨
[対象: 中級] 新しいページや更新したページを含めサイト内のすべてのページのクロールを促進するために、XMLサイトマップとRSS・Atomフィードの両方を送信することを、英語版ウェブマスター向け公式ブログでGoogleは推奨しました。 有用性の高い情報なので、早ければ今日にも、日本語版の公式ブログで翻訳記事が公開されるだろうと予測します。 したがってこの記事では、若干の補足を加えつつも要点を簡潔にまとめて解説します。 XMLサイトマップとフィードの違い まずXMLサイトマップとフィードの違いと特徴を知りましょう。 一般的には、単にサイトマップと呼ぶことが多いですね。 普段僕たちがウェブマスターツール（またはrobots.txtのAuto Discovery）で送信する検索エンジン向けのサイトマップです。 サイトマップには通常、Googleにクロール・インデックスさせたいURLをすべて記述
Google、検索結果での著者情報の写真とフォロワー数の表示を中止
[対象: 中級] Googleは、写真とGoogle+のフォロワーの数を検索結果での著者情報に表示することをやめました。 John Mueller（ジョン・ミューラー）氏が、今朝Google+で発表しました。 英語版のヘルプはすでに情報を更新していて写真なしの例を見せています。 この記事を書いている時点では日本語版のヘルプはまだ更新されておらず、写真付きの例を見せています。 でも近いうちに更新されるでしょう。 写真の表示をやめた理由 写真とフォロワー数の表示をやめたおおもとの理由は次の2つです。 モバイル体験を向上させるため モバイルとPCで統一感があるデザインを提供するため これらの目的を達成する施策の一環として、検索結果をシンプルにするために写真とGoogle+のフォロワー数の表示を廃止しました。 すでに写真とフォロワー数の表示が消滅 すでに写真とフォロワー数が著者情報から消えているこ
SEOのために、商品名やカテゴリ階層をURLに入れる必要はない
[対象: 上級] SEOの効果を期待して、商品やサービスの名前、あるいはジャンルや地域などそれらのアイテムが含まれるカテゴリを必ずしもURLに含める必要はありません。 またキーワードをURLに含める必要もありません。 検索エンジンのためには不要 確かに、検索エンジンはURLをヒントにして、そのページのトピックが何であるかやサイトの構造がどうなっているかを知ろうとしているかもしれません。 しかしそれは副次的なものであり、それ単体で強い影響力を持つものではありません。 コンテンツや内部リンクなど他のシグナルによって理解させることができているのであれば、URLの構成がアドバンテージになることはないのです。 GoogleのJohn Mueller（ジョン・ミューラー）氏による、これを証明する、発言のいくつかを挙げます。 From our (Google’s) point of view, you
つぎはぎしたコンテンツだけのまとめサイトはGoogleで上位表示できるのか
[対象: 全員] 外部のサイトから少しずつコンテンツを引用し、それらを1つにまとめただけのコンテンツを作ることは良いことではない。 GoogleのMatt Cutts（Matt Cutts）氏はウェブマスターツール向けQ&Aビデオで上のように答えました。 まとめコンテンツに対するGoogleの見解 質問は以下のとおりです。 コンテンツの一部をいろいろなサイトから少しだけコピーして単にそれらをすべてまとめて自分で記事を作ったとしても、Google検索で上位表示できるか？ もちろん引用元のソースは明記してURLにリンクもする。 Matt Cutts氏の回答は以下のとおりです。 Yahoo!は、こうしたやり方を特に嫌っていたものだ。「つぎはぎ (stitching)」と呼んでいた。ある記事から2、3行引用し、別の記事から2、3行引用し、また別の記事から2、3行引用する。実際にスパムとしてみなして
削除したページを単一のページにまとめて301リダイレクトするとソフト404になる
[対象: 中級] 削除したページをいくつも1つのページに301リダイレクトすると、ソフト404としてGoogleには認識されることがあるようです。 複数の古いページを1つのページにまとめてリダイレクトしない 英語版のGoogleウェブマスター向け公式フォーラムで、Google社員のJohn Mueller（ジョン・ミューラー）氏が次のようにコメントしています。 古いページたちを単一のページにリダイレクトすると、ソフト404としてみなされる。これは基本的には、私たちのアルゴリズムにおいては404、「ページが見つかりませんでした」と同じように扱われる。 一般的には、（なくなったURLに対しては）エラーだとはっきりわかるページを使い、404のHTTPステータスコードを返すことが推奨される解決策になる。 内容が古くなったり削除したりしたページをすべてトップページに301リダイレクトすることは、ソフ
事前レンダリングでウェブページの表示時間を高速化
[対象: 上級] 事前レンダリングと呼ぶ技術を使って、ウェブページの表示時間を高速化する方法をこの記事では解説します。 事前レンダリングとは 事前レンダリング (Prerendering)とは、その名のとおり、ページの読み込み（正確にはレンダリング）を前もって実行する仕組みです。 Google検索で採用されている「インスタントページ」には事前レンダリングが使われています。 下のキャプチャは、Googleで「Amazon」を検索したときのChromeのタスクの状況をタスクマネージャで確認したものです。 「事前レンダリング」でAmazon.co.jpが出ています。 「Amazon」で検索したユーザーはかなり高い確率で（1位に出てきた）Amazonのホームページをクリックするはずです。 Chromeは先回りして、ユーザーがクリックしなくてもAmazonのホームページを取得および描画、つまりレンダ
Above the foldのコンテンツを1秒以内に高速表示させるための3つのテクニック
[対象: 上級] モバイルサイトにおいては、モバイルユーザーのユーザーエクスペリエンスを高めるためにスクロールせずに最初に見える、いわゆるAbove the foldのコンテンツを1秒未満で表示することをGoogleは推奨しています。 そこでこの記事では、feedthebotが解説しているAbove the foldのコンテンツ表示のスピードアップに役立つ3つのテクニックを紹介します。 1. Above the foldのHTMLをそれ以外と分割する サイドバーを含むAbove the foldで表示されるのコンテンツのHTMLコードを先に記述します。 ここでのポイントは、Above the foldのエリアとそれより下のエリア (Below the fold) の2つに分けるという点です。 メインコンテンツだけではなくAbove the foldで表示する部分のサイドバーのコードも残りと
GoogleアラートにRSSフィード配信がひっそりと復活
[対象: 全員] Googleアラートの配信先にRSSフィードを再び選択できるようになりました。 2ヶ月前にGoogleリーダーが廃止された影響を受けて、Googleアラートのフィード配信は提供を中止していました。 ところがひっそりと復活していました。 Googleからのアナウンスは特別には出ていないようです。 ユーザーからの要望が多かったのかもしれませんね。 Googleリーダーを廃止したからといって、Googleアラートのフィード配信まで併せて廃止しなくてもいいだろうにとは僕も感じました。 メールでも用は足りるかとも思いましたが、RSSリーダーを使っている身にとってはフィード配信があったほうがありがたいですね。 ひっそりと登録しなおしました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
