rel="canonical"やnoindexはクロールバジェットの節約に効果があるか？

海外のSEO/SEM情報を日本語でピックアップ

rel="canonical"やnoindexはクロールバジェットの節約に効果があるか？
ありません （John Mueller on Twitter）

rel="canonical"タグを使えば、クロールバジェットの節約に効果がありますか？

noindex metaタグを使えば、クロールバジェットの節約に効果がありますか？

グーグルのジョン・ミューラー氏が、似たような質問を別々のユーザーからツイッターで受け取った。

「クロールバジェット」とは、簡単に言えば、GooglebotがクロールできるURLの限度を表現するSEO用語だ（もう少し詳しい内容は以前にこのコーナーで解説した）。

さてミューラー氏の回答だが、どちらも「効果なし」ということである。

実はこの質問は少し滑稽だ。なぜだかわかるだろうか？

というのも、rel="canonical"タグもnoindex metaタグも、ページをクロールしなければ、そのページにそのタグがかかれていることがわからない。だから、クロールバジェットの節約には役立たないということだろう。

それらのタグの存在をすでにグーグルが知っているページであれば、ひょっとしたらクロール頻度が下がるかもしれない。だが、“節約”といえるほどの減少ではないはずだ。

そもそも、質問したユーザーはなぜクロールバジェットを節約したがっているのだろうか？ 通常のサイトでクロールバジェットを気にかける必要はない。その理由もこのコーナーで説明しているので、参照してほしい。

rel="alternate"をHTMLとサイトマップの両方で設定したらどうなる？
サイトマップが優先、HTMLは無視される （Gary Illyes on Twitter）

rel="alternate"のリンク要素をHTMLのheadセクションとサイトマップの両方で設定してはダメでしょうか？ それとも、単純にどちらか片方だけにしたほうがいいですか？

こうした質問をツイッターで受けたグーグルのゲイリー・イリェーシュ氏が、次のように回答した。

この件に関して、同じくグーグルのミューラー氏も、次のように補足している（ちなみにミューラー氏はイリェーシュ氏の同僚だ）。

rel="alternate"はHTML中の設定よりもサイトマップの設定が優先されるというイリェーシュ氏の説明は、筆者には初耳だった。

ちなみに、rel="alternate"で指定できる設定は、イリェーシュ氏が言及したhreflangのほかにもある。

たとえば、PC向けとスマホ向けが別URLの構成で、スマホ向けページのURLをグーグルに知らせるmediaだ。こちらも同様に、HTMLででもサイトマップででも設定可能だが、サイトマップの設定が優先的に適用されるのだろうと推測する。

（ほかにもtypeやstylesheetなどがある）

いずれにせよ、複数の場所で設定できるものでも、すべてを設定する必要はない。いくら無視されるとは言え、それぞれの設定に不整合が発生する状況は好ましいこととは思えない。

ミューラー氏が指摘するように、管理に漏れやミスが発生する可能性をわざわざ増やす必要はない。

HTTPS移行とURL構造変更を同時に実施することは可能か？
可能だけど、処理完了に長い時間がかかるかも （Google Webmaster Central office-hours）

英語版のウェブマスター向けオフィスアワーで、参加者の1人が、次のような質問をした。

HTTPS移行を計画しています。

ちょうど良い機会なので、ついでにユーザーフレンドリーなURLへの変更も同時に行ってはどうかと考えました。

HTTPS移行とURL変更を同時に行うことについては、どう思いますか？

この質問に対して、ジョン・ミューラー氏は次のように答えた。

判断は難しい。

HTTPからHTTPSへのプロトコル変更だけ、あるいはドメイン名の変更だけで、残りのURL構造が変わらないのであれば、グーグル側の移行処理はずっと楽になる。あらゆることを見なくてもすむから、元のURLと新しいURLの関係性を非常に簡単に理解できる。

しかしURL構造が変わるのであれば、URLがどのように形成されているのかを私たちはもう一度理解しなければならない。単純に、「HTTPからHTTPSに移行した」だけではすまない。

HTTPS移行とURL変更を組み合わせるのはいい考えかもしれない。だが、実行して、次の日にすぐに処理が完了するようなものではないと認識しておいてほしい。

サイトを管理する側からすれば、HTTPS移行とURL構造変更は同時に実施したいと思うだろう。それ自体は、必ずしも悪いことではないようだ。小さな規模のサイトであれば、一度にまとめてやったほうが楽に思える。

しかし、サイトの規模が大きければ（ページ数が多ければ）、グーグル側の移行処理が完了するまで、より長い時間がかかるかもしれない。また、トラブルが発生したときの原因解明や対処が複雑になる可能性もある。

テスト環境で綿密に検証し、問題発生時の対処手順を確立してからならば、同時に実施してもよさそうだ。しかし、安全策を取るなら、別々に実施するほうが無難だろう。

ページの一部分が他サイトからの配信、グーグルにはどう伝えたらいい？
何もしなくていい （John Mueller on Twitter）

うちのサイトでは、1つのページ内に、別のサイトから配信してもらっているコンテンツと、オリジナルのコンテンツが両方あります。

ページの一部分が配信コンテンツ（他サイトのコンテンツの複製）であることをグーグルに伝えるには、どのようにしたらいいですか？

グーグルのジョン・ミューラー氏にツイッターのフォロワーがこのように質問した。ミューラー氏はシンプルにこう回答した。

何もしなくていい。すごく簡単にわかることだ。

ページ内のどのくらいの割合が配信コンテンツかにもよるだろうが、オリジナルではないコンテンツが本当に「一部分」だけなら、特別な対処は不要だろう。重複コンテンツを心配する必要はないし、ましてペナルティにおびえる必要もない。

ただし、「オリジナルのコンテンツ」といっても、付加価値がある独自コンテンツを加えることは重要だ。簡単なコメントをちょっと足す程度では、オリジナルだとみなされないだろう。グーグルは、「そんなページを検索結果に出してもユーザーの役にたたない」と考えるだろう。

このトピックに関連して、よくあるSEOの勘違いを1つ紹介しておこう。

これは間違っているのだが、こういったことを信じている人もいるようだ。グーグルがそういう動作をしないことを、筆者はグーグルの人から直接聞いたことがある。言い換えれば、blockquote タグにSEO的な意味はない。

とは言え、blockquote タグの使用そのものが無意味だということではない。コンテンツを読んでいるユーザーには引用であることを表現できるからだ。ユーザーに明示するために、引用部分には blockquote タグを使うべきだ。

仮想ページビューのURLで404エラーが記録されてる! どう対処すればいい?
無視して大丈夫 （John Mueller on Twitter）

グーグルのジョン・ミューラー氏が、ツイッターで次のように質問された。

アクセス解析で使っている仮想ページビューのURLが原因の404エラーが突然増え始めました。robots.txtでブロックした方がいいでしょうか？

ミューラー氏は次のようにアドバイスした。

何にもしなくていいんじゃないかな。私ならそのままにしておくね。

念のために解説しておこう。「仮想ページビュー」とは、PDFのダウンロードやフォームのボタンの送信をアクセス解析ツールで分析したいときに使う手法だ。

アクセス解析ツールで少し特別な指定をして、訪問者がダウンロードしたときやフォームを送信したときに、あらかじめ決めた存在しないURL（仮想URL、たとえば/dummy/pdf-dlや/dummy/form-submitなど）にアクセスがあったように記録するのだ。

しかし、その仮想URLにアクセスしても実際にはコンテンツはない。そのため、GooglebotがそのURLをクロールすると404エラーがSearch Consoleに記録される。

GooglebotはURLを発見することに貪欲なため、リンクではなくてもURLらしきものがあればとにかくクロールを試す。仮想ページビューのURLが、Search Consoleのクロールエラーレポートに出てくるのは、よくあることだ。

仮想ページビューのURLに限らず、Search Consoleの404エラーは、本当に存在しないURLならば気にする必要はない。クロールやインデックスはもちろんのこと、ランキングにも悪い影響を与えることはないので無視してかまわない。

SEO Japanの
掲載記事からピックアップ

更新がなかったので今週もお休み。再開はあるのか？