병원 홈페이지에 진료과 안내, 의료진 소개, 진료시간, 위치 안내가 각각 있어도 방문자가 현재 페이지의 위치를 알기 어려우면 다음 정보를 찾는 데 시간이 걸립니다. 탐색 경로(Breadcrumb)는 ‘홈 › 진료 안내 › 진료과 페이지’처럼 페이지의 상위 단계를 보여 주는 장치입니다. Google은 BreadcrumbList 구조화 데이터를 통해 검색 결과에서 페이지의 위치를 이해하고 표시할 수 있다고 설명합니다. 다만 마크업을 넣었다는 이유만으로 특정 모양의 검색 결과나 AI 답변 인용이 보장되지는 않습니다. 이 글은 병원 운영자가 실제 화면의 탐색 경로와 JSON-LD를 함께 점검하는 순서를 정리합니다.
먼저 방문자에게 보이는 경로를 정한다
스키마 코드를 만들기 전에 진료과 페이지 한 장을 열어 보세요. 상단 메뉴에서 그 페이지까지 클릭으로 도달하는 경로와 화면에 표시되는 안내가 일치해야 합니다. 예를 들어 홈에서 ‘진료 안내’를 누르고 ‘이비인후과’를 선택한다면 ‘홈 › 진료 안내 › 이비인후과’가 자연스럽습니다. 병원의 조직도나 내부 파일명에 맞춘 경로보다 방문자가 실제로 이해하고 이동할 수 있는 이름이 좋습니다. ‘콘텐츠 1 › 카테고리 13’처럼 관리자만 알 수 있는 명칭은 피합니다.
모든 글에 똑같은 경로를 강제로 붙이지 않습니다. 진료시간 페이지가 홈페이지에서 바로 연결된다면 ‘홈 › 진료시간’이 더 정확할 수 있습니다. 특정 의사 소개가 의료진 목록의 하위라면 ‘홈 › 의료진 › 해당 의료진’처럼 표현합니다. 여러 진료과에 공통인 안내 페이지는 실제 사이트에서 이용자가 주로 접근하는 분류를 정하고, 필요하면 Google 공식 안내의 복수 경로 예시를 검토합니다. 같은 URL을 여러 번 생성하는 방식으로 해결하지는 않습니다.
클릭 가능한 단계와 마지막 단계를 구분한다
탐색 경로의 앞 단계는 실제로 열리는 페이지로 연결해야 합니다. ‘홈’은 홈페이지, ‘진료 안내’는 진료 안내의 허브나 목록으로 가야 합니다. 마지막 ‘이비인후과’는 현재 페이지 이름입니다. 방문자가 앞 단계를 눌렀는데 404가 열리거나 언어가 다른 화면으로 이동하면 경로를 수정해야 합니다. 메뉴의 텍스트와 URL을 별도 표로 적어 두면 리뉴얼 때 오래된 링크를 찾기 쉽습니다.
예시 점검표는 ‘현재 URL, 화면에 보이는 탐색 경로, 각 상위 링크의 최종 도착 URL, 모바일에서 누를 수 있는지’ 네 칸이면 충분합니다. 병원 사이트의 진료과 페이지 세 장과 자주 보는 안내 글 두 장만 먼저 표본으로 골라 보세요. 한 페이지에 오류가 있으면 같은 템플릿을 쓰는 다른 페이지에도 영향을 줄 수 있으므로 페이지 유형별로 나눠 확인합니다. 텍스트 링크는 실제 HTML의 href를 가진 일반 링크로 제공하고, 이미지 안에 경로를 그려 넣는 것으로 끝내지 않습니다.
JSON-LD는 화면의 계층과 맞춘다
Google 공식 문서의 BreadcrumbList 예시는 itemListElement 배열에 ListItem을 순서대로 넣습니다. 각 항목에는 position과 name이 필요하며 상위 단계의 item은 해당 페이지 URL을 가리킵니다. 병원 예시라면 1번 홈, 2번 진료 안내, 3번 현재 진료과 순서입니다. position이 빠지거나 두 항목이 같은 숫자면 순서를 제대로 설명하지 못합니다. JSON-LD의 ‘진료과’라고 쓰인 단계가 화면에서는 ‘센터 소개’로 보인다면 둘 중 하나를 고쳐야 합니다. 구조화 데이터는 화면에서 확인할 수 있는 내용을 대신 만들기 위한 장치가 아닙니다.
워드프레스에서 Rank Math 같은 SEO 플러그인을 쓰면 BreadcrumbList가 이미 출력될 수 있습니다. 새 코드를 붙이기 전에 공개 페이지의 JSON-LD를 확인하세요. 같은 페이지에 BreadcrumbList가 두 개 있는데 서로 다른 경로를 말한다면 테마와 플러그인 중 어느 쪽에서 나오는지 파악해야 합니다. 의도한 복수 경로인지, 단순 중복인지 구분하지 않은 채 세 번째 스키마를 추가하면 유지보수만 어려워집니다. 개발자가 수정할 때는 템플릿 한 곳에서 경로의 출처와 URL 생성 규칙을 관리하는 편이 안전합니다.
병원 사이트에서 자주 생기는 네 가지 오류
첫째, 화면에는 ‘홈 › 의료진 › 원장 소개’가 보이는데 구조화 데이터에는 ‘홈 › 블로그 › 원장 소개’가 들어갑니다. 콘텐츠를 이동하고 플러그인의 기본 카테고리만 남겼을 때 흔합니다. 실제 메뉴 경로와 게시글의 카테고리를 확인한 뒤, 방문자가 보는 계층을 기준으로 수정합니다. 둘째, 상위 단계의 item이 이미 삭제된 옛 주소를 향합니다. 브라우저 주소창에서 리디렉션이 몇 번 발생하는지와 최종 페이지가 정상인지 확인합니다.
셋째, 모바일에서는 탐색 경로를 숨기면서 페이지에 현재 위치를 알려 주는 다른 수단도 없습니다. 검색용 코드만 통과하더라도 방문자의 길 찾기 문제는 남습니다. 화면 공간이 좁다면 줄바꿈이나 가로 스크롤을 설계하되, 중요한 링크가 손가락으로 누를 수 없는 크기가 되지 않게 봅니다. 넷째, 현재 페이지의 이름을 글 제목과 다르게 자동 축약해 모호하게 만듭니다. 긴 제목을 그대로 다 쓰지 않아도 되지만, ‘정보’나 ‘안내’만 남으면 어떤 페이지인지 알기 어렵습니다.
실제 수정 순서: 표본부터 전체 템플릿까지
먼저 진료과, 의료진, 오시는 길, 블로그 글의 대표 URL을 한 개씩 고릅니다. 각 페이지에서 표시 경로와 클릭 가능한 상위 URL을 적습니다. 다음으로 페이지 소스의 application/ld+json을 확인해 BreadcrumbList가 있는지, 항목 순서와 이름이 화면과 같은지 비교합니다. Rank Math와 테마의 빵부스러기 설정이 동시에 켜져 있다면 어느 출력이 책임지는지 결정합니다. 플러그인 설정을 바꾸기 전에는 한 페이지의 기존 출력을 보관해 두면 수정 전후 비교가 쉽습니다.
수정 후에는 Google의 리치 결과 테스트에서 구조화 데이터의 주요 오류를 확인하고, 실제 공개 URL을 휴대전화 화면에서도 열어 봅니다. 테스트가 통과해도 모든 검색 화면에 탐색 경로가 표시되는 것은 아닙니다. Google 공식 문서는 배포한 페이지가 robots.txt, noindex, 로그인 요구로 막히지 않아야 한다고 안내합니다. 따라서 크롤러 접근, 페이지 제목, canonical, 내부 링크도 함께 살핍니다. GSC에 접근 권한이 있다면 URL 검사로 Google이 보는 페이지를 확인하고, 실질적으로 변경된 URL만 색인 요청합니다.
마케팅 담당자가 인수인계할 때 남길 기록
한 페이지에서 바로 따라 하는 비교 예시
가상의 ‘해솔의원 피부과 안내’ 페이지를 예로 들어 보겠습니다. 상단 메뉴에는 ‘진료 안내’가 있고 그 안에 ‘피부과’가 있으며, 현재 주소는 /services/skin/이라고 가정합니다. 정상 상태라면 방문자에게 ‘홈 › 진료 안내 › 피부과’가 보이고, 홈과 진료 안내를 누르면 각각 해당 페이지가 열립니다. JSON-LD에도 같은 순서와 명칭이 표시됩니다. 반대로 JSON-LD의 두 번째 단계가 오래된 /department/를 가리키거나 ‘블로그’로 되어 있다면, 현재 메뉴와 맞지 않는 오류입니다. 예시는 실제 병원 사례가 아니며, 자신의 사이트에서 실제 URL과 화면을 기준으로 확인해야 합니다.
수정 담당자는 먼저 현재 URL의 카테고리와 메뉴 연결을 확인합니다. 카테고리가 검색 필터에만 쓰이는지, 실제 상위 페이지인지 구분하세요. 다음으로 SEO 플러그인의 경로 설정과 테마의 출력 기능 중 어느 쪽이 구조화 데이터를 생성하는지 찾습니다. 표시 텍스트만 고치고 JSON-LD를 그대로 두거나 그 반대로 처리하면 두 정보가 다시 어긋납니다. 마지막으로 저장 전후의 페이지 소스를 비교하고, 모바일 화면에서 링크를 직접 눌러 봅니다. 검사 도구의 초록 표시 하나로 운영 검수를 끝내지 않는 이유가 여기에 있습니다.
경로가 없는 페이지라면
현재 병원 사이트에 진료 안내 허브가 없고 모든 진료과가 홈에서 바로 연결된다면 존재하지 않는 ‘진료 안내’ 페이지를 구조화 데이터에 만들지 마세요. 먼저 이용자에게 필요한 목록 페이지를 실제로 만들 것인지 결정합니다. 필요성이 없다면 ‘홈 › 현재 진료과’처럼 간단한 경로가 더 정직합니다. 예약 버튼이나 문의 버튼은 탐색 경로의 상위 단계가 아닙니다. 페이지에서 가능한 행동과 페이지의 위치를 섞지 않아야 합니다. 영문 페이지가 따로 있다면 한국어 이름과 주소를 영문 페이지에 복사하지 말고 해당 언어의 메뉴와 도착 URL을 기준으로 별도 점검합니다.
단순히 ‘Breadcrumb 스키마 적용 완료’라고 적지 말고 적용 범위와 예외를 남기세요. 예를 들어 ‘진료과 상세 템플릿 8개, 의료진 상세 템플릿 5개, 위치 안내 1개’처럼 유형별 URL 수를 기록합니다. 화면 경로와 JSON-LD가 서로 다른 페이지, 상위 목록이 없는 페이지, 다국어 버전에서 경로가 바뀌는 페이지를 따로 표시합니다. 변경 전후 URL 한 쌍과 테스트 일자도 남기면 다음 운영자가 같은 실수를 반복하지 않습니다.
SEO 보고서에는 스키마 개수보다 ‘방문자가 상위 정보를 찾을 수 있는가’, ‘실제 링크가 열리는가’, ‘공개 코드가 화면의 계층과 같은가’를 먼저 넣는 것이 좋습니다. 검색 결과의 표시 형태는 검색어와 Google 시스템에 따라 달라질 수 있습니다. 성과를 설명할 때 탐색 경로만으로 클릭률이나 AI 인용이 올랐다고 단정하지 말고, 수정한 페이지의 유입과 탐색 행동을 별도로 관찰합니다. 병원 홈페이지의 정보 구조를 검토할 때는 메디리바이브 AEO·GEO 안내와 상담 페이지를 참고할 수 있습니다.
오늘의 실행 체크리스트
① 진료과 상세·의료진 상세·오시는 길·블로그 글에서 표본 URL을 고른다. ② 화면의 탐색 경로를 읽고 앞 단계 링크를 모두 눌러 본다. ③ 공개 JSON-LD의 BreadcrumbList 항목 이름·순서·주소를 화면과 대조한다. ④ 플러그인과 테마의 중복 출력을 확인한다. ⑤ 수정 후 모바일 화면과 리치 결과 테스트를 확인하고 필요한 URL만 GSC에서 검사한다. 이 다섯 단계를 완료하면 ‘코드가 있다’는 것과 ‘경로가 정확하다’는 것을 구분해 설명할 수 있습니다.