Web担当者は7月の危機に備えよ！ 「サイトを開くとChromeが“保護されていない”と警告する」の問い合わせが殺到！？【SEO記事12本まとめ】
「世界HTTPS化計画」をグーグルが強力に推進している。今週は、ChromeでのHTTPS／HTTPS表示に関する重要な変更の情報を2つお届けする。HTTPS化がまだのサイトも済んでいるサイトも、どちらも把握しておくべき情報だ。
ほかにも、「元グーグル社員が内部リンクの重要性を数字で説明」「現役グーグル社員がMFIのFAQを日本語で解説」「サイトマップ」「ヤフーがグーグルよりも早く検索結果を改善」「直帰率・滞在時間の思い込み」などなど、SEOに役立つ情報をまとめてお届けする。
今週のピックアップ
Web担当者は7月の危機に備えよ！ 「サイトを開くとChromeが“保護されていない”と警告する」の問い合わせが殺到！？
2月に事前告知した変更実施が迫る （Google Europe on Twitter） 海外情報
グーグルが7月に、HTTPSではないサイトに戒めの鉄槌を下ろす。その影響で、Web担当者のなかには、上司・社内・顧客・株主などから次のような問い合わせが寄せられて困ったことになる人がいるかもしれない
Webサイトを開くと“保護されていない通信”と表示されるのだが、これはどういうことだ？
非HTTPSページ（HTTPページ）に対するChromeブラウザの表示方法に大きな変更が7月に加えられる予定があったことを覚えているだろうか？ 2018年2月に事前告知されていたものだ。
その内容は、すべての非HTTPSページには、アドレスバーに「保護されていない通信」の警告ラベルが表示されるようになるというものだ（シークレットモードかどうかは関係ない）。
この変更が間近に迫り、ヨーロッパ地域のGoogleのツイッター公式アカウントがリマインドしている。
警告ラベルが表示されたからといって、検索ランキングが下がることはない。まったく気にしないユーザーもいることだろう。
とはいえ、Chromeのシェアは高く、自動的にアップデートされる。そのため、あなたのサイトを開いてこの警告が表示されたら不安になって問い合わせてくる人がいても、不思議はない。
もしかしたら役員から「どうなってるんだ！？」と突然叱責されるかもしれないし、株主総会で「これは問題なのではないか」と質問されるかもしれない。
もしあなたのサイトがまだHTTPS化していないのであれば、そうした問い合わせが来ることを覚悟しておくほうがいいかもしれない。
ウェブの世界では確実にHTTPSが標準になりつつある――これは紛れもない事実だ。まだHTTPのままだとしたら、一刻も早くHTTPSへ移行してほしい。
- HTTPSに移行していないすべてのWeb担当者 必見！
ウェブはHTTPSが当たり前の状況に、Chromeが安全ラベルを撤去予定
一方で非HTTPSページにはさらに厳しく （Google Developers Japan） 国内情報
非HTTPSのページでは、Chromeブラウザが「保護されていない通信」のラベルをアドレスバーに表示するようになる――これは、1つ前の記事でお伝えしたことだ。
しかしグーグルはそれだけでなく、HTTPSに関係する表示方法をさらに変えていく計画だ。具体的には、HTTPSのときは特別な表示を一切しなくするように変えていくのだ。
現在は、HTTPSのページを閲覧しているときには、HTTPSであることを示す「保護された通信」のラベルなどが表示されているはずだ（Chromeでこの記事を読んでいるとしたら、アドレスバーを見てほしい）。
2018年9月にリリース予定のChrome 69からは、「保護されている通信」ラベルと、URL中の「https://」のスキームを表示しなくなるとのことだ。安全性を示す鍵アイコンだけになる。
グーグルは最終的には、鍵アイコンも取り去る予定だ。つまり、HTTPSページには特別なラベルやアイコンが何も付かなくなるのだ。
最終的に落ち着く予定のHTTPSページ表示。HTTPSであることを示す特別な要素はない（サーバー証明書を確認する手段はまだ未定だが、EV SSLの場合は今と同様な表示になる予定だということだ）
こうしていく理由は、ブラウザとWebサーバーの間で安全に通信されていることは当たり前であり、問題がある場合は警告が出されると想定しているからだそうだ。
もし通信が非HTTPならば、危険性を示す警告が出る（ように7月に変わる）ので、安全なHTTPSページにはことさら安全性を示す必要がないとも考えているのだろう。
そして2018年10月リリース予定のChrome 70からは、非HTTPSページにはさらに厳しい仕様変更をするという。ユーザーがHTTP ページにデータを入力すると、「保護されていません」警告が赤色で表示されるようになるのだ。
ページが表示された時点では黒色の「保護されていない通信」ラベルなのだが、そのページでフォームに入力し始めると赤色に変わるという、ユーザーの意識が向きやすい警告表示だ。
グーグルの「HTTPSにあらざる者にWeb上での立ち位置はない」という方針がどんどん進んでいる。もうHTTPSにしないという選択肢はありえないと思っておくほうがよさそうだ。
- すべてのWeb担当者 必見！
グーグル検索SEO情報
元グーグル社員からのSEOアドバイス、内部リンクを修正すべし
正規URLを向くように直したらトラフィック増加 （Pedro Dias on Twitter） 海外情報
内部リンクの重要性について、グーグル ブラジルのサーチクオリティチームで以前働いていたペドロ・ディアス氏が強調していた。
少しわかりづらいかもしれないが、ディアス氏のツイートで紹介されているグラフを見てほしい。縦軸が検索エンジンでの強さのような指標で、横軸が時間だ。時間とともに値が上下していて、変化のポイントに「1」「2」「3」とマークしてある。
このツイートは、次のようなことを表している。
サイトでサーバーサイドレンダリングのJavaScriptを実装した。しかし、内部リンクが正規URLを指していなかった。
サイトがHTTPSへ移行した。しかし、内部リンクが正規URLを指していなかった。
サイト内の内部リンクを、正しく正規URLを指すように修正した。
内部リンクを修正すべし！
「SEOに大切なのはコンテンツ」だと言われるが、それでもリンクにまったく意味がなくなったわけではない。特にサイト内リンクには、「コンテンツをグーグルに見つけてもらう」「ページのトピックをグーグルに理解してもらう」といった役割があるほか、PageRankの流れにも関係する。
このサイトの例では、内部リンクを適切に修正したら検索トラフィックが増加しているように見える。
もちろん、比較的長い期間のグラフなので、内部リンクとは関係ない要因によって検索トラフィックが変化している可能性はある。
とはいえ元グーグル社員からのアドバイスでもあるので、正しいURLに内部リンクが設定されているかどうかをチェックしてみることには価値がありそうだ。
- SEOがんばってる人用（ふつうの人は気にしなくていい）
MFIに関してよくある質問をグーグルがツイッターで一挙に解決
助かる日本語訳 （金谷 武明 on ツイッター） 国内情報
グーグルのウェブマスターのツイッター公式アカウントが、モバイルファーストインデックスに関してときどき見られる誤解や混乱を解消するための一連の解説を投稿した。原文は英語であるが、金谷氏がポイントを押さえて日本語に訳してくれた。
MFIに関してあなたは正しく理解できていただろうか？
- すべてのWeb担当者 必見！
サイトマップに記述するURLの順番は何かに関係してくるのか？
関係なし、記載されていれば準備万端 （John Mueller on Twitter） 海外情報
グーグルのジョン・ミューラー氏に、ツイッターのフォロワーが次のように質問した。
サイトマップに記載するURLの順番は何かに影響しますか？
ミューラー氏は次のように返信した。
URLを並べる順番は関係ない。理想的なのは、サイト内にある全ページのURLが並んでいる状態だ。そうすれば準備万端だ。
ミューラー氏の発言を原文で読むと「重要なURLをサイトマップファイルの先頭のほうに記述する」ようにも読み取れる。しかし、そういった意味ではないとミューラー氏は補足している。そう読める表現の裏側には「サイト内に重要ではないURLなんて存在しないだろう？」というニュアンスがあったということだ。
サイトマップファイルの上のほうに書いてあるURLが優先的にクロールされたりインデックスされたりということはないようだ。確実に記述されていればそれで十分だ。
- SEOがんばってる人用（ふつうの人も気にしたいところ）
robots.txtでのサイトマップ送信は必要か？
必要ではないが、面倒でなければ併用するといい （John Mueller on Twitter） 海外情報
サイトマップに関するトピックをもう1つ紹介する。
robots.txtにサイトマップのURLを記述するのは必須でしょうか？
こんな質問をジョン・ミューラー氏がツイッターで尋ねられた。ミューラー氏は次のように答えた。
必須ではない。サイトマップがあることを検索エンジンに伝えるには、さまざまな方法がある。robots.txtである必要はない（が、ほかに劣らない良い方法だ）。
robots.txtは検索エンジンのクロールを制御するために用いる。しかし、サイトマップの送信にも使える。利用しているウェブ担当者も多いことだろう。
たとえば次のような記述をrobots.txt内に加えるのだ。
Sitemap: https://www.exmaple.com/sitemap.xmlGoogle Search Consoleからでもサイトマップを送信できる。これは、Googleに対してだけ有効だ。Bingウェブマスターツールからもサイトマップを送信できる。これはBingに対してだけ有効だ。
対して、robots.txtでのサイトマップ送信は検索エンジンがサポートしてさえいれば共通で有効だ。主だった検索エンジンはrobots.txtによるサイトマップをサポートしている。
Search Consoleとrobots.txtの両方でサイトマップを送信することに、特に大きな価値があるとは思えない。それでも、一回書いておけばいいだけなので、面倒でなければrobots.txtも併用するといいだろう（ただしサイトマップファイルのURLを変更したら書き換えなければいけない設定が増えるということでもある点には注意が必要だ）。
- SEOがんばってる人用（ふつうの人は気にしなくていい）
- 日本ではグーグルよりも早くヤフーが検索結果で医療情報の提供を開始
- 滞在時間が短くても直帰率が高くても、優れたUXになりうる
- はてなブログが独自ドメイン名でもHTTPSをサポート開始
- BingはJavaScriptコンテンツをレンダリングできるのか？
- JavaScriptによるnoindex挿入をGoogleは推奨せず、JSレンダリングはセカンドウェーブのインデックス
- Googleが2017年に手動で対策したウェブスパムは600万件
Web担当者に役立つ最新情報
日本ではグーグルよりも早くヤフーが検索結果で医療情報の提供を開始
専門機関と提携した信頼性がおける情報 （Yahoo! 検索ガイド） 国内情報
ヤフーは、検索結果画面で各種疾病に関する情報を改善した。具体的には、医療の専門機関と提携し、信頼性が置ける情報をユーザーに届けるようにした。
対象となる検索ワードはインフルエンザ・高血圧などの一般的な疾病や、脳卒中・関節リウマチなどの約1,000種で、今後も拡大していく予定とのことだ。
健康に関して信頼できる結果を提供することに検索エンジンは腐心している。ヤフーの取り組みが、不確かな医療情報の検索結果からの駆逐に役立つことを期待したい。
こうしたヤフーの動きは地味ではあるが非常に価値があるものだ。業界としても、インターネットユーザーとしても、高く評価したい。
なおグーグルも、病気に関する各種情報をナレッジパネルに掲載しているのだが、日本ではまだ導入されていない（なぜか「ジカ熱」だけが提供されているが）。
- SEOがんばってる人用（ふつうの人は気にしなくていい）
滞在時間が短くても直帰率が高くても、優れたUXになりうる
ユーザーがやりたかったことを完了させる （Rand Fishkin on Twitter） 海外情報
ランド・フィッシュキン氏のツイッターの投稿を紹介する。
「短い滞在時間で、高い直帰率」は、果たして良いことなのだろうか？
良いことだ！
検索者・訪問者の疑問ややりたいことが、基本的で時間がかからないようなものであるならば、それをすばやく解決すれば、彼らはやるべきことにすぐに戻れる。理想的なユーザー体験だ。
あなたは、次のように思い込んでいないだろうか。
- 滞在時間は長いほうが良い
- 直帰率は低いほうが良い
基本的には間違っていないのだが、これらが常に正しいとは限らない。
たとえば、「東京とロサンゼルスの時差」や「frogとtoadの違い（日本語ではどちらもカエル）」といった検索の場合はどうだろう。どちらも、緊急性や深刻度がさほど高くなく、簡単に解決できる疑問だ。長々と冗長に説明する必要はない。
ユーザーの検索意図によっては、すばやく簡単にそれを満たすこともユーザー体験としては優れている。そうした場合に滞在時間が短く直帰率が高くなるのは、気にしなくていいはずだ。
もちろん、ダメな「滞在時間が短く、直帰が多い」ケースもある。それは、ユーザーが「検索結果ページ」→「あなたのページ」→「すぐに検索結果ページに戻る」→「別のページに行く」という行動になってしまう場合だ。これは、ユーザーのニーズを満たしていない。
- ユーザーが疑問に思っていたことを完璧に解決する
- ユーザーが望んでいるものを確実に提供する
直帰率を下げたり滞在時間を伸ばしたりするのを金科玉条とするのではなく、ユーザーの検索ニーズをスムーズに満たす手助けをすることが、ユーザー体験を高めるうえで重要だ。
（残念ながら最近のグーグルのアルゴリズムには、こうした本質から離れてしまう要素がなくもない気がしないでもないが）
ちなみに、ランドによるこのツイートには非常に多くのコメントや返信がついており、興味深いものも多い。すべて日本語にして紹介できないのが残念だが、ぜひ確認していってほしい。
- すべてのWeb担当者 必見！
はてなブログが独自ドメイン名でもHTTPSをサポート開始
上級者ほど待ち望んでいた変更 （はてなブログ開発ブログ） 国内情報
はてなブログのシステムを利用して独自ドメイン名で運用されているブログも、HTTPS化できるようになった。これまでは、はてなが提供しているドメイン名を使ったブログだけがHTTPSに対応していた。
上級者ほど独自ドメイン名で運用していたはずで、今回のHTTPS対応は待ちに待っていた変更だろう。しかしいざ実際に移行すると、トラブルが発生するケースも少なくないようだ。移行前には情報収集し、入念に準備したほうがいいだろう。
- はてなブログを独自ドメイン名で運用している人のみ
BingはJavaScriptコンテンツをレンダリングできるのか？
できなくはないが、信頼できない （Screaming Frog） 海外情報
グーグルはJavaScriptで生成されたコンテンツを、完璧ではないにしてもかなり上手にインデックスできるようになっている。
では、Bingはどうなのだろうか？
JavaScriptコンテンツをBingがどのように認識するかを、20ほどのサイトで検証した結果が公開されている。
結果を簡潔に言うと、JavaScriptコンテンツをBingはインデックスできなくはないが、信頼できるレベルではないようだ。どういった条件だとJavaScriptを実行してコンテンツを正常にレンダリングでき、どういった条件だとレンダリングできないのかのパターンもつかめなかった。
日本ではBingはさほど重視されない検索エンジンだが、米国では一定のシェアを保っている。Bingからの検索トラフィックを無視できないサイトを運営しているのであれば、JavaScriptを用いてクライアントサイドでレンダリングさせるページは、依然としてSEOには不向きだと認識しておいたほうがいいだろう。
- ふつうの人は気にしなくていい
掲載記事からピックアップ
JSレンダリングとスパム対策に関する記事を今週はピックアップ。
- JavaScriptによるnoindex挿入をGoogleは推奨せず、JSレンダリングはセカンドウェーブのインデックス
JSレンダリングは時間がかかる
- ホントにSEOを極めたい人だけ
- 技術がわかる人に伝えましょう
- Googleが2017年に手動で対策したウェブスパムは600万件
600万件のペナルティってこと!?
- SEOがんばってる人用（ふつうの人は気にしなくていい）
ソーシャルもやってます!