Browser Router vs Hash Router

Browser Router

HTML5 History API를 사용해 브라우저의 주소창 URL을 직접 조작한다.
URL에 해시(#)가 없는 깔끔한 경로(domain.com/about)를 제공한다.

장점

• History API를 활용하여 자연스러운 내비게이션과 페이지 전환 효과 구현
• 서버가 모든 경로에 대해 index.html을 반환하거나 SSR(서버 사이드 렌더링)을 적용하면 초기 HTML이 검색 엔진에 노출되어 SEO에 유리하다.

단점

• 새로고침이나 직접 URL 입력 시 서버에서 해당 경로에 대한 별도 처리가 없으면 404 오류 발생
• 서버 측에서 항상 index.html파일을 반환하도록 fallback 설정을 별도로 구성해야 한다.
• IE9 이하의 레거시 브라우저에서는 사용할 수 없다.

---

Hash Router

URL에 해시(#)를 사용하여 그 이후의 경로를 클라이언트 측에서만 해석한다.
domain.com/#/about에서 해시 뒤의 about만 읽어내어 라우팅한다.

장점

• 서버 설정 없이도 모든 요청이 기본 index.html로 처리되어 404 문제 없이 동작한다.
• 정적 파일 호스팅이나 서버 구성이 제한된 환경, 구형 브라우저와 같은 환경에 적합하다.

단점

• URL에 해시가 포함되어 사용자에게 익숙하지 않고 지저분하다고 느껴질 수 있다.
• 해시 이후의 내용은 서버에 전달되지 않아 검색 엔진이 크롤링하지 못하므로 SEO에 불리하다.
• 클라이언트 측에서만 동작하므로 SSR(서버 사이드 렌더링)을 지원하지 않는다.

---

대부분의 프로젝트에서 Browser Router 사용하는 이유

HTML5 History API를 사용하여 뒤로 가기, 앞으로 가기 등의 기능이 자연스럽게 동작하여 사용자 경험(UX)을 개선하고 해시(#) 없이 깔끔한 URL 구조를 제공하여 사용자에게 직관적으로 보이고 검색 엔진 최적화(SEO)에도 유리하다.

HTML5 History API가 IE 9 이하 버전과 같은 레거시 브라우저에서는 지원되지 않지만 대부분의 최신 브라우저에서는 지원되기 때문에 사용자 타겟 브라우저 환경에 따라 추가적인 고려가 필요할 수는 있지만 크게 무리되는 사항은 아니다.

---

SEO 관점에서 Browser Router vs Hash Router

Browser Router

• 해시(#) 없이 완전한 URL 구조를 제공하므로 검색 엔진 크롤러가 URL 전체를 인식하고 인덱싱할 수 있다.
• 서버가 모든 경로에 대해 index.html을 반환하거나 SSR(서버 사이드 렌더링)을 적용하면 초기 HTML이 검색 엔진에 노출되어 SEO에 유리하다.
• CSR(클라이언트 사이드 렌더링)만 사용하는 경우 JavaScript를 실행하지 못하는 크롤러는 초기 콘텐츠가 비어 있는 상태로 인식할 수 있어 SEO에 불리할 수 있다.

Hash Router

• URL의 해시(#) 이후 부분은 브라우저에서만 사용되고 서버에 전달되지 않는다.
• 대부분의 검색 엔진 크롤러 해시(#) 이후의 내용을 무시하거나 동적으로 생성된 콘텐츠를 제대로 크롤링하지 못할 가능성이 있다.
• 이로 인해 페이지 콘텐츠가 검색 엔진에 충분히 노출되지 않아 인덱싱과 순위 결정에 불리하다.

💡 일부 최신 검색 엔진은 JavaScript 렌더링을 지원하지만 완전한 인덱싱에는 한계가 있다.

• Google: WRS(Web Rendering Services)를 사용하여 JavaScript를 실행하고 DOM을 생성한 후 이를 크롤링하고 인덱싱한다.
• Bing: Chromium 기반으로 일부 JavaScript를 처리할 수 있지만 Google만큼 신뢰할 수 있는 수준은 아니다. 복잡한 JavaScript 콘텐츠는 제대로 인덱싱되지 않을 가능성이 있다.
• Yandex: 제한적으로 JavaScript 렌더링을 지원하며 베타 기능으로 제공되고 있지만 대부분의 경우 정적 HTML 콘텐츠를 선호한다.
• Baidu: JavaScript 렌더링을 거의 지원하지 않으며, 정적 HTML 콘텐츠만 제대로 크롤링할 수 있다.

결론

검색 엔진은 서버에서 받은 HTML 문서를 기반으로 페이지의 콘텐츠를 분석한다.

Browser Router 방식은 URL 구조가 정적 경로처럼 보이기 때문에 크롤러가 이를 일반적인 MPA(다중 페이지 애플리케이션)처럼 처리할 수 있어 SEO에 유리하다.
특히 SSR(서버 사이드 렌더링)을 병행하면 효과적으로 SEO를 최적화할 수 있다.

반면 Hash Router는 해시(#) 이후의 내용은 브라우저에서만 해석되고 서버에는 전달되지 않기 때문에 검색 엔진이 이를 무시하거나 제대로 분석하지 않아 SEO 관점에서 적합하지 않다.

---

SPA에서 Browser Router로 배포할 때 처리해야 하는 작업들

SPA(단일 페이지 애플리케이션)에서 Browser Router를 사용할 때 페이지 새로고침이나 직접 URL 입력 시 브라우저가 실제 파일(ex. about.html)을 찾으려 하기 때문에 404에러가 발생한다.

이를 방지하고 클라이언트 측 라우팅을 올바르게 동작하게 하려면 배포 플랫폼 별로 특정 설정이 필요하다.

Vercel

프로젝트 루트에 vercel.json 파일을 생성하고 다음과 같이 rewrite rule을 추가한다.

{
  "rewrites": [{ "source": "/(.*)", "destination": "/" }]
}

이 규칙은 모든 요청이 실제 정적 파일을 찾지 못할 경우 index.html을 반환하도록 한다.

Netlify

프로젝트의 public 폴더(또는 빌드 결과물이 위치하는 곳)에 확장자 없는 _redirects 파일을 생성하고 아래와 같은 내용을 추가한다.

/*    /index.html    200

이 설정은 모든 경로 요청을 index.html로 리다이렉트하여 클라이언트 측에서 라우팅이 정상적으로 처리되도록 한다.

💡 이외에 클라우드 호스팅 환경에서도 유사한 rewrite 또는 fallback 설정이 필요하다.

---

Electron에서 Hash Router를 사용하는 이유

💡 Electron이란?
Github에서 개발한 오픈 소스 프레임워크로 HTML, CSS, JavaScript 등 웹 기술을 사용하여 크로스 플랫폼 데스크톱 애플리케이션을 쉽게 만들 수 있도록 돕는다.

• Chromium과 Node.js의 통합: Chromium 브라우저 엔진을 사용하여 사용자 인터페이스를 렌더링하고 Node.js를 통해 운영체제 기능 및 파일 시스템 접근 등 백엔드 기능을 지원한다.
• 메인 프로세스: 애플리케이션의 전반적인 실행 흐름과 창 관리, OS와의 상호작용을 담당한다.
• 렌더러 프로세스: 웹 페이지를 렌더링하며, 사용자 인터페이스를 담당한다.
• 크로스 플랫폼 지원: Windows, macOS, Linux 등 다양한 운영체제에서 같은 코드 베이스로 애플리케이션을 배포할 수 있다.

Electron 환경과 라우팅 문제

Electron은 데스크톱 환경에서 동작하며 웹 서버가 아닌 로컬 파일 시스템 file:// 프로토콜에서 실행되기 때문에 웹 서버에서 동작하는 일반적인 HTML5 History API 기반의 라우팅 방식(Browser Router)을 사용하면 해당 요청을 처리할 웹 서버가 없기 때문에 문제가 발생한다.

Electron 환경에서 BrowserRouter를 사용하려면, 앱을 로컬 파일로 로드하는 대신 별도의 HTTP 서버(ex. Express.js)를 구축하여 모든 경로 요청을 index.html로 리다이렉션 해야 한다.

이 방식으로 rewrite rules를 적용하면 웹 서버의 도움을 받아 정상적으로 동작할 수 있지만 Electron의 기본 동작 방식은 로컬 파일 시스템을 활용하는데 이러한 이점을 살릴 수 없고 로컬 서버를 구성하는 추가 복잡성과 보안, 패키징 문제 등이 발생할 수 있어 권장되지 않는다.

이러한 이유로 Electron에서는 Browser Router가 아닌 Hash Router를 사용하는 것이 간단하고 효율적이다.

---

정리하기

구 분	Browser Router	Hash Router
URL 형식	domain.com/about	domain.com/#/about
서버 설정	서버가 모든 경로 요청에 대해 index.html 반환 필요	서버 설정 없이 항상 index.html 반환
내비게이션	History API를 사용하여 자연스러운 내비게이션	URL 해시 변경으로 클라이언트 측에서만 처리
SEO	올바른 설정 시 검색 엔진이 전체 페이지 인덱싱 가능	해시 이후의 내용은 검색 엔진이 무시하여 SEO에 불리
사용 환경	동적 웹 애플리케이션, SEO 및 사용자 경험이 중요한 경우	정적 사이트, 서버 구성이 어려운 환경, Electron 등

---

🙃 도움이 되었던 글들

<BrowserRouter> - React-Router v5 문서
History API - MDN 문서
<HashRouter> - React-Router v5 문서
BrowserRouter와 HashRouter, 뭐가 다를까? (feat. React Router)
Browser Router와 Hash Router
Ultimate Guide to JavaScript SEO
Does bingbot render JavaScript?
JavaScript page rendering (β) - Yandex
JavaScript API v2.0 - Baidu