ProxyPassと301リダイレクトを駆使して無理やりサイトコンテンツを引越する

昔々、siteA.comとsiteB.comという二つのサイトがありました。
siteAは主にロングテールSEO、siteBは主に広告をぶん回して、
それぞれが順調に別の方法にて成長していましたが、
ビジネスリソース戦略上の観点から、
siteA.comはsiteB.comに統合される事となりました。

二つのサイトの統合作業というのは殆どの場合において大変で、
時にはびっくりするほど長い時間がかかってしまう事もあります。
「これからその長い時間を統合の為に頑張るのか・・」と考えていると
偉い人が「検索エンジンのインデックスだけは統合先のsiteBに選考して移そう」と言い出しました。
エンジニアにとっては良い迷惑です。

しかし偉い人にやれと言われればやらざるを得ないのがこの世界の常です。
エンジニアは考えました。
「インデックスを別ドメインに移す場合は301リダイレクトを使わなくては」
「siteA.comからsiteB.comに301リダイレクトすればよいか」
「・・・あれ？でもロングテールSEOのコンテンツはsiteAにあるんだぞ」
「リダイレクトは良い、しかしどうやってsiteBのコンテンツとして表示するんだ・・？」
「そうか、リバースプロキシだ！」

そしてエンジニアは世にも奇妙な下記の様なプロキシー設定を実行しました。
（絵が雑すぎるのはご容赦下さい・・）

  # siteA.com 301 redirect setting
  location ~ ^/contents {
    return 301 http://siteB.com/$uri;
  }

  # siteB.com proxy pass setting
  ProxyPass /contents http://siteA.com/contents

「よし、これで完璧・・・あれ？リダイレクトループするぞ？」

この設定だと５の部分、同じURIで正引きしてるので301リダイレクトとリバースプロキシがループするのです。
「ぐぬぬ・・ならば同じリソースを別名でルーティングしてその先にプロキシすればどうだ」

  # siteB.com proxy pass setting
  ProxyPass /contents http://siteA.com/temp_contents

  # routes.rb
  resources :contents, only: [:show]
  resources :temp_contents, controller: :contents, only: [:show]

エンジニア「偉い人さん、出来ました！」
偉い人「たかだかリダイレクトなのに、もっとパッと出来ないの？（心の声：お疲れ様、ありがとう！）」
エンジニア「」

ニッチすぎて誰が使うんだという感じですが、SEO対策を頑張ると「何だソレ」みたいな設定が結構出てくるので一応残してみます。

ちなみにコード例で推察できますが、実際にやった際の構成は・・
siteA.com：nginx＋Ruby on Rails
siteB.com：httpd＋某phpフレームワーク
でした。
railsのルーティングはルールと柔軟性のバランスが良く、本当に便利ですね。