ウェブサイトのSSL化+モバイルフレンドリー化。必要なリダイレクト設定と、ページソースの記述方法。

当店HPを、まとめてモバイルフレンドリー+常時SSL化を同時に行う際に経験した、注意点をまとめております。きちんと設定しないと、次のような問題が発生します。

Google のインデックスに、http:// と https://の両方が登録され、双方の評価点が分散してしまい、検索順位が下がる。
同様に、ソーシャルの「いいね」や「シェア」も分散され、正しく反映されない。
スマホ版について、トップページのみ正しくリダイレクトしても、個別ページが個別にリダイレクトされていなければ、個別ページに関してはモバイルフレンドリーとはみなされず、これも検索順位が下がる。
誤ってhttp://　でリクエストされたアクセスが通ってしまうと、セキュリティ上のリスクがある。

Googleの「モバイルフレンドリーアルゴリズム」に適合したウェブサイトの構築

Googleは、2015年4月21日の公式ブログで「モバイルフレンドリーアップデートを開始します」と発表し、検索結果に反映させ始めました。

※2017/01より、Googleはこれを一歩すすめ、「モバイルファーストインデックス」の実装を開始しました。

これにより、Googlebotのクロールは、「PCページを基準にインデックス」から、「モバイルページを基準にインデックス」に大きく変わりました。

スマートフォンの普及で、パソコンからではなくスマホからの検索トラフィックが増加しきてました。スマホのような画面が小さい端末でも情報が読み取れるウェブページの普及が、今後のインターネットの普及にとって死活問題である、(Googleの広告収入の維持のための死活問題!)という観点でのアップデートです。

対応方法や仕様の詳細は、モバイルフレンドリーなサイトにするためのガイドページ　に詳しく記されています。

この方法にのっとって、正しく「モバイルフレンドリー化」されていれば、それはサイトの検索順位を上昇させる一要素として働きます。

ウェブサイトを「常時SSL化」することの意義

当教室のウェブサイトは、現在すべてのページが「https://」で始まる、常時SSL化されたサイトです。

これは、閲覧している端末とサーバーの間の通信が、すべて暗号化され、中間で傍受されても中身が解読されない、という意味です。インターネットは、電話回線などと違って、たくさんのサーバーの間を通信回線で結んで構成されており、通信経路上のサーバーからは、通信内容がすべて見えるようになっています。ですので、暗号化していなければ、悪意のある第三者から簡単に通信の中身が丸見えになってしまいます。このため、通信内容を暗号化する技術が必要になるのです。

正確には、「SSL」という暗号化アルゴリズムには脆弱性が見つかっており、100%安全ではないことから、現在は「TLS」というアルゴリズムで暗号化されています。ただ、「SSL」という言葉が「暗号化」とほぼ同義の語として定着していることから、慣用的に「SSL化」という表現が使われています。現在読んでいただいているこの記事をGoogle Chromeブラウザで表示し、「F12」キーでデベロッパーモードにして、「Securty」タブを選択すると、「Secure TLS Connection」と表示され、TLSによって暗号化されていることが分かります。

このように「常時SSL化」されたウェブサイトについても、Googleは「検索で優遇する」と明言しています。Googleがこのような方針を実行した意義は、どこにあるのでしょうか?

SSL化の意義として、とても分かりやすいのは、サイト内で氏名、住所、クレジットカード番号などを入力するサイトの場合です。このような場合には、非常に直接的な意味で個人情報が通信に含まれますので、通信経路上で内容が漏えいしない、ということは必須条件となります。このため、入力フォームのあるページだけをSSL化する、ということは、従来から広く行われてきました。

しかし、すべてのページを暗号化する「常時SSL化」は、対象がさら広く、その背景にある考え方は大きくちがうものです。あるコンピュータからあるサイトを見ている、という事実自体を第三者から見えないようにし、「興味・関心、関係性」という広い意味での個人情報を保護する、ということになります。つまりこの「常時SSL化」は、インターネットという通信手段そのものを、「いつでも情報が洩れる」不確かなものから、「常に通信の秘密が守られ、信用に値する通信手段」に変える、という目的をもっているのです。

Googleが、このようにSSL化されたサイトを優遇する、ということは、このように、個々のサイトの利害を超えてインターネット全体をセキュアなものに変え、ひいてはGoogleの広告ビジネス・決済ビジネスの発展につなげよう、という意図をもっているのです。

実際に必要な作業

※注　この記事公開後、当店ウェブサイトは再度のリニューアルを行い、現在はレスポンシブデザインを採用しております。現時点の当店ウェブサイトには、この記事はあてはまりませんのでご注意ください。

当店HPは

https://curio-shiki.com/　を親として、　/sp/がスマホ版、　　　/blog/がブログ、という構造となっております。ブログ部分は、wordpressでレスポンシブ化しております。

これを正しく「スマホ対応」のページとして検索エンジンに認識させ、なおかつ常時SSL化するにあたって、必要だった作業を列挙しますと、

ルートディレクトリの.htaccessで、https://にリダイレクト
スマホエージェントに対応したリダイレクトの細かな設定
PC版スマホ版各ページで、相互に対応関係を記述(link rel=”alternate” <> link rel=”canonical”)
wordpress部分に独自の設定

常時SSL化～ルートディレクトリの.htaccessで、https://にリダイレクト

http://～で来たリクエストを、301リダイレクトでhttps://～に転送します。リダイレクトコード「301」は、「恒久的なリダイレクト」を意味し、「リダイレクト元のURL(SSLでないhttp://～の方)はインターネット上に存在しない」という意味を、Googlebotを含む全閲覧者に通知する意味を含んでいます。

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://curio-shiki.com/$1 [R=301,L]

スマホエージェントに対応したリダイレクトの細かな設定

単に　「ユーザーエージェント(UA)がスマホであれば/sp/にリダイレクトすればよい」ように見えましたが、実際は違いました。そのような単純な実装を行うと、.css や .js 、.jpegまでリダイレクトしてしまい、スマホからPC版に”?mode=pc”付きでアクセスした際、画像やメニューが表示されなくなるのです。

そこで、PC版の.htmlからのリンクでしかアクセスされないこれらのPC版パーツを、すべてRewriteCond ～![parts] で回避しました。

RewriteCond %{HTTP_USER_AGENT} (iPhone|Android.*Mobile|Windows.*Phone) [NC]
RewriteCond %{QUERY_STRING} !mode=pc
RewriteCond %{REQUEST_URI} !/sp/
RewriteCond %{REQUEST_URI} !(^/blog/)
RewriteCond %{REQUEST_URI} !(navi\.html)
RewriteCond %{REQUEST_URI} !(news\.html)
RewriteCond %{REQUEST_URI} !(slider\.html)
RewriteCond %{REQUEST_URI} !(\.js)$
RewriteCond %{REQUEST_URI} !(\.css)$
RewriteCond %{REQUEST_URI} !(\.jpg)$
RewriteCond %{REQUEST_URI} !(\.png)$
RewriteCond %{REQUEST_URI} !(\.gif)$

RewriteRule ^(.*)$ https://%{HTTP_HOST}/sp%{REQUEST_URI} [R=302,L]

こちらのリダイレクトは、301ではなく302を用いています。Googleの推奨は302です。これは、「一時的なリダイレクト」の意味があり、「PC版は存在するが、今回のアクセスはスマホなので、こちらのURLに飛ばします」という意味を持ちます。

Search Console上で、URLパラメータの無効化

上記に関連して、スマホ版からPC版を参照する場合のURLパラメータ「?mode=pc」をクロールしない設定をする必要がありました。こうしないと、スマホ版のGooglebotが「?mode=PC」付きのPC版ページをインデックスしてしまい、モバイルフレンドリーでないと認識されてしまうのです。

このため、Search Consoleの「URLパラメータ」の設定で、パラメータ「mode」だけが違うURLをクロールしない設定を行いました。

PC版スマホ版各ページで、相互に対応関係を記述

ウェブサイトをモバイルフレンドリー化する上で、ベストな方法は「レスポンシブ化」することです。これは、同一のURLをサイズの違う端末で見た場合に、CSSによって表示を分け、適切なレイアウトで表示されるようにすることですが、どちらでも見やすいようなレスポンシブ表示をするには、高い技術が必要です。

当教室のサイトは、現在レスポンシブ化の作業を進めており、ブログだけは現在レスポンシブで表示しています。しかし、教室サイト本体の方は、PC版・スマホ版別々のURLに、別々のコンテンツを配置することによって、スマホ対応を行っています。

このような場合には、PC版、スマホ版の各ページを、ソース内に特定のタグを記述することによって、相互に関連付けます。Googleの公式ブログで推奨されている方式です。

こうすることで、Googlebotがクロールした際、PC版・スマホ版を正しく認識し、インデックスにはPC用もモバイル用も、すべてPC版のURLが代表(canonical)として登録されるようになります。

PCサイト側　<link rel="alternate" media="only screen and (max-width: 640px)" href="https://curio-shiki.com/sp/" />
スマホサイト側　<link rel="canonical" href="https://curio-shiki.com/index.html" />

ここに記述するURLも、すべてhttps://で統一します。

なぜこんなことをするかといいますと、関連付けをしていない場合、PC版のGooglebotとモバイル版のGooglebotが、両方とも、当教室のPC版とスマホ版の両方をクロールしてしまうのです。

その結果、次のようなことが起こります。

ほとんど同内容のウェブサイトが2個あるように認識され、インデックスのスコアが分散する
検索結果にPC版とスマホ版が混在して掲載され、ユーザーにとって非常に分かりにくい
PC版サイトに「モバイルフレンドリーではない」というエラーがついてしまい、検索順位が下がる
SNSで「いいね」や「シェア」をされた場合に、その記録が「そのときいいね!された方の版」に紐づいてしまう。例えば、PCで2回、スマホで2回いいね!された場合、トータル4いいね!ですが、きちんと紐づけていないと、「それぞれ2回」となり分散してしまいます。

また注意しなければならないのは、トップページのみにこのような施策を施しても、十分な施策とは言えない、という点です。

当教室の場合も、サイト立ち上げ時はトップベージのみに、しかもリダイレクトだけかけていました。その結果、Search Consoleに大量の「モバイルフレンドリーのエラー」が表示されてしまいました。また、特定のキーワードに対してはスマホ版のみが上位表示される、といった現象も起きていました。

検索からのアクセスはトップページのみでよい、という場合には、トップページのみの施策で十分なようにも思えますが、これは間違いです。トップページの検索順位は、各個別ページの検索順位と関連があります。特に最近は、クロール技術の進歩により、個別のキーワードの検索結果に個別ページが掲載される例が増えてきました。そうなると、せっかく個別ページに作りこんだコンテンツがあるのに、みすみす上位表示を逃したり、個別ページのクリック率が下がることによりトップページの順位にも影響が出る、といったことが起こります。

ですので、Googleのガイドラインが示すとおり、個別ページのすべてに対して、リダイレクト+タグの記述によって、正しく紐づけする必要があるのです。

wordpress独自の設定。/blog/ディレクトリでも、https://にリダイレクト

WordPressは、インストールフォルダに独自の.htaccessを持っています。これを書き換えないと、ルートディレクトリのリダイレクトが無効となり、ブログのところだけhttp:// のアクセスが通ってしまいます。

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

また、Wordpressの一般設定で、サイト名をhttps://～に変更します。
以上の結果を、実際にご覧いただきたいところなんですが、

https://curio-shiki.com/は、レスポンシブデザインにリニューアルしたため、残念ながら現在サンプルはございません。

ぜひ、ご自身のサイトとSearch Consoleで、効果をご確認ください。