Web担当者は7月の危機に備えよ！ 「サイトを開くとChromeが“保護されていない”と警告する」の問い合わせが殺到！？【SEO記事12本まとめ】

今週のピックアップ

Web担当者は7月の危機に備えよ！ 「サイトを開くとChromeが“保護されていない”と警告する」の問い合わせが殺到！？
2月に事前告知した変更実施が迫る （Google Europe on Twitter） 海外情報

illustration by つきのあめだま

グーグルが7月に、HTTPSではないサイトに戒めの鉄槌を下ろす。その影響で、Web担当者のなかには、上司・社内・顧客・株主などから次のような問い合わせが寄せられて困ったことになる人がいるかもしれない

Webサイトを開くと“保護されていない通信”と表示されるのだが、これはどういうことだ？

非HTTPSページ（HTTPページ）に対するChromeブラウザの表示方法に大きな変更が7月に加えられる予定があったことを覚えているだろうか？ 2018年2月に事前告知されていたものだ。

その内容は、すべての非HTTPSページには、アドレスバーに「保護されていない通信」の警告ラベルが表示されるようになるというものだ（シークレットモードかどうかは関係ない）。

この変更が間近に迫り、ヨーロッパ地域のGoogleのツイッター公式アカウントがリマインドしている。

警告ラベルが表示されたからといって、検索ランキングが下がることはない。まったく気にしないユーザーもいることだろう。

とはいえ、Chromeのシェアは高く、自動的にアップデートされる。そのため、あなたのサイトを開いてこの警告が表示されたら不安になって問い合わせてくる人がいても、不思議はない。

もしかしたら役員から「どうなってるんだ！？」と突然叱責されるかもしれないし、株主総会で「これは問題なのではないか」と質問されるかもしれない。

もしあなたのサイトがまだHTTPS化していないのであれば、そうした問い合わせが来ることを覚悟しておくほうがいいかもしれない。

ウェブの世界では確実にHTTPSが標準になりつつある――これは紛れもない事実だ。まだHTTPのままだとしたら、一刻も早くHTTPSへ移行してほしい。

ウェブはHTTPSが当たり前の状況に、Chromeが安全ラベルを撤去予定
一方で非HTTPSページにはさらに厳しく （Google Developers Japan） 国内情報

非HTTPSのページでは、Chromeブラウザが「保護されていない通信」のラベルをアドレスバーに表示するようになる――これは、1つ前の記事でお伝えしたことだ。

しかしグーグルはそれだけでなく、HTTPSに関係する表示方法をさらに変えていく計画だ。具体的には、HTTPSのときは特別な表示を一切しなくするように変えていくのだ。

現在は、HTTPSのページを閲覧しているときには、HTTPSであることを示す「保護された通信」のラベルなどが表示されているはずだ（Chromeでこの記事を読んでいるとしたら、アドレスバーを見てほしい）。

現状のHTTPSページ表示。鍵マーク、「保護された通信」「https:」が表示されている

2018年9月にリリース予定のChrome 69からは、「保護されている通信」ラベルと、URL中の「https://」のスキームを表示しなくなるとのことだ。安全性を示す鍵アイコンだけになる。

2018年9月にリリースされるChrome 69でのHTTPSページ表示。鍵マークだけになり、「保護された通信」と「https:」が表示されなくなる

グーグルは最終的には、鍵アイコンも取り去る予定だ。つまり、HTTPSページには特別なラベルやアイコンが何も付かなくなるのだ。

最終的に落ち着く予定のHTTPSページ表示。HTTPSであることを示す特別な要素はない（サーバー証明書を確認する手段はまだ未定だが、EV SSLの場合は今と同様な表示になる予定だということだ）

こうしていく理由は、ブラウザとWebサーバーの間で安全に通信されていることは当たり前であり、問題がある場合は警告が出されると想定しているからだそうだ。

もし通信が非HTTPならば、危険性を示す警告が出る（ように7月に変わる）ので、安全なHTTPSページにはことさら安全性を示す必要がないとも考えているのだろう。

そして2018年10月リリース予定のChrome 70からは、非HTTPSページにはさらに厳しい仕様変更をするという。ユーザーがHTTP ページにデータを入力すると、「保護されていません」警告が赤色で表示されるようになるのだ。

ページが表示された時点では黒色の「保護されていない通信」ラベルなのだが、そのページでフォームに入力し始めると赤色に変わるという、ユーザーの意識が向きやすい警告表示だ。

グーグルの「HTTPSにあらざる者にWeb上での立ち位置はない」という方針がどんどん進んでいる。もうHTTPSにしないという選択肢はありえないと思っておくほうがよさそうだ。

グーグル検索SEO情報

元グーグル社員からのSEOアドバイス、内部リンクを修正すべし
正規URLを向くように直したらトラフィック増加 （Pedro Dias on Twitter） 海外情報

内部リンクの重要性について、グーグル ブラジルのサーチクオリティチームで以前働いていたペドロ・ディアス氏が強調していた。

少しわかりづらいかもしれないが、ディアス氏のツイートで紹介されているグラフを見てほしい。縦軸が検索エンジンでの強さのような指標で、横軸が時間だ。時間とともに値が上下していて、変化のポイントに「1」「2」「3」とマークしてある。

このツイートは、次のようなことを表している。

1. サイトでサーバーサイドレンダリングのJavaScriptを実装した。しかし、内部リンクが正規URLを指していなかった。

2. サイトがHTTPSへ移行した。しかし、内部リンクが正規URLを指していなかった。

3. サイト内の内部リンクを、正しく正規URLを指すように修正した。

内部リンクを修正すべし！

「SEOに大切なのはコンテンツ」だと言われるが、それでもリンクにまったく意味がなくなったわけではない。特にサイト内リンクには、「コンテンツをグーグルに見つけてもらう」「ページのトピックをグーグルに理解してもらう」といった役割があるほか、PageRankの流れにも関係する。

このサイトの例では、内部リンクを適切に修正したら検索トラフィックが増加しているように見える。

もちろん、比較的長い期間のグラフなので、内部リンクとは関係ない要因によって検索トラフィックが変化している可能性はある。

とはいえ元グーグル社員からのアドバイスでもあるので、正しいURLに内部リンクが設定されているかどうかをチェックしてみることには価値がありそうだ。

MFIに関してよくある質問をグーグルがツイッターで一挙に解決
助かる日本語訳 （金谷 武明 on ツイッター） 国内情報

グーグルのウェブマスターのツイッター公式アカウントが、モバイルファーストインデックスに関してときどき見られる誤解や混乱を解消するための一連の解説を投稿した。原文は英語であるが、金谷氏がポイントを押さえて日本語に訳してくれた。

MFIに関してあなたは正しく理解できていただろうか？

サイトマップに記述するURLの順番は何かに関係してくるのか？
関係なし、記載されていれば準備万端 （John Mueller on Twitter） 海外情報

グーグルのジョン・ミューラー氏に、ツイッターのフォロワーが次のように質問した。

サイトマップに記載するURLの順番は何かに影響しますか？

ミューラー氏は次のように返信した。

URLを並べる順番は関係ない。理想的なのは、サイト内にある全ページのURLが並んでいる状態だ。そうすれば準備万端だ。

ミューラー氏の発言を原文で読むと「重要なURLをサイトマップファイルの先頭のほうに記述する」ようにも読み取れる。しかし、そういった意味ではないとミューラー氏は補足している。そう読める表現の裏側には「サイト内に重要ではないURLなんて存在しないだろう？」というニュアンスがあったということだ。

サイトマップファイルの上のほうに書いてあるURLが優先的にクロールされたりインデックスされたりということはないようだ。確実に記述されていればそれで十分だ。

robots.txtでのサイトマップ送信は必要か？
必要ではないが、面倒でなければ併用するといい （John Mueller on Twitter） 海外情報

サイトマップに関するトピックをもう1つ紹介する。

robots.txtにサイトマップのURLを記述するのは必須でしょうか？

こんな質問をジョン・ミューラー氏がツイッターで尋ねられた。ミューラー氏は次のように答えた。

必須ではない。サイトマップがあることを検索エンジンに伝えるには、さまざまな方法がある。robots.txtである必要はない（が、ほかに劣らない良い方法だ）。

robots.txtは検索エンジンのクロールを制御するために用いる。しかし、サイトマップの送信にも使える。利用しているウェブ担当者も多いことだろう。

たとえば次のような記述をrobots.txt内に加えるのだ。

Google Search Consoleからでもサイトマップを送信できる。これは、Googleに対してだけ有効だ。Bingウェブマスターツールからもサイトマップを送信できる。これはBingに対してだけ有効だ。

対して、robots.txtでのサイトマップ送信は検索エンジンがサポートしてさえいれば共通で有効だ。主だった検索エンジンはrobots.txtによるサイトマップをサポートしている。

Search Consoleとrobots.txtの両方でサイトマップを送信することに、特に大きな価値があるとは思えない。それでも、一回書いておけばいいだけなので、面倒でなければrobots.txtも併用するといいだろう（ただしサイトマップファイルのURLを変更したら書き換えなければいけない設定が増えるということでもある点には注意が必要だ）。