JavaScript SEO는 개발자만 다루는 영역처럼 보이지만, 첫 질문은 의외로 단순합니다. 이 페이지는 방문자가 무엇을 하도록 도와야 하는가? 어떤 콘텐츠와 링크가 반드시 제공되어야 하는가? 서버는 무엇을 반환했는가? 페이지가 실행된 뒤 무엇이 나타났는가? 아직 확보하지 못한 사실은 무엇인가?
Hermes Agent는 JavaScript SEO 조사에서 섞어서는 안 되는 여러 업무를 분리할 수 있어 유용합니다. 한 역할은 최초 응답을 기록하고, 다른 역할은 제공된 렌더링 증거를 살펴보며, 세 번째 역할은 두 보고서를 의사결정 카드로 정리합니다. 코드 변경 여부는 여전히 사람인 담당자가 결정합니다.
이 워크플로로 완성할 결과물: 중요한 URL 하나에 대한 1페이지짜리 케이스 파일입니다. 모든 관찰에는 출처가 있고, 모르는 내용은 명확히 표시되며, 다음 행동은 하나의 제한된 범위로 정리됩니다. 이 절차는 Google 색인을 증명하거나 순위를 약속하지 않으며, 에이전트가 운영 환경을 수정하도록 허가하지도 않습니다.
1부: JavaScript를 작성하지 않는 사람을 위한 JavaScript SEO
페이지는 여러 단계로 전달된다
전통적인 HTML 페이지를 열면 유용한 콘텐츠의 상당 부분이 서버 응답에 이미 들어 있을 수 있습니다. JavaScript 의존도가 높은 사이트에서는 최초 응답이 시작에 불과할 수 있습니다. 브라우저가 스크립트를 내려받고, 추가 데이터를 요청하고, 상품 카드와 내비게이션을 만들고, 초기 HTML이 도착한 뒤 메타데이터를 갱신할 수 있기 때문입니다.
그렇다고 페이지가 SEO에 나쁘다는 뜻은 아닙니다. Google은 JavaScript를 처리할 수 있고, 많은 현대적인 웹사이트가 이를 성공적으로 사용합니다. 실무의 위험은 불일치입니다. 방문자에게는 완성된 페이지가 보이더라도, 중요한 콘텐츠나 URL, 페이지 신호가 최초 응답에는 없거나, 사용자 행동 뒤에 지연되어 있거나, 실패한 요청에 막혀 있거나, 발견하기 어려운 방식으로 표현될 수 있습니다.
페이지를 관찰 가능한 네 개 층으로 나누어 생각해 보세요.
층 | 초보자가 물어볼 질문 | 유용한 증거 |
|---|---|---|
URL과 응답 | 요청한 URL이 의도한 페이지를 반환했는가 | 상태 코드, 리디렉션, 응답 헤더 |
소스 HTML | 브라우저가 애플리케이션을 실행하기 전에 무엇이 있었는가 | 저장한 응답 또는 소스 보기 |
렌더링된 페이지 | 스크립트와 데이터 요청이 끝난 뒤 무엇이 나타났는가 | 렌더링 DOM, 스크린샷, 브라우저 캡처 |
검색 증거 | 권한이 있는 검색 도구가 실제로 무엇을 보고했는가 | URL 검사, 크롤링 결과, 로그, Search Console |
각 층은 서로 다른 질문에 답합니다. 스크린샷은 한 브라우저가 보여 준 상태이지 서버 응답이 아닙니다. 200 응답은 전달 성공을 뜻하지만 색인을 뜻하지 않습니다. 렌더링 DOM에 안정적인 링크가 있어도 검색엔진이 그 URL을 색인에 선택했다는 증거는 아닙니다.
먼저 확인할 여섯 가지 신호
초보자가 페이지를 검토하기 위해 전체 프레임워크를 배울 필요는 없습니다. 발견과 이해에 직접 연결되는 여섯 가지 신호부터 확인합니다.
- 상태 코드와 리디렉션. 유효한 페이지는 목적에 맞는 상태를 반환해야 합니다. 사라진 상품이 성공한 빈 페이지처럼 보이면 안 됩니다. 리디렉션은 혼란스러운 체인 없이 올바른 목적지에서 끝나야 합니다.
- 주요 콘텐츠. 페이지 제목, 핵심 설명, 상품 또는 기사 정보처럼 페이지 목적을 정의하는 내용이 필요한 상태에서 이용 가능해야 합니다. 클릭이나 불안정한 요청 뒤에만 나타난다면 그 의존성을 기록합니다.
- 크롤링 가능한 링크. 중요한 목적지는 보통
href를 가진a요소처럼 안정적인 URL의 실제 링크를 사용해야 합니다. 이벤트 핸들러로만 작동하는 카드는 방문자에게는 클릭되더라도 발견 경로가 약할 수 있습니다. - canonical과 robots 지시. canonical URL, robots 메타 지시, 응답 상태, 사이트맵 항목, 내부 링크가 일관된 이야기를 하는지 봅니다. canonical은 명령이 아니라 힌트이며, 사이트가 방지할 수 있는 URL 중복을 감추는 수단이 아닙니다.
- 점진적 로딩. 지연 로딩 이미지, 무한 스크롤, 클라이언트 페이지네이션 때문에 가치 있는 항목이 스크롤이나 클릭, 안정적인 URL이 없는 브라우저 상태에만 의존하지 않도록 합니다.
- 메타데이터와 구조화 데이터. JavaScript로 만든 제목, 설명, canonical 태그, 구조화 데이터는 실제로 보이는 페이지를 정확히 나타내야 합니다. 구조화 데이터는 해석을 도울 수 있지만 리치 결과를 보장하지 않습니다.
렌더링과 색인은 같지 않다
이 구분은 잘못된 작업 티켓을 줄여 줍니다. 렌더링은 시스템이 페이지를 처리해 의도한 콘텐츠를 얻을 수 있는지를 묻습니다. 색인은 검색엔진이 URL을 저장하고 노출 후보로 선택했는지를 묻습니다. 순위는 어떤 검색어에서 언제 어느 위치에 나타났는지를 다룹니다.
한 번의 브라우저 세션으로 세 가지를 모두 증명할 수 없습니다. 증거가 스크린샷뿐이라면 정직한 결론은 “이 브라우저 상태에서는 콘텐츠가 나타났다. 서버 응답, 검색엔진 렌더링, 색인 선택은 아직 모른다”입니다. “Google이 이 페이지를 볼 수 없다”는 문장보다 이 결론이 더 유용합니다. 팀이 다음에 어떤 증거를 구해야 하는지 알려 주기 때문입니다.
검사를 시작하기 전에 페이지 스토리를 쓴다
에이전트는 긴 체크리스트를 만들면서도 페이지의 비즈니스 목적을 놓칠 수 있습니다. 먼저 짧은 페이지 스토리를 작성합니다.
항목 | 예시 |
|---|---|
페이지 |
|
방문자의 할 일 | 상품을 비교하고 상품 상세 페이지로 이동하기 |
반드시 나타날 콘텐츠 | 카테고리 제목, 상품명, 가격, 상품 링크 |
일치해야 할 신호 | 200 응답, canonical URL, 색인 가능한 robots 지시, 제목 |
사용할 수 있는 증거 | 응답 캡처와 렌더링 DOM |
사용할 수 없는 증거 | Search Console과 서버 로그 |
범위 밖 | 플랫폼 이전, 게시, robots.txt 변경, 대량 수정 |
이 페이지 스토리는 모든 Hermes 역할이 공유하는 브리프가 됩니다. 사람 담당자는 “이 발견이 방문자의 할 일이나 페이지 신호에 영향을 주는가?”라는 기준으로 해당 내용을 케이스에 포함할지 판단할 수 있습니다.
2부: 조사를 Hermes Agent 팀 런북으로 전환하기
Hermes Agent의 공개 문서는 agents, tools, skills, memory, automation, subagents 같은 개념을 설명합니다. 하지만 정확한 도구와 권한은 배포 환경마다 다릅니다. 따라서 이 런북은 모든 Hermes 설치가 URL을 탐색하고, 명령을 실행하고, 저장소를 읽거나 티켓을 만들 수 있다고 가정하지 않고, 필요한 출력과 경계를 정의합니다.
세 역할에 서로 다른 증거 업무를 준다
“JavaScript SEO 수정”이라는 큰 작업 하나를 열지 마세요. 수집과 해석을 분리하고, 해석과 행동도 분리합니다.
역할 | 읽는 자료 | 만드는 결과 | 해서는 안 되는 일 |
|---|---|---|---|
응답 조사자 | 제공된 응답, 헤더, 소스, 리디렉션 | 응답 사실과 신호 충돌 | Google 색인 상태 추론 |
렌더링 조사자 | 렌더링 DOM, 브라우저 캡처, 승인된 페이지 증거 | 콘텐츠, 링크, 로딩 관찰 | 컴포넌트나 라우팅 변경 |
트리아지 편집자 | 두 보고서와 권한 있는 내보내기 자료 | 케이스 파일, 우선순위, 담당자 질문 | 가정을 사실로 바꾸기 |
세 개의 subagent로 실행해도 되고, 순서가 있는 세 작업으로 실행해도 되며, 한 에이전트가 명확히 분리된 세 번의 패스로 수행해도 됩니다. 에이전트 수를 늘리는 것이 목적이 아니라 모든 인계 과정을 검토 가능하게 만드는 것이 목적입니다.
케이스 파일은 기술 결정을 내리기 전에 증거 출처와 불확실한 상태가 분리되어 보이게 합니다.
공통 증거 계약을 정한다
조사자가 시작하기 전에 사용할 수 있는 출처를 정합니다. 입력이 빠졌다면 그럴듯한 답으로 채우지 말고 이용 불가로 표시하게 합니다.
하나의 JavaScript SEO 케이스를 조사합니다.
대상 페이지: [URL 또는 제공된 페이지 증거]
방문자 목적: [한 문장]
필수 페이지 요소: [목록]
허용된 증거: [응답 HTML, 렌더링 DOM, HAR, 스크린샷, 크롤링 내보내기,
또는 저장소 파일]
이용할 수 없는 증거: [목록]
읽기 전용으로 작업하세요. 파일 수정, 게시, URL 제출, CMS 변경,
메시지 전송, 티켓 생성, 명시적으로 허용되지 않은 계정 접근은 금지합니다.
모든 관찰에 증거 출처와 다음 상태 중 하나를 기록하세요:
CONFIRMED, PLAUSIBLE RISK, UNKNOWN, OWNER DECISION.
권한이 있는 출처에서 구체적인 증거가 제공되지 않았다면 검색엔진이 페이지를
색인, 렌더링 또는 순위화했다고 주장하지 마세요.기대 출력: 짧은 증거 원장. 품질 확인: 모든 관찰에 출처가 있어야 합니다. 복구 방법: 출처 없는 결론이 있다면 해당 행을 제거하고 승인된 증거 목록만으로 역할을 다시 실행합니다.
응답 조사자를 실행한다
응답 조사자는 페이지 애플리케이션이 일하기 전에 도착한 내용을 설명합니다. 승인된 도구에 따라 저장된 응답, 크롤링 내보내기 또는 공개 URL을 살펴볼 수 있습니다. 다음과 같은 사실을 기록합니다.
- 알려진 리디렉션 이후의 최종 URL
- 확인 가능한 경우의 HTTP 상태
- 응답의 제목, canonical, robots 지시, 언어 신호
- 페이지 목적을 정의하는 콘텐츠의 존재 여부
- 필수 목적지로 향하는 일반 링크
- 제공된 소스에서 보이는 스크립트 및 데이터 의존성
- 색인 가능한 페이지가 다른 URL을 canonical로 지정하는 것과 같은 충돌
출력은 단순한 표로 만듭니다.
관찰 | 증거 | 상태 | 중요한 이유 | 다음 확인 |
|---|---|---|---|---|
제공된 응답에 카테고리 제목이 없음 | 응답 캡처와 줄 참조 | Confirmed | 최초 응답에 목적을 정의하는 문구가 없음 | 렌더링 DOM과 비교 |
canonical이 요청 URL을 가리킴 | 응답 캡처 | Confirmed | 내부 신호가 일치함 | 렌더링 뒤 재확인 |
Google이 선택한 canonical | 권한 있는 출처 없음 | Unknown | 마크업만으로 추론할 수 없음 | 필요하면 URL 검사 요청 |
응답에 콘텐츠가 없다는 이유만으로 서버 사이드 렌더링을 권고해서는 안 됩니다. 조사자가 발견한 것은 하나의 상태이지 원인이나 필수 해결책이 아닙니다.
렌더링 조사자를 실행한다
렌더링 조사자는 팀이 실제로 제공할 수 있는 완성된 페이지 상태를 살펴보고, 페이지 스토리와 응답 원장을 비교합니다. 다음을 확인하도록 합니다.
- 주요 콘텐츠가 임의의 사용자 행동 없이 나타나는가
- 중요한 목적지가 안정적인 링크로 표현되는가
- 렌더링 후 메타데이터나 canonical 신호가 바뀌는가
- 지연 로딩 항목이 스크롤이나 상호작용을 요구하는가
- 무한 스크롤에 안정적으로 도달 가능한 페이지 경로가 있는가
- 오류, 빈 상태, 이용 불가 상태도 의미가 있는가
- 필수 데이터 요청이 실패할 때 콘텐츠가 어떻게 변하는가
스크린샷만 있다면 링크 마크업이나 메타데이터를 검사할 수 없습니다. 렌더링 DOM은 있지만 네트워크 캡처가 없다면 요청 실패의 이유를 설명할 수 없습니다. 결과에는 반드시 이런 한계를 적습니다.
트리아지 편집자는 불확실성을 그대로 둔다
트리아지 편집자는 두 보고서를 합칩니다. 더 단정적으로 보이게 만드는 것이 아니라 관찰, 가능한 메커니즘, 부족한 출처의 차이를 유지하는 것이 임무입니다.
상태 | 의미 | 예시 |
|---|---|---|
Confirmed | 제공된 증거가 조건을 직접 보여 줌 | 렌더링 DOM 캡처에 상품 링크가 없음 |
Plausible risk | 증거가 실패 경로를 시사하지만 영향은 확정하지 못함 | 링크가 클릭 핸들러에 의존할 수 있음 |
Unknown | 필요한 증거가 제공되지 않음 | 검색엔진이 선택한 canonical |
Owner decision | 둘 이상의 구현이 유효할 수 있음 | 카드 전체 또는 주요 동작에 링크 추가 |
우선순위는 기술적으로 들리는 정도가 아니라 페이지 영향과 증거 강도로 정합니다. 매출 관련 템플릿의 주요 상품 링크가 빠졌다면 즉시 담당자 검토가 필요할 수 있습니다. 근거 없는 프레임워크 선호는 그렇지 않습니다.
하나의 발견을 승인 카드로 바꾼다
트리아지 뒤에는 확인되었거나 충분히 뒷받침된 발견 하나를 선택합니다. 감사 전체를 구현 단계로 넘기지 마세요.
발견 ID: JS-01
페이지와 방문자 목적: [URL과 한 문장]
증거: [구체적인 응답, DOM 또는 코드 관찰]
상태: [CONFIRMED / PLAUSIBLE RISK]
방문자 영향: [도달하거나 이해하기 어려울 수 있는 내용]
제안하는 최소 행동: [범위가 제한된 변경 또는 조사 하나]
영향받는 템플릿 또는 시스템: [KNOWN / UNKNOWN]
승인 기준: [로컬 동작, 응답, 렌더링 DOM, 기능 링크]
롤백: [이전 동작으로 복원하는 방법]
결정 담당자: [이름 또는 역할]
구현 상태: WAITING FOR APPROVAL
범위가 제한된 승인 카드는 에이전트의 발견을 담당자가 검토할 수 있는 결정으로 바꿉니다.
Hermes는 카드를 준비할 수 있지만 비즈니스나 엔지니어링 결정을 소유할 수 없습니다. memory와 automation 기능만으로 중요한 변경이 안전해지는 것도 아닙니다.
승인 뒤에는 별도의 구현 작업을 만든다
담당자가 행동을 승인했고 Hermes 환경에 적절한 도구가 있다면 승인 범위만 포함한 새 작업을 만듭니다. 감사 작업을 조용히 쓰기 작업으로 바꾸지 않습니다.
케이스 JS-01에서 승인된 행동만 구현하세요.
변경하기 전에 다음을 다시 설명하세요.
1. 영향을 받는 파일 또는 시스템
2. 승인 기준
3. 계속 금지되는 행동
4. 롤백 조건
변경 뒤 정확한 diff 또는 변경 기록을 보여 주고 승인된 테스트만 실행하세요.
배포, 게시, URL 제출, 관련 없는 파일 수정, 범위 확대는 금지합니다.
예상 파일이나 메커니즘이 승인 브리프와 다르면 중단하고 새 증거를 담당자에게 돌려주세요.기대 출력: 검토 가능한 변경 기록 하나. 품질 확인: 관련 없는 파일과 행동이 없어야 합니다. 복구 방법: 테스트가 실패하거나 메커니즘이 브리프와 다르면 승인된 방식으로 복원하고 케이스를 다시 엽니다.
결과를 층별로 검증한다
에이전트가 성공했다고 말하는 것만으로 구현이 끝나지는 않습니다. 페이지가 전달되는 순서대로 확인합니다.
- 로컬 동작: 페이지나 컴포넌트가 빌드되고 방문자 흐름이 작동하며 접근성이나 분석 동작이 깨지지 않았는가.
- 응답 층: 상태, 리디렉션, 제목, canonical, robots 지시, 중요한 소스 콘텐츠가 승인 목표와 일치하는가.
- 렌더링 층: 필요한 콘텐츠와 링크가 숨은 상호작용 의존성 없이 필요한 페이지 상태에 나타나는가.
- 검색 증거: 권한 있는 데이터가 생기면 URL 검사, 크롤링, 로그, Search Console이 실제로 보고한 내용을 기록합니다. 로컬 렌더링으로 대체하지 않습니다.
- 결정 기록: 날짜, 증거, 승인 행동, 테스트 결과, 담당자, 롤백 참조를 저장합니다.
한 층이 실패하면 자신감 있는 요약으로 덮지 말고, 실패한 확인과 가장 작은 다음 조사를 담당자에게 돌려줍니다.
관리 가능한 주간 Hermes 루틴
사이트 전체에 에이전트를 대량 투입하지 말고, 매주 대표성이 있고 가치가 높은 템플릿 하나를 선택합니다.
단계 | 활동 | 결과물 |
|---|---|---|
접수 | URL 하나를 고르고 페이지 스토리 작성 | 공유 브리프 |
증거 | 응답 및 렌더링 조사자 실행 | 두 개의 원장 |
트리아지 | 사실, 위험, 모르는 내용 통합 | 하나의 케이스 파일 |
검토 | 범위가 제한된 행동 하나 선택 | 서명된 승인 카드 |
검증 | 승인된 변경 또는 조사 테스트 | 층별 결과 기록 |
여러 페이지에서 같은 메커니즘이 확인되면 영향을 받는 템플릿을 위한 새 케이스를 엽니다. URL 하나만 보고 사이트 전체 결함으로 선언하지 않습니다.
흔한 실패와 복구 방법
에이전트가 중복 보고서를 만든다
역할이 겹쳤기 때문입니다. 각 역할에 서로 다른 출처 목록과 출력 계약을 줍니다. 응답 조사자는 렌더링 동작을 해석하지 않고, 렌더링 조사자는 응답 사실을 다시 쓰지 않습니다.
데이터가 없는데 트리아지 보고서가 확정적으로 들린다
네 가지 상태 라벨을 의무화하고 증거 출처가 없는 행을 거부합니다. Unknown은 유용한 결과입니다. 담당자가 다음에 무엇을 요청해야 하는지 알려 주기 때문입니다.
버그를 찾기 전에 SSR을 논쟁한다
페이지 스토리와 확인된 증상으로 돌아갑니다. SSR, 프리렌더링, hydration 변경, client-only rendering은 아키텍처 선택지이지 보편적인 답이 아닙니다.
예약 작업이 소음을 만든다
범위를 템플릿 하나나 제공된 URL 목록으로 줄입니다. 일정 작업은 날짜, 실패, 담당자가 있는 검토 대기열을 만들어야 합니다. 별도 승인이 없다면 변경이나 외부 메시지를 만들지 않습니다.
응답 보고서와 렌더링 보고서가 다르다
그 차이가 조사 핵심인 경우가 많습니다. 더 좋아 보이는 한쪽을 고르지 말고 두 관찰을 모두 유지합니다. 예를 들어 소스에는 상품 정보가 없고 렌더링 DOM에는 있다면, 다음 질문은 렌더링 경로가 신뢰할 만한지, 결과에 안정적인 목적지가 있는지입니다. 불일치를 실패의 증거로 단정하지 말고 알려진 응답 캡처나 승인된 크롤링 결과처럼 가장 작은 추가 출처를 요청합니다.
검토자가 페이지 하나로 사이트 전체 결론을 원한다
URL 하나는 템플릿 가설을 만들 수 있지만 적용 범위를 증명하지 못합니다. 첫 케이스에서 공유 메커니즘을 찾은 뒤에만 두 번째 대표 페이지를 추가합니다. 두 번째가 다르면 케이스를 나눕니다. 보편적 결함을 선언하는 것보다 느려 보여도 하나의 예외 때문에 비싼 프로젝트를 시작하는 일을 피할 수 있습니다.
첫 케이스의 전체 예시
유기적 방문이 있는 카테고리 페이지에서 SEO 담당자가 상품 카드를 감사하기 어렵다고 느꼈다고 가정해 봅시다. 페이지 스토리는 방문자가 상품을 비교하고 상세 페이지를 열 수 있어야 한다고 말합니다. 응답 조사자는 제공된 캡처에서 200 응답과 자기참조 canonical을 확인했지만 최초 소스에는 상품명이 없습니다. 렌더링 조사자는 렌더링 뒤 이름과 가격을 확인했지만, 제공된 캡처가 불완전해 카드의 주요 동작이 일반 링크인지 확인하지 못합니다.
트리아지 편집자는 “Google이 상품을 색인할 수 없다”고 쓰면 안 됩니다. 방어 가능한 케이스는 더 작습니다.
항목 | 상태 | 다음 행동 |
|---|---|---|
요청 URL이 정상 응답함 | Confirmed | 기준으로 유지 |
렌더링 뒤 상품 콘텐츠가 나타남 | Confirmed | 렌더링 의존성 기록 |
상품 목적지가 일반 링크를 사용함 | Unknown | 렌더링 마크업 또는 코드 담당자 확인 요청 |
검색엔진 색인 선택 | Unknown | 필요하면 권한 있는 URL 검사 요청 |
첫 결정은 저장소 검사를 승인하는 것뿐이어도 됩니다. 코드 담당자가 카드가 안정적인 주요 목적지 없이 클릭 핸들러를 사용한다고 확인하면, 두 번째 결정에서 작고 테스트 가능한 컴포넌트 변경을 승인할 수 있습니다. 순위 데이터가 바뀌기 전이라도 불안한 주장 대신 검증 가능한 메커니즘으로 이동했다면 Hermes 워크플로는 성공한 것입니다.
자주 묻는 질문
여러 Hermes 에이전트가 한 페이지를 병렬로 조사할 수 있나요?
네. 서로 다른 읽기 전용 역할, 겹치지 않는 증거 출처, 공유 케이스 파일 형식이 있을 때 가능합니다. 여러 에이전트가 같은 구현 영역을 수정하게 하지 마세요.
Hermes만으로 Google이 JavaScript 페이지를 색인했는지 알 수 있나요?
소스 코드나 브라우저 화면만으로는 알 수 없습니다. 권한 있는 URL 검사, 크롤링, 로그, Search Console 증거를 제공하세요. 없다면 색인 질문을 Unknown으로 둡니다.
응답 조사자는 항상 실제 URL을 탐색해야 하나요?
아닙니다. 사용할 수 있고 승인된 도구와 출처만 이용합니다. 제한된 환경에서는 저장된 응답이나 크롤링 내보내기가 올바른 입력일 수 있습니다.
소스에 없는 모든 요소에 서버 사이드 렌더링이 필요한가요?
아닙니다. 실제 해결책은 안정적인 링크, 올바른 상태, 이용 가능한 데이터 경로, 일관된 메타데이터 또는 작은 템플릿 변경일 수 있습니다. 먼저 메커니즘을 진단하세요.
초보자에게 가장 좋은 첫 Hermes 작업은 무엇인가요?
중요한 URL 하나에 응답 조사자 하나를 실행하세요. 출처가 있는 사실 표를 요구한 뒤 렌더링 페이지 증거가 필요한지 결정합니다.
작성자: Julian Mercer, Auspia에서 14년 경력을 가진 테크니컬 SEO 실무자. 크롤링 가능성, 렌더링, 사이트 구조, AI가 읽기 쉬운 콘텐츠를 위한 기술 기반을 다룹니다.
