ディレクトリにこだわる?

ディレクトリと内部リンク構造(パンくずリスト)がコンテンツテーマに則したツリー構造になっていて、それが相似しているとクローラビリティ(回遊性)とインデックス効率が良い、という話は何度かさせていただいています。これが実現できれば確かに最も美しいと思います。しかし一方で、これを遵守するあまりユーザーにとって使い勝手が悪くなるものまた良くないです。最近このディレクトリ構造のご相談が多かったので、改めて記事にしておきたいと思います。

ふわふわ

美しいディレクトリ構造と内部リンク構造とは

相似したディレクトリ構造と内部リンク構造(パンくず)は確かに分かりやすくクローラーも理解しやすいサイト設計になっていることでしょう。例えばディレクトリ構造とパンくず構想が以下のような作りになっているケースです。

ディレクトリ構造例

ディレクトリに相似したパンくず構造例
パンくずリスト構造例

ディレクトリにおける階層構造とパンくずの項目数が同じ規則であれば、確かに非常に分かりやすいです。さらに、Googleの推奨としても「内容を推察しやすいファイル名が好ましい」と記載されていますので、ディレクトリやファイル名称が内容通りであれば尚のこと、クローラーだけでなくユーザーにも分かりやすいでしょう。

他にも例えば、Googlebotはページをクローリングする上で、内部リンクと(XML等の)サイトマップを参照しますが、内部リンクを辿る方が圧倒的に比重としては強いと思いますので、その内部リンク構造がディレクトリ通りだとよりテーマや情報構造を理解しやすくなるというのは容易に想像できます。

参考(当ブログ内記事)

ふわふわ

一方で管理や運用のしやすさ

前述のようにディレクトリ構造と内部リンク構造が相似していればクローラビリティ上美しいのは事実です。しかし、一方でそれが現実的に可能かといえば、そうではないケースもあります。例えば、案件を抱えるような、ECサイトや人材サイト、物件サイト等が分かりやすい例として挙げられます。

案件系サイトにありがちなディレクトリ構造例
ディレクトリ構造例1

求人や物件、ECのように、在庫が流動的なページを大量に作成しなければならない場合、ページの管理が非常に大変です。ですので、管理上同じディレクトリ配下にファイルページを格納し、一元管理するケースが多々見られます。だからと言って、ディレクトリに合わせてパンくずリストを設計するでしょうか。ユーザーの導線や情報設計の構造を考えれば以下のような内部リンク構造になるケースは多いですよね。

案件系サイトにありがちなパンくず構造例
パンくず構造例1

これだと前述のようなディレクトリと内部リンクが相似しない構造になっているので、SEO上不利になるのではないか…というご質問が意外と多いのですが…全然不利になりません。

確かにディレクトリと内部リンクが相似していれば美しく、クローラビリティ性も高まると言いましたが、では相似してなければSEOで評価されないか、といえばそうではないのです。当然ですよね。美しく、クローラビリティ性が高まることがSEO上の評価になるわけではないからです。ややこしい話ですが、「テーマや情報構造を理解しやすい道筋を作る=検索ランキングの評価」ではないということです。

Google検索のメカニズムの3大要素はクローリング、インデクシング、ランキングです。この構成要素は順序的な意味合いです。クローリングしてからインデクシングして、その後にランキングします。つまり、クローリングしやすく、インデクシングしやすいからと言ってランキングにそのまま影響するわけではないのです。このニュアンスを勘違いする人が多いので、この手の質問が多くなるのだと思います。

繰り返しになりますが、ランキングという検索順位での評価はクローリングとインデクシングが終わった後に改めて行われるプロセスです。就職試験に例えて説明するなら、ランキングを「面接」とした場合、クローリングは就職希望先企業への「到着」時、インデックスは面接待ちの「着席」時だと思っていただければ良いかと思います。「到着」も「着席」もスムーズであれば印象は良いですが、最終的には「面接」で決まりますよね。あれ? 分かりづらいですかね(笑)。でもそんなイメージです。

クロール、インデックス、ランクの例

つまり、ディレクトリ構造と内部リンク構造が相似しているとクローラビリティが良くインデックスもされやすいというだけで、それだけで検索順位が上がるわけではないのです。

そうなるとこの場合、ディレクトリ構造に合わせたパンくずリストが良いか、それともユーザー導線やテーマ性、情報設計を考えたパンくずリストが良いか――もうお分かりですよね?
ユーザー導線やテーマ性、情報設計を考えて内部リンク構造を整えることです。管理・運用をしやすいディレクトリ構造を構築しつつ、クローラーとユーザーに理解してもらいやすい内部リンク導線を敷けば良いのです。

ちなみにパンくずリストの設計ですが、何もひとつの経路導線だけに限る必要はありません。ユーザーやクローラーにとって分かりやすく、見つけやすいと考えられるのであれば、複数敷いても問題ございません。「高島屋オンライン」のように複数のパンくずリストを作ることはなんら問題ございません。

複数のパンくず例
パンくず例

パンくずリストは掲載位置や数に関して推奨される事象はありません。ユーザーに使い勝手の良い掲載位置で分かりやすい内容であれば問題ないのです。まぁ、だからと言って多すぎても…それは使い勝手が良いかと言われれば…またそれは…ですが(笑)。

ふわふわ

ここでGoogleの公式文言をご紹介

Googleは検索デベロッパーガイドでしっかりと以下のように述べています。

実際のパンくずリストによく見られるのが、URLのパス部分をそのまま反映させたものです。ただ、URLパスの一部は、ページのウェブサイト内での位置づけを理解するうえでは役に立ちません。たとえば「https://example.com/pages/books/catcher_in_the_rye.html」というURLの場合、「pages」の部分やトップレベル要素「example.com」は役に立ちません。パンくずリストにはURL構造をそのまま反映させるのではなく、ユーザーがそのウェブページにたどり着くまでの一般的な経路を示すことをおすすめします。

引用)Google検索デベロッパーガイド

要はディレクトリ構造(URLパス)に捉われることなくユーザーに分かりやすい経路でパンくずを記載しましょう、ってことですね。また、パンくずの経路を複数設置することに関しましても以下に記載されています。

ページに移動する方法がサイト内に複数ある場合は、1つのページに複数のパンくずリストを指定できます。

引用)Google検索デベロッパーガイド

ふわふわ

ユーザーの使い勝手を最優先すべき

いずれにしましてもGoogleが推奨するのはただひとつ――ユーザーにとってそれが良いのかどうかを考えなさい、ということです。であれば、サイト運用者側としてもユーザーの使い勝手を最優先して考えると良いと思います。

最後に、私が考えるパンくずリスト生成における注意点を箇条書きにしておきますのでご参考ください。

  • 内部リンクを集約させる必要も無く、ユーザーにとっても不要なページはパンくずリストに入れないこと。
  • 該当ページに行く通過ページでも、引き返すために不要なページであればパンくずに入れないこと。
  • 該当ページに行く通過ページでも、引き返すために必要なコンテンツとして一部含まれる場合は、その前後の経路ページ内にも同様のコンテンツを入れられないか考えること。入れられるのであれば通過ページは不要になる。
  • パンくずリストはサイトを縦軸に進む経路のため、サイトページを横軸に進む経路があっても良いケースの場合は別のリンク構造を作ること。
  • パンくずリストは多くても3種類の経路に留めておき、メインの経路となるパンくずリストは明示しておくこと。それ以上は混乱を招きやすい。
  • いずれの場合においてもパンくずリストは構造化データでしっかりマークアップしておくこと。

ディレクトリ構造も大事ですが、それに固執することなく、ユーザーファーストで考えていきましょう!


関連記事

Google検索セントラルブログへ

Googleは今まで検索に関するブログをWebmaster Central Blog(ウェブマスター向け公式ブログ)という名称で運営していましたが、この度、Webmaster(ウェブマスター)という名称を廃止し、developers.google.com配下で運用するようになりました。 新旧の違い ...(続きを読む)

古いコンテンツの削除ツールが刷新

リンク否認ツールに続き、古いコンテンツの削除ツールがリニューアルしました。GoogleがTwitterで発表しています。インターフェースの変更のようですが、サイトオーナー側で行う作業ではなく、第3者が行うツールですのであまり馴染みがないかと思います。でも何かと便利かもしれませんので、知っておくと良い ...(続きを読む)

リンク否認ツールが刷新

リンク否認ツールがリニューアルしました。GoogleがTwitterで発表しています。マイナーチェンジではありますが、ご紹介します。 Today we're completing the migration of the Disavow links tool to the new Search Co ...(続きを読む)

Core Web Vitalsの導入時期

Core Web Vitals(ウェブに関する主な指標)について、今までご紹介してきました。そしてCore Web Vitalsが導入されるのは2021年であることと、導入6ヶ月前に発表すること、が前提でした。そしてこの度ついに来年5月になると発表されましたので、ご紹介します。 ▼Core Web ...(続きを読む)

コメントを書く

コメントは承認から反映までしばらく時間がかかる場合がございます。メールアドレスが公開されることはございません。