기술 SEO에서 특히 경계해야 할 조언은, 진단 없이 행동만 알려주는 유형입니다. 색인되지 않는다고 SSR로 바꾸고, 트래픽이 감소하면 제목까지 바꾸라는 식입니다. iCanvas 실험과 Vercel·MERJ 연구를 읽고 나니, 저는 먼저 묻습니다. ‘정확히 어느 단계에서 문제가 생겼을까?’ 이 글에서는 사례를 실제 트러블슈팅 과정에 다시 놓고, HTML, 렌더링, 색인 증거를 비교한 다음, 어떤 코드를 고칠 가치가 있고 어떤 프레임워크는 굳이 바꿀 필요가 없는지 판단하겠습니다.
인디 개발자 SEO 실전 · 1편. 공개된 사례를 정리했으며, 자료 확인 시점은 2026년 9월입니다.
서로 모순처럼 보이는 두 가지 JavaScript SEO 증거
SearchPilot는 2017년 iCanvas의 카테고리 페이지 실험을 공개했습니다. 당시 일부 상품 콘텐츠와 링크는 JavaScript에 의존해서, 스크립트를 끄면 보이지 않았습니다. 하지만 GSC의 크롤 및 렌더링 검사에서는 페이지가 정상적으로 표시됐습니다.
팀은 카테고리 페이지의 절반에서만 해당 의존성을 제거하고, 나머지는 그대로 두었습니다. 실험 보고서에 따르면 자연 검색 성과가 6% 넘게 개선됐습니다. 쉽게 놓치기 쉬운 디테일은, 실제 변경이 주로 CSS에 이루어졌다는 점입니다. 사이트 전체를 다른 프레임워크로 옮긴 것은 아닙니다. iCanvas 실험 원문
이 사례를 읽어볼 만한 이유는 ‘SSR이면 6%를 끌어올릴 수 있다’는 것을 증명해서가 아니라, 두 가지 질문을 분리해 보여주기 때문입니다.
페이지가 한 번의 검사에서 보인다고 해서 제공 방식에 더 나아질 여지가 없다는 뜻은 아닙니다. 한 곳의 콘텐츠 노출을 개선했다고 애플리케이션 전체를 재구성해야 하는 것도 아닙니다.
하지만 여기까지만 읽고 넘어가면, 9년 된 실험을 오늘의 아키텍처 판단 근거로 쓰기 쉽습니다.
2024년 Vercel과 MERJ의 연구는 10만 회가 넘는 Googlebot 크롤을 분석했습니다. 주요 표본은 nextjs.org였고, 별도로 두 사이트의 보조 데이터도 포함했습니다. 오류 상태와 색인할 수 없는 페이지를 제외하고 보니, 표본 HTML이 완전히 렌더링됐고 비동기 콘텐츠와 RSC 스트리밍 콘텐츠를 처리할 수 있는지도 검증했습니다. 연구 방법과 결과
제 해석은 이 연구만으로 ‘Google은 JavaScript를 인식하지 못한다’는 막연한 주장을 반박할 수 있다는 것입니다. 하지만 어떤 사이트에 대해서든 API, 권한, 타임아웃, 페이지 상태에 문제가 없다는 보장은 없습니다. 모든 프레임워크의 순위를 비교한 실험인 것도 아닙니다.
한 연구는 렌더링 능력을 관찰했고, 다른 실험은 특정 페이지 변경이 검색 성과에 미친 영향을 측정했습니다. 시대, 표본, 지표가 모두 다르므로, 한쪽을 믿음의 기준으로 삼을 필요는 없습니다.
프레임워크 설정부터 확인하기 전에, 세 가지 페이지 증거를 비교한다
공개된 제품 페이지 하나가 색인되지 않는다면, 저는 세 가지 증거를 남깁니다.
첫째는 서버가 반환한 HTML입니다. 첫 요청에서 무엇이 전달됐는지 보여줍니다.
둘째는 로그인하지 않고 방문 기록도 없는 브라우저의 최종 페이지입니다. 일반 방문자가 스크립트 실행 후 무엇을 받게 되는지 보여줍니다.
셋째는 GSC URL Inspection의 크롤 또는 테스트 결과입니다. 그 시점에 Google이 무엇을 확인했는지 보여줍니다.
Google 공식 문서는 여전히 JavaScript 페이지 처리를 크롤, 렌더링, 색인으로 구분합니다. 차단된 리소스는 정상적으로 렌더링에 참여하지 못하며, 서버 출력이나 프리렌더링은 스크립트를 실행할 수 없는 사용자와 크롤러 모두에게 도움이 된다고 안내합니다. Google JavaScript SEO 문서
아래는 제가 쓰는 기본 명령입니다. 도메인과 본문 키워드는 바꿔 넣어야 합니다. 점검 방법일 뿐, 특정 고객의 장애 기록이 아닙니다:
최종적으로 본문까지 확인해야 하므로, HEAD만 보내지 않고 실제로 GET을 보냅니다. 리디렉션을 따라갈 때도 마지막 응답이 200이라고 확인하고 끝내지 말고, 중간 상태를 함께 살펴봅니다.
또 하나 중요한 점이 있습니다. HTML 파일에서 상품 문구를 찾았다는 사실만으로 그것이 반드시 화면에 보이는 본문인지는 알 수 없습니다. 그 문구가 스크립트 안의 직렬화된 데이터일 수도 있기 때문입니다. 어느 요소 안에 들어 있는지, 렌더링 후 DOM에서는 어떤 상태인지도 확인해야 합니다.
세 가지 증거가 서로 다를 때, 비로소 트러블슈팅 방향이 선명해집니다.
| 관찰 결과 | 우선 의심하는 요소 | 다음 단계 |
|---|---|---|
| 원본 HTML에는 본문이 없지만 브라우저와 Google에는 있음 | 스크립트 의존성은 있지만 아직 장애라고 단정할 수 없음 | 안정성과 실제 색인 상태를 확인하고, 마이그레이션은 서두르지 않음 |
| 브라우저에는 본문이 있지만 Google에는 없음 | 리소스 접근, 세션 상태, 사용자 상호작용 의존성 또는 실행 실패 | 네트워크 요청과 서버 로그를 대조 |
| 세 가지 모두에 본문이 있지만 여전히 색인되지 않음 | URL 정규화, 중복 콘텐츠 또는 페이지 가치 | Google이 선택한 정규 URL을 확인 |
| 디렉터리 전체가 갑자기 실패하고 다른 디렉터리는 정상 | 공용 템플릿 또는 배포 변경 | 같은 템플릿 페이지를 몇 개 추적해 본 뒤 배포 시점과 대조 |
이 표의 목적은 시행착오 범위를 줄이는 것입니다. 마지막 경우에는 페이지마다 키워드를 하나씩 보충해도 문제를 제대로 건드리지 못합니다.
‘크롤은 됐지만 색인되지 않았다’를 ‘콘텐츠가 좋지 않다’로 곧바로 해석할 수는 없다
먼저 같은 템플릿을 쓰는 페이지 세 개를 찾습니다. 정상적으로 색인되는 하나, 오랫동안 색인되지 않는 하나, 최근 게시된 하나입니다. 사이트 전체의 색인되지 않은 페이지 수만 들여다보는 것보다 이들을 비교하는 편이 훨씬 효과적입니다.
가상의 템플릿 사이트에 다음과 같은 주소가 있다고 가정해 봅시다:
/templates/invoice
/templates/invoice?color=blue
/templates/invoice?sort=popular
/templates/invoice-for-freelancers
색상과 정렬 파라미터는 같은 콘텐츠의 다른 뷰일 수도 있습니다. 프리랜서를 위한 템플릿은 필드, 예시, 사용 설명이 다를 수 있습니다. 두 경우를 기계적으로 같은 canonical 규칙으로 처리해서는 안 됩니다.
Google은 리디렉션, canonical, Sitemap을 강도가 서로 다른 정규화 신호로 봅니다. 사이트 자체에서 내보내는 신호는 서로 일관되어야 합니다. canonical을 선언했다고 검색 엔진이 반드시 받아들이는 것도 아닙니다. Google 정규 URL 가이드
제가 작업을 진행하는 순서는 다음과 같습니다.
먼저 GSC의 사용자 선언 정규 URL과 Google이 선택한 정규 URL이 같은지 확인합니다. 다르다면 선택된 페이지를 열어 실제 내용을 비교합니다.
다음으로 Sitemap과 사이트 내부 링크가 모두 같은 버전을 가리키는지 봅니다. 사이트에서는 A를 정식 버전으로 선언하면서 내부 링크로는 B를 가리킨다면, 먼저 그 충돌을 해결합니다.
마지막으로 페이지가 그 자체로 가치가 있는지 판단합니다. 프리랜서 페이지가 제목만 바꾼 채 나머지가 범용 페이지와 완전히 같다면, 키워드 세트가 있다는 이유만으로 억지로 유지하지는 않겠습니다. 반대로 필드, 예시, 작업 내용이 실제로 다르다면, 검색 권위를 한곳에 모으려고 다시 홈페이지에 합치면 안 됩니다.
noindex와 robots.txt에 대해서는 트러블슈팅 원칙 하나만 기억합니다. 크롤을 차단한 뒤에는 크롤러가 페이지 안의 noindex를 읽어줄 것을 기대할 수 없습니다. 접근 제한, 색인 의도, URL 정규화는 서로 다른 세 가지입니다. Google noindex 설명
수정 우선순위는 피해 범위에 따라 달라진다
SEO를 처리할 시간이 주말 하나뿐이라면, 감사 도구가 보고한 오류 개수순으로 우선순위를 정하지 않습니다.
공개 페이지 전체에 실수로 noindex가 붙었다면, 규칙은 하나뿐이지만 모든 진입 경로에 영향을 줍니다. 오래된 글의 설명 200개가 중복된 문제는 개수가 많아 보여도 그보다 급하지 않을 수 있습니다.
먼저 중요한 페이지에 접근할 수 없는 문제, 잘못된 URL 정규화, 핵심 본문 누락처럼 진행을 막는 문제를 처리합니다. 그다음에는 핵심 페이지가 내비게이션이나 본문에서 발견되기 어려운 문제를 해결합니다. 마지막으로 제목 표현, 이미지, 성능 같은 세부 사항입니다.
성능도 마찬가지입니다. 페이지가 너무 느려 사용자가 등록을 끝내지 못할 정도라면 바로 고치는 편이 좋습니다. 단순히 실험실 점수를 95에서 100으로 높이는 일은 먼저 엔지니어링 비용과 실제 이득을 비교해야 합니다. Google도 양호한 Core Web Vitals이 순위 상향을 보장하지는 않는다고 분명히 밝힌 바 있습니다. Google 페이지 경험 설명
이것은 세부 사항이 쓸모없다는 뜻이 아닙니다. 소규모 팀은 모든 제안을 동시에 실행할 여유가 없다는 뜻입니다.
수정 작업을 인수 기준으로 적는다
‘JavaScript SEO 최적화’는 검증하기 어렵습니다. 저는 그보다 작업을 다음과 같이 적는 편입니다:
여기서 반드시 ‘수정이 배포됐다’와 ‘검색 효과가 증명됐다’를 구분해야 합니다.
서버가 올바른 콘텐츠를 반환하는지는 바로 검증할 수 있는 엔지니어링 결과입니다. 색인 여부와 검색 성과는 이후 데이터를 기다려야 합니다. 단일 페이지의 배포 전후 증가량이 계절 요인, 경쟁, 다른 변경의 영향일 수도 있습니다. 후자를 얻지 못했다면 전자를 성장 실험으로 포장할 수는 없습니다.
이 사례들에서 제가 정말 가져가고 싶은 것은 바로 이런 작업 방식입니다. 먼저 장애를 설명할 수 있는 증거를 남기고, 그다음 가능한 한 국소적으로 수정하는 것입니다. 기술 SEO 문제 상당수에 필요한 것은 프레임워크 전체를 옮기는 일이 아니라, 문제에 정확히 맞는 패치입니다.
다음 글: 첫 번째 키워드 묶음은 어떻게 고를까: Plausible와 Bannerbear로 제품형 SEO 분석하기