概要

SEO ではURLに商品名を加えたものが良いとされます。但し、英語圏ならまだしもマルチバイトな日本語では、

日本語のままURLへ含める

→重複の可能性、これをキーにするのは実装上問題が多そう

URL用に英語名を入力

→重複の可能性と入力の手間とカタカナ英語以外で効果が低そう

と問題が考えられます。

SEO上の効果の程度や実装の手間を考慮すると、「データベースの一意なIDをそのまま使用する」(オートインクリメントなIDやハッシュ値、UUID)実装がシンプルで変更に強く魅力的に思えてきます。

また、多数のパラメータを持つ商品(服ならばサイズ・色)をどこまでURLへ反映させているかが気になったので、各社のURL構造を自分なりに調べました。

※URLの構造とその実装に興味があります。
※中の人ではないため、意図を読み違えている可能性があります。
※SEO上の効果を検証したり、また、それ自体について議論するものではありません。

クックパッド

シンプルな構成

http://cookpad.com/recipe/2221390

recipe のディレクトリの下に、シーケンシャルなIDの構成です。レシピサイトのため、レシピへのオプションは存在しません。また、他にキーとするならタイトルしかありませんが、レシピは投稿されるもののため、タイトルの変更を考慮すると、IDしか使用できないと思われます。

ID がデータベースのキーになっている可能性が高く、実装や運用がシンプルに行えそうです。 IDがシーケンシャルに発行されているようなので、クックパッドの規模ですと、SPOFをどう回避しているかが気になります。

アスクル

シンプルな構成

http://www.askul.co.jp/v/4853/

http://www.askul.co.jp/p/5784852/

http://www.askul.co.jp/p/K302379/

v または p の1文字のディレクトリの直下にシーケンシャルなIDの構成です。色・サイズ違いは別IDになります。

v と p の違いは不明です。v だけ、p だけのカテゴリもあれば、同じカテゴリ内でも混在する場合もあります。 IDは頭にアルファベットの頭文字がつくときがあります。この ID がデータベースのキーになっている可能性が高いです。

実装上の意図が分かりにくいところがありますが、考え方はシンプルです。

lighthouseapp

内部IDとタイトルを同時に表示している例

https://cakephp.lighthouseapp.com/projects/42648/tickets/3891-cakeemail-cant-set-invalid-rfc-email-address

projects プロジェクトであることを示す 42648 アカウントID tickets チケットであることを示す 3891-cakeemail-cant-set-invalid-rfc-email-address 個別チケット(シーケンシャルなIDとタイトルのスラグの構成) ※正規化はされていないが、シーケンシャルなIDだけである

https://cakephp.lighthouseapp.com/projects/42648/tickets/3891

でも同じページを返すので、内部的には、3891だけを見ている可能性が高いです。

コンテンツの内容をURLに含めるが、管理上はなくても構わないという実装です。

アマゾン

内部IDとタイトルを同時に表示している例

書籍の場合

正規化されたURL

http://www.amazon.com/Quiet-Power-Introverts-World-Talking/dp/0307352153 http://www.amazon.co.jp/Quiet-power-introverts-world-talking/dp/0141029196 http://www.amazon.co.jp/内向型人間の時代-社会を変える静かな人の力-スーザン・ケイン/dp/4062178591

洋書のままではIDは同じで、翻訳の場合は異なります。書籍の場合、商品IDはISBNになります。

上記の記述では、タイトルの内容を削ることが可能で、最小構成は以下になります。(リダイレクトされません)

http://www.amazon.co.jp/dp/4062178591

但し、サイト内では以下のようなタイトル部分が「gp」に置き換えられたURLが使用されています。(リダイレクトされません)

http://www.amazon.co.jp/gp/dp/4062178591

また、カート内からのリンクでは、「product」が含まれるURLが使用されています。(リダイレクトされません)

http://www.amazon.co.jp/gp/product/4062178591

おそらく、タイトル部分の容量を削減しているのでしょう。

ファッションの場合

サイズ・色毎に商品IDが用意されています。URLへはIDによって商品のオプションが反映されています。但し、変わっているのは、これらの商品の正規化されるURLがサイズ・色毎の個別の商品IDでなく、全く別の商品IDになることです。

つまり、代表する商品IDがあり、これを直接注文することはできず、それらにぶら下がるサイズ・色が具体的に決まった商品IDで注文するという構成になっています。おそらく、サイズ・色毎にURLを用意したいが、サイズ・色は生産計画や在庫の都合でなくなる可能性があるため、代表する商品IDを別途用意していると思われます。

カート内からの商品個別のURL(サイズ違いはなく、色違いが2種類のみ)

http://www.amazon.co.jp/dp/B00E97LP7W

http://www.amazon.co.jp/dp/B00E97LOO6

上記から正規化されたURL

http://www.amazon.co.jp/dp/B00E97LNLU

書籍以外の商品IDはB[0-9A-Z]{9}で構成され、1桁目から採番されているようです。 36の9乗≒10の14乗で約100兆のアイテムが登録可能になっています。

流石アマゾン、必要な要件をすべて取り揃えています。

楽天ブックス

内部IDとタイトルを同時に表示している例正規化されたURL

http://books.rakuten.co.jp/rb/内向型人間の時代-社会を変える静かな人の力-スーザン・ケイン-9784062178594/item/12279831/

アマゾンより複雑な構成で、 rb は商品単位のディレクトリであることを示していますが、item の扱いが不明です。また、タイトル後の 9784062178594 が何を示しているのかも不明です。タイトル部分は削ることができ、アマゾン同様に以下まで削ることが可能です。

http://books.rakuten.co.jp/rb/item/12279831/

但し、削られたURLは正規化されたURLへリダイレクトされます。

サイト内では、

http://books.rakuten.co.jp/rb/12279831/

が使用されていますが、このURLも正規化されたURLへリダイレクトされます。

商品IDは、整数値がインクリメントされるもののようです。ちなみに、現在の最小idは以下の商品でした。

http://books.rakuten.co.jp/rb/ア-スアンカ-による圧入工法の設計と施工-角田安一-9784274099434/item/12/

zappos

タイトルだけを表示している例

正規化されたURL

http://www.zappos.com/oakley-full-auto-tour

http://www.zappos.com/oakley-full-auto-tour-black

ディレクトリなしで、商品名をスラグ(+属性[色])にした構成です。商品名が色なしが正規化されたURLで、デフォルトの色のURLや色違いのURLは色なしに正規化されます。但し、サイズはURLに含まれず、HTMLから判断するに、個別の商品idを持っているようです。

後発ほど、商品名の重複を気にしなければならないので、運用はどうやっているのかが気になります。また、 URLが任意に指定できる以上、変更があった場合、URLの永続化をどのようにしているかも気になりましたが、外部からうかがい知ることはできませんでした。

Qiita

ハッシュで構成されているURL

http://qiita.com/dz_/items/55ae18f7fe3a873bace1

dz_ はユーザー名
items は固定
55ae18f7fe3a873bace1 TIPSを特定するID

DELL

商品の最小URL v323010dc2ojp でカスタマイズ前の商品構成を識別している模様

http://configure.apj.dell.com/dellstore/config.aspx?oc=v323010dc2ojp

カートから商品を編集する際に発行されるURL

http://configure.apj.dell.com/dellstore/config.aspx?reconfigure=true&cart=ActiveCart&id=e66da8b6-2362-451c-89ff-a102f6eacea2

UUIDの e66da8b6-2362-451c-89ff-a102f6eacea2 がカスタマイズされた内容を保持しているキーになるようです。カートから削除したり、別のセッションでは利用できないことを考慮すると、セッションと一緒に管理されており、カスタマイズ後のURLは提供されていないようです。

ゾゾタウン

オートインクリメントな商品IDを持つシンプルなURLです。商品IDは、サイズ・色を統括する「商品」に振られ、サイズ・色毎の個別のURLは生成されないようです。

グラフィック

商品の選択が進んだ後のURL

http://www.graphic.jp/price/12_2_1/250_2

「12_2_1」について

12 はA4チラシのID
2 は用紙コート63kgのID
1 は5日納期のID

「250_2」について

250 は部数の数
2 は両面モノクロのID

と、ディレクトリ構造にはあまり意味がなく、実装側の都合のURLのようです。オプションについては、URLに反映されませんでした。

納期・カラー数・部数を選ぶ画面

http://www.graphic.jp/price/12_2_3/

上記の価格一覧表では、行列の項目と生成されるURLに規則性があることから、すべて自動生成されているようです。また、こんなにURLを生成していると、どうインデックスされているのかと思ったら、「A4チラシ」と最初に仕様を選んだページまでがインデックスされるようになっており、その後の用紙の種類以降は、「noindex,follow」とリンクは辿るけど、インデックスはしないという指定がされていました。

まとめ

各社とも考えられたURLの構造をしており、勉強になる部分が多かったです。

特に、アマゾン、lighthouseapp、楽天のような、管理IDとコンテンツ内容をURLに含めつつ、その実際は、管理IDだけでアクセス可能な仕組みは、SEO上のURLと実装・運用の妥協点となっているようでした。

zz log

zaininnari Blog

URLへのキーワードの埋め込みと管理IDの実装調べ

概要