去年に引き続き、Google ウェブマスターYouTubeチャネルでJohn Mueller氏がウェブマスターからもらった質問に答えていく#AskGoogleWebmastersのQ&Aシリーズが配信されています。
この記事では2020年に入ってから配信されたSEO関連の5つのQ&Aを日本語に訳してお届けします。
1. SEO担当者がURL 検査について知るべきこと
ゲスト参加： GoogleのMartin Splitt氏
Q：Googleサーチコンソールの「スクリーンショット」を見る限り、Googleがページの一部しかレンダリングできていないように見えます。スクリーンショット機能の問題ですか？それともページに問題がありますか？
Martin Splitt氏：大事なコンテンツなら、ちゃんとレンダリングできていることを確認すべきです。念のために「HTML」も確認してください。たまにHTMLに含まれているけれど、スクリーンショットでファーストビューに含まれないために表示されない場合があります。なので、レンダリングされたソースコード（HTML）に含まれていることを確認してください。また、たまに不具合が発生することもありますので、もう一度（公開URLのテストを）試してみると良いです。
John Muller氏：ファーストビューに含まれていなければ、スクリーンショットには表示されないですが、インデックス登録の際には使用されますよね？
MS：はい、単純にスクリーンショットをどこかで切る必要があるため、ファーストビューまで表示しています。
ということは、スクリーンショットに異常値があって、HTMLにも想定している要素が含まれていなくて、公開URLのテストを何度してもその現象が続いていればレンダリングに問題があると思って良いですね。HTMLとスクリーンショットと別に「その他の情報」タブを確認して、ページのリソースがブロックされていないか、リソースのエラーがないかなど確認して、調査を行うと良いでしょう。またモバイルフレンドリーテストツールでのチェックとリソースの確認も可能です。
Q：アロー関数式を使うと毎回サーチコンソールでJavaScriptのエラーが表示されるのはなぜですか？ なぜ対応されないのですか？
JM：今は対応していますので、試してみたらおそらくエラーが出ないと思います。
Q：301リダイレクトが設定されているURLに対して、URL 検査ツールが200を返しているのは何故ですか？Googleサーチコンソール内のどこにも、そのテスト対象URLが301を返していることが表示されていません。
MS：URL検査ツールは、ページをインデックスされた場合のイメージを提供するツールです。301リダイレクトがある場合、リダイレクト先のページに新しいリクエストをします。最終的には301のURLではなく、リダイレクト先のページ（質問者のページの場合は200のページ）が対象です。こちらは仕様です。URL 検査ツールは、Googlebotが実際にウェブサイトを処理する際に起きたことを見せるためのツールだからです。
2. 画像検索の対応
Q：Googleで画像を検索結果に表示させる方法を教えてください。何か役立つヒントを下さい。
JM：画像検索で一番大事なのは、どのようにユーザーに見つけてもらいたいか意識することです。ユーザーがどのような検索をするか想定して、自社のサイトがそのユーザーにどのように役に立てるか考えましょう。画像があるからと画像の最適化を行うのではなく、目的を持って最適化を行ってください。
その次は技術的な詳細を考えます。
- 高品質の画像を使いましょう
- ウェブサイト上で画像が見えやすく、（テキストに）関連性がある位置に配置しましょう
- 良いページタイトルを使って、画像にユーザーの役に立つAltテキストを設定しましょう
- 可能でしたら、画像のキャプションも追加しましょう
- 画像の内容を表すファイル名を設定しましょう
- 画像の表示速度が早いホスティング方法を選びましょう
他にも最適化ができる項目がありますので、興味のある方はGoogleヘルプでベストプラクティスを確認してください。
3. 手動による対策と再審査リクエスト
Q：ドメインがスパムとして認識されました。既に直して、サーチコンソールより再審査リクエストしましたが、現在もスパムとして認識されています。どうすれば良いでしょうか？
JM：スパムとして認識されている理由がわからない場合、ウェブマスターのヘルプコミュニティから他ウェブマスターの意見をもらうことをおすすめします。このコミュニティにいる方は、スパムとして認識されたサイトをたくさん見てきましたので、改善のアイデアをもらえると思います。コミュニティに書き込む際は、元の問題と、既に行った施策について説明してください。何も隠さずに書くことをおすすめします。失敗は誰でもすることです。今まであったことを何も隠さずに説明した方がコミュニティのメンバーも助けやすいです。
フィードバックが厳しい場合がありますが、色々なサイトを見てきた外部の方の意見をもらうのは有益です。
改修を行った後、サーチコンソールから再審査リクエストをします。変更の詳細を説明して、またコミュニティに立てたスレッドにリンクを記載すると背景が見せやすいかもしれません。ウェブスパムチームがリクエストを手動で確認していますので、説明をわかりやすく、不要な詳細を含めないことを意識してください。
4. SEO担当者がJavaScriptについて知るべきこと
ゲスト参加： GoogleのMartin Splitt氏
Q：Railsのアセットパイプラインをキャッシュに使っている場合、古いアセットにどのステータスコードを設定すべきですか？現在、404を返すように設定していますが、Googlebotがそれらの古いアセットをクロールしています。410に設定すべきですか、それとも古いアセットを数ヵ月生かせておくべきですか？
JM：Railsのアセットパイプラインがわかりませんので、Martinお願いします。
MS：Railsでないアセットでも同じです。Railsのアセットパイプラインは、Railsアプリのアセットの自動化されたパイプラインで、Railsがステージング環境のアセットを本番化前に処理するためのものです。大事なのは、古いアセットがあって、ウェブサイトを更新したら新しいアセットができる。例えば、古いJavaScript、CSSの以前のバージョン、使わなくなった画像などがありますが、それをどうすれば良いか？HTMLの中身が再度クロールされて新しいアセットを取得するまで生かせます。Googleがなるべく早くクロールするようにしていますが、キャッシュのせいで古いURLが使われる場合があります。そのURLが404であれば、レンダリングが壊れますが、それは避けたいですね。
JM：ということは、しばらく生かせるべきですね。
MS：そうです、サーバーログを確認して旧URLがリクエストされなくなったことを確認できれば、削除して良いです。
Q：事前レンダリングにおいて、関係ない要素をスキップするまたは置き換えることは大丈夫ですか？例えばJSのsvgのグラフなど
JM：Googlebotがページを見た際に、すべてのコンテンツが確認できるように、なるべくすべての要素を含めた方が良いです。
MS：事前レンダリングの話であれば、コンテンツに変更があった際にJavaScriptをサーバーサイドで一度実行して、静的なアセットを全員向けにデプロイすることですので、スキップはしません。ダイナミックレンダリングの話であれば、ユーザーとクローラーに異なるコンテンツを出し分けるので…その場合もスキップしないですね。
Q：チャット機能があって、ページのタイトルがユーザーへの通知で変わる場合、タイトルのJSリライトをGoogleにインデックスさせないようにするにはどうすれば良いですか？
MS：無理だと思います。ページをレンダリングすれば、リライトされたタイトルを拾ってしまいます。強いて言えば、チャットをユーザーインタラクションの裏に隠すのはありだと思います、Googleがインタラクションしないからです。例えば、一度チャットのボタンをクリックしてからチャットが展開されてタイトルが変わるという対応は、GoogleにJSリライトされたタイトルをインデックスさせない方法の一つだと思います。
Q：事前レンダリングについて：中にJSを含めて良いですか？ AJAXリクエストではなく、例えば細かいレイアウト変更をするJSをです。
JM：問題ありません。事前レンダリングでページを事前に再生して、それをユーザーに提供しています。その中で、JavaScriptが含まれいても大丈夫です。ユーザーの観点からでもおかしくないし、事前レンダリングでコンテンツを最速に表示できて、更にJSでインタラクティブな要素を追加できるので良いと思います。事前レンダリングしているからといってすべてのJSをなくす必要はないです。
MS：事前レンダリングして「ハイドレーション」*をしたいと思いますが、コンテンツを事前レンダリングして、JavaScriptを使ってそのコンテンツを拡張して例えばSPAにするなど、それは大丈夫です。ユーザーにコンテンツをなるべく早く届けるのが目的なので。
*ハイドレーション=サーバーサイドレンダリングされたページを拡張するためにブラウザでJavaScriptを実行すること
JM：JavaScriptとSEOの絡みが今後も続きそうですね。個人的に良く聞かれるのは、事前レンダリングやダイナミックレンダリングは今後なくなるのか？まだやる必要があるのか？です。
MS：根本的になくなることはないと思います。なくなるとしたらダイナミックレンダリングです。ダイナミックレンダリングは回避策なので、今後もずっと使うことはないと思いたいです。サーバーサイドレンダリングと事前レンダリングは根本的に重要な概念です。なぜならユーザーと検索エンジンにコンテンツをより速く提供するからです。HTMLはすぐにパースできますが、JavaScriptでコンテンツを生成するにはまずはJavaScriptをパースして実行する必要があって、ブラウザでストリームできません。サーバーサイドレンダリングがあるので、その必要もありません。
JavaScriptのSEOについてもっと知りたい方はJavaScript SEOのプレイリストもご確認ください。
5. 301リダイレクトの処理
Q：301リダイレクトを設定すれば、旧URLの代わりに新URLがランキングされるまでどれぐらいかかりますか？ AからBに301リダイレクトを設定して、Googleがどちらもインデックスしましたが、ランキングされるのは引き続き旧URLです。
JM：根本的に、301リダイレクトはURL正規化のシグナルです。301リダイレクトを設定して元のページではなく、新しいページをインデックスしてほしい、と言っています。ただし、Googleが正規のURLを選ぶ際に、様々なシグナルを参照しています。前の動画にもその詳細について話しています。（アユダンテ：こちらの記事の「カノニカルURLの選択基準」で翻訳しています）なので、リダイレクトに気づいても、他の要素も確認しています。他の要素も一致していれば、新しいURLをメインに見ます。
そのためには、サイト内リンク、Sitemapsや他にリンクを参照しているところ（アユダンテ：例えばカノニカルタグ）も併せて新URLに置き換えましょう。
注意点として、旧ページを意図的に探す場合、旧URLを検索結果に表示するようにしています。例えば、新URLがメインとなったとしても、旧URLを検索窓に入れて検索すれば、おそらく旧URLを検索結果に表示できると思います。
正しいURLに正規化されていることをサーチコンソールのURL 検査ツールより確認できます。「Google が選択した正規 URL」からどのURLが現在正規と認識されているか確認できます。新ページでなければ、旧ページを指定する正規化のシグナルがないか確認して、それらを直してください。
#AskGoogleWebmastersシリーズが今後も続きそうでしたら、また和訳していこうと思いますのでご興味ある方はチェックしてください！
