네이버 플레이스와 홈페이지, 따로 놀면 손해입니다

환자는 두 번 묻습니다. 첫 번째는 '어디 있지?', 두 번째는 '여기 괜찮나?'.

• 네이버 플레이스 — 첫 번째 질문의 자리. 위치·영업시간·리뷰로 후보군에 진입합니다. 여기서 하는 일은 설득이 아니라 후보에 드는 것입니다.
• 홈페이지 — 두 번째 질문의 자리. 진료 철학·의료진·시설·상세 안내로 '여기라면 괜찮겠다'를 확인시키고 예약으로 잇습니다.

역할이 다르니 담을 내용도 다릅니다. 플레이스에 긴 진료 철학을 적는 것도, 홈페이지에서 진료시간을 한참 찾아야 하는 것도 둘 다 잘못된 배치입니다.

다만 사실 정보만은 완전히 같아야 합니다. 상호, 주소, 전화번호, 진료시간. 이 넷이 어긋나는 순간 두 채널은 서로를 갉아먹기 시작합니다.

플레이스엔 토요일 진료라는데 홈페이지엔 휴진이면, 환자는 확인 전화를 겁니다. 운이 나쁘면 헛걸음하고, 더 나쁘면 그냥 다른 병원을 고릅니다. 검색 결과 안에서 경쟁자는 늘 한 칸 아래에 있습니다.

검색엔진은 여기저기 흩어진 업체 정보를 서로 대조해 신뢰도를 매깁니다. 지역 검색에서는 이를 흔히 NAP(Name·Address·Phone) 일관성이라고 부릅니다. 같은 병원이 어디서는 '○○이비인후과', 어디서는 '○○ 이비인후과의원'이면, 기계는 둘을 같은 곳으로 묶는 데 확신을 덜 갖습니다.

그리고 이 대조는 사람의 상식만큼 너그럽지 않습니다. 사람 눈에는 누가 봐도 같은 병원이지만, 표기가 다르면 서로 다른 표기로 남습니다 — 띄어쓰기 하나, 하이픈 하나까지.

현장에서 반복해서 발견되는 불일치는 대체로 다음 다섯 가지에 모입니다.

• 상호 표기 — 띄어쓰기, '의원/병원' 접미사 유무, 영문 병기 여부.
• 전화번호 형식 — 02-000-0000, 020000000, (02)000-0000. 대표번호와 예약번호가 채널마다 다르게 걸린 경우도 흔합니다.
• 주소 — 도로명과 지번 혼용, 층·호수 표기 누락(3층 / 301호 / 아예 없음).
• 진료시간 — 점심시간, 토요일 단축 진료, 공휴일, 그리고 '마지막 접수 시간'. 특히 마지막 접수는 홈페이지에만 적혀 있고 플레이스에는 없는 경우가 많습니다.
• 홈페이지 주소 — www 유무, http/https. 플레이스에 등록된 URL이 리다이렉트를 한 번 더 거치면 그만큼 이탈이 생깁니다.

목록이 시시해 보이지만, 이 다섯 줄이 두 채널에서 한 글자도 다르지 않은 병원은 생각보다 드뭅니다.

이 문제를 '앞으로 잘 챙기자'로 풀면 반드시 다시 어긋납니다. 진료시간은 바뀌고, 담당자도 바뀌기 때문입니다. 그래서 정합은 주의력이 아니라 원본을 하나만 두는 구조로 지킵니다.

홈페이지 안에서만 봐도 그렇습니다. 진료시간이 푸터에 한 번, 오시는 길 페이지에 한 번, 구조화 데이터에 한 번 하드코딩돼 있으면 세 곳이 서로 달라지는 건 시간 문제입니다.

이렇게 두면 진료시간이 바뀔 때 고칠 곳이 한 곳입니다. 그리고 그 한 곳이 화면과 구조화 데이터를 동시에 바꿉니다. 남는 일은 플레이스 쪽 값을 같은 값으로 맞추는 것 하나뿐입니다.

사람이 보는 화면 아래에는 기계가 읽는 층이 하나 더 있습니다. 병원 정보를 schema.org 어휘로 적어 두는 JSON-LD입니다. 병원은 MedicalClinic 타입을 씁니다. 이 타입은 정의상 LocalBusiness를 상속하므로, 주소·전화·영업시간 같은 지역 업체 속성을 그대로 쓸 수 있습니다.

두 가지가 중요합니다. 첫째, 이 JSON은 앞의 consultHours 배열에서 생성돼야 합니다. 손으로 다시 적는 순간 원본이 두 개가 되고, 다시 어긋납니다. 둘째, sameAs에 네이버 플레이스 URL을 넣습니다. '이 홈페이지와 저 플레이스는 같은 곳'이라고 기계에게 직접 말해 주는 자리입니다.

다만 기대치는 정확히 잡는 편이 좋습니다. JSON-LD는 주로 구글과 AI 검색이 업체를 이해하는 데 쓰는 층입니다. 반면 네이버 지도에 뜨는 정보는 스마트플레이스에 등록된 값에서 옵니다. 즉 홈페이지의 구조화 데이터는 플레이스에 채워야 할 정보를 대신해 주지 않습니다. 둘 다 하는 이유는 두 검색이 서로 다른 곳을 읽기 때문입니다.

1. 어느 화면에서든 한 번에 — 전화·네이버 지도·예약을 헤더든 푸터든 모바일 하단 고정 바든, 한 번의 탭으로 닿게 둡니다.
2. 플레이스 링크는 최종 URL로 — 단축 URL이나 리다이렉트를 거치지 않고 최종 주소를 직접 겁니다.
3. 지도는 이미지가 아니라 링크로 — 캡처 이미지만 올려 두면 길찾기가 시작되지 않습니다.
4. 지역 랜딩 페이지 — '○○동 이비인후과' 같은 지역 의도 검색은 지도 밖에서도 일어납니다. 그 검색을 받아 낼 페이지가 따로 있어야 합니다.

플레이스 운영 자체는 병원이 하더라도, 홈페이지가 이 기반을 갖추면 지도에서 시작된 동선이 예약까지 끊기지 않습니다.

• 순위를 보장한다는 제안 — 네이버는 플레이스 노출 순위의 세부 기준을 공개하지 않고, 그 기준은 언제든 바뀝니다. 순위 보장은 지킬 수 없는 약속입니다.
• 리뷰 대가 지급 — 플랫폼 정책 위반일 뿐 아니라, 의료광고에서는 환자 유인으로 해석될 소지가 있습니다.
• 지역명 반복 삽입 — '강남 강남역 강남구 이비인후과'식 키워드 나열은 사람에게도 기계에게도 도움이 되지 않습니다.

환자에게 플레이스와 홈페이지는 '한 병원'입니다. 두 채널이 다른 말을 하면, 신뢰도 검색도 반으로 갈립니다.

정합은 마케팅 문제가 아니라 정보 설계 문제입니다. 원본을 하나 두고, 화면과 구조화 데이터가 모두 거기서 파생되게 하고, 플레이스를 그 값에 맞추면 — 담당자가 바뀌어도 두 채널은 같은 말을 계속합니다.

Studio Sion은 병원 홈페이지를 만들 때 진료정보의 원본을 코드 한 곳에 두고, 화면·푸터·JSON-LD가 모두 그 값을 읽도록 설계합니다. 플레이스 운영은 병원이 이어받되, 무엇을 어떤 값으로 맞춰야 하는지는 인수인계 문서로 남깁니다.

이 글은 일반적인 정보이며, 네이버의 검색·노출 정책과 schema.org 명세는 사전 공지 없이 바뀔 수 있습니다.