ダイナミックレンダリングは一時的な回避策、最終的にはSSRの実装を
[レベル: 上級] Dynamic Rendering（ダイナミック レンダリング）は、JavaScript で生成されるコンテンツを確実にインデックスさせるために利用できる仕組みです。 しかし、一時的な回避策としてみなしたほうがいいでしょう。 数年後には必要性が薄れているかもしれません。 最終的には、Server-side Rendering（サーバー サイド レンダリング）の実装が望まれます。 ダイナミックレンダリングよりも SSR JavaScript が関わってくるコンテンツのインデックスに特に問題を感じていないのであれば、Googlebot のレンダリング（正確には、Web Rendering Service）に任せて構いません。 特別な構成は不要です。 しかしながら、Googlebot が実行できない JavaScript を使っていたりインデックスされるまでに時間がかかりすぎ
JavaScript SEOの基本を解説するドキュメントをGoogleが公開
[レベル: 上級] JavaScript を多用するウェブサイトの SEO のために必要な基本知識を解説するドキュメントを Google はデベロッパーサイトで公開しました。 ドキュメントに書かれている内容をざっくり紹介します。 Googlebot が JavaScript を処理するプロセス Googlebot による JavaScript の処理は次の 3 つのプロセスに大きく分かれます。 Crawling（クローリング） Rendering（レンダリング） Indexing（インデックシング） 2 番目のレンダリングが、静的な HTML ドキュメントにはないプロセスになります。 レンダリングが完了して初めて最終的なコンテンツがインデックシング プロセスに渡されます。 クローリングもレンダリングも、すぐ実行されるとは限りません。 “キュー” に保存され順番に処理されます（なので、レンダ
SEOに役立つ、Googlebotのレンダリングを検証する4つの方法
[レベル: 上級] この記事では、Googlebot によるレンダリングを検証、デバッグする方法を4つ紹介します。 Googlebot ＝ Chrome 41 まず、前提知識として知っておかなければならないことは、Googlebot がレンダリングする仕組み (Web Rendering System、略して WRS と呼ぶ）は、Chrome 41 に相当するということです。 この記事を書いている時点では、Chrome の最新バージョンは 65 です。 現在利用されている ES6 の機能のごく一部しか Googlebot はサポートできていません。 たとえば、CSS カスタムプロパティや Strict mode、IndexedDB をサポートしていません。 Chrome 41 がリリースされたのは、2015年3月です。 つまり、SEO を意識するなら、3年前のブラウザに合わせなければならな
モバイルウェブのスピードアップに不可欠なのは 画像・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（パフォーマンス バジェット）
Google、SEOに適したLazyloadの仕様を公開
[レベル: 上級] SEO と相性がいい Lazyload の実装を解説するドキュメントを Google はデベロッパー向けサイトで公開しました。 3つのアドバイス ドキュメントには3つの指針が書かれています。 1. viewport 内で見えるようにする viewport 内にあるコンテンツは、必ず Google にも見えるようにしておきます（viewport は簡単に言えば、スクリーンに表示される領域）。 つまり、重要なコンテンツが viewport に入ったときは確実に読み込ませます。 IntersectionObserver API と polyfill を実装するように Google は指示しています。 2. 無限スクロールでは paginated loading を使う 無限スクロールを採用している場合は、paginated loading を実装します。 paginated
iOSのSafariでPWAがいよいよ動くようになった、iOS 11.3ベータ版がService Workerを本格的にサポート開始
[レベル: 上級] iOS の Safari で PWA (Progressive Web Apps: プログレッシブ ウェブ アプリ) がいよいよ稼働し始めました。 iOS 11.3 ベータ版に搭載の Safari 11.1 で PWA の一部機能が動く iOS が Service Worker をサポートする可能性が浮上したのが昨年の夏でした。 年末には開発版 Safari で Service Worker がデフォルトで有効になりました。 とはいえ、PWA の何らかの機能が実質的に動くようになったわけではありません。 しかしながら、iOS 11.3 ベータ版に搭載されている Safari 11.1 で PWA の一部機能がついに動くようになりました。 AppleのSafariのエンジニア、Ricky Mondello（リッキー・モンデッロ）氏が明らかにしています。 iOS 11.3
構造化データを設定する際に従うべきガイドラインをGoogleが公開
[レベル: 中級] 構造化データを利用する際に遵守すべきガイドラインを説明するページを Google は開発者向けサイトに公開しました。 既存の内容 +α ページ (URL) は新たに作られたようですが、中身も完全に新たに作られたわけではありません。 既存の内容の修正や追加、整理です。 冒頭では、構造化データを設定しても検索結果でその構造化データによる特殊機能が表示されない場合の原因を挙げています。 技術的なガイドラインとして7月に出されていたものですが、今回新たに作成された一般的なガイドラインページに移動しました。 構造化データを使用するとさまざまな機能を表示させることができますが、表示が保証されるとは必ずしも限りません。ユーザーにとって最適な検索体験だと考えるものを作成できるように Google のアルゴリズムは検索結果を調整します。これには、検索履歴や場所、デバイスの種類を含むさまざ
クリックしたときに作られるJavaScriptコンテンツはGoogleにインデックスされない
[レベル: 中級] JavaScriptによって動的に生成される展開型コンテンツをGoogleはインデックスしません。 GoogleのGary Illyes（ゲイリー・イリーズ）氏が、あらためて注意を喚起しました。 PSA: If you put contents in a javascript array and only expand them when you click e.g. "…", those contents won't be indexed by Google — Gary Illyes (@methode) 2015, 11月 4 公共サービス情報: JavaScript Arrayにコンテンツを格納していて、たとえば「…」をクリックしたときにだけそのコンテンツが展開するとしたら、そのコンテンツはGoogleにはインデックスされないだろう。 Googlebotはクリッ
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は公開しました。 これまでのものとは変更がない部分がある一方で、新たにモバイルに関する章が加わったことが最新版の最大の特徴となっています。 検索品質評価ガイドラインとは？ Googleは、ユーザーのクエリに対して関連性が高くかつ高品質なページを検索結果で返すことができているかどうかを、外部の評価者（Evaluator）に常に評価させています（評価者は普通に求人として募集されているらしい。日本でさえも）。 評価者による評価は検索品質の改善のために役立てられます。 直接的にランキングを調整するためには用いられません。 どのように検索結果の品質を評価するかを説明した「General Guidelines」（一般ガイドライン）というマニュアルが評価者に提供されます。 このマニュアルは原則的に評価者だけに配布されます
入力フォームの「必須」「任意」のラベルは両方付けないとコンバージョン率が下がる
[レベル: 初〜中級] 入力フォームのフィールドには、入力が「必須」なのかまたは「任意」なのかのラベルを両方付けることが推奨されます。 どちらか片方だけだと入力途中の離脱の原因になります。 ECサイトのユーザービリティ調査と最適化を専門に扱っているBaymard Instituteが詳しく解説しています。 15の大手ECサイトのユーザビリティ調査と18の主要なモバイルサイトのユーザビリティ調査、そして自社による最新の大規模なアイトラッキングテストによって実証することができました。 この記事では、その解説の要点をまとめて紹介します。 片方だけの「必須」「任意」ラベルの問題点 入力が「必須」か「任意」かをどちらか片方のラベルだけで示すことにはさまざまな問題点があります。 必須か任意かを示さないのはいちばんよくない そのフィールドの入力が必須か任意かを示さないのはいちばんよくないスタイルです。
ブログの完全HTTPS化を完了、HTTPからHTTPSへの移行プロセスを共有
[対象: 上級] 気付いている人もいるかと思いますが、このブログ全体をHTTPSにしました。 この記事では、備忘録を兼ねて、完全HTTPSへの移行を検討しているサイトの参考になるように僕が実行してきたプロセスをまとめます。 実行した主な作業は次のとおりです。 サーバー証明書の取得 HTTPSへのリダイレクト 内部リンクの修正 各種ツール・パーツのHTTPS動作確認 すべてのコンテンツがHTTPSでダウンロードされているかを確認 WordPressの設定変更 rel=”canonical”の更新 ウェブマスターツールへの登録 サイトマップの更新 ソーシャルシェアの引き継ぎ HSTSの設定 外部リンクの更新 高速化 順に説明します。 1. サーバー証明書の取得 サーバー証明書をまず取得します。 手順は利用しているサーバー会社によって変わってきます。 詳しくはお使いのサーバー会社のヘルプを参照し
モバイル検索結果の15%がディープリンク、App Indexing設定の4つのコツをGoogleが解説
[対象: 上級] Googleによると、App Indexingは着実に普及しているようです。 AndroidにおけるGoogle検索の15%がApp Indexingによるディープリンクを現在返す 直近の四半期ではディープリンクのクリックが10倍に急増した こうした流れを受けて、App Indexingを適切に実装するための4つのコツをGoogleは英語版ウェブマスター向け公式ブログで紹介しました。 アプリ開発者にウェブマスターツールへのアクセス権を与える 検索結果でのアプリの利用状況を理解する 確実に、アプリの重要なリソースがクロールされるようにする アプリのエラーを監視する 1. アプリ開発者にウェブマスターツールへのアクセス権を与える App Indexingに関して次の状況をウェブマスターツールでは現在チェックできます。 アプリ内のインデックスされているページのエラー Googl
schema.orgを使ってGoogleの検索結果にサイトリンク検索ボックスを表示させよう
[対象: 上級] Googleは、検索結果でのサイト内検索ボックスの表示方法と機能を改良しました。 オートコンプリートも利用可能です。 より目立つ表示に 検索結果に表示されたそのサイト内のページをさらにサイト内検索する検索ボックスは以前から一部のサイトを対象に提供されていました。 そのサイト内検索ボックスを上部に配置し、より目立つデザインにしたのが今回の改良です。 上は公式アナウンスで例として出されている“YouTube”の（モバイル検索の）検索結果です。 サイトリンクよりも上の位置に、大きめの虫眼鏡アイコンが付いたサイト内検索ボックスが表示されています（左）。 通常の検索のようにオートコンプリートで検索キーワードを提案してくれます（右）。 そのサイトのサイト内検索へリダイレクト 新しいサイト内検索ボックスで検索すると、そのサイト独自のサイト内検索の結果にリダイレクトされます。 従来のサイ
Googleの検索品質評価ガイドラインが大幅改定、高品質サイトに求められるのは「E-A-T」
[対象: 上級] Googleの「検索品質評価ガイドライン」が大幅に改定されました。 評価対象から削除された要素があるなかで、高品質なサイトやページに必要な要素としての「E-A-T」など新たな評価要素が加わっています。 検索品質評価ガイドラインとは Googleは検索結果の品質を外部の評価者に評価させています。 その際にマニュアルとして「検索品質評価ガイドライン（英語名: General Guidelines）」を配布します。 マニュアルのサンプルは、Google検索の仕組みを紹介するポータルサイトで一般公開されておりダウンロード可能です。 しかし一般公開されているこのガイドラインはごく一部で、（僕たちSEOを施策する人間にとって）肝心な部分が大幅にカットされています。 評価者が実際に利用していると思われる本物の品質評価ガイドラインは、これまでたびたび外部に流出してきました。 直近は201
複数のパンくずリストを1つのページに設置することはSEOにおいて問題ないか？
[対象: 中級] 複数のパンくずリストを1つのページに設置することは、検索エンジンの視点からは問題がないのでしょうか？ 僕からの質問（！）に、GoogleのMatt Cutts（マット・カッツ）氏が回答してくれました。 パンくずリストがある場合は、現状では1つ目を採用する。適切なカテゴリや階層構造に入れようとする。 でもそうは言っても、1つのアイテムが階層構造のなかで複数の区分に属しているなら、1つのページに複数のパンくずリストをおくのはありだ。そうしたほうがGooglebotがもうちょっとだけ適切にサイトを理解する手助けになる状況も実際にある。 でも1つで間に合うならそれで十分で、ほとんどの人がそうやっているし、それが普通のやり方だ。僕たちも、1つのパンくずリストを勧める。 だが、分類方法やカテゴリ、階層構造がすでに決まっていてサイトがそうなっていて、20個もの別々のカテゴリに入っている
世界で最も美しくSEOに適した無限スクロールを実装するサイト、QUARTZ (qz.com)
[対象: 上級] この記事では、非常に華麗な無限スクロールを実装しているサイトを紹介します。 美しく、見やすい、SEOも考慮できた QUARTZ の無限スクロール そのサイトは、ニュースメディアサイトの QUARTZ です。 「百聞は一見にしかず」で、実際に QUARTZ に訪問して見てください。 注目してほしいのはブラウザに表示されるURLです。 無限スクロールで下がっていくと、今あなたが見ている記事に対応したURLに自動的に切り替わります。 下方向だけでなく上に戻ればまたそれに対応してURLが変わります。 titleタグももちろん切り替わります。 個別のURLをブラウザのアドレスバーに入れれば、直接そのコンテンツを閲覧できます。 そして、そこから無限スクロールが始まります。 記事に与えられた個別のURLは、そのURLできちんとGoogleにインデックスされています。 Mozのランドもイ
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を変える、しかし最初の読み込みで静的なコンテンツを返す。 より新しい代替
スマートフォンのコンバージョン率を上げる秘策 from Conversion Conference Boston 2013
[対象: 中〜上級] 僕が所属するセルフデザイン・ホールディングスの海外遠征の一環で、昨年の秋に米ボストンで開催されたConversion Conference Boston 2013に参加しました。 僕が海外カンファレンスに参加したときはセッションレポートをこのブログで公開するのが通常です。 ところがConversion Conference Boston 2013に関しては、帰国後予想以上に忙しかったせいもありレポートをまとめる時間がとれませんでした。 時間がたちましたが、ようやくまとめることができたのでセッションレポートを公開します。 この記事でとりあげるセッションはモバイルサイトのコンバージョン率を上げるための秘策です。 スピーカーは、SeeWhyの創設者、Charles Nicholls（チャールズ・ニコルズ）氏です。 では行ってみましょう。 モバイルにおけるコンバージョンの問題
検索結果1位のクリック率は17.16%、ロングテールはCTRが高い 〜 CATALYST調べ
[対象: 中級] Google検索のCTR（クリック率）を調査したデータをまとめたレポートを、CATALYSTが公開しました。 この記事では、このCTR調査レポートのなかから主だったデータを紹介します。 調査方法 対象キーワード: 17,500個 対象サイト: 59サイト 対象期間: 2012年10月〜2013年6月 利用したデータ: Googleウェブマスターツールの検索クエリ 調査方法の詳細はレポートを参照してください。 検索結果10位のCTR 下の表は、検索結果1位〜10位まで、言い換えると検索結果1ページ目のCTRを表しています。 上の表のデータをグラフ化したものです。 1位のCTRは17.16%です。 やっぱり1位はダントツで高いですね。 上位の4位で全体の83%を占めています。 Above the foldに表示されることが重要だとCATALYSTは述べています。 48%のユー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
