【要注意】HTTPS移行後はSearch Consoleから否認ファイルの再アップロードが必要
[レベル: 中級] サイト全体をHTTPからHTTPSへ移行した際には、Search Consoleに新たに登録したHTTPSサイトの方でリンクの否認ファイルを再度アップロードし直す必要があります。 HTTPサイトのプロパティで送信していたリンクの否認は、HTTPSサイトには引き継がれません。 HTTPS移行後にペンギンが戻ってきた!? GoogleのGary Illyes（ゲイリー・イリーズ）氏にTwitterでフォロワーが次のように質問しました。 おかしなことが起こりました。クライアント（のサイト）をhttpからhttpsへ移行したら、ペンギンアルゴリズムのペナルティがまた戻ってきたように見えます。 Search Consoleのアカウントに新しいhttpsのサイトを追加しました。でも、否認ファイルは移行していません。（httpsで登録したサイトは）新しいサイトとして認識されて、新たに
モバイルウェブが爆速に！ GoogleがAMP (Accelerated Mobile Pages) を立ち上げ
[レベル: 上級] Googleは、Accelerated Mobile Pages （アクセラレイティッド・モバイル・ページ）という、モバイル端末でのウェブページの表示を高速化するためのプロジェクトを公開しました。 略して、AMP（アンプ）と呼びます。 AMPで策定された仕様に従ってモバイルサイトを構成すると、モバイル検索結果からリンク先ページがまさに“一瞬”で表示されます。 AMPをデモで体験 AMPを使ったページがどのようにモバイル検索から表示されるのかを見てみましょう。 Inside Searchの公式アナウンスに動画があります。 まずこれを見て、何となくでいいので雰囲気をつかんでください。 ただ、見てもどんなだか十分にはわかりませんでしたよね。 実際に試したほうが理解できます。 AMPを体験できるサンプルのリンクもアナウンスに出ていますが、日本からでは機能しないので少し細工を加え
Googleは302リダイレクトを301リダイレクトとして処理することがある
[レベル: 中〜上級] 301リダイレクトは恒久的なURLの移転の際に用います。 対して、302リダイレクトは一時的なURLの移転の際に用います。 特にユーザーを自動的に転送する点において両者に違いはありませんが、検索エンジンの処理においてはいくつかの違いがあります。 使う場面も異なってきます。 しかし、状況によってはGoogleは302リダイレクトを301リダイレクトとして認識し処理することがあるとのことです。 また、301リダイレクト扱いされた302リダイレクトはPageRankを渡します。 長期間継続する302は301 英語版のオフィスアワーで参加者がJohn Mueller（ジョン・ミューラー）氏に次のように質問しました。 一時的な302リダイレクトが十分な時間継続すると、最終的にGoogleは恒久的な301リダイレクトとして処理すると聞いたことがあります。 どのくらいの時間がたつ
PC版を作らない、モバイル版だけのサイトはあり？なし？
PC向けページを一切作らず、モバイル向けページだけのサイトを公開しても問題はないのでしょうか？ GoogleのJohn Mueller（ジョン・ミューラー）氏によれば、まったく問題ないとのことです。 PC向けサイトがなくてもまったく問題なし 現状では、モバイル向けサイトだけしか提供していない。 PC向けサイトを作らずに、モバイル向けサイトだけだとSEO的に問題があるか？ 英語版のウェブマスター向けオフィスアワーで出たこの質問に、ミューラー氏は次のように答えました。 モバイル向けだけのサイトを作っても何も問題ない。すべてのサイトがPC版を持つ必要があるということではない。 モバイル向けページであってもPCで利用することができるだろう。もっとも見え方は多少違ってくるだろうが。 だけどモバイルだけのサイトは完全にありえる。検索でもほかのサイトと同じように私たちは扱う。 気を付けたいのは、PCから
JavaScriptの読み込みを最適化してページの表示速度を高速化する6つの方法
[対象: 中〜上級] 僕のブログではてブ数がいちばん多いのはウェブページを高速化するTIPSを解説した記事です（まだ読んでない人はぜひ読んでください！）。 その記事では高速化全般を扱っていましたが、今日の記事ではJavaScriptに的を絞って表示速度をスピードアップできる施策を6つ紹介します。 もともとはSearch Engine PeopleブログのOptimizing JavaScript for Better Web Performanceで説明されていたものです。 記事作者のJoydeep Deb（ジョイディープ・デブ）氏に僕のブログでの転載許可をもらえました (Thanks, Joydeep!)。 逐一の翻訳ではなく、書かれている内容をもとに僕の言葉で解説していきます。 1. HTTPリクエスト削減のためにJavaScriptファイルを1つに統合する ウェブページの表示を高速化
CSSとJSファイルをブロックしているサイトに警告メッセージをGoogleが一斉送信
[レベル: 中級] CSSとJavaScriptのファイルへのアクセスをrobots.txtでブロックしているサイトに対して、Search Console経由で警告メッセージをGoogleは一斉に送信し始めました。 CSSおよびJSファイルにGooglebotがアクセスできません Google Search Console Teamから次のようなメッセージが届きます。 http://example.com/ の CSS および JS ファイルに Googlebot がアクセスできません http://example.com/ のウェブマスター様 Google のアルゴリズムによるコンテンツのレンダリングとインデックス登録に影響を及ぼす問題が貴サイトで発生していることが Google のシステムにより判明しました。具体的には、robots.txt ファイルでの制限のために Googlebot
全ページ共通のテンプレート定型文をGoogleはどのように評価するのか？
[レベル: 初級] サイト内のすべてのページに共通の定型文を、テンプレートとしてページ上部に掲載していたとします。 メインコンテンツは、そのテンプレート定型文の後から始まります。 こうした定型文のGoogleの扱い方について、6月30日に開催された英語版のウェブマスター向けオフィスアワーでJohn Mueller（ジョン・ミューラー）氏が説明しました。 テンプレート定型文のGoogleの扱い ミューラー氏による説明のポイントを箇条書きでまとめます。 定型文のコンテンツではなく、そのページ固有のコンテンツに基づいて評価する 定型文とメインコンテンツに同じ言葉があったからといって、その言葉の価値を低くしたりはしない 定型文のあとに、h1タグからメインコンテンツを始めるのは、どこからメインコンテンツが始まるかをGoogleに伝える手助けになる ページの上部にある定型文のテキストはスニペットに使わ
HTTPS移行後に外部リンクのURLを https:// に変更する必要はない
[レベル: 上級] 常時HTTPSへ移行した際に、外部サイトから張られているリンクのURLを https:// で始まるURLにわざわざ更新する必要はありません。 GoogleのGary Illyes（ゲイリー・イリーズ）氏は、Twitterユーザーからの質問に次のように答えています。 @pip_net if your redirects are properly implemented, the benefit from doing that is so minimal that IMO it's not worth it. — Gary Illyes (@methode) 2015, 7月 7 HTTPSへ移行するとき、可能であれば、重要な外部リンクをSSLに変更したほうがいいと思いますか？ リダイレクトが適切に実装されているなら、そうすることでプラスになるのはごくわずかだ。僕の考えで
ページを削除したときは404と410のどちらを返すべきか？ => どちらでもいい
[レベル: 初〜中級] ページを削除したときには、404と410のどちらのHTTPステータスコードを返すべきなのでしょうか？ 結論を一言でいえば、Googleにおいてはどちらでも構いません。 再クロール率にも影響しません。 Googleのミューラー氏による説明 GoogleのJohn Mueller（ジョン・ミューラー）は、ユーザーから受け取った質問メールを引用して、404と410のGoogleの扱いについてGoogle+で説明しました。 I have a large site and removed lots of irrelevant pages for good. Should I return 404 or 410? What’s better for my “crawl budget”? (more from the depths of my inbox) The 410 (“G
Googleのなかの人だけど何か質問ある？ at #SMX Advanced 2015
[レベル: 中〜上級] お知らせしていたように、米シアトルで開催されたSMX Advanced 2015に参加してきました。 この記事では、今回のSMX Advancedの最大のハイライト、AMA With Google Searchのセッションをレポートします。 AMA With Google Searchとは AMAは、Ask Me Anything の頭文字を取ったものです。 日本語に訳すと「私に何でも質問して」という意味になります。 日本で俗に使われている、「◯◯だけど、質問ある？」に相当しますかね。 例年、SMX Advancedでは Q&Aをもじった You&A という、米Googleウェブスパムチームのトップ、Matt Cutts（マット・カッツ）氏とSMX主催者の代表、Danny Sullivan（ダニー・サリヴァン）氏との1対1のトークが目玉セッションでした。 マットが長
Google、パンくずリストとサイト名をURLの代わりにモバイル検索結果で表示。構造化データで指定可能
[レベル: 中級] Googleはモバイル検索で、すべての結果にURLの代わりにパンくずリストを表示するように仕様を変更しました。 また、ドメイン名の代わりにサイト名を表示することがあります。 Official Google Webmaster Central Blog: Better presentation of URLs in search results モバイル検索結果ではパンくずリストを表示 下のモバイル検索結果では、URLのところがすべてパンくずリストで表示されています。 とはいえ、もともとPCからの検索でもパンくずリスト表示だったのなら、モバイル検索特有の機能とはいえません。 比較してみましょう。 こちらのPCからの検索結果では、通常どおりにURLがそのまま表示されています。 スマートフォンから検索するとこのようになります。 少々わかりづらいのですが、パンくずリストっぽく変
モバイルフレンドリーテストに合格しているのにモバイルユーザビリティレポートでエラーが出る理由
[レベル: 初〜中級] モバイルフレンドリーテスト ツールでは合格しているのに、ウェブマスターツールのモバイルユーザビリティ レポートでは、エラーが通知されることがあります。 ほとんどの場合理由は単純で、最新の状態がモバイルユーザビリティレポートに反映されていないためです。 モバイルユーザビリティレポートは過去の状態をレポート モバイルフレンドリーテストは、ツールを実行したその時点での状態を診断します。 対して、モバイルユーザビリティでは、Googlebotがクロール・インデックスし、その後の処理が行われ、さらにそれからのレポートへの反映になります。 極端な言い方をすれば、過去の状態を示しています。 つまりモバイルフレンドリーなページに修正したとしても、Googleが持つデータとして実際に格納されるには再クロールと再インデックス、再処理が必要になります。 ページによってはクロール頻度が低い
「スマホ対応」アルゴリズム更新の疑問にGoogle社員が答えた
[レベル: 初・中・上級] サイトがモバイルフレンドリーかどうか（モバイル対応しているかどうか）をランキング要素として使用することを先週Googleは発表しました。 4月21日から開始の予定です。 この記事では、このアルゴリズム変更に関連した疑問についての回答を紹介します。 Googleジョン・ミューラーがオフィスアワーで回答 発表の当日に、GoogleのJohn Mueller（ジョン・ミューラー）氏が英語版のオフィスアワーをGoogle+で開催しました。 当然のごとく、モバイルフレンドリーアルゴリズムの質問が終始たくさん出てきます。 僕たちが知りたいことも多く含まれています。 参加者から出てきた質問とそれに対するミューラー氏による回答をピックアップしてまとめました。 あなたのモバイル対応の参考にしてください。 モバイルフレンドリー アルゴリズム Q&A Q: サイトがモバイル対応してい
モバイル検索ではナレッジグラフは自然検索よりも視線を集める、2・3位のほうが1位よりも長く見られる − Googleのモバイル検索調査からわかったこと
Googleが、モバイル検索でユーザーがどこに注目しどのように検索結果に満足しているかの調査をエモリー大学と共同で行いました。 結果と考察をまとめたレポートを公開しています。 調査結果から僕が重要に感じたところを抜き出します。 下は調査の対象に含まれる典型的なパターンの検索結果です。 「phone viewport（フォン ビューポート）」とは、スマートフォンのディスプレイに表示されている範囲のことです。 つまりユーザーに見えているページの中のエリアです。 次のようなことがわかりました。 答えを提供する形式の結果が表示されたほうがユーザーは満足する ナレッジグラフの関連性が高いときはユーザーは答えをすぐに発見しタスクをより速く完了させる 一方、ナレッジグラフの関連性が低いときは答えを探すためにより長い時間を検索結果で費やす 関連性が高いナレッジグラフ結果が表示されたときは、（表示されないと
Googleが今もっとも注力する3つの技術: ナレッジグラフ・音声検索・Google Now
[レベル: 初・中・上級] Google幹部へのインタビューをもとにしたBackchannelによる記事から、モバイルに関することを昨日の記事で紹介しました。 今日の記事では残りの部分で、僕が興味をもったところを抜粋して紹介します。 Googleが今もっとも力を入れているのは次の3つの技術なようです。 ナレッジグラフ 音声検索 Google Now Googleの最近の変化 過去3年間に、それ以前の13年間よりも多くのランキングアルゴリズムの変更をGoogleは実行した。 最近の重要な変化は2つ。 ナレッジグラフ 音声検索 この2つとGoogle Nowを合わせた3つのシステムは、今のGoogleのモバイルへの注力と密接に結びついている。 ナレッジグラフと音声検索、Google Nowは他のシステムとともに、「10個の青いリンク」を提供するという形式からこの3年間にGoogle検索の姿を変
入力フォームの「必須」「任意」のラベルは両方付けないとコンバージョン率が下がる
[レベル: 初〜中級] 入力フォームのフィールドには、入力が「必須」なのかまたは「任意」なのかのラベルを両方付けることが推奨されます。 どちらか片方だけだと入力途中の離脱の原因になります。 ECサイトのユーザービリティ調査と最適化を専門に扱っているBaymard Instituteが詳しく解説しています。 15の大手ECサイトのユーザビリティ調査と18の主要なモバイルサイトのユーザビリティ調査、そして自社による最新の大規模なアイトラッキングテストによって実証することができました。 この記事では、その解説の要点をまとめて紹介します。 片方だけの「必須」「任意」ラベルの問題点 入力が「必須」か「任意」かをどちらか片方のラベルだけで示すことにはさまざまな問題点があります。 必須か任意かを示さないのはいちばんよくない そのフィールドの入力が必須か任意かを示さないのはいちばんよくないスタイルです。
ブログの完全HTTPS化を完了、HTTPからHTTPSへの移行プロセスを共有
[対象: 上級] 気付いている人もいるかと思いますが、このブログ全体をHTTPSにしました。 この記事では、備忘録を兼ねて、完全HTTPSへの移行を検討しているサイトの参考になるように僕が実行してきたプロセスをまとめます。 実行した主な作業は次のとおりです。 サーバー証明書の取得 HTTPSへのリダイレクト 内部リンクの修正 各種ツール・パーツのHTTPS動作確認 すべてのコンテンツがHTTPSでダウンロードされているかを確認 WordPressの設定変更 rel=”canonical”の更新 ウェブマスターツールへの登録 サイトマップの更新 ソーシャルシェアの引き継ぎ HSTSの設定 外部リンクの更新 高速化 順に説明します。 1. サーバー証明書の取得 サーバー証明書をまず取得します。 手順は利用しているサーバー会社によって変わってきます。 詳しくはお使いのサーバー会社のヘルプを参照し
コメントも含めたページ全体のコンテンツが品質評価される
[対象: 全員] サイト管理者が作成したメインコンテンツだけでなく、UGCのように外部のユーザーが作ったコンテンツは、たとえそれがコメントであってもそのページの品質を評価する際の対象になります。 したがって、ページ全体としてのクオリティを高めなければなりません。 ユーザーによるコメントもコンテンツの一部 9月末に実行されたパンダアップデートの影響を受けたと思われるサイトの管理者が、その原因と対処方法を英語版のオフィスアワーでGoogleのJohn Mueller（ジョン・ミューラー）氏に質問しました。 ミューラー氏は、ユーザーによって書き込まれたブログへのコメントのチェックをアドバイスの1つとして提案します（注: ユーザーコメントが原因でパンダアップデートに低品質評価されたとは言っていない）。 理由は、コメントも含めたページ全体のコンテンツが品質評価の対象になるからです。 メインコンテンツ
非HTTPSサイトに対して安全ではないとGoogle Chromeが警告を表示するようになるかも
[対象: 中級] Google Chrome ブラウザが、HTTPSではないサイトに対して警告を発するように将来的になるかもしれません。 Chromeのセキュリティチームが提案 Chromeのセキュリティチームは、非HTTPSのリソースがセキュアではないことを表示するようにUXを変更する提案をThe Chromium Projectsに公開しました。 Marking HTTP As Non-Secure – The Chromium Projects HTTPではデータが保護されないことをよりはっきりとユーザーに伝えることが目的です。 2015年に立案し移行に向けての計画を立て始めます。 非セキュアとセキュアの分け方 安全か安全ではないかを、どういう条件のもとでどのように区別し、どんな段階を経て実現していくかを決める必要があります。 提案で挙がっているセキュリティは3レベルです。 Secu
[モバイルSEOツール] PageSpeed Insightsでは合格するのにMobile-Friendly Testでは不合格になる理由
[対象: 中級] Googleは先日、スマートフォンに対応したページが検索結果が表示された際に、「スマホ対応」（英語では“Mobile-friendly”）のラベルを付けるようにしました。 スマホ向けサイトのユーザビリティとユーザーエクスペリエンスを検証するために2つのツールをGoogleは提供しています。 PageSpeed Insights Mobile-Friendly Test また、ウェブマスターツールのFetch as Googleレンダリングでは、スマートフォンとしてチェック可能です。 Mobile-Friendly Testでは問題点が指摘されるのにPageSpeed Insightsでは合格になることがあります。 2つの代表的な理由をGoogleのJohn Mueller（ジョン・ミューラー）氏がGoogle+で説明しました。 モバイル向けツールごとに結果が異なるの2つの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
