【JavaScript SEO】サーバーサイドでレンダリングすべき要素: メインコンテンツ、構造化データ、titleタグ、hreflangほか
[レベル: 上級] DeepCrawl が主催したウェビナーで Google の Martin Splitt（マーティン・スプリット）氏が、JavaScript サイトの SEO に関するさまざまな質問に回答しました。 このなかで、サーバーサイドでレンダリングすべき要素、言い換えると、JavaScript を介してレンダリングさせるべきではない要素をスプリット氏は挙げました。 スプリット氏によると、SEO を考慮するのであれば、次の要素はサーバーサイドでレンダリングしてからクライアント（ユーザーと Googlebot）に配信したほうがいいとのことです。 メインコンテンツ 構造化データ title タグ meta description hreflang 日付に関する記述 メインコンテンツは、ページの評価において最も重要です。 現在の WRS（ウェブ レンダリング サービス）が、古い Chr
モバイルウェブのスピードアップに不可欠なのは 画像・JS・フォント の最適化 #ChromeDevSummit
[レベル: 中級] 昨日とおとといに続いて、今日も Chrome Dev Summit 2018 のセッションレポートをお届けします。 セッションのタイトルは “Speed Essentials: Key Techniques for Fast Websites” です。 昨日レポートしたセッションと同じようにモバイルウェブの高速化がテーマです。 しかし、こちらはより実践的な内容になっています。 パフォーマンス改善に非常に役立つテクニックが満載です。 パフォーマンス改善の優先対象は画像とJS、フォントの3つ モバイルウェブで 1 ページあたりデータ量が多いリソースは次の順番（HTTP Archive 調べ） 画像 (約 500 KB) JavaScript (約 380 KB) フォント (約 80 KB) この 3 つは Performance Budget（パフォーマンス バジェット）
ページのダウンロード時間が1000ミリ秒を超えると、Googlebotがクロールに制限をかける可能性あり
[レベル: 上級] Googlebot がページをクロールするときにかかるダウンロード時間が 1,000 ミリ秒を超えると、クロールに支障をきたすかもしれません。 一応の目安として、100 〜 500 ミリ秒以内を考慮しておくとよさそうです。 ページのダウンロード時間は 100 〜 500 ミリ秒が理想、1,000 ミリ秒は遅すぎ （旧）Search Console のクロールの統計情報レポートでは、ページのダウンロード時間の情報を確認することができます。 ページのダウンロード時間は、Googlebot がリソースを純粋にリクエストするのにかかった時間を示すデータです。 PageSpeed Insights のようにユーザーが使うブラウザの表示にかかる時間ではありません。 リソースは、HTML のほか画像や CSS、JavaScript、PDF なども含みます。 ダウンロード時間の目安に関
今月導入される 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
モバイル向けページの画像にはalt属性を必ず設定すること。MFIへの切り替えで検索順位に悪影響が出る可能性あり
[レベル: 初〜中級] 導入時期が依然として不透明なモバイル ファースト インデックスですが、導入に備えて確実に必要になる対処がいくつかあります。 そのうちの1つが alt 属性です。 モバイル向けページで alt 属性 をもし省略しているなら、今すぐにでも設定する必要があります。 ひとたびモバイル ファースト インデックスへの切り替えが実行されれば、検索結果、特に画像検索結果に悪い影響が出るかもしれません。 alt 属性を設定していなモバイルサイトが多い モバイルサイトでの alt 属性の状況について、Google の John Mueller（ジョン・ミューラー）氏は英語版のオフィスアワーで 次のように注意を促しました。 alt 属性に関してモバイルファーストインデックス チームから特によく聞くのは、alt 属性を画像に設定していないサイトがたくさんあるということだ。 alt 属性がな
Google、モバイルファーストインデックスの導入予定を正式発表。スマホ向けページを検索の評価対象に。SEOへの影響は？
[レベル: 中級] Googleは、Mobile First Index（モバイル ファースト インデックス）の導入を正式にアナウンスしました。 Mobile-first Indexing モバイル ファースト インデックスに向けて モバイル ファースト インデックスでは、PC向けページではなく、モバイル向けページの評価に主に基づいてランキングが決定されます。 Gary Illyes（ゲイリー・イリェーシュ）氏が米ラスベガスで10月に開催されたPubCon Las Vegas 2016で発表していたGoogle検索の仕様変更です。 正式な実施時期はまだ決まっていません。 今後数か月にわたり小規模な実験を行ったうえでの判断になるとのことです。 評価対象がPC向けページからモバイル向けページへ 詳細は公式アナウウンスを読んでいただくとして、概要としてはモバイル ファースト インデックス（以下、
スマホ対応が不要になる!? Google、通常のモバイル検索結果でスマホ向けページの代わりにAMPページを表示する実験を開始
[レベル: 中級] モバイル検索の通常の検索結果で、スマホ向けページに置き換えてAMPページを表示する実験をGoogleは開始しました。 これまでは、AMPに対応したページは「トップニュース」として、通常の検索結果とは別枠のカルーセル（またはリスト）の中に掲載されていました。 AMPページとスマホ対応ページが混在 通常の検索結果にAMPページが表示される実験用の検索ページには、g.co/ampdemo からアクセスできます（スマホでアクセスしてください）。 うまくいかない場合は、こちらからアクセスしてください。 トップニュース用のAMPカルーセルではなく通常の検索結果の中にAMPページが表示されます。 （僕たちにとっては）おなじみのAMPマークが付いているのですぐにわかります。 検索結果の上には、AMPを説明するためのメッセージが表示されていますね。 こちらは、AMPページとスマホ対応ペー
Google、「スマホ対応」をランキング要因に利用することを決定。4/21から導入。
[レベル: 初・中・上級] Googleは、スマホ対応しているかどうかをモバイル検索のランキング要因として使用することを発表しました。 4月21日からの導入を予定しています。 またApp Indexingに対応したアプリコンテンツもランキング要因として利用するようにしました。 こちらは今日（現地時間の2月26日）から導入されています。 モバイルフレンドリーが単なるラベル表示からランキング要因に 昨年11月に、そのページがスマートフォンに対応しているときに、「Mobile-friendly」（モバイル フレンドリー）というラベルをGoogleはモバイル検索結果に表示するようにしました。 日本には、翌月の12月に導入されました。 「スマホ対応」というラベルが付きます。 導入時点では、「スマホ対応」ラベルは単純に表示だけの仕様でした。 スマホ対応しているかどうかはランキング要因にはなっていません
Google、検索結果での著者情報の写真とフォロワー数の表示を中止
[対象: 中級] Googleは、写真とGoogle+のフォロワーの数を検索結果での著者情報に表示することをやめました。 John Mueller（ジョン・ミューラー）氏が、今朝Google+で発表しました。 英語版のヘルプはすでに情報を更新していて写真なしの例を見せています。 この記事を書いている時点では日本語版のヘルプはまだ更新されておらず、写真付きの例を見せています。 でも近いうちに更新されるでしょう。 写真の表示をやめた理由 写真とフォロワー数の表示をやめたおおもとの理由は次の2つです。 モバイル体験を向上させるため モバイルとPCで統一感があるデザインを提供するため これらの目的を達成する施策の一環として、検索結果をシンプルにするために写真とGoogle+のフォロワー数の表示を廃止しました。 すでに写真とフォロワー数の表示が消滅 すでに写真とフォロワー数が著者情報から消えているこ
Googleのマット・カッツがあんな質問、こんな質問、どんな質問にも答える at #SMX Advanced 2014
[対象: 全員] 6月11〜12日に米シアトルで開催されたSMX Advanced 2014に参加してきました。 この記事では、1日目の最後のセッション「You&A」をレポートします。 「You&A」」は、SMXの主催者代表、Danny Sallivan（ダニー・サリバン）氏と米GoogleのMatt Cutts（マット・カッツ）氏とのQ&Aトークです。 マットが新しい発表をしたり、ダニーがマットに鋭い質問をぶつけたりと、SMX Advancedは定番でもっとも人気があるセッションです。 最前列に陣取って2人のトークを目の前で聴いてきました。 そのときの模様をお伝えします。 マット・カッツに質問中のダニー・サリバン では行ってみましょう！ You&A at SMX Advanced 2014 Q&Aに先立ってマットからいくつか発表がありました。 重要そうなものを2つ紹介します。 Payda
Google、JavaScriptの処理能力を向上。ウェブマスターツールにJS診断ツールを提供予定。
[対象: 中〜上級] Googleは、JavaScriptを理解する能力を一段と向上させていることを公式ブログで紹介しました。 また、JavaScriptを診断するツールをウェブマスターツールで近日中に提供する予定です。 Image credit – http://goo.gl/XtM0UG JavaScriptの処理能力をさらに向上 Googleに限らず、検索エンジンはJavaScriptの理解、処理が得意ではありません。 それでもGoogleは、JavaScriptのリンクを読めるようになっているし、JavaScriptを実行することもできます。 しかし僕たちが使っているブラウザとまったく同じようにJavaScriptを完全に扱えるわけではありません。 そのためGoogleはJavaScriptの理解力の向上によりいっそう力を入れているのです。 GoogleのMatt Cutts（マッ
不必要に静的化したURLよりもパラメータ付きURLをGoogleは好む
[対象: 上級] 一般的に言って、Googleにとっては、擬似静的化したURLよりもパラメータが付いた動的なURLのほうが好ましいようです。 動的URLは書き換えずにパラメータを付けたままで GoogleのJohn Mueller（ジョン・ミューラー）氏が、あるSEO関連フォーラムで次のようにコメントしました。 Just wanted to add that from Google’s point of view, the clean, parameterized URL is generally preferred to any unnecessary URL-rewriting. If you want a nice-looking URL-line in search, use breadcrumb markup instead. Googleの観点から付け加えさせてもらうと、わかり
Google日本、いよいよSPYW (Search Plus Your World) を正式公開か？
[対象: 中級] Google日本 (google.co.jp) が、SPYW (Search Plus Your World)を正式に公開した可能性が濃厚です。 これまではテストを繰り返し実施していたものの、ごく短時間で消えることが普通でした。 しかし先週末頃から、常時、幅広い環境でSPYWを確認できています。 SPYWが適用されているかどうかは、検索結果右上にある「人」と「地球」マークのアイコンで識別できます（このあと見せるキャプチャで確認してください）。 僕が調べた限りでは、英Google (google.co.uk) や 豪Google (google.com.au) でもGoogleアカウントにログインした状態でSPYWが適用されていました。 3月末にIA Summitで米国に滞在してるときは、co.jpでも常にSPYWを利用できました。 一方で同じとき日本では、見えたり消えたり
Googleジョン・ミューラー、新しいサイトには「#!」のAjaxよりも「HTML5のHistory API/pushState」を推奨
[対象: 上級] GoogleのJohn Mueller（ジョン・ミューラー）氏は、Ajaxを利用する場合は、「example.com/#!/xyz」のように「#!」を使ってURLを構成するよりも、HTML5で採用されたHistory APIやpushStateの機能を使うことを勧めました。 「HTML5のpushState/replaceState」の使用を推奨 John Mueller氏は、SEO系のフォーラムに投稿された「#!」の使い方に関する2つの別々の質問に、次のようにアドバイスしました。 非難されるかもしれないのを承知で言うと、HTML5で新しいサイトを運用しているなら、HTML5のHistory APIを利用し通常のURLを使ってコンテンツを提供した方がいい。 ナビゲーションにはJSを使いブラウザのURLを変える、しかし最初の読み込みで静的なコンテンツを返す。 より新しい代替
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
