ProxyPass와 301 리디렉션을 사용하여 억지로 사이트 콘텐츠를 이사
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
「좋아, 이것으로 완벽・・・어라? 리디렉션 루프 할거야?」
이 설정이라면 5 부분, 같은 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의 라우팅은 규칙과 유연성의 균형이 좋고 정말 편리하네요.
Reference
이 문제에 관하여(ProxyPass와 301 리디렉션을 사용하여 억지로 사이트 콘텐츠를 이사), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://qiita.com/yokozawa/items/e43a4be98a44f4ec7511텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)