React·Vue 같은 프레임워크로 만든 SPA(단일 페이지 애플리케이션)를 운영하는 기업은 SEO 대행을 맡기기 전에 먼저 렌더링 상태를 점검해야 합니다. 검색엔진이 받는 첫 HTML에 본문, 제목, 내부 링크가 들어 있는지에 따라 이후 작업의 효과가 크게 달라지기 때문입니다. 검색엔진 최적화를 위한 서버 사이드 렌더링(SSR) 적용 여부, 페이지별 메타 정보, 상태 코드 이 세 가지를 사내에서 먼저 확인하고 결과를 문서로 정리해 두면, 대행사와의 협의 기간과 비용을 함께 줄일 수 있습니다.
SPA 사이트는 왜 검색엔진에 제대로 읽히지 않을 수 있습니까?
SPA는 서버가 거의 비어 있는 HTML 껍데기와 자바스크립트 파일을 보내고, 브라우저가 스크립트를 실행하면서 화면을 만드는 구조입니다. 사용자 입장에서는 화면 전환이 매끄럽지만, 검색엔진 수집기는 스크립트를 실행하기 전의 HTML을 먼저 읽습니다. 구글은 200 상태 코드를 반환하는 페이지를 렌더링 대기열에 넣어 별도의 대기열에서 나중에 처리합니다. 그래서 신규 페이지의 색인이 늦어지거나 일부 콘텐츠가 아예 인식되지 않을 수 있습니다.
현장에서 자주 보이는 문제는 다음과 같습니다.
- 모든 경로가 같은 title과 description을 반환해 페이지 구분이 되지 않습니다.
- 내부 이동을 a 태그의 href 대신 클릭 이벤트로만 처리해 수집기가 링크를 따라가지 못합니다.
- 존재하지 않는 주소에도 서버가 정상 응답 코드를 돌려주고 화면에만 오류 문구를 띄웁니다. 이른바 소프트 404입니다.
- API 호출이 실패하거나 지연되면 본문이 빈 상태로 수집됩니다.
검색엔진 최적화를 위한 서버 사이드 렌더링(SSR)은 어떤 방식으로 문제를 해결합니까?
서버 사이드 렌더링(SSR)은 요청이 들어올 때 서버가 완성된 HTML을 만들어 보내는 방식입니다. 수집기는 스크립트를 실행하지 않아도 본문, 제목, 링크를 바로 읽을 수 있습니다. 이후 브라우저에서는 하이드레이션 과정을 거쳐 SPA처럼 동작합니다. 다만 모든 페이지에 SSR을 적용할 필요는 없습니다. 페이지 성격에 맞게 방식을 골라 섞어 쓰는 것이 일반적입니다.
| 렌더링 방식 | HTML 생성 시점 | 검색 노출 측면 | 적합한 페이지 |
|---|---|---|---|
| CSR(클라이언트 렌더링) | 브라우저에서 스크립트 실행 후 | 첫 HTML에 본문이 없어 색인이 지연되거나 누락될 수 있음 | 로그인 이후 대시보드, 관리자 화면 |
| SSR(서버 렌더링) | 요청 시마다 서버에서 | 완성된 HTML을 바로 제공해 수집에 유리함. 서버 부하와 응답 시간 관리가 필요함 | 상품 상세, 검색 결과, 자주 바뀌는 목록 |
| SSG(정적 생성) | 빌드 시점에 미리 | 응답이 빠르고 안정적임. 내용이 바뀌면 다시 빌드해야 함 | 회사 소개, 가이드, 블로그 글 |
| ISR(점진적 재생성) | 빌드 후 정해진 주기나 요청에 따라 갱신 | 정적 생성의 속도와 최신성을 함께 확보할 수 있음 | 상품 수가 많은 카탈로그, 공지 목록 |
SSR을 도입할 때는 서버 응답 시간이 길어지지 않도록 캐시 정책을 함께 설계해야 합니다. 서버에서 만든 HTML과 브라우저에서 다시 그린 화면이 서로 달라지는 하이드레이션 불일치도 점검 대상입니다. 수집기가 받은 내용과 사용자가 보는 내용이 크게 다르면 검색 품질 평가에서 불리해질 수 있습니다.
대행 의뢰 전에 사내에서 무엇을 직접 확인해야 합니까?
다음 절차는 개발 지식이 많지 않은 마케팅 담당자도 브라우저 기능만으로 진행할 수 있습니다. 대표 페이지 유형별로 한 개씩, 모두 다섯 개에서 열 개 정도의 주소를 골라 확인합니다.
- 원본 소스 확인: 페이지에서 '페이지 소스 보기'를 열고, 화면에 보이는 본문 첫 문장이 소스에 있는지 검색합니다. 없다면 클라이언트 렌더링에 의존하고 있는 것입니다.
- 메타 정보 확인: 소스 안의 title, meta description, canonical 값이 페이지마다 다른지 비교합니다.
- 상태 코드 확인: 개발자 도구의 네트워크 탭에서 없는 주소를 입력했을 때 404가 반환되는지, 이전한 주소에서 301이 반환되는지 확인합니다.
- 링크 구조 확인: 메뉴와 목록의 이동 요소가 href를 가진 a 태그인지 요소 검사로 확인합니다.
- 사이트맵·robots 확인: 사이트맵에 실제 공개 페이지만 들어 있는지, robots 파일이 자바스크립트나 API 경로를 막고 있지 않은지 살핍니다.
확인 결과를 표로 정리해 전달하면, 대행사가 진단에 쓰는 시간이 줄고 견적 범위도 더 명확해집니다.
렌더링을 개선할 때 접근성·보안 기준은 어떻게 함께 챙겨야 합니까?
렌더링 방식을 바꾸는 작업은 마크업 전체를 손보는 기회입니다. 따라서 웹 접근성과 보안 기준을 같은 일정 안에서 반영하는 편이 효율적입니다. 의미 있는 제목 구조, 이미지 대체 텍스트, 명확한 링크 텍스트는 검색엔진과 보조기술 모두가 페이지를 이해하는 데 도움이 됩니다.
행정안전부 범정부 UI/UX 디자인 시스템(KRDS)은 한국형 웹 콘텐츠 접근성 지침 관련 안내에서 장식용 이미지를 제외한 모든 이미지에 대체 텍스트를 제공하도록 안내하고 있습니다. 이미지 중심의 상품 상세 페이지를 서버 렌더링으로 바꿀 때 이 항목을 함께 정비하면 검색 노출과 접근성을 동시에 개선할 수 있습니다.
W3C가 공식 권고로 발표한 웹 콘텐츠 접근성 지침(WCAG)은 인식의 용이성, 운용의 용이성, 이해의 용이성, 견고성이라는 네 가지 원칙을 바탕으로 합니다. 이 가운데 견고성은 보조기술을 포함한 다양한 사용자 에이전트가 콘텐츠를 안정적으로 해석할 수 있어야 한다는 원칙으로, 수집기가 읽기 쉬운 표준 마크업을 만드는 방향과도 맞닿아 있습니다.
국내에서는 「장애인차별금지 및 권리구제 등에 관한 법률」에 따라 웹사이트 등 전자정보에 대한 장애인의 접근을 보장하기 위한 조치 의무가 정해져 있습니다. 적용 대상과 범위는 사업자 유형에 따라 다를 수 있으므로, 구체적인 의무 여부는 법률 전문가에게 확인하는 것이 바람직합니다.
보안 측면에서는 개인정보보호위원회가 고시하는 「개인정보의 안전성 확보조치 기준」이 개인정보를 정보통신망을 통해 인터넷망 구간으로 송·수신할 때 안전한 암호 알고리즘으로 암호화하도록 요구하고 있습니다. 서버 렌더링으로 전환하면서 회원 정보나 주문 정보를 서버에서 처리하게 된다면, 렌더링 결과 HTML이나 캐시에 개인정보가 남지 않도록 캐시 범위를 분명히 정해야 합니다.
검색엔진최적화대행사와 개발팀의 역할은 어떻게 나눠야 합니까?
렌더링 구조 개선은 코드 수정이 필요한 작업입니다. 그래서 검색엔진최적화대행 계약만으로는 끝나지 않는 경우가 많습니다. 대행사는 진단과 요구사항 정의, 결과 검증을 맡고, 실제 구현은 사내 개발팀이나 개발 협력사가 맡는 구조가 일반적입니다. 역할을 처음에 나누지 않으면 진단 보고서만 남고 개선이 이루어지지 않는 상황이 생기기 쉽습니다.
| 업무 단계 | 대행사 역할 | 개발팀 역할 | 산출물 |
|---|---|---|---|
| 진단 | 수집·색인 상태 분석, 문제 페이지 유형 분류 | 현재 렌더링 구조와 배포 방식 설명 | 진단 보고서 |
| 요구사항 정의 | 페이지 유형별 렌더링 방식, 메타 규칙 제안 | 기술적 실현 가능성, 일정 검토 | 요구사항 명세 |
| 구현 | 마크업·메타 규칙 검수 기준 제공 | SSR·SSG 적용, 상태 코드와 리디렉션 처리 | 배포 내역 |
| 검증 | 배포 후 수집 상태와 색인 변화 추적 | 오류 로그, 응답 시간 모니터링 | 검증 보고서 |
대행사를 비교할 때는 렌더링 진단을 실제로 수행한 경험이 있는지, 개발팀이 바로 작업할 수 있는 수준으로 요구사항을 문서화하는지 확인하는 것이 좋습니다. 예를 들어 넥스트티처럼 기술 진단과 콘텐츠 전략을 함께 다루는 곳에 의뢰한다면, 사내 점검표를 미리 공유하고 어떤 산출물을 받을지 계약 단계에서 합의해 두는 편이 효과적입니다.
자주 묻는 질문
모든 페이지를 서버 사이드 렌더링으로 바꿔야 합니까?
그렇지 않습니다. 검색 유입이 필요한 공개 페이지를 중심으로 적용하고, 로그인 이후 화면처럼 색인이 필요 없는 영역은 기존 방식을 유지해도 됩니다. 페이지 유형별로 우선순위를 정해 단계적으로 전환하는 것이 일반적입니다.
프레임워크를 바꾸지 않고도 개선할 수 있습니까?
사용 중인 프레임워크가 서버 렌더링이나 정적 생성을 지원한다면 설정 변경과 일부 코드 수정으로 대응할 수 있습니다. 지원하지 않는다면 사전 렌더링 도구를 쓰거나 전환 계획을 세워야 합니다. 어느 쪽이 적합한지는 개발팀의 검토가 필요합니다.
렌더링 개선 후 효과는 언제부터 확인할 수 있습니까?
수집기가 페이지를 다시 방문하고 색인을 갱신하는 데 시간이 걸리므로 효과가 나타나는 시점은 사이트마다 다릅니다. 기간을 예측하기보다 배포 직후부터 색인된 페이지 수, 수집 오류, 페이지별 노출 변화를 정기적으로 기록하며 추이를 보는 것이 바람직합니다.