Redirection

URL의 변경, 혹은 접근 권한 등의 이유로 Redirection이 필요하다. Server Side Redirection과 Client Side Redirection에 대해 살펴보자

Server-side Redirection

Server-side Redirection은 SEO 관점에서 좋기 때문에, 기본적으로 Server side에서 Redirection을 구현하는 것이 권장된다.

• UX

  • 어떤 페이지(사용자가 요청한 페이지)가 다른 페이지로 Redirection되어 두 개의 페이지가 연속적으로 로드되는 문제를 방지할 수 있다.

• SEO

  • 서버 측 스크립트 또는 구성 파일을 통해, 서버가 3xx 범위의 상태 코드와 다른 URL의 Location 헤더가 포함된 적절한 HTTP 응답을 전송할 수 있다.
  • 브라우저가 이 response를 수신하면 url(주소창)이 변경되고 브라우저는 새 URL로 요청을 한다.

• ex. express

  • res.redirect([status,] path)

Permalink(Permanent Link)

여기서 잠깐 Permalink에 대해 알아보자.

Permalink는 말 그대로 인터넷에서 특정 페이지에 영구적으로 할당된 URL 주소를 의미하는데, 이는 🔎 SEO에 유리하다.

Redirect URL에 Permanent 옵션을 더하면, redirect 뿐만 아니라 다음과 같은 장점을 갖는다.

1. 클라이언트와 검색 엔진이 해당 Redirect 정보를 영구적으로 캐시할 수 있다.
2. 검색 엔진은 해당 리소스에 대한 link를 업데이트한다.

Client-side Redirection

Client에서 Redirection을 구현하면, 브라우저의 history 상태가 변경되고 사용자는 새로운 화면을 보게 된다.

• UX

  • 구현 방식에 따라 사용자는 두 개의 페이지가 연이어 로드되는 것을 볼 수도 있다.

• SEO

  • 이는 엄밀히 말해 Redirection이 아니다. 서버는 상태 코드 200을 보냈고, 이는 HTML이 유효함을 의미한다.
  • 검색 엔진은 유효한 HTML 페이지를 얻고, 해당 페이지를 인덱싱한다.
  • 상태 코드 200은 Redirection에 대해 아무 정보도 얻지 못한다.

history.push() vs. history.replace()

그럼에도 클라이언트 상황에 따라 Client-side Redirection이 필요한 경우가 있는데, 그때는 적절하게 Redirection을 구현해주어야 한다. 사용하는 프레임워크에서 지원하는 Redirection을 잘 활용할 수도 있고, 적절하게 history 메서드를 사용할 수도 있다.

• history.push()

  • 새로운 entry를 history 스택에 넣는다.
  • 뒤로가기 버튼을 누르면(history.back()) 제대로 동작하지 않는다.

• history.replace()

  • 새로운 entry는 history 스택에 덮어씌워(override)진다.
  • history.back()이 잘 동작한다.
  • ex. react-router의 <Redirect>

Reference

Implementing automatic redirects on the server side instead of on the client side