JavaScript SEOの基本を解説するドキュメントをGoogleが公開
[レベル: 上級] JavaScript を多用するウェブサイトの SEO のために必要な基本知識を解説するドキュメントを Google はデベロッパーサイトで公開しました。 ドキュメントに書かれている内容をざっくり紹介します。 Googlebot が JavaScript を処理するプロセス Googlebot による JavaScript の処理は次の 3 つのプロセスに大きく分かれます。 Crawling（クローリング） Rendering（レンダリング） Indexing（インデックシング） 2 番目のレンダリングが、静的な HTML ドキュメントにはないプロセスになります。 レンダリングが完了して初めて最終的なコンテンツがインデックシング プロセスに渡されます。 クローリングもレンダリングも、すぐ実行されるとは限りません。 “キュー” に保存され順番に処理されます（なので、レンダ
モバイルウェブのスピードアップに不可欠なのは 画像・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（パフォーマンス バジェット）
安全性を示すHTTPSのラベルとアイコンがGoogle Chrome 69から削除、一方で非HTTPSページでは赤色反転で危険性を強調
[レベル: 中級] セキュリティに関する Chrome ブラウザの UI 変更を Google はアナウンスしました。 HTTPS および HTTP ページのインジケータが将来のバージョンの Chrome で変わります。 鍵アイコンと「保護された通信」ラベルの削除 HTTPS で配信されるページに対して表示されるラベルとアイコンが削除されます。 現在は、HTTPS ページにアクセスしていると鍵アイコン🔒と「保護された通信」ラベルがアドレスバーの先頭に表示されます。 2018年9月にリリースされる Chrome 69 ではラベル表示がなくなり、鍵アイコンだけになります。 「https://」のスキームもなくなります。 最終的には鍵アイコンも表示しなくなる予定とのことです。 HTTPS 通信であることがわからなくなりますが、セキュリティが守られていることがウェブでは当たり前だとユーザーは想定
読み込み速度改善が売上に与える影響と競合とのスピードを比較するツールをGoogleが公開
[レベル: 中級] ページの読み込み速度に関係するデータを計測するツールを Google は新たに2つ公開しました。 1つは Speed Scorecard（スピード スコアカード）、もう1つは Impact Calculator（インパクト カリキュレータ）です。 どちらも同じページで利用できます。 Speed Scorecard Speed Scorecard は他のサイトとのスピードを比較できるツールです（1つのサイトの計測ももちろん可能）。 日本を含む12か国でのスピードと、3G/4G を選択して計測できます。 Amazon と楽天市場、メルカリのスピードを比べてみました。 右上にあるオプションで国と 3G/4G を選択できます。 スピードはリアルタイムの計測ではありません。 Chrome User Experience Report のデータに基づいています。 実際の Chrom
遂に来た！通信が安全ではないことを示す警告をすべての非HTTPSページにGoogle Chromeが常に表示。2018年7月リリースのバージョン68から
[レベル: 初〜中級] HTTPS ではなく HTTP で配信されているすべてのページに対して、通信が安全ではないことを通知するラベルを Chrome ブラウザで常に表示することを Google はアナウンスしました。 2018年7月にリリースされる Chrome 68 から実装する予定です。 全 HTTP ページに「保護されていない通信」ラベルを常時表示 HTTPS で配信していないページ、言い換えれば、HTTP のままで配信しているページには「保護されていない通信」のラベルが URL アドレス欄の先頭に表示されます。 たとえば、今でも HTTP で頑張っている東京都の公式ホームページは、この記事を書いている時点での最新版の Chrome（安定版）のバージョン 64 では、次のように表示されます。 と言っても、気になるところは何もありませんが。 これが、2018年7月にリリースされる C
iOS がプログレッシブ ウェブ アプリをサポートする可能性が浮上
[レベル: 上級] iOS で、PWA (プログレッシブ ウェブ アプリ）がサポートされる可能性が出てきました。 Service Worker が In Development に WebKit Bugzilla で Service Worker の ステータス が開発中を意味する「In development」になっていることを Marco Pöhler 氏が発見しました ※WebKit Bugzilla は Safari ブラウザで使われている HTML レンダリングエンジンである WebKit の不具合や修正を管理するサイト Apple のエバンジェリストが認める ステータスが「In development」になっていることについてコメントを求められた Apple のウェブ テクノロジー エバンジェリストである Jonathan Davis 氏は、開発への取り組みが始まっていること
Google、構造化データテストツールをバージョンアップ。ショートカットキー・オートコンプリート機能を追加
[レベル: 中級] Googleは、構造化データテストツールをバージョンアップしました。 基本的な性能は変わらないものの、いくつかの改良点があります。 新しい構造化テストツールの改良点 新しい構造化テストツールの主な変更点を見てみます。 URLの変更 まず、URLが変わりました。 以前 ― https://developers.google.com/structured-data/testing-tool/ 現在 ― https://search.google.com/structured-data/testing-tool/ 古いURLにアクセスしても新しいURLにリダイレクトされますが、ブックマークしている人は更新しておきましょう。 UIの変更 ツールにアクセスすると、最初に気付くのはユーザーインターフェイスの変更です。 以前のバージョンの初期画面こんなふうでした。 新しいバージョンの
モバイル向けページの画像にはalt属性を必ず設定すること。MFIへの切り替えで検索順位に悪影響が出る可能性あり
[レベル: 初〜中級] 導入時期が依然として不透明なモバイル ファースト インデックスですが、導入に備えて確実に必要になる対処がいくつかあります。 そのうちの1つが alt 属性です。 モバイル向けページで alt 属性 をもし省略しているなら、今すぐにでも設定する必要があります。 ひとたびモバイル ファースト インデックスへの切り替えが実行されれば、検索結果、特に画像検索結果に悪い影響が出るかもしれません。 alt 属性を設定していなモバイルサイトが多い モバイルサイトでの alt 属性の状況について、Google の John Mueller（ジョン・ミューラー）氏は英語版のオフィスアワーで 次のように注意を促しました。 alt 属性に関してモバイルファーストインデックス チームから特によく聞くのは、alt 属性を画像に設定していないサイトがたくさんあるということだ。 alt 属性がな
仮称「Google Posts」がGoogleマイビジネスの「投稿」機能として正式公開
[レベル: 中級] “Google Posts” と呼んで、このブログで紹介していた機能が正式に公開されました。 Google マイビジネスの新機能として、すべてのローカルビジネスオーナーが利用できるようになっています。 ヘルプ記事ができあがっていたので間もだろうと予想していたところ、その通りになりました。 Google Small Business ブログで公式アナウンスが出ており、日本語版の AdWords 公式ブログでは翻訳記事を読むことができます。 Google に「投稿」 Google Posts と勝手に呼んでいましたが、特別な名称は付けられていません。 単純に「投稿」という名前の機能で提供されています。 Google マイビジネスのダッシュボードまたはモバイルアプリ(Android & iOS) で投稿できます。 こちらは、Google マイビジネスに PC からアクセスした
Google モバイルファーストインデックスの年内導入は困難、早くても2018年にずれ込むことが確実
[レベル: 中級] Google が準備を進めているモバイル ファースト インデックス（以下、MFI）は、年内の導入は難しそうです。 早くても来年、つまり 2018 年にずれ込むことが確実な情勢です。 MFI導入は早く2018年、実施日は未定 probably many quarters away （MFI の導入は）おそらく数四半期先になりそうだ。 米シアトルで今週開催されている SMX Advanced 2017 のモバイル ファースト インデックスをテーマにしてセッションのなかで Google の Gary Illyes（ゲイリー・イリェーシュ）氏はこのように発言したとのことです。 “quarters” は「四半期」を意味します。 今は6月で、第2四半期が終わりに近づいています。 残りの四半期は、第3（7〜9月）と第4（10〜12月）の2つです。 四半期が“many”（たくさん）なの
Google、ウザい広告はChromeで表示しなくなることを決定。広告に関する問題のレポートをSearch Consoleで公開
[レベル: 初・中・上級] ユーザー体験を損ねる広告を掲載しているサイトに対して、Chrome ブラウザでは広告を一切表示しなくなるようにすることを Google は発表しました。 これにあわせて、サイトに掲載している広告に問題があるかどうかを調べるツールの提供を始めました。 背景 Google が、こうした決定を今回下した背景の1つに、ユーザー体験を損ねる広告の増加が挙げられます。 いきなり大きな音楽で再生が始まる広告や記事を見る前に強制的に見せつけられる広告のような不愉快な広告は誰しもが体験したことがあるはずです。 広告そのものは悪いものではなく、健全な経済活動です。 広告閲覧者と広告発行者の双方にとってより良いオンライン広告を提供するために Coalition for Better Ads という団体が組織されています。 Coalition for Better Ads は消費者に受
AMP Start、レスポンシブウェブデザインのAMPサイトを簡単に構築できるテンプレートを公開
[レベル: 中級] AMP プロジェクトは、AMP HTML で構成したウェブサイトを簡単に作成するためのテンプレートの提供を始めました。 AMP Start という名称のサイトで公開しています。 まずは2種類のテンプレートを配布 AMP Start で公開されているテンプレートを使えば、AMP に対応したサイトをゼロから構築する必要はありません。 テンプレートはデザイン的に洗練されており、たいていのサイトに必要な要素を備えています。 現在公開されているテンプレートは、次の2種類です。 記事用 ブログ用 記事もブログも大差ないように思いますが、ナビゲーションメニューやソーシャルボタンなどの要素に多少の違いがあります。 “COMING SOON”とあるので、もう1種類のテンプレートが近々公開されると思われます。 RWD + AMP HTML どちらのテンプレートも、レスポンシブ ウェブ デザ
Google、リッチスニペットよりもビジュアルなリッチカードをグローバル展開。レシピ、レストラン、映画が対象
[レベル: 中〜上級] リッチカードが、世界中の Google モバイル検索で利用可能になりました。 日本でも利用できます。 リッチカードは、従来のリッチスニペットよりも視覚に訴える効果が高くなっているのが特徴です。 2016年5月に米 Google (google.com) で公開されました。 レシピと映画、飲食店のリッチカードをサポート 次の3つのジャンルでリッチカードがサポートされています。 レシピ 映画 飲食店 こちらは、レシピのリッチカードです。 そのサイト専用 (host-specific) のカルーセルとして掲載されるのもリッチカードの特徴です。 上で見たチキンカレーのレシピは、楽天レシピだけのリッチカード カルーセルになっています。 こちらは、飲食店のリッチカードです。 食べログ専用のカルーセルになっています。 米 Google ではホテルもリッチカードカルーセルに掲載され
ECサイト初のAMP成功事例？ AMP対応したインドのショッピングサイトは1日の注文が52%増加、一覧ページのトラフィックが59%増加
[レベル: 上級] 3月7〜8日に米ニュヨークで Google が主催している AMP Conf 2017 で、AMP 対応した EC サイトの成功事例が紹介されました。 eBay や Namshi のように AMP 対応した EC サイトがいくつかありますが、AMP 対応したことが良い結果に繋がったのかどうかの事例は、僕は今までに聞いたことがありません。 Snapdealは、オーダーが52%↑、一覧ページのトラフィックが59%↑ EC サイトの AMP 成功事例として紹介されたのは、インドのショッピングサイト、Snapdeal（スナップディール） です。 Snapdealは、PCやスマホ、家電、ファッション、キッチン用品などさまざまな製品を販売する総合オンラインショッピングサイトです。 Amazonみたいなものですね（Amazonは出店もできますが）。 Snapdeal は、商品一覧ペー
301リダイレクトと302リダイレクトの違い
301リダイレクトは、”Permanent Redirect”で「恒久的な転送」、一方、302リダイレクトは、”Temporary Redirect”で「一時的な転送」を表します。 恒久的？、一時的？ 分かるようでよく分からない表現です。 サーチエンジンの取り扱い方に違いが出てくるのですが、たとえばSERPでの表示（インデックスの仕方）が異なってきます。 以前、GoogleのWebmaster Centralチームで働いていたVanessa Foxさんがパーソナルブログで、301リダイレクトと302リダイレクトのケーススタディを記事投稿しているので、見てみましょう。 彼女は、「www.vanessafoxnude.com」というドメインで「Vanessa Fox Nude」というサイトを運用していました。 しかし数ヶ月前に「www.nineblue.com」というドメインの「Nine By
モバイルファーストインデックスについて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向けページと同じリンクをモバイル向け
Chrome 56 と Firefox 51 が非HTTPSでパスワードを収集するページに警告表示
[レベル: 中級] 非HTTPS、言い換えるとHTTPで、パスワードを送信するページにGoogle Chrome 56 と Firefox 51 では警告が出るようになりました。 Chromeでは、クレジッドカード情報を非HTTPSで送信するページも警告の対象になります。 GoogleもMozillaも事前にアナウンスしていた仕様変更を遂に実施しました。 より安全なウェブを目指して – Google Developers Japan Communicating the Dangers of Non-Secure HTTP – Mozilla Security Blog Search Consoleに届くセキュリティ警告 パスワードやクレジッドカード情報をHTTPで送信するページが存在しているサイトには、セキュリティ警告がSearch Consoleに届くことがあります。 http://ww
AMP CDNのキャッシュURL構成をGoogleが更新、専用のサブドメインを各サイトに割り当て
[レベル: 上級] Googleは、AMPキャッシュのURL構成を近いうちに更新することを開発者向けブログでアナウンスしました。 セキュリティを高めることが狙いです。 一部のサイトを除く、ほとんどのサイトでは特別な対応は不要です。 AMP CDNドメインのサブドメインを各サイトに割り当て 今後は、Googleが提供するAMP CDNが使用しているドメイン名のサブドメインが、各サイトに割り当てられます。 たとえば現状では、この記事のAMPキャッシュURLは次のようになります。 https://cdn.ampproject.org/c/s/www.suzukikenichi.com/blog/google-updates-url-scheme-for-amp-cache/amp/ 今後は、僕のブログ専用のサブドメインが割り当てられ、次のように変わります。 https://www-suzukik
WordPressのプラグインでブログをAMP対応にしてみた
[レベル: 上級] この記事では、WordPressをAMP対応させるプラグインについて解説します。 AMPプラグインを使えば、WordPressで構築したサイトをいとも簡単にAMP化できます。 しかし初期ステージでのバージョンの公開のため機能が不完全です。 今すぐに利用する必要はまったくありません。 AMPにものすごく興味があったりSearch Consoleに実装予定のAMP機能のベータテストに参加したかったりする場合のみ、試してみるとよさそうです。 WordPressのAMPプラグインの設定方法や仕上がり WordPressのAMPプラグインのインストールや設定の方法、仕上がりをここから説明します。 インストール WordPressのプラグインサイトにあるAMPプラグインのページからファイルをダウンロードし、 /wp-content/plugins/ ディレクトリにアップロードします
ブログの完全HTTPS化を完了、HTTPからHTTPSへの移行プロセスを共有
[対象: 上級] 気付いている人もいるかと思いますが、このブログ全体をHTTPSにしました。 この記事では、備忘録を兼ねて、完全HTTPSへの移行を検討しているサイトの参考になるように僕が実行してきたプロセスをまとめます。 実行した主な作業は次のとおりです。 サーバー証明書の取得 HTTPSへのリダイレクト 内部リンクの修正 各種ツール・パーツのHTTPS動作確認 すべてのコンテンツがHTTPSでダウンロードされているかを確認 WordPressの設定変更 rel=”canonical”の更新 ウェブマスターツールへの登録 サイトマップの更新 ソーシャルシェアの引き継ぎ HSTSの設定 外部リンクの更新 高速化 順に説明します。 1. サーバー証明書の取得 サーバー証明書をまず取得します。 手順は利用しているサーバー会社によって変わってきます。 詳しくはお使いのサーバー会社のヘルプを参照し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
