우리 병원 홈페이지, 구글이 '빈 페이지'로 볼 수 있습니다: 자바스크립트와 크롤링

핵심 요약

• 구글은 페이지를 크롤링 → 렌더링 → 색인 3단계로 읽습니다. 자바스크립트는 이 중 '렌더링' 단계에서 실행됩니다
• 렌더링은 곧바로 되지 않고 순서를 기다립니다. 구글 문서는 "몇 초 걸릴 수도, 그보다 더 걸릴 수도 있다"고 말합니다. 그 사이 자바스크립트로만 채워지는 내용은 늦게 읽히거나 놓칠 수 있습니다
• 구글봇은 사람처럼 버튼을 누르거나 스크롤하지 않습니다. 클릭해야 나타나는 진료 정보는 구글이 못 볼 수 있습니다
• 링크는 반드시 <a href="..."> 형태여야 구글이 따라갑니다. onclick으로만 움직이는 버튼은 링크로 인정되지 않습니다
• 구글 문서는 "서버 렌더링·프리렌더링은 여전히 좋은 방법"이라고 권합니다. 사람과 크롤러 모두에게 빠르고, 모든 봇이 자바스크립트를 실행하는 건 아니기 때문입니다
• 우리 눈으로 확인하는 법: 서치 콘솔의 'URL 검사' 도구로 구글이 실제로 렌더링한 HTML을 보면, 우리 화면에 보이는 내용이 구글에도 보이는지 알 수 있습니다

"홈페이지는 멀쩡한데 검색에는 내용이 안 뜬다"

병원 홈페이지를 열면 진료 안내도, 의료진 소개도, 오시는 길도 잘 보입니다. 그런데 정작 구글에서 우리 병원 이름을 검색하면 그 내용이 제대로 안 잡히는 경우가 있습니다. "사람 눈에는 다 보이는데 구글은 왜 못 보지?"라는 의문이 여기서 생깁니다.

원인 중 하나가 바로 자바스크립트입니다. 요즘 홈페이지는 화면에 글자와 이미지를 처음부터 다 박아 두는 대신, 자바스크립트라는 프로그램이 브라우저에서 실행되면서 내용을 그려 넣는 방식이 많습니다. 사람 눈에는 똑같아 보여도, 구글이 이 내용을 읽는 방식은 조금 다릅니다.

이 글은 개발자가 아니라 병원 운영자를 위한 것입니다. 코드를 직접 고치자는 게 아니라, "우리 홈페이지가 구글에게 어떻게 보이는지"를 이해하고 확인할 줄 알게 되는 것이 목표입니다.

구글은 페이지를 3단계로 읽습니다

구글 공식 문서는 구글이 페이지를 처리하는 과정을 세 단계로 설명합니다.

1. 크롤링(Crawling) — 구글봇이 주소를 방문해 HTML을 받아오고, 그 안의 링크를 따라 다른 페이지를 찾습니다
2. 렌더링(Rendering) — 받아온 페이지의 자바스크립트를 실제로 실행해서, 사람이 보는 것과 같은 최종 화면을 만들어 봅니다
3. 색인(Indexing) — 그렇게 완성된 내용을 분석해 검색에 저장합니다

여기서 중요한 건 자바스크립트가 실행되는 시점이 2단계, 즉 렌더링 단계라는 점입니다. 자바스크립트로 채워지는 내용은 구글이 렌더링을 마쳐야 비로소 보입니다.

자바스크립트 실행(렌더링)은 '나중에' 처리됩니다

가장 오해하기 쉬운 지점이 여기입니다. 구글이 페이지를 방문하자마자 자바스크립트까지 다 실행해서 본다고 생각하기 쉽지만, 실제로는 그렇지 않습니다.

구글 문서는 이렇게 설명합니다.

"Googlebot은 200 상태 코드를 반환하는 모든 페이지를 렌더링 대기열에 넣습니다. (…) 페이지는 이 대기열에 몇 초 머물 수도 있지만, 그보다 더 오래 걸릴 수도 있습니다."

풀어 쓰면 이렇습니다. 구글은 일단 페이지의 HTML을 받아 두고, 자바스크립트 실행(렌더링)은 자원에 여유가 생길 때 순서대로 처리합니다. 이 렌더링에는 최신 크롬(evergreen Chromium)이 쓰입니다.

문제는 이 대기 시간 동안입니다. HTML 자체에 진료 정보가 담겨 있으면 1단계에서 바로 읽히지만, 그 정보가 자바스크립트가 실행돼야만 나타난다면 렌더링 순서를 기다려야 합니다. 렌더링이 밀리거나 그 과정에서 오류가 나면, 정작 중요한 진료·의료진 정보가 늦게 읽히거나 아예 놓칠 위험이 생깁니다.

그래서 구글 문서도 결론을 이렇게 냅니다.

"서버 측 렌더링이나 프리렌더링은 여전히 좋은 방법입니다. 사용자와 크롤러 모두에게 사이트를 더 빠르게 만들어 주고, 모든 봇이 자바스크립트를 실행할 수 있는 것은 아니기 때문입니다."

'서버 렌더링'이라는 말이 어렵게 들리지만, 뜻은 단순합니다. 자바스크립트가 실행되기를 기다릴 필요 없이, 페이지를 열자마자 진료·의료진 같은 핵심 정보가 HTML에 이미 담겨 있게 만드는 것입니다. 이 개념은 구글 AI 검색과 병원 홈페이지 HTML 편에서도 다뤘습니다.

구글봇은 버튼을 누르지 않습니다

또 하나 병원 사이트에서 자주 걸리는 함정이 있습니다. 사람은 홈페이지에서 '진료과목 더보기'를 누르고, 탭을 눌러 의료진 목록을 펼치고, 아래로 스크롤해 오시는 길을 봅니다. 그런데 구글봇은 이렇게 화면을 조작하지 않습니다. 버튼을 클릭하지도, 탭을 넘기지도, 스크롤로 무언가를 불러오지도 않습니다.

즉 우리 병원의 핵심 정보가 "클릭해야 나타나는" 구조라면, 구글은 그 클릭을 하지 않기 때문에 그 안의 내용을 못 볼 수 있습니다. 예를 들어 이런 경우입니다.

• 진료과목이 탭으로 나뉘어 있고, 첫 탭 말고는 클릭해야 내용이 로드되는 경우
• 의료진 프로필이 "더보기"를 눌러야 상세가 펼쳐지는 경우
• 자주 묻는 질문이 클릭해야 답이 열리는 아코디언인데, 답 내용이 열릴 때 자바스크립트로 불러와지는 경우

처음부터 HTML에 담겨 있고 화면에서만 접었다 폈다 하는 구조라면 대체로 괜찮습니다. 문제는 클릭하는 순간 비로소 내용을 가져오는 구조입니다. 이 둘은 사람 눈에는 똑같아 보여도 구글에게는 전혀 다릅니다.

링크는 <a href>여야 구글이 따라갑니다

페이지끼리 연결하는 링크도 마찬가지입니다. 구글 문서의 원칙은 아주 분명합니다.

"Google은 링크가 href 속성을 가진 <a> 요소(앵커 요소)일 때만 크롤링할 수 있습니다."

즉 아래 형태여야 구글이 링크로 인정하고 따라갑니다.

<a href="/doctors">의료진 소개</a>

반대로 아래 같은 형태는 구글이 링크로 보지 못합니다.

<span onclick="goTo('/doctors')">의료진 소개</span>   <!-- a 요소가 아님 -->
<a onclick="goTo('/doctors')">의료진 소개</a>          <!-- href가 없음 -->

병원 홈페이지에서 메뉴가 예쁜 버튼이나 이미지로 되어 있고, 클릭하면 자바스크립트로 페이지가 바뀌는 구조라면 이 함정에 걸리기 쉽습니다. 사람은 잘 이동하지만, 구글봇은 그 경로를 따라가지 못해 의료진·진료 페이지 자체를 발견하지 못할 수 있습니다. 발견되지 않은 페이지는 검색에도 뜨지 않습니다. 이 링크 문제는 사이트맵 편에서 다룬 "내부 링크가 부실할 때 사이트맵이 필요한 이유"와도 이어집니다.

'주소 없는 페이지'도 문제입니다

자바스크립트로 화면만 바꾸고 주소(URL)는 그대로인 사이트도 있습니다. 예를 들어 의료진을 눌러도 주소창이 계속 우리병원.kr 하나로 고정된 채 화면 안쪽만 바뀌는 경우입니다.

구글은 페이지를 주소 단위로 저장합니다. 진료 안내와 의료진 소개가 서로 다른 주소를 갖고 있어야, 구글도 그 둘을 각각의 페이지로 색인할 수 있습니다. 구글 문서는 이럴 때 브라우저의 History API를 써서 화면마다 제대로 된 주소를 갖게 하라고 권합니다. # 뒤에 붙는 방식(프래그먼트)으로 화면을 나누면 "구글봇이 그 주소를 안정적으로 해석하지 못한다"고 명시합니다.

또 하나, 없는 페이지를 열었을 때의 처리도 중요합니다. 이런 자바스크립트 방식 사이트에서는 존재하지 않는 주소를 열어도 서버가 정상(200) 응답을 주고 화면에만 "페이지를 찾을 수 없습니다"를 자바스크립트로 띄우는 일이 생깁니다. 이걸 흔히 '소프트 404'라고 부릅니다. 구글은 이런 페이지를 어떻게 다뤄야 할지 헷갈리게 됩니다. 진짜 없는 페이지라면 실제로 404 응답을 주거나 noindex 처리를 해서, "이 페이지는 검색에 넣지 마세요"라고 분명히 알려 주는 편이 맞습니다.

우리 눈으로 확인하는 법: 'URL 검사' 도구

여기까지 읽으면 "그래서 우리 병원 홈페이지는 괜찮은 거야, 아니야?"가 궁금해집니다. 다행히 구글이 직접 확인하는 도구를 제공합니다.

가장 쉬운 방법은 우리가 브라우저에서 보는 '소스 보기'가 아니라, 구글이 실제로 렌더링한 결과를 보는 것입니다. 이 둘은 다를 수 있습니다. 소스 보기는 자바스크립트가 실행되기 전의 원본이고, 우리에게 필요한 건 "구글이 자바스크립트까지 실행한 뒤 최종적으로 본 화면"이기 때문입니다.

Google Search Console의 URL 검사(URL Inspection) 도구가 이걸 보여줍니다.

1. 서치 콘솔에서 확인하려는 페이지 주소를 URL 검사에 입력합니다
2. 검사 결과에서 렌더링된 HTML(구글이 본 최종 화면)과 로드된 리소스, 자바스크립트 오류 등을 볼 수 있습니다
3. 우리 화면에 보이는 진료·의료진 정보가 이 렌더링된 HTML 안에도 들어 있는지 확인합니다

만약 사람 화면에는 보이는 의료진 목록이 렌더링된 HTML에는 없다면, 그건 구글이 그 내용을 못 보고 있다는 신호입니다. 서치 콘솔 자체를 아직 안 붙였다면 서치 콘솔 색인 생성 리포트 편부터 보는 순서가 맞습니다.

병원 운영자가 업체에 물어볼 질문

직접 코드를 볼 수는 없어도, 홈페이지를 만든 업체나 담당자에게 이렇게 물어보면 상태를 가늠할 수 있습니다.

질문	확인하려는 것
"진료·의료진 내용이 처음 HTML에 담겨 있나요, 아니면 자바스크립트로 나중에 채워지나요?"	렌더링 대기 위험
"메뉴 링크가 실제 <a href> 링크인가요?"	크롤링 가능 여부
"진료과목·의료진이 클릭해야 내용이 로드되나요?"	클릭 함정
"페이지마다 고유한 주소가 있나요?"	색인 단위
"서치 콘솔 URL 검사에서 우리 내용이 그대로 보이나요?"	실제 결과 확인

흔히 하는 오해

• "사람 눈에 보이면 구글에도 보인다." 사람은 자바스크립트가 다 실행된 화면을 보지만, 구글은 렌더링을 나중에 처리하고 클릭도 하지 않습니다. 같지 않습니다
• "소스 보기로 확인하면 된다." 소스 보기는 자바스크립트 실행 전 원본입니다. 구글이 본 최종 화면은 URL 검사의 렌더링 결과로 봐야 합니다
• "자바스크립트 사이트는 무조건 검색에 안 뜬다." 그렇지는 않습니다. 구글은 자바스크립트를 실행할 수 있습니다. 다만 늦어지거나 함정에 걸릴 위험이 있어, 핵심 정보는 HTML에 미리 담아 두는 편이 안전합니다

솔직하게 짚어 둘 것

• 자바스크립트를 서버 렌더링으로 바꾼다고 순위가 오른다는 보장은 없습니다. 이건 순위 기법이 아니라, 구글이 우리 내용을 놓치지 않게 하는 위생 작업입니다
• 렌더링이 잘 된다고 해서 문의나 예약이 늘어난다고 약속할 수 없습니다. 우리가 할 수 있는 건 "우리 병원의 핵심 정보를 구글이 확실히 읽을 수 있게 하는 것"까지입니다
• 홈페이지 구조를 바꾸는 일은 개발이 필요합니다. 운영자가 할 일은 상태를 확인하고, 무엇이 문제인지 정확히 짚어 요청하는 것입니다

병원 운영자 실전 체크리스트

상태 확인

• 서치 콘솔 URL 검사로, 우리 진료·의료진 내용이 렌더링된 HTML에 들어 있는지 확인했는가
• '소스 보기'가 아니라 '렌더링 결과'로 확인했는가

구조 점검(업체에 확인)

• 핵심 정보가 처음 HTML에 담겨 있는가(자바스크립트로 나중에 채워지지 않는가)
• 메뉴·본문 링크가 실제 <a href> 링크인가
• 진료과목·의료진이 클릭해야만 내용이 로드되는 구조는 아닌가
• 페이지마다 고유한 주소가 있는가
• 없는 페이지를 열면 제대로 404가 뜨는가(소프트 404가 아닌가)

다음 단계

우리 병원이 검색에서 어떻게 읽히는지는 여러 단계로 이어집니다.

1. 구글이 내용을 읽을 수 있는 형태인가 — 자바스크립트와 렌더링 (이 글)
2. 페이지 내용을 검색·AI가 읽는 HTML 기본기 — 구글 AI 검색과 병원 홈페이지 HTML
3. 실제로 색인됐는지 확인 — 서치 콘솔 색인 생성 리포트
4. 페이지 목록을 구글에 알려주기 — 사이트맵

자바스크립트로 만든 홈페이지가 잘못된 건 아닙니다. 다만 사람 눈에 보이는 것과 구글이 읽는 것은 다를 수 있습니다. "우리 병원의 핵심 정보를 구글이 확실히 읽고 있는지"를 한 번 확인해 두는 것, 그게 검색의 출발점입니다.

---

구글 공식 문서: 자바스크립트 SEO 기본사항 이해하기, 자바스크립트 관련 검색 문제 해결하기, Google이 인식할 수 있는 링크 만들기 (Google Search Central)