Next.js·SPA 사이트가 검색에 안 잡히는 이유: 렌더링과 색인 문제 진단법

검색 노출을 기대하고 페이지를 만들었는데 검색 결과에는 제목조차 보이지 않는 경우가 있습니다. 이때 메타 태그부터 고치기보다 먼저 확인할 것은 검색엔진이 실제 콘텐츠를 읽었는지입니다. 조코헌트에 출시된 프로덕트 중 웹 서비스가 43%라는 점을 보면, 1인 빌더에게 렌더링과 색인은 특정 팀만의 문제가 아닙니다.

1. ‘검색에 안 잡힌다’를 세 단계로 나누기

크롤링과 렌더링은 다르다

검색엔진이 URL을 발견했다고 해서 곧바로 화면의 모든 텍스트를 읽는 것은 아닙니다. 서버가 처음 보낸 HTML이 비어 있고, 브라우저에서 자바스크립트가 실행된 뒤에야 제목·본문이 나타나는 구조라면 별도의 렌더링 과정이 필요합니다. 자바스크립트 오류, 느린 API 응답, 접근 제한이 있으면 이 단계에서 콘텐츠가 빠질 수 있습니다.

렌더링과 색인도 다르다

콘텐츠를 읽었다고 해서 반드시 검색 색인에 등록되는 것도 아닙니다. 중복 페이지, 낮은 품질 신호, noindex 설정, canonical 오지정 등은 별도로 확인해야 합니다. 따라서 “페이지가 브라우저에서 잘 보인다”는 사실만으로 색인 문제를 해결했다고 판단하면 곤란합니다.

2. 화면보다 HTML을 먼저 비교하기

원본 HTML과 최종 DOM 확인

페이지에서 우클릭해 보이는 DOM만 보지 말고, 서버가 처음 전달한 HTML과 비교해 보세요. 핵심 검색어, 페이지 제목, 설명, 본문 요약, 내부 링크가 원본 HTML에 있는지 확인합니다. 모두 자바스크립트 실행 이후에만 생긴다면 검색엔진이 읽을 수 있는 초기 신호가 약한 상태입니다.

또한 개발자 도구 콘솔의 hydration 오류도 확인하세요. 서버가 만든 마크업과 클라이언트가 기대하는 마크업이 다르면 화면이 순간적으로 바뀌거나 일부 내용이 사라질 수 있습니다. 날짜·랜덤 값·브라우저 전용 객체를 초기 렌더링에 섞는 패턴이 흔한 원인입니다.

데이터 요청 실패를 분리해서 보기

본문이 API 응답에 의존한다면 네트워크 탭에서 요청 상태와 응답 내용을 확인합니다. 로그인이나 쿠키가 필요한 요청, 클라이언트에서만 존재하는 토큰, 무한 스크롤로 뒤늦게 불러오는 목록은 색인 대상 콘텐츠에 불리할 수 있습니다. 검색에 보여야 하는 핵심 설명은 가능한 한 서버 응답에 포함시키고, 인터랙션용 데이터만 클라이언트에서 가져오는 식으로 경계를 나누는 편이 안전합니다.

3. 페이지 성격에 맞춰 렌더링 방식 고르기

SSR: 요청마다 서버에서 만들기

페이지 내용이 사용자 상태나 최신 데이터에 따라 달라지고 검색 유입이 중요하다면 SSR을 검토할 수 있습니다. 초기 HTML에 핵심 콘텐츠를 넣기 쉽지만, 요청마다 처리 비용과 장애 지점이 생깁니다. 공개 프로필, 상세 페이지처럼 URL별 내용이 뚜렷한 화면에 어울리는 경우가 많습니다.

SSG·ISR: 미리 만들고 필요할 때 갱신하기

내용이 자주 바뀌지 않는 소개 페이지나 문서라면 SSG가 단순합니다. 자주 바뀌지만 매 요청마다 새로 만들 필요는 없다면 ISR처럼 생성 결과를 재사용하는 방식을 고려할 수 있습니다. 중요한 것은 방식의 이름보다 배포 후에도 원본 HTML에 실제 콘텐츠가 들어가는지 확인하는 것입니다.

CSR: 앱 화면과 검색 랜딩을 분리하기

로그인 뒤 대시보드, 복잡한 편집기처럼 검색 유입이 목적이 아닌 화면은 CSR로 충분할 수 있습니다. 반대로 공개 랜딩, 콘텐츠 상세, 카테고리 페이지까지 전부 CSR로 만들면 색인 진단이 어려워집니다. 공개 정보는 서버 렌더링 계열로 두고 앱 기능만 클라이언트 렌더링으로 분리하면 유지보수 부담도 줄어듭니다.

4. 서치콘솔 URL 검사로 원인을 좁히기

검사 순서

문제가 발생한 정확한 URL을 입력합니다.
색인 가능 여부와 noindex, canonical, robots 관련 신호를 확인합니다.
실제 URL 테스트를 실행해 현재 배포본이 접근 가능한지 봅니다.
렌더링된 페이지에서 제목과 본문이 보이는지 확인합니다.
수정 후에는 즉시 결과가 바뀐다고 가정하지 말고, 다시 검사할 기준을 기록합니다.

여기서 “URL을 발견하지 못함”, “크롤링은 됐지만 색인되지 않음”, “페이지를 가져오지 못함”은 서로 다른 문제입니다. 첫 번째는 내부 링크나 사이트맵 같은 발견 경로를, 두 번째는 콘텐츠·중복·색인 지시를, 세 번째는 서버와 렌더링 오류를 우선 점검하세요. 사이트맵과 메타 태그를 함께 점검하려면 기술 SEO 체크리스트도 참고할 만합니다.

5. 1인 빌더용 수정 순서

가장 작은 변경부터 적용하기

먼저 공개 핵심 페이지 한두 개를 고릅니다. 원본 HTML에 제목과 본문을 넣고, hydration 오류를 제거한 뒤, API 의존성을 줄입니다. 그 다음 SSR·SSG·ISR 중 현재 데이터 성격에 맞는 방식을 적용합니다. 모든 화면을 한 번에 개편하면 어떤 수정이 효과가 있었는지 알기 어렵습니다.

배포 후 다시 검증하기

로컬 개발 서버가 아니라 실제 배포 URL에서 소스 HTML, 모바일 화면, 자바스크립트 오류, canonical, robots를 차례로 확인하세요. 검색엔진별 노출 차이를 이해해야 한다면 네이버 vs 구글 SEO, 뭐가 다른가도 함께 읽어보세요. 마지막으로 URL 검사 결과와 수정 날짜를 간단히 기록하면, 다음 배포에서 같은 문제를 훨씬 빠르게 찾을 수 있습니다.

검색 노출 문제의 핵심은 “SPA라서 안 된다”가 아니라, 검색에 필요한 콘텐츠가 언제·어디서·어떤 상태로 만들어지는지 불분명하다는 데 있습니다. 브라우저 화면, 원본 HTML, 렌더링 결과, 색인 상태를 분리해 보면 해결 순서가 보입니다.