タグ

ブックマーク / www.suzukikenichi.com (17)

  • 【JavaScript SEO】サーバーサイドでレンダリングすべき要素: メインコンテンツ、構造化データ、titleタグ、hreflangほか

    [レベル: 上級] DeepCrawl が主催したウェビナーで Google の Martin Splitt(マーティン・スプリット)氏が、JavaScript サイトの SEO に関するさまざまな質問に回答しました。 このなかで、サーバーサイドでレンダリングすべき要素、言い換えると、JavaScript を介してレンダリングさせるべきではない要素をスプリット氏は挙げました。 スプリット氏によると、SEO を考慮するのであれば、次の要素はサーバーサイドでレンダリングしてからクライアント(ユーザーと Googlebot)に配信したほうがいいとのことです。 メインコンテンツ 構造化データ title タグ meta description hreflang 日付に関する記述 メインコンテンツは、ページの評価において最も重要です。 現在の WRS(ウェブ レンダリング サービス)が、古い Chr

    【JavaScript SEO】サーバーサイドでレンダリングすべき要素: メインコンテンツ、構造化データ、titleタグ、hreflangほか
  • サイトマップはインデックスさせる必要なし。X-Robots-Tagのnoindexでインデックス回避が可能

    [レベル: 中級] 検索エンジンのために構成するサイトマップ ファイルをインデックスさせる必要はありません。 X-Robots-Tag で noindex を送信するとサイトマップが検索結果に出ないようできます。 サイトマップをインデックスさせる必要なし Google の John Mueller(ジョン・ミューラー)氏が、次のようなリマインダーを Twitter に投稿しました。 XML サイトマップを対象にした “noindex” の X-Robots-Tag HTTP ヘッダー を使ってかまわない。サイトマップとして機能するために、サイトマップはインデックスされる必要はない。サイトマップは(インデックスさせるために作られた)HTML ページというよりも、むしろ(機械のために作られた)robots.txt のようなものだ。 Since this comes up from time t

    サイトマップはインデックスさせる必要なし。X-Robots-Tagのnoindexでインデックス回避が可能
    mut00tum
    mut00tum 2019/01/10
  • モバイルウェブの高速化は成果に直結する、スタバはRewards登録が65%⬆ #ChromeDevSummit

    [レベル: 中〜上級] この記事では、昨日に続いて Chrome Dev Summit 2018 のセッションをレポートします。 セッションタイトルは “Get Down to Business: Why the Web Matters” 、モバイルウェブ、特にモバイルウェブの高速化が重要な理由をケーススタディとともに解説するセッションです。 モバイルウェブとスピード 回線速度が速い 4G がまだ普及していない国、地域がある。 ※暖色になるほど、4G が普及していない パフォーマンス改善で成果を上げたサイトが世界中に存在する。 wayfair: CV 10 % ⬆ ClickBus: 売上 15 % ⬆ Stylelight: クリックアウト CV 6.5 % ⬆ JD.ID: CV 43 % ⬆ LinkedIn: 求人応募 4 倍 ⬆ Spotify 事例 2107 年の時点では Sp

    モバイルウェブの高速化は成果に直結する、スタバはRewards登録が65%⬆ #ChromeDevSummit
  • クライアントサイドでレンダリングしたrel=”canonical”をGoogleは完全無視 #io18 #io18jp

    [レベル: 上級] Google は生 の HTML に記述されている rel="canonical" だけを処理します。 クライント側のレンダリングで生成された rel="canonical" は完全に無視されます。 Web担当者Forum 連載コラムで先週取り上げ、その後 Twitter でも補足したことなのですが、特に、開発者と密接に連携してサイト管理している人にとっては重要な情報なので僕のブログでも触れておきます。 最初の状態で rel=”canonical” を返すこと JavaScript を使ってクライント側で rel="canonical" を生成させることができます。 言い換えれば、レンダリング後に rel="canonical" を挿入可能です。 JavaScript のフレームワークを使ってもいいでしょうし、Google タグマネージャでも実現可能です。 “クライント

    クライアントサイドでレンダリングしたrel=”canonical”をGoogleは完全無視 #io18 #io18jp
    mut00tum
    mut00tum 2018/05/22
  • HTTPS接続の状態をチェックできるGoogle ChromeのSecurityパネル

    [レベル: 上級] HTTPSの状態を検証するための「Securityセキュリティ)」パネルがGoogle Chromeのデベロッパーツールに追加されました。 Securityパネルでは、次の3項目の安全性を知ることができます。 証明書: 有効なTLS/SSL証明書が使用されているかどうか TLS接続: 安全なTLS/SSL接続が確立されているかどうか リソース: 画像やJavaScriptなどのリソースもTLS/SSLで配信されているかどうか Securityパネルのレポート具体例 SecurityパネルでHTTPSの状態がどのようにレポートされるかの具体例をいくつか見てみましょう。 まずChromeのデベロッパーツールを立ち上げます。 [Google Chromeの設定](右上の3バー) − [その他のツール] − [デベロッパー ツール] Ctrl + Shift + i (Wi

    HTTPS接続の状態をチェックできるGoogle ChromeのSecurityパネル
  • Google、リッチスニペットよりもビジュアルなリッチカードをグローバル展開。レシピ、レストラン、映画が対象

    [レベル: 中〜上級] リッチカードが、世界中の Google モバイル検索で利用可能になりました。 日でも利用できます。 リッチカードは、従来のリッチスニペットよりも視覚に訴える効果が高くなっているのが特徴です。 2016年5月に米 Google (google.com) で公開されました。 レシピ映画、飲店のリッチカードをサポート 次の3つのジャンルでリッチカードがサポートされています。 レシピ 映画店 こちらは、レシピのリッチカードです。 そのサイト専用 (host-specific) のカルーセルとして掲載されるのもリッチカードの特徴です。 上で見たチキンカレーレシピは、楽天レシピだけのリッチカード カルーセルになっています。 こちらは、飲店のリッチカードです。 べログ専用のカルーセルになっています。 米 Google ではホテルもリッチカードカルーセルに掲載され

    Google、リッチスニペットよりもビジュアルなリッチカードをグローバル展開。レシピ、レストラン、映画が対象
  • 表示速度が1秒→7秒で直帰率は113%↑、モバイル向けサイトのUXはとにかくスピードが命

    [レベル: 初・中・上級] 特にモバイル向けサイトでは、ユーザー体験改善のための最優先事項として”スピードアップ”が挙げられます。 現状のモバイルサイトがいかに遅く、遅い表示速度がどのくらい悪い影響をユーザー体験に与えているかを調査した結果を Google が公表しました。 「完全に表示されるまでに3秒以上かかると、53%のユーザーはページを離れる」「表示速度が1秒から7秒に落ちると、直帰率は113%上昇」など興味深いデータが出ています。 モバイルページは遅い、遅いとユーザーは立ち去る 新しい調査による次のような結果に Google はまず言及しています。 モバイル向けのランディングページが完全に表示されるまでにかかる時間は22秒 完全に表示されるまでに3秒以上かかると、53%のユーザーはページを離れる 全般的に、とにかくモバイルページは遅いということが明らかです。 にもかかわらず、モバイ

    表示速度が1秒→7秒で直帰率は113%↑、モバイル向けサイトのUXはとにかくスピードが命
    mut00tum
    mut00tum 2017/02/28
    “3G通信では、1.49MBのデータをロードするのに7秒かかるそうです。”
  • モバイルファーストインデックスについて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向けページと同じリンクをモバイル向け

    モバイルファーストインデックスについてGoogleに何でも聞いてみた #inhouseseo ―― 内部リンクの評価は? 導入時期は? 分割数が異なるページネーションは? など
  • Googleモバイル検索に「他の人はこちらも検索」機能が登場、今までの関連ワード検索になかった3+1つの新しい特徴あり

    [レベル: 初・中級] 「他の人はこちらも検索」という関連ワード検索の機能をGoogleはモバイル検索に導入しました。 今までの関連ワード機能にはなかった新しい特徴が「他の人はこちらも検索」には3つあります。 【UPDATE】 もう1つ大きな特徴があったので追加しました。 検索結果に戻ってきたときに表示 カルーセル形式 アクセスした結果の下に表示 ページによって異なる関連ワードを提示 4つの特徴を持つ「他の人はこちらも検索」 こちらは通常のモバイル検索結果です。 1位表示のNHKのサイトをタップして訪問し、検索結果に再び戻ってきます。 そうすると、すぐ下に「他の人はこちらも検索」が出現します。 カルーセル形式になっていて、横にフリックするとスライドして検索ワードがさらに出てきます。 「他の人はこちらも検索」のもう1つの特徴は、訪問したページの結果の下に出現する点です。 こちらのスクリーンシ

    Googleモバイル検索に「他の人はこちらも検索」機能が登場、今までの関連ワード検索になかった3+1つの新しい特徴あり
  • Googleがウェブマスター向けガイドラインを大幅改定 ―― いったい何が変わったのか?

    [レベル: 初・中・上級] Googleは、ウェブマスター向けガイドラインを大幅に改定しました。 この記事では、主だった変更点を抽出して解説します。 認識しておきたい変更点が数多くあります。 新しいウェブマスター向けガイドラインの主だった変更点 セクション分け 以前は、次の3つのセクションに大きく分かれていました。 デザインとコンテンツに関するガイドライン 技術に関するガイドライン 品質に関するガイドライン 現在は、2つに分かれています。 一般的なガイドライン 品質に関するガイドライン 内容が減ったわけではなく、「デザインとコンテンツに関するガイドライン」と「技術に関するガイドライン」の2つが、「一般的なガイドライン」にまとめられた感じになっています。 「一般的なガイドライン」はさらに次の3つのサブセクションに分かれています。 Google がページを検出できるよう手助けする Google

    Googleがウェブマスター向けガイドラインを大幅改定 ―― いったい何が変わったのか?
    mut00tum
    mut00tum 2016/02/02
    “バリデーションで100点を取ったからといって評価は上がらないし、60点だからといって順位が下がることもありません。”
  • 今どきの見出しとしてのhタグの正しい使い方

    [レベル: 初級] hタグに対するGoogleの扱いについて、GoogleのJohn Mueller(ジョン・ミューラー)氏が英語版のウェブマスターオフィスアワーで参加者からの質問に回答しました。 コンテンツを内容を正確に反映したhタグを使うべきなのでしょうか? 複数のh1タグは検索エンジンの評価に影響を与えるのでしょうか? 見出しには、階層をきちんと反映したhタグを使うべきか 次のような質問が出ます。 h2タグの見出しの下にコンテンツを書いています。 そのなかには小見出しもあります。 小見出しにはh3タグを使うべきでしょうか? それともh2タグのなかにすべて置いたままにしておいたほうがいいでしょうか? ミューラー氏は次のように答えます。 見出しタグはコンテンツの文脈を理解するのに少しだけ手助けになる。 だが特効薬となるようなものではない。 なので、見出しを正しく使っていないからといって、

    今どきの見出しとしてのhタグの正しい使い方
  • クリックしたときに作られる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はクリッ

    クリックしたときに作られるJavaScriptコンテンツはGoogleにインデックスされない
  • Ajaxクロールの推奨構成のサポートをGoogleがついに終了

    [レベル: 上級] Googleは、今からさかのぼること2009年に公開した、Ajaxクロールの推奨構成を終了することを公式にアナウンスしました。 以前の推奨構成を保持したままでもインデックスされ続けますが、現状に即した技術を利用するように促しています。 ごく限られたJavaScriptしか実行できなかった当時、GoogleはAjaxによって生成されるコンテンツを確実にクロール、インデックスするために特殊な構成をウェブマスターに提唱しました。 この構成を、ざっと簡単に説明すると次のようになります。 ウェブページのレンダリングをすませた、いわゆる“スナップショット”を事前に作成しておき、AjaxページにGooglebotがアクセスしたときには準備済みのスナップショットを返す。 Googlebotにスナップショットを取得させるために、AjaxページのURLに含まれる「#」(ハッシュ、フラグメン

    Ajaxクロールの推奨構成のサポートをGoogleがついに終了
  • モバイルフレンドリーアップデートで海外SEO情報ブログはどのくらい順位が下がったのか?

    [レベル: 初・中・上級] この記事では、モバイルフレンドリーアップデートの実施後に、モバイル検索の間でどのくらいの順位下落が発生しているのかを“生のデータ”で紹介します。 対象サイトは、まだスマホ対応していない僕のブログです。w 結論を先にいうと、僕のブログにおいては、幅広いクエリで、順位の下落が発生している可能性が高そうです。 しかし、順位の下落幅はほとんどのクエリで微々たるものです。 調査方法 以下の方法で調べました。 ウェブマスターツールの新機能、「検索アナリティクス」のデバイスフィルタ機能でPCとモバイルの掲載順位を比較 アップデート実行前のデータは、3月21日〜4月20日の1か月間 アップデート実施後のデータは、4月22日と23日の2日間 PCとモバイルのどちらでも表示されたクエリが対象 気付いた人がいるかもしれませんが、アップデート実施後のデータはたったの2日分です。 検索ア

    モバイルフレンドリーアップデートで海外SEO情報ブログはどのくらい順位が下がったのか?
  • 不必要に静的化した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の観点から付け加えさせてもらうと、わかり

    不必要に静的化したURLよりもパラメータ付きURLをGoogleは好む
  • Googleが推奨するSEOに適した無限スクロールの構成方法

    [対象: 上級] Google英語版ウェブマスター向け公式ブログで、検索エンジンが処理しやすい無限スクロール(Infinite Scroll)の推奨構成を説明しました。 細かな話は後回しにして、その推奨構成をさっそく日語で紹介します。 なお逐一の訳ではなく、理解しやすくするために表現や構成を原文とは多少変えてあります。 構成の概要 無限スクロールからリンクされている個々のアイテム(記事やコンテンツなど)を検索エンジンが確実にクロールできるように、利用しているシステムが、無限スクロールとともにページネーションしたページも作成できるように必ずしておく(無限スクロールで、1つのURLに収めるのではなく、分割して複数のページに分けるということ)。 ※拡大画像はオリジナルのURLで表示します(もう1つの画像も同様) 無限スクロールは、分割したページに変換されることで検索エンジンが処理しやすくなる

    Googleが推奨するSEOに適した無限スクロールの構成方法
  • 「No」と言わせない、コンバージョンを勝ち取るためのランディングページ最適化 at #SMX London 2012

    [対象: 初〜中級] SMX London 2012でのGoogleのAmit Singhal氏のキーノートスピーチを昨日は紹介しました。 今日から数回に分けてセッションレポートを公開していきます。 意表をついて、SEOではなく、ランディングページ最適化、LPOのセッションから始めます。 セッションタイトルは “Winning The Conversion: Creating “Can’t Say No” Paid Search Landing Pages” です。 4人登場したうちの3人のスピーカーのプレゼンテーションからになります。 まずは1人目、LimeTreeのMalcolm Graham(マルコム・グレアム)氏からです。 − あからさまな広告のようなランディングページは機能しない ・「今すぐ購入!」みたいなのはNG ・ただし安い商品はこれで済んでしまうこともある − 慣例となって

    「No」と言わせない、コンバージョンを勝ち取るためのランディングページ最適化 at #SMX London 2012
  • 1