※弊社記事はたぶんにPRが含まれますので
話半分で受け取ってください。

FeedTweetの短縮URLは短縮URLとして見られていない?

 Twitterに新着記事を出すのにFeedTweetを利用しているのですが、このサービスを利用すると、つぶやきに表示される記事のURLがam6.jpという短縮URLになります。なぜか、bit.lyを設定してもam6.jpになるようです(bit.lyに転送してる?トラフィックを計測してる?)。
 で、それはいいのですが、どうもFeedTweetの短縮URLは、TOPSYやTweetmemeなどでは短縮URLとしてではなく、am6.jpドメインのページとして計測されているようです。なんで?

 クローラが単純に記事に書かれているURLを参照しているなら当たり前じゃない?と思ったのですが、bit.lyやtinyurlの短縮URLの場合はちゃんと元記事の方を参照しているようで、「icoro.com」として計測されています。

Topsyでのbit.lyとtinyurlの表示

 一方で、FeedTweetは、「am6.jp」として計測されています。

TopsyでのFeedTweetの表示

 このように、TOPSYやTweetmemeはam6.jpの短縮URLになっているページをことごとくam6.jpのページとして認識しちゃっているようです。よって、FeedTweet経由で投稿された新着情報がTwitter上でいっぱいRTされても、「ページに表示される被RT数が0のままなんですけど!」ということになります。

TOPSYはどうやって短縮URLを区別しているのか?

TOPSYやTweetmemeなどのクローラはどうやって短縮URLかそうでないかを見分けているのでしょうか。幾つか可能性を考えてみました。

短縮URLサービスを手作業で登録している?

 FeedTweetのユーザは日本人がほとんどだと思われるので、逆に、海の向こうの方々にはbit.lyやtinyurlのようには知られていないかもしれません。
 で、もしTOPSYの中の人が「bit.lyやtinyurlは短縮URLサービスなんだよ。わかったかな?」と手作業でクローラに教えているとしたら、FeedTweetは登録から漏れてしまうかもしれません。

 でも、短縮URLサービスは世界中に大規模なモノから小規模なモノまでさまざまありそうなわけで、そんなことするかなぁ。

Twitterの短縮URL展開APIを利用している?

 Twitterには短縮URLを展開するAPIが存在するようです。(TwitterのAPIリファレンスを見てみたのですが、よく分かりませんでした。。)

試しに今使われてるbit.lyを渡してみたら展開されたから、tinyurl.comでもbit.lyでも使える。
Twitterの短縮URLを元に戻すには search.twitter.com/hugeurl?url= に問い合わせればわかることを知った – otsune's SnakeOil – subtech

 要は「http://search.twitter.com/hugeurl?url=(展開したいURL)」で短縮URLが展開出来るようです。これを利用すればTwitterのAPIが対応している短縮URLに対応出来ると言うことになります。
 試してみたらbit.lyやtinyurlの短縮URLは展開されましたが、am6.jpの短縮URLは展開出来ませんでした。

 でも、RSSをFeedBurner経由で配信していて、そのRSSをFeedTweet等のサービスでTwitterに投稿している場合、展開したURLは記事のURLではなくFeedBurnerのURLになります。で、FeedBurnerのURLは上記のAPIでは展開することが出来ませんでした(当然と言えば当然か)。でも、実際にはFeedBurnerのURLもちゃんと区別出来ているみたいです。
 ということは、これは違うのかも。

HTTPステータスを見ている?

 ふと思い立ってHTTPステータスコードを調べてみました。その結果、am6.jpは302を、bit.ly、tinyurl、FeedBurnerは301を使ってリダイレクトをしているらしいことがわかりました。(てか、やっぱりam6.jpからbit.lyに転送しているなぁ。。)

bit.lyとFeedTweetのHTTPステータスコード

 301と302の意味は以下の通り。どちらもリダイレクトに使用されるステータスコードですが、意味が若干違います。

301 Moved Permanently
恒久的に移動した。リクエストしたリソースが恒久的に移動されているときに返される。Location:ヘッダに移動先のURLが示されている。
HTTPステータスコード – Wikipedia
302 Found
発見した。リクエストしたリソースが一時的に移動されているときに返される。Location:ヘッダに移動先のURLが示されている。
HTTPステータスコード – Wikipedia

 もしかしたら、この違いが被RT数として計測されるかされないかの違いではないでしょうか。

 たとえば、「www.icoro.com」の短縮URLが「am6.jp/abcdefg」だとした場合。

 Twitterの投稿の中に「am6.jp/abcdefg」というURLを発見したクローラは、HTTPステータスコードをチェック。ここで「am6.jp/abcdefg」が返したステータスが301なら、クローラは、このURLのコンテンツは別のページに「恒久的に移動」したと考え(クローラは考えてはいないと思うけど)、「www.icoro.com」を取得する。
 一方、302だった場合は「一時的に移動されている」と考え、「am6.jp/abcdefg」を取得する。

 と言う感じでしょうか。そうであれば、am6.jpの短縮URLが短縮URLとして認識されていない理由も分かります。
 まあ、短縮URLは「コンテンツを移動した」わけではないので、どちらのステータスも違うと言えば違うかも。でも、じゃあどちらのステータスを返すのがベターかと言えば、やっぱり301じゃないかなぁ、とも思います。
 302を返すと言うことは、実際にコンテンツがあるのは本来「am6.jp/abcdefg」であり、「www.icoro.com」は一時的にコンテンツを移しているページだ、と言うことになってしまうので。

 無料で使わせてもらっているのであんまりうるさく言えた義理ではないですが、出来たらステータスは301にした方が良いんじゃないかと思います。(クローラがステータスを見ているという確証はありませんが。。)

 なんかこの記事、「FeedTweet」がビミョーって言ってるみたいですが、(短縮URLが短縮URLとしてみられていないことを除けば)なかなか良いと思いますよ。FeedTwitterよりもちゃんと投稿してくれますし、日本語で使えますし、設定も分かりやすいです。オススメ。

追記

2010/01/15

 上記の件についてFeedTweetに問い合わせをしたところ、さっそく対応してくれました!メールを送信してからわずか1時間での対応&返信でした。早っ。

リダイレクト問題 その後

 確認したところ、301でリダイレクトするように変わっていました。

 また、クローラと閲覧者に別のコンテンツを見せるのは「悪質なクローキング」なんじゃないか?という話もありました。

301リダイレクトで元記事へリダイレクトしているサービスの場合は SEO 的には問題ないと認識しています。なので am6.jp だけあやしげ。Googlebot に対してユーザーが目にするものとは異なるコンテンツを返してしまうと am6.jp がクローキングになってしまう気がするのですが、大丈夫でしょうか。。
短縮URLとそのリダイレクトについてSEO的に問題ないか調べてみた – F.Ko-Jiの「一秒後は未来」

 これについても一緒に問い合わせたところ、こちらにも対応して頂けたようです!

 対応の早さにびびりました。。
 そんなわけで、FeedTweet、チョーオススメです!

2010/01/23

 FeedTweetのアカウントで、bit.lyを設定しても短縮URLがam6.jpのままな件について。

 上の接続パネルの画像を見てもらえば分かるのですが、接続をam6.jpからbit.lyに転送しています。なので、bit.lyでもちゃんとクリックが計測されていることはされています。
 では、なんでこんな事をしているのかということになるのですが、これはFeedTweetで提供している「クリック解析」というサービスや「人気リンク」の計測のために、どうしても一度am6.jpを通す必要があるためだと思われます。(ユーザ的にそれが必要か必要ではないかは別として。)
 というわけで、bit.lyの短縮URLにしないのではなく、これらの機能を提供するためにbit.lyの短縮URLが出せないと言うのが正解かと思われます。

 個人的には、別にbit.lyでもam6.jpでも、被RT数さえちゃんと反映されていればそれでいいので、この辺にとくにこだわりはありませんです。

参考

関連する記事