モバイルファーストインデックスまとめ

モバイルファーストインデックスまとめ

昨年10月にSEO関連のセミナーに参加した際にわかりやすく教えていただいたので、まとめます!

その前に、インデックスって?

新しく制作したウェブサイトをインターネット上に公開すると、何らかの形でGoogleに見つけてもらいます。(後述)
Googleは新しいウェブサイトを見つけると、ボットと呼ばれるサイトの中身を調べるプログラムを使って情報をストックします。
Googleはストックした情報を整理しておきます。これがインデックスされた状態となります。

Googleに見つけてもらうには?

サーチコンソールでクロールのリクエスト等を行います。
具体的には

・URL検査ツールにて、該当のURLを入力し、インデックス状況を確認します。
インデックスされていない場合は、[インデックス登録をリクエスト] を行うことにより、インデックス登録のリクエストができます。

・サイトマップを送信します。
URL検査ツールはURLひとつずつしかできないため、新しくウェブサイトを立ち上げる場合は、こちらを利用します。

これらについて詳細は、Googleサーチコンソールヘルプページを参照ください。
※既にGoogleが知っている他のサイトやブログ記事等からリンクが貼られている場合は、そのリンクを辿ってGoogleボットが見つけてくれることもあります。

ユーザーがGoogleで検索すると?

検索されたキーワードに関連性の高いものから順に、最新のインデックスから検索結果に配信されます。

モバイルファーストインデックスって?

ウェブサイトを調査するボットには2種類あります。

・PCサイト版ボット
・スマホサイト版ボット

2018年3月のモバイルファーストインデックス実装までは、PCサイト版ボットが集めてきた情報をメイン、スマホサイト版ボットの情報をサブとして情報をストックし、インデックスしていました。

<PCサイトとスマホサイトが別URLで存在する場合>

PCサイトの情報がGoogleへ保存・インデックスされ、検索結果へ配信されていました。

しかし、PCサイトと違うURLにてスマホサイトがある場合、スマホの画面サイズに適応させるため、PCサイトより情報量が削減されている場合があります。
(PCサイトにはあって、スマホサイトにはない情報がある場合があるということです。)

スマホからGoogle検索した際、上記の状態だと、検索では表示されるのに、実際のサイトには該当の情報がない状況があるということになります。

もう3年以上前からPCよりもスマホからの検索クエリーの方が多いということもあり、更にこのような問題も解決するためにも、モバイルファーストインデックスが実装され、スマホサイト版ボットが集めてきた情報をメイン、PCサイト版ボットの情報をサブとしてストックされるようになったようです。

<PCサイトとスマホサイトが別URLで存在する場合>

スマホサイトの情報が優先してGoogleへ保存・インデックスされ、検索結果へ配信されるようになりました。
→スマホでの検索には、スマホサイトの情報が必ず配信されるようになりました。

ということは・・

今度は逆に、PCサイトとスマホサイトのURLが異なる場合、PC向けの情報をスマホサイトにも入れておかないと、モバイルファーストインデックス前のスマホ検索と同様、検索結果には表示されるのに実際のサイト内には情報がない状態となりますね。

以上のことから・・

モバイル対応は個別のサイト制作ではなく、レスポンシブデザインが推奨ということですね!
スマホ出始めの頃に制作したウェブサイトで、非レスポンシブデザインの場合は、これを機にレスポンシブ化を検討してみるとよいかもですね!

PCサイトのみの場合・・

PCからの閲覧のみを想定しているウェブサイト(PCサイトのみ)の場合は、モバイルファーストインデックスは影響がないみたいです。

どういうことかというと・・

PCサイトのみの場合は、PCサイト版ボットの情報でインデックスされるため、検索結果に変動がありません。

”スマホからの閲覧・検索が不要なサイト”というのは、サイトの保有者のポリシーによるので、具体的な例が出しにくいですが、
モバイルフレンドリーはGoogleからすると、推奨ではあるが必須ではない という見解のようですね。

サーチコンソールの使用方法やCanonicalAMP等、Canonicalタグやhreflangタグ等、調べた内容をまた記事にしたいと思います。

ホームページの脆弱性診断 その2

ホームページの脆弱性診断 その2

前回は簡単・無料で脆弱性診断ができるツール「OWASP ZAP」をご紹介しました。
※前回記事はこちら

今回はお仕事で何サイトか簡易診断した際に、よく検出された脆弱性について、その説明と対策方法をご紹介します。

その前に、OWASP ZAP での診断実行についてですが、今回はクイックスタートにて検査しました。

ブラウザと連動させ、コンテキストを追加して・・・

っていう、本格的な使い方については、私もまだ数回しか行ったことがないため、
わかりやすく説明できるようになってからまた記事を書きます。

OWASP ZAPを起動します

※結構時間かかりますが、フリーズではありません。気長に待ちましょう。

とりあえず、「現在のタイムスタンプで・・・」の選択でOKです。
OWASP ZAP起動

右上項目のURL欄に診断するサイトのURLを入力します。
OWASP ZAPクイックスタート

※くれぐれも関係のないサイトへのアタック(攻撃)には使わないでくださいね。

当サイトの脆弱性については、対策後に記事にします。

よく検出される脆弱性

今まで診断したサイトでほぼ確実に検出された脆弱性について、ご紹介します。

X-Frame-Optionsヘッダーの欠如

リスク:Medium

説明:「クリックジャッキング」攻撃を防止するためのX-Frame-OptionsヘッダーがHTTPレスポンスに含まれていません。

対策:.htaccess へ Header always append X-Frame-Options SAMEORIGIN(同一ドメイン内からのiframeのみ許可)もしくは、Header always append X-Frame-Options DENY を記載することで対策可能です。

X-Content-Type-Optionsヘッダの設定ミス

リスク:Low

説明:ウェブブラウザの中には、HTML内にContent-Typeとして指定してあった場合でも、HTTPレスポンス全体を検査(sniffing)してコンテンツタイプを独自に判断し、「Content-Type」を無視した動作を行うものが存在します。このsniffingを防止するのが「X-Content-Type-Options」です。

対策:.htaccess へ Header always set X-Content-Type-Options “nosniff” を記載することで対策可能です。

WebブラウザのXSS防止機能が有効になっていません。

リスク:Low

説明:ウェブブラウザのXSS防止機能が有効になっていない、またはウェブサーバーからのHTTPレスポンスヘッダ ‘X-XSS-Protection’ が無効になっています。

対策:.htaccess へ Header always set X-XSS-Protection “1; mode=block” を記載することで対策可能です。

Cross-Domain JavaScript Source File Inclusion

リスク:Low

説明:別ドメインから1つ以上のスクリプトファイルが含まれています。

対策:検出されたコードを確認し、問題ないコード(GoogleAnalyticsのトラッキングコード等)の場合は対策不要です。
不要なスクリプトコードが検出される場合は、念のために削除しておいた方がよいです。

まとめ

上記の対策の際に追加したコードは下記です。

もし同じ脆弱性が検出される場合は、参考にしていただければと思います。

次回は、他に検出された脆弱性と対策をご紹介します。

特にMovableTypeサイトの脆弱性は少し厄介でした。

WordPressサイトのURL正規化+常時SSL化まとめ

WordPressサイトのURL正規化+常時SSL化まとめ

昔はURL正規化だけでよかったですが、今は常時SSLも含めて、サイト公開時にURL正規化処理が必要になりました。

URL正規化の詳細については別記事にまとめていますので、そちらを参考にお願いします。

先日、Wordpress+常時SSLで、URL正規化を行ったのでまとめてみます!

※当サイトのURLを使って解説します。

—————————–

1.まずは、自分のサイトの正規なURLを決めます!

www有りなのか、なしなのか?

好みによりますが、私はできるだけ短い方が好きなので、wwwは基本的に付けません。

この正規なURLは、
SSL証明書を取得する際に設定するCommon Name(コモンネーム)と同じURLにします。
逆に言うと、
正規なURLをコモンネームにして、SSL証明書を発行しましょう。

2.Wordpress内で設定をします。

正規なURLを決めたら、それをWordpressに設定をします。
SSLの取得が完了している場合は、https://で設定しましょう。

※wwwなしを正規なURLとする場合

wordpress設定wwwなしの場合

wordpress設定wwwなしの場合

3.リダイレクト設定を行います。(その1)

WordPressを設置したディレクトリに”.htaccess”というデータがあると思うので、下記のように追記します。

◆Wordpressにて自動的に記述された下記のに、

◆下記を追記します。 
※” https://nov.tokyo/index.html”、” http://nov.tokyo/index.html”を”https://nov.tokyo/”へリダイレクト。

参考:www有に正規化する場合

4.リダイレクト設定を行います。(その2)

.htaccessに下記を追記します。

◆下記の記述のに、

◆下記を追記します。 
※” https://www.nov.tokyo/”、” http://www.nov.tokyo/”を”https://nov.tokyo/”へリダイレクト。

参考:www有に正規化する場合

5.最後に常時SSL化します。

.htaccess下部へ追記します。

ここでハマったのですが、
取得したSSL証明書が”SANs”対応であれば、www有となしの両方のURLにてSSL証明書を設定しておく必要があるようです。
この対応をしていないと、URL正規化の過程でSSL証明書エラーが起き、正常にアクセスができません。

さくらインターネットやロリポップ、エックスサーバーなど有名どころは対応しているみたいです。
CPI-SSLはSANs未対応のようです。

まとめ 当サイトURLの箇所を自サイトのURLへ置き換えて確認してください。

※wwwなしへ正規化

※www有へ正規化

何かの参考になれば幸いです。

URL正規化とは

URL正規化とは

外部サイトから自サイトへリンクを貼られる際、色んなパターンがあります。

URLのパターン

※当サイトのURLの場合

https://nov.tokyo/
https://nov.tokyo/index.php
https://nov.tokyo/index.html
https://www.nov.tokyo/
http://nov.tokyo/
http://nov.tokyo/index.php
http://nov.tokyo/index.html
http://www.nov.tokyo/

もし、上記のどのアドレスへリンクされても同じホームページが表示される場合でも、検索エンジンからはそれぞれ異なるサイトとして評価されます。

これは、被リンクが別々にカウントされるということです。
要するに、被リンクパワーが分散します。
これはもったいないですよね?

そこで、301リダイレクトを使って、ひとつの正規なURLへ検索エンジンからの見方を一本化させ、被リンクパワーを漏れなく受け取るというのが、SEO対策の意味でのURL正規化となります。

また、SSL証明書を取得する際にCommon Name(コモンネーム)というものを設定しますが、この正規化するURLとコモンネームは、同じ文字列である必要があります。

具体的なURL正規化の方法は別記事でご紹介します。