サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
www.suzukikenichi.com
Web担当者Forum の連載コーナー「海外&国内SEO情報ウォッチ」を更新。「コンテンツ SEO!」「今の SEO で大事なのはコンテンツ!」でも、どんなコンテンツを、どんな構成で、どんな順番で作っていくといいのだろうか? 検索ボリュームだけを見るのではなく、見込み客の検索ジャーニーから考える手法を知っておこう。
[対象: 上級] ページの表示速度が、Googleのランキングを決める指標として日本を含むインターナショナルで導入されていることがSMX Advanced Seattle 2012で判明しました。 そこで今日は、ウェブページの高速化を取り扱ったセッションをレポートします。 スピーカーは、ECサイトのREIでSEOに携わるJonathon Colman(ジョナサン・コールマン)氏です。 ウェブサイトのパフォーマンス最適化 サイトを高速化する理由 コンバージョン率の最適化 カスタマーエクスペリエンスとカスタマー満足度の向上 直帰率を下げる。 競争率が非常に激しいキーワードでオーガニックからのトラフィックを増やす。 全体的な競争力を高める。 運用費を節約する。 数字で見るページスピード Googleではページスピードが検索の1%に影響している。 ユーザーがページ表示に待てるのは2秒まで。 3秒以
Googleのスパム対策強化やブランドリンク重視そしてその他もろもろを先日参加したPubCon Las Vegas 2010のレポートとして、お伝えしてきました。 今日はレポートをもう1つ追加します。 ECサイトを運営するサイト管理者、特に「ECサイトではオリジナルのコンテンツを作るのは無理」と“あきらめモード”に逃げているネットショップの運営者(そう、あなたのことです!)の参考になるはずです。 (たった数秒といえど)言い訳を探すのに費やすムダな時間と思考回路をこれからリストアップするコンテンツ増強のアイディアを探すことに向けてください。w モデルとなるのは、“狩猟犬アイテム”をオンラインで販売するGUN DOG SUPPLYというECサイトです。 このサイトが、当初の売上見込額の3倍の1,000万ドル(日本円で8億数千万円)を6年間で増やすことに成功した施策の1つがサイトのコンテンツを増
[レベル: 初・中・上級] Googleは、ウェブマスター向けガイドラインを大幅に改定しました。 この記事では、主だった変更点を抽出して解説します。 認識しておきたい変更点が数多くあります。 新しいウェブマスター向けガイドラインの主だった変更点 セクション分け 以前は、次の3つのセクションに大きく分かれていました。 デザインとコンテンツに関するガイドライン 技術に関するガイドライン 品質に関するガイドライン 現在は、2つに分かれています。 一般的なガイドライン 品質に関するガイドライン 内容が減ったわけではなく、「デザインとコンテンツに関するガイドライン」と「技術に関するガイドライン」の2つが、「一般的なガイドライン」にまとめられた感じになっています。 「一般的なガイドライン」はさらに次の3つのサブセクションに分かれています。 Google がページを検出できるよう手助けする Google
[レベル: 中級] 昨日とおとといに続いて、今日も 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(パフォーマンス バジェット)
iPhoneやiPad、Android端末の普及でスマートフォン専用のページを用意するサイトも増えてきています。 スマートフォンからのアクセスに対して「リダイレクトによってスマートフォン専用のURLに振り分けるとき」の注意点を今日はお伝えします。 rel=”canonical”タグで、対応するデスクトップ用ページのURLを指定してください。 重複コンテンツの発生を防止するためです。 現状GoogleはデスクトップPCとスマートフォンを区別せず同等に扱います。 スマートフォン用の検索結果も用意していません。 共に、ウェブクローラのGooglebotがクローリングします。 ※従来のモバイル端末はモバイルクローラのGooglebot-Mobileがクローリングします。詳しくはこちらの記事を参照。 スマートフォン用のコンテンツはデスクトップ用のページと、完全ではないにしてもほぼ同じになるはずです。
[対象: 中〜上級] 僕のブログではてブ数がいちばん多いのはウェブページを高速化するTIPSを解説した記事です(まだ読んでない人はぜひ読んでください!)。 その記事では高速化全般を扱っていましたが、今日の記事ではJavaScriptに的を絞って表示速度をスピードアップできる施策を6つ紹介します。 もともとはSearch Engine PeopleブログのOptimizing JavaScript for Better Web Performanceで説明されていたものです。 記事作者のJoydeep Deb(ジョイディープ・デブ)氏に僕のブログでの転載許可をもらえました (Thanks, Joydeep!)。 逐一の翻訳ではなく、書かれている内容をもとに僕の言葉で解説していきます。 1. HTTPリクエスト削減のためにJavaScriptファイルを1つに統合する ウェブページの表示を高速化
[レベル: 初〜中級] 入力フォームのフィールドには、入力が「必須」なのかまたは「任意」なのかのラベルを両方付けることが推奨されます。 どちらか片方だけだと入力途中の離脱の原因になります。 ECサイトのユーザービリティ調査と最適化を専門に扱っているBaymard Instituteが詳しく解説しています。 15の大手ECサイトのユーザビリティ調査と18の主要なモバイルサイトのユーザビリティ調査、そして自社による最新の大規模なアイトラッキングテストによって実証することができました。 この記事では、その解説の要点をまとめて紹介します。 片方だけの「必須」「任意」ラベルの問題点 入力が「必須」か「任意」かをどちらか片方のラベルだけで示すことにはさまざまな問題点があります。 必須か任意かを示さないのはいちばんよくない そのフィールドの入力が必須か任意かを示さないのはいちばんよくないスタイルです。
http://www.suzukikenichi.com と http://www.suzukikenichi.com/ URLの終りに「/」(スラッシュ)を付けた方がいいのか、付けない方がいいのか、付いたときと付かないときでは何か違いがあるのか。 誰もが1度は疑問に思ったことがあるはずです。 URLの末尾に付ける「/」のことを「トレイリングスラッシュ(trailing slash)」と技術的に呼びます。 トレイリングスラッシュのあり・なしについて、ウェブマスター向け公式ブログでGoogleが説明しました。 補足を交えながら要点をまとめて解説します。 まず、トレイリングスラッシュのあり・なしによるウェブサーバーの一般的な振る舞いの違いです。 http://example.com/foo/ (トレイリングスラッシュあり) http://example.com/foo (トレイリングスラッシュ
[レベル: 上級] Googleは、Accelerated Mobile Pages (アクセラレイティッド・モバイル・ページ)という、モバイル端末でのウェブページの表示を高速化するためのプロジェクトを公開しました。 略して、AMP(アンプ)と呼びます。 AMPで策定された仕様に従ってモバイルサイトを構成すると、モバイル検索結果からリンク先ページがまさに“一瞬”で表示されます。 AMPをデモで体験 AMPを使ったページがどのようにモバイル検索から表示されるのかを見てみましょう。 Inside Searchの公式アナウンスに動画があります。 まずこれを見て、何となくでいいので雰囲気をつかんでください。 ただ、見てもどんなだか十分にはわかりませんでしたよね。 実際に試したほうが理解できます。 AMPを体験できるサンプルのリンクもアナウンスに出ていますが、日本からでは機能しないので少し細工を加え
[レベル: 中級] Googleは、Mobile First Index(モバイル ファースト インデックス)の導入を正式にアナウンスしました。 Mobile-first Indexing モバイル ファースト インデックスに向けて モバイル ファースト インデックスでは、PC向けページではなく、モバイル向けページの評価に主に基づいてランキングが決定されます。 Gary Illyes(ゲイリー・イリェーシュ)氏が米ラスベガスで10月に開催されたPubCon Las Vegas 2016で発表していたGoogle検索の仕様変更です。 正式な実施時期はまだ決まっていません。 今後数か月にわたり小規模な実験を行ったうえでの判断になるとのことです。 評価対象がPC向けページからモバイル向けページへ 詳細は公式アナウウンスを読んでいただくとして、概要としてはモバイル ファースト インデックス(以下、
[レベル: 初・中・上級] Googleは、スマホ対応しているかどうかをモバイル検索のランキング要因として使用することを発表しました。 4月21日からの導入を予定しています。 またApp Indexingに対応したアプリコンテンツもランキング要因として利用するようにしました。 こちらは今日(現地時間の2月26日)から導入されています。 モバイルフレンドリーが単なるラベル表示からランキング要因に 昨年11月に、そのページがスマートフォンに対応しているときに、「Mobile-friendly」(モバイル フレンドリー)というラベルをGoogleはモバイル検索結果に表示するようにしました。 日本には、翌月の12月に導入されました。 「スマホ対応」というラベルが付きます。 導入時点では、「スマホ対応」ラベルは単純に表示だけの仕様でした。 スマホ対応しているかどうかはランキング要因にはなっていません
[レベル: 上級] SEO と相性がいい Lazyload の実装を解説するドキュメントを Google はデベロッパー向けサイトで公開しました。 3つのアドバイス ドキュメントには3つの指針が書かれています。 1. viewport 内で見えるようにする viewport 内にあるコンテンツは、必ず Google にも見えるようにしておきます(viewport は簡単に言えば、スクリーンに表示される領域)。 つまり、重要なコンテンツが viewport に入ったときは確実に読み込ませます。 IntersectionObserver API と polyfill を実装するように Google は指示しています。 2. 無限スクロールでは paginated loading を使う 無限スクロールを採用している場合は、paginated loading を実装します。 paginated
[対象: 全員] Googleは、Googleアカウントのログイン状態にかかわらず、すべてのGoogle検索をHTTPSでの接続つまりSSL検索を利用するように仕様を変更しました。 すでに実施済みです。 僕たちにとってこれが何を意味するかというと、Google検索からのトラフィックの検索キーワードを取得することが不可能になります。 Googleアナリティクスでいうと、「(not provided)」だけになってしまいます。 HTTPSへ強制的にリダイレクト Googleアカウントからログオフした状態で、http://www.google.co.jp/ のように http:// で始まるURLでGoogle検索にアクセスしても、 https:// で始まるURLに強制的にリダイレクトされます。 FirefoxやChromeでは、ブラウザが内蔵しているGoogle検索ツールやアドレスバーからG
[対象: 上級] 気付いている人もいるかと思いますが、このブログ全体をHTTPSにしました。 この記事では、備忘録を兼ねて、完全HTTPSへの移行を検討しているサイトの参考になるように僕が実行してきたプロセスをまとめます。 実行した主な作業は次のとおりです。 サーバー証明書の取得 HTTPSへのリダイレクト 内部リンクの修正 各種ツール・パーツのHTTPS動作確認 すべてのコンテンツがHTTPSでダウンロードされているかを確認 WordPressの設定変更 rel=”canonical”の更新 ウェブマスターツールへの登録 サイトマップの更新 ソーシャルシェアの引き継ぎ HSTSの設定 外部リンクの更新 高速化 順に説明します。 1. サーバー証明書の取得 サーバー証明書をまず取得します。 手順は利用しているサーバー会社によって変わってきます。 詳しくはお使いのサーバー会社のヘルプを参照し
[レベル: 中級] Googleはモバイル検索で、すべての結果にURLの代わりにパンくずリストを表示するように仕様を変更しました。 また、ドメイン名の代わりにサイト名を表示することがあります。 Official Google Webmaster Central Blog: Better presentation of URLs in search results モバイル検索結果ではパンくずリストを表示 下のモバイル検索結果では、URLのところがすべてパンくずリストで表示されています。 とはいえ、もともとPCからの検索でもパンくずリスト表示だったのなら、モバイル検索特有の機能とはいえません。 比較してみましょう。 こちらのPCからの検索結果では、通常どおりにURLがそのまま表示されています。 スマートフォンから検索するとこのようになります。 少々わかりづらいのですが、パンくずリストっぽく変
[レベル: 中級] 【UPDATE】 この記事は事実を正しく反映していないことが判明しました。 こちらの記事で説明しています。 ページの読み込み速度をモバイル検索のランキング要因として用いる “Speed Update”(スピード アップデート)を Google は今月導入する予定です。 Speed Update は、本当に遅いページだけが影響を受けるアルゴリズムだと思われていました。 しかしながら実際には、速ければ速いほど評価が上がるアルゴリズムになっているようです。 Speed Update では、読み込み速度が速いと段階的に評価が上がる Speed Update の導入を事前アナウンスした公式ブログの記事は次のように説明していました。 The “Speed Update,” as we’re calling it, will only affect pages that delive
[レベル: 中級] 検索結果の品質を評価するためのガイドラインの最新版をGoogleは公開しました。 これまでのものとは変更がない部分がある一方で、新たにモバイルに関する章が加わったことが最新版の最大の特徴となっています。 検索品質評価ガイドラインとは? Googleは、ユーザーのクエリに対して関連性が高くかつ高品質なページを検索結果で返すことができているかどうかを、外部の評価者(Evaluator)に常に評価させています(評価者は普通に求人として募集されているらしい。日本でさえも)。 評価者による評価は検索品質の改善のために役立てられます。 直接的にランキングを調整するためには用いられません。 どのように検索結果の品質を評価するかを説明した「General Guidelines」(一般ガイドライン)というマニュアルが評価者に提供されます。 このマニュアルは原則的に評価者だけに配布されます
[レベル: 上級] Googlebot がページをクロールするときにかかるダウンロード時間が 1,000 ミリ秒を超えると、クロールに支障をきたすかもしれません。 一応の目安として、100 〜 500 ミリ秒以内を考慮しておくとよさそうです。 ページのダウンロード時間は 100 〜 500 ミリ秒が理想、1,000 ミリ秒は遅すぎ (旧)Search Console のクロールの統計情報レポートでは、ページのダウンロード時間の情報を確認することができます。 ページのダウンロード時間は、Googlebot がリソースを純粋にリクエストするのにかかった時間を示すデータです。 PageSpeed Insights のようにユーザーが使うブラウザの表示にかかる時間ではありません。 リソースは、HTML のほか画像や CSS、JavaScript、PDF なども含みます。 ダウンロード時間の目安に関
[対象: 全員] Google Research Blogがユーザーテストに基づいてまとめたレポートから、入力フォームの完了にもっとも大きな影響を与えた設定をこの記事では紹介します。 次の4つの設定になります。 入力条件を事前に指示する エラーメッセージをフィールドの横に配置する 必須の項目と任意の項目を区別しやすくする ラベルをフィールドの上に配置する 順に説明します。 入力条件を事前に指示する 入力条件(たとえば、パスワードの最低文字数)は、フォームを送信する前にフォームのなかで指示します。 このガイドラインの適用は、フォームの完了と被験者の評価に大きなプラスの影響を与えました。また、被験者のコメントにも(前もって指示してもらった方がいいと)頻繁に現れました。 エラーメッセージをフィールドの横に配置する ユーザーがすぐに訂正できるように、エラーメッセージは入力フィールドの隣に配置します
[対象: 全員] 検索結果に表示されるページのタイトルが、HTMLに記述したtitleタグとは異なりGoogleによって勝手に変更されてしまうことがあります。 このブログでもGoogleによるtitleタグ書き換えについて何度か記事を書いてきました。 検索結果のタイトルをGoogleが激しく書き換える理由 Googleによるtitleタグ書き換えを防ぐ方法 Google社員に4つ質問してみた 〜 rel=prev/next、titleタグ書き換え、不自然リンクへの警告、ツイッターの影響 Google、titleタグ書き換えのアルゴリズムを改善か? titleタグが修正されてしまう原因は多少は分かっているものの、合点がいかないことも多く対処が難しいのが実情です。 ウェブマスターからの問い合わせやクレームが多いのか、ウェブマスター向け公式ブログでついにtitleタグの書き換えについて説明があり
[レベル: 上級] rel="nofollow" 属性の扱いを Google は変更しました。 従うべき命令としてではなく、手がかりのためのヒントとして利用するようになります。 また、nofollow の派生型として、link タグと用いる 2 種類の rel 属性を新たに導入しました。 nofollow 属性の扱いを変更 rel="nofollow" 属性が付いたリンクを Google はこれまでランキング要因としては利用していませんでした。 PageRank を渡すこともないしアンカーテキストも評価しません。 そして、nofollow 属性を命令 (Directive) として Google は扱い、必ず従ってきました(nofollow リンクが評価されている状況があるという分析もあるけれど、公式見解では nofollow リンクはランキング要因から除外されることになっている)。 今後
今日はGoogle Analyticsのレポート表示に関する便利なTIPSを紹介します。 Google Analyticsで使える「セカンダリディメンション」はなかなか便利な機能なのですが、なかには選択できないディメンションもあります。 たとえば上位のコンテンツではもっとも閲覧数の多い順にページの「URL」が表示されます しかしセカンダリディメンションとして「ページタイトル」を指定することはできません。 でもセカンダリディメンションとしてタイトルを表示させることができるのです。 やり方は簡単です。 “&segkey=request_uri|page_title“、このパラメータをGoogle Analyticsで「上位のコンテンツ」を閲覧しているときのURLに挿入します。 挿入する場所は、”id=XXXXXXX”の後です。 XXXXXXXにはあなたのGoogle Analyticsのプロフ
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向けページと同じリンクをモバイル向け
[レベル: 中級] 【UPDATE】 この記事は公式発表よりも前に投稿したものです。 Googleから公式発表が出ています。 より具体的な情報は下の記事で説明してます。 Google、モバイルファーストインデックスの導入予定を正式発表。スマホ向けページを検索の評価対象に。SEOへの影響は? 米ラスベガスで開催されたPubCon Las Vegas 2016でGoogleのGary Illyes(ゲイリー・イリェーシュ)氏は、Mobile First Index(モバイル ファースト インデックス)への移行を計画していることを発表しました。 現在は、PC向けページの評価をもとにして検索結果ができあがります。 対して、モバイル ファースト インデックスでは、モバイル向けページ(スマホ向けページ)の評価をもとにして検索結果ができあがります。 モバイル ファースト インデックスに関してさまざまな情
というのです。 動的URL(Dynamic URL:ダイナミックURL)とは、ユーザーの要求に応じてその都度、生成されるURLです。 多くの場合「?」「&」「=」で区切られたパラメータ(引数)を伴います。 例1:http://code.google.com/p/google-checkout-php-sample-code/issues/detail?id=31 例2:http://www.google.com/support/webmasters/bin/answer.py?answer=40349&cbid=1beyxilfwhlqn&src=cb&lev=answer eコマースサイトやヘルプのように、データベースを利用したシステムで使われています。 一方、静的URL(Static URL:スタティックURL)は、誰がいつアクセスしても同じ、固定のURLです。 拡張子が、.htmや.
[対象: 初〜中級] この記事では、モバイル向けサイトのユーザビリティやユーザーエクスペリエンスの向上に役立つ、Googleが提供する公式ツールを5つ紹介します。 Chrome PageSpeed Insights Mobile-Friendly Test Fetch as Google モバイルユーザビリティ レポート 順に説明します。 Chrome Google Chromeの「デベロッパー ツール」では、スマートフォン端末で見たときのそのページの表示をエミュレーションできます。 「デベロッパー ツール」は次の手順で起動します。 [Google Chromeの設定](右上の3本バー) − [その他のツール] − [デベロッパー ツール] Ctrl + Shift + i (Windows) / Cmd + Opt + i (Mac) スマホを表すアイコンをクリックするとスマホでの表示モ
昨日、鷲見さんが『Google Analyticsの直帰率は評価の指標にならない』という記事を、寄稿してくれました。 Google Analyticsの直帰率は、純粋に1ページだけを見てサイトを離れたユーザーの割合を示しています。 鷲見さんが説明しているように、「直帰率が高い = 悪いこと」とは限りません。 例えば、ブログにフォーカスしてみましょう。 ブログはその特性上、最新の記事だけ読んで、あとはそのブログから離脱するケースも少なくありません。 また、RSS などで更新ごとにブログに訪れるユーザーや、リピートの多いブログであれば、尚更その割合は多くなります。 まさしく、僕のブログにあてはまります。 僕のブログは、通常1日1記事の更新です。 RSSリーダーに登録して新着記事をチェックしたり、毎日お気に入りなどから直接アクセスしたりするユーザーが大勢いてくれます。 リピータになっているので、
[対象: 中級] 今日は、スマートフォン向けのサイトを検証するときに便利なツールを2つ紹介します。 レスポンシブ・ウェブデザインでの表示を簡単に確かめられるブックマークレットとスマホでのページ閲覧をシミュレーションするアプリケーションソフトです。 1. レスポンシブ・ウェブデザイン ブックマークレット 1つ目はレスポンシブ・ウェブデザインがどのように機能しているかをチェックするブックマークレットです。 こちらのページにアクセスして「RWD Bookmarklet」というボタン(リンク)をブラウザのお気に入りに追加するか、ブックマークバーにドラッグ&ドロップします。 レスポンシブ・ウェブデザインを確かめたいページでブラウザに追加したそのリンクをクリックすると下のような画面になります。 中央上にある赤枠で囲んだ4つのアイコンをクリックすると解像度を変化させた表示に切り替えることができます。 ア
次のページ
このページを最初にブックマークしてみませんか?
『海外SEO情報ブログ - SuzukiKenichi.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く