JavaScript SEO는 JavaScript로 만든 페이지를 검색엔진이 수집하고 렌더링해 색인할 수 있도록 점검하는 작업입니다. React나 Vue로 만든 사이트는 브라우저가 코드를 실행한 뒤에야 본문이 나타날 수 있습니다. 이때 서버가 보낸 HTML과 코드 실행 후 페이지를 비교해 검색로봇에도 본문과 링크, 검색 설정이 제대로 전달되는지 검사합니다.
Google은 JavaScript 페이지를 어떻게 읽나요?
Google은 서버가 보낸 HTML을 읽은 뒤 JavaScript를 실행해 추가된 콘텐츠도 확인할 수 있습니다. 처음 받은 HTML과 실행 후 페이지가 다를 수 있으므로 두 결과를 함께 점검합니다.
- Googlebot이 URL에 접속해 서버가 보낸 HTML을 가져옵니다.
- HTML에 들어 있는 링크와 검색 설정을 먼저 확인합니다.
- JavaScript를 실행해 사용자가 보는 화면을 만듭니다.
- 실행 후 나타난 본문과 링크를 다시 확인합니다.
- 확인한 내용을 바탕으로 색인 여부를 판단합니다.
Google이 JavaScript를 지원해도 사용자의 브라우저와 항상 같은 결과를 얻는 것은 아닙니다. 실행에 필요한 파일을 막았거나 API에서 오류가 나면 본문이 빠질 수 있습니다.
검색에 문제가 생기기 쉬운 구현
페이지가 브라우저에서 정상적으로 열려도 아래와 같이 구현했다면 검색로봇이 URL이나 콘텐츠를 놓칠 수 있습니다.
- 초기 HTML에는 제목과 본문이 없고 API 호출 후에만 나타나는 경우
- robots.txt가 필요한 JavaScript나 CSS 파일을 막는 경우
- 메뉴와 내부 링크가
a href없이 클릭 이벤트로만 작동하는 경우 - URL의
#뒤 값만 바꿔 서로 다른 콘텐츠를 보여주는 경우 - 오류 페이지가 실제 404가 아니라 200 상태 코드를 반환하는 경우
- JavaScript가 canonical이나 noindex 값을 예상과 다르게 바꾸는 경우
서버 렌더링은 언제 도움이 되나요?
Google은 클라이언트 렌더링 페이지도 처리하므로 모든 JavaScript 사이트에 서버 사이드 렌더링이 필수인 것은 아닙니다. 다만 서버 렌더링이나 정적 생성으로 제목, 본문, 링크를 초기 HTML에 담으면 크롤러가 JavaScript를 실행하기 전에도 핵심 내용을 읽을 수 있습니다. 사용자에게 첫 화면을 더 빨리 보여 주는 데도 도움이 될 수 있습니다.
HTML을 만드는 시점과 위치에 따라 CSR, SSR, SSG를 구분합니다.
| 방식 | 처음 전달되는 내용 | 확인할 위험 |
|---|---|---|
| CSR | 빈 틀이나 일부 HTML 뒤에 브라우저가 본문 생성 | API 실패, 실행 지연, 링크와 메타 정보 누락 |
| SSR | 요청할 때 서버가 완성 HTML 생성 | 서버 오류와 느린 응답, 하이드레이션 뒤 값 변경 |
| SSG | 빌드할 때 페이지별 HTML 생성 | 새 데이터가 빌드 전까지 반영되지 않음 |
하이드레이션은 SSR이나 SSG로 받은 HTML에 클릭 등의 동작을 처리하는 JavaScript를 연결하는 과정입니다. 서버가 HTML을 완성해 보내도 이후 코드가 본문이나 검색 설정을 바꿀 수 있으므로, SSR과 SSG 페이지도 실행 후 결과를 검사해야 합니다.
본문이 누락된 지점 찾기
구글 서치 콘솔의 URL 검사에서 실시간 URL을 테스트하고 Google이 본 HTML과 로드된 리소스를 확인합니다.
- 브라우저에서 JavaScript를 끄거나 페이지 소스를 열어 초기 HTML을 확인합니다.
- URL 검사에서 렌더링된 HTML과 화면을 확인합니다.
- H1, 본문, 내부 링크, canonical, robots meta 값을 비교합니다.
- 로드 실패한 JavaScript와 API, 콘솔 오류를 확인합니다.
- 서버 로그에서 Googlebot의 요청과 응답 상태를 살펴봅니다.
본문이 빠졌다면 어느 단계에서 사라졌는지 확인합니다.
- CSR 페이지의 초기 소스에 본문이 없는 것은 설계상 정상일 수 있습니다. 렌더링 뒤에도 없다면 API와 실행 오류를 확인합니다.
- 초기 소스에는 본문이 있지만 실행 뒤 사라지면 JavaScript나 하이드레이션 문제를 점검합니다.
- 브라우저의 최종 DOM에는 있고 Google의 렌더링 HTML에는 없다면 Googlebot이 요청한 API와 리소스의 상태 코드, robots 차단 여부를 확인합니다.
- 주소 접근과 새로고침에서 결과가 달라 404가 나타난다면 클라이언트와 서버의 라우팅이 일치하는지 점검합니다.
색인할 페이지는 초기 HTML에 noindex를 넣지 않아야 합니다. Google이 원본에서 noindex를 발견하면 렌더링을 생략할 수 있어 JavaScript로 나중에 지우는 방식은 신뢰하기 어렵습니다.
이런 오류가 배포 때마다 반복된다면 대표 템플릿의 페이지를 자동 검사할 수 있습니다. 서버 응답과 초기 HTML, 렌더링 후 DOM에서 아래 값을 수집해 이전 결과나 예상값과 비교합니다.
- HTTP 상태 코드와 최종 URL
- title, H1, canonical과 robots meta
- 핵심 본문 길이와 내부
a href링크 수 - 구조화 데이터 유형과 필수 값
- 이미지 주소와 alt 텍스트
본문을 나중에 불러오는 템플릿은 초기 HTML과 렌더링 후의 본문 길이가 달라도 정상입니다. 반면 렌더링 후에도 본문이 없거나, 의도하지 않은 noindex가 추가됐다면 배포 전에 원인을 찾아야 합니다. 단순히 두 결과가 같은지만 검사하지 말고 각 템플릿에서 기대하는 상태를 기준으로 삼습니다.
네이버에서 주의할 URL과 본문 구성
네이버도 JavaScript로 만든 SPA 사이트의 수집과 색인을 지원합니다. 다만 주요 본문은 서버에서 렌더링한 HTML로 제공하도록 권장합니다.
Naver 검색로봇은 주소의 # 뒤를 제외하고 URL을 수집합니다. #/product처럼 # 뒤 값에 따라 다른 내용을 보여 준다면 각 페이지에 고유한 URL을 만드는 편이 좋습니다.
자주 묻는 질문
React 사이트는 Google에 노출되지 않나요?
React를 사용했다는 이유만으로 검색에서 제외되지는 않습니다. URL에 접근할 수 있고 렌더링 후 핵심 콘텐츠와 링크가 나타난다면 Google이 페이지를 처리할 수 있습니다. 오류 응답이나 noindex 등 별도의 색인 제외 원인이 없는지도 점검합니다.
CSR과 SSR 중 어느 방식이 SEO에 더 좋은가요?
CSR도 Google 검색에 노출될 수 있습니다. 다만 SSR은 서버가 본문을 담은 HTML을 보내므로 크롤러의 JavaScript 실행에 덜 의존합니다. 검색 유입이 중요한 페이지에서 본문 누락이나 렌더링 지연이 반복된다면 SSR이나 SSG를 검토할 이유가 있습니다.
동적 렌더링을 사용하면 해결되나요?
동적 렌더링은 크롤러에는 미리 렌더링한 페이지를, 사용자에게는 기존 JavaScript 페이지를 제공하는 방식입니다. 두 결과를 계속 맞춰야 하므로 관리가 복잡해집니다. Google은 이를 임시 대응으로 보고 SSR이나 정적 생성 등의 대안을 권장합니다.
함께 알아두면 좋은 용어
- 렌더링: HTML과 CSS, JavaScript를 처리해 최종 페이지를 만드는 과정
- CSR: 사용자의 브라우저에서 JavaScript로 화면을 만드는 방식
- SSR: 서버에서 HTML을 만들어 전달하는 방식
- SPA: 한 페이지에서 화면을 동적으로 바꾸는 웹 애플리케이션 구조
- 크롤링: 검색로봇이 URL과 리소스를 가져오는 과정