병원 홈페이지의 새 진료 안내를 발행했는데 검색 결과에 보이지 않는다면, 먼저 URL 발견 → 접근 → 수집 → 색인 가능 → 검색 노출을 서로 다른 단계로 나눠 확인해야 합니다. 사이트맵에 주소가 있다고 즉시 검색에 나오는 것은 아닙니다. 검색 로봇이 페이지를 찾았더라도 서버 오류나 로봇 규칙 때문에 읽지 못할 수 있고, 읽은 뒤에도 색인 여부는 검색 서비스가 결정합니다. 이 글은 병원 운영자가 담당 개발자나 대행사에 정확한 수정 요청을 전달할 수 있도록 실제 URL 한 개를 기준으로 점검 순서를 정리했습니다.
진료시간·위치·진료과 안내처럼 방문자가 바로 확인해야 할 페이지부터 시작하세요. 다른 글과 같은 문장을 늘려 새 페이지 수를 늘리는 방식은 문제를 해결하지 못합니다. 점검표에는 URL, 공개 날짜, 확인 도구, 발견한 오류, 담당자, 수정 날짜, 다시 검사한 결과를 같은 행에 적습니다. “색인 요청을 눌렀다”와 “실제로 색인됐다”를 반드시 다른 칸으로 기록하세요.
1. 검색에서 빠진 정확한 URL을 고른다
첫 단계는 “우리 병원이 검색에 안 나온다”는 넓은 증상을 한 개의 공개 URL로 바꾸는 일입니다. 병원명 검색, 특정 진료 질문, 네이버 플레이스 노출은 서로 다른 화면입니다. 예를 들어 신규 진료시간 페이지를 점검한다면 검색 결과의 위치나 특정 문구보다 그 페이지의 최종 주소를 먼저 적습니다. 주소 끝의 슬래시, 한글 주소의 인코딩, www 유무, HTTP에서 HTTPS로 이동하는 경로가 섞이면 같은 문제를 여러 건으로 세기 쉽습니다.
브라우저에서 주소를 열어 최종적으로 도착한 URL을 복사하고, 페이지 제목과 본문이 기대한 내용인지 확인합니다. 같은 내용을 가진 다른 URL이 이미 검색에 보이는지도 살펴보세요. 이때의 목표는 “어떤 주소가 대표 페이지인가”를 합의하는 것입니다. 별도 모바일 주소나 캠페인 매개변수가 붙은 URL이 있다면 그것도 목록에 적되, 새 글을 만들기 전에 기존 페이지의 대표 URL과 연결 관계를 확인합니다. 중복 페이지의 canonical·리디렉션 결정은 별도 문제이므로 무턱대고 모두 색인 요청하지 않습니다.
정상 예시는 병원이 공유한 진료 안내 주소와 실제 도착 주소가 같고, 제목·본문에 그 진료 안내가 명확하게 보이는 경우입니다. 오류 예시는 모바일에서 같은 주소를 열었는데 홈페이지로 이동하거나, 예전 이벤트 안내가 뜨거나, 존재하지 않는 페이지로 연결되는 경우입니다. 후자라면 키워드 수정보다 링크와 서버 응답을 먼저 고쳐야 합니다.
2. 공개 응답과 로그인·리디렉션을 확인한다
구글의 기술 요구사항은 검색 로봇이 차단되지 않고, 페이지가 정상적인 HTTP 200 응답을 주며, 색인 가능한 내용을 제공하는 것입니다. 여기서 브라우저에 화면이 보이는 것과 서버가 올바른 상태 코드를 보내는 것은 다를 수 있습니다. 예를 들어 화면에는 “찾을 수 없음”이 적혀 있는데 서버가 200을 반환하면 검색 도구는 소프트 404로 판단할 수 있습니다. 반대로 정상 안내가 열려도 중간에 로그인이나 접근 제한이 끼면 공개 검색 로봇은 같은 내용을 읽지 못합니다.
담당자에게는 점검 URL의 최종 응답 코드, 중간 리디렉션 단계, 로그인 없이 열리는지, 주요 CSS와 이미지가 함께 제공되는지를 한 번에 요청하세요. 개인 브라우저에서 관리자 로그인한 상태로만 검사하면 공개 방문자의 상황을 놓칩니다. 시크릿 창이나 로그아웃 상태에서도 제목과 핵심 본문이 보이는지 확인하는 이유가 여기에 있습니다. 예약 폼 안쪽처럼 민감한 개인 정보를 다루는 화면은 공개 색인 대상과 구분해야 합니다.
정상 사례는 공개 페이지가 200으로 열리고 진료과·운영시간·연락 경로가 본문 텍스트로 표시되는 것입니다. 오류 사례는 잘못된 URL이 여러 번 이동하다가 홈으로 끝나거나, 페이지마다 동일한 오류 문구만 출력하는 것입니다. 이런 경우 색인 요청을 반복하지 말고 응답·리디렉션·본문을 먼저 수정합니다.
3. robots.txt와 noindex를 분리해 점검한다
robots.txt는 크롤러가 어디에 접근할 수 있는지를 관리하고, noindex는 접근 가능한 페이지를 검색 색인에서 제외하라는 지시입니다. 두 설정을 같은 것으로 취급하면 진단이 엇갈립니다. 구글은 robots.txt로 차단한 URL도 다른 링크를 통해 주소만 발견할 수 있으므로, 검색 결과에서 반드시 숨기는 수단으로 사용하지 말라고 설명합니다. 네이버 역시 robots.txt를 수집 허용·제한 규칙으로 설명하며, 비공개 정보 보호에는 로그인 등 별도 방법이 필요하다고 안내합니다.
병원 사이트에서는 robots.txt의 일반 규칙이 진료 페이지나 이미지·스타일 리소스까지 막고 있지 않은지 확인합니다. 동시에 해당 HTML의 robots 메타 태그 또는 응답 헤더에 noindex가 들어 있는지 봅니다. 워드프레스의 “검색 엔진이 사이트를 검색하지 못하도록 요청” 설정이 실수로 유지된 경우도 검토 대상이지만, 서버 설정을 확인하지 않고 플러그인을 마구 끄는 방식은 피하세요. 변경 전에는 왜 그 규칙이 있었는지 개발 담당자와 확인해야 합니다.
정상 예시는 공개 진료 안내 URL에 크롤링 차단 규칙이 없고, 페이지에 noindex가 없으며, 검색용이 아닌 관리자·개인정보 화면만 보호되는 것입니다. 오류 예시는 사이트를 새로 개편한 뒤 테스트 서버의 차단 규칙이 운영 사이트에 복사된 경우입니다. 또 robots.txt로 페이지 접근을 막아 놓고 noindex만 추가하면 로봇이 그 태그를 읽지 못할 수 있으므로 두 규칙의 역할을 분리해 수정합니다.
4. 사이트맵과 내부 링크로 발견 경로를 확인한다
사이트맵은 중요한 URL의 목록을 검색 서비스에 알려 주는 단서이지 색인을 보장하는 버튼이 아닙니다. 구글은 사이트맵에 검색 결과에 표시되기를 원하는 완전한 URL을 넣고, 갱신 날짜가 실제 수정과 맞도록 관리하라고 안내합니다. 병원 홈페이지에서 새 글을 발행했다면 사이트맵에 최종 대표 URL이 실렸는지 확인하세요. 과거 주소, 비공개 미리보기 URL, noindex 대상이 함께 들어 있다면 목록의 품질을 점검할 필요가 있습니다.
내부 링크는 사람과 검색 로봇 모두에게 다음 페이지를 찾는 길입니다. 진료시간 안내가 사이트맵에는 있지만 홈페이지와 진료과 페이지에서 연결되지 않는다면 방문자도 찾기 어렵습니다. 관련 페이지에서 평범한 HTML 링크를 제공하고, “자세히” 같은 모호한 문구 대신 목적을 알 수 있는 연결 문장을 씁니다. 다만 모든 글의 하단에 같은 링크를 무작정 붙이기보다 그 질문을 이어 읽을 필요가 있는 곳에 배치합니다.
정상 예시는 대표 진료과 페이지에서 세부 진료 안내로 이동할 수 있고, 사이트맵에도 같은 HTTPS URL이 있는 경우입니다. 오류 예시는 사이트맵에 /old-hours/가 남아 있고 공개 메뉴는 /new-hours/로 향하는 경우입니다. 무엇을 유지할지 정한 뒤 링크와 사이트맵을 함께 고치고, 주소 변경이 있었다면 적절한 리디렉션이 있는지 별도 확인합니다.
5. 모바일 화면에서 핵심 내용을 읽을 수 있는지 본다
구글은 모바일 버전의 내용을 기준으로 색인하고 순위를 정한다고 안내합니다. 따라서 데스크톱에서 보이는 진료 안내가 모바일에서는 접힌 버튼을 눌러야만 불러와지거나, 이미지 속 글자로만 제공된다면 점검이 필요합니다. 접기 UI 자체가 금지된다는 뜻은 아닙니다. 중요한 것은 모바일 HTML과 렌더링 결과에서 제목, 진료 범위, 위치, 운영시간, 연락 경로를 확인할 수 있는지입니다.
휴대전화로 글을 직접 열어 제목과 첫 답변을 읽어 보고, 이미지가 차지하는 공간 때문에 본문이 사라지지 않았는지 살펴보세요. 모바일과 데스크톱에 서로 다른 URL을 쓰는 사이트는 대응 페이지가 하나씩 연결되는지도 확인해야 합니다. 구글 문서는 서로 다른 데스크톱 URL이 모두 모바일 홈페이지 하나로 이동하면 개별 페이지가 색인에서 빠질 수 있다고 설명합니다. 반응형 사이트라도 숨겨진 본문이나 차단된 이미지 리소스가 없는지 확인하면 좋습니다.
정상 예시는 두 화면에서 같은 핵심 진료 정보를 읽을 수 있고, 버튼을 누르지 않아도 주요 답변이 본문에 존재하는 경우입니다. 오류 예시는 휴대전화에서 진료과 내용 대신 홈 화면만 나오거나, 병원 안내가 하나의 이미지로만 남는 경우입니다. 이때는 모바일 레이아웃과 콘텐츠 전달 방식을 수정하고, 변경 후 렌더링 화면을 다시 검사합니다.
6. URL 검사 결과를 원인별로 해석한다
사이트 소유 권한이 있다면 구글 서치 콘솔의 URL 검사와 네이버 서치어드바이저의 URL 검사를 각각 사용합니다. 네이버 URL 검사는 상태 코드, 수집 여부, 색인 가능 여부, 색인 여부와 제목·설명 등 메타 정보를 나눠 보여 줍니다. 구글에서도 최근 수집 상태와 페이지가 선택된 대표 URL을 확인할 수 있습니다. 두 도구의 용어와 반영 시각은 다르므로 결과를 한 문장으로 섞지 말고 도구 이름과 검사 날짜를 같이 남기세요.
결과가 “아직 발견하지 못함”이라면 사이트맵과 내부 링크를 먼저 보고, “접근할 수 없음”이면 서버·robots 규칙을 확인합니다. “수집했지만 색인되지 않음”이라면 기술 차단만 의심하지 말고 기존 페이지와의 중복, 본문의 실제 가치, 페이지가 다루는 질문도 검토합니다. 검사가 성공했다고 곧바로 검색 순위가 생기는 것은 아닙니다. 검색 서비스가 어떤 검색어에 노출할지 별도로 결정하기 때문입니다.
담당자가 보내는 보고서에는 검사 화면 캡처만이 아니라 URL, 검사일, 발견한 상태, 원인 가설, 수정한 파일 또는 페이지, 재검사 결과가 있어야 합니다. 접근 권한이 없다면 요청을 완료했다고 기록하지 않습니다. 사이트 공개 상태 확인과 콘솔의 색인 생성 요청은 서로 다른 작업입니다.
7. 수정 후 재검사와 기록을 남긴다
수정은 원인 하나를 고른 뒤 영향 범위를 확인하며 진행합니다. 예를 들어 robots 규칙 하나를 바꾸면 진료 페이지뿐 아니라 이미지나 다른 폴더에도 영향이 갈 수 있습니다. 특정 URL의 noindex를 제거했다면 최종 HTML에 태그가 사라졌는지, 캐시가 오래된 버전을 내보내지 않는지 다시 봅니다. 사이트맵을 고쳤다면 운영 도메인의 파일에서 새 URL이 실제로 보이는지 확인합니다.
권한이 있는 도구에서 새 URL 검사를 실행하고 필요한 경우 색인 요청을 할 수 있지만, 요청 수락은 색인 완료가 아닙니다. 변경 직후 같은 URL을 여러 번 제출하는 행동도 우선순위를 보장하지 않습니다. 일정 시간이 지난 뒤 도구의 상태와 실제 검색 노출을 다시 보고, 방문자가 페이지를 정상적으로 이용하는지도 확인하세요. 구글은 사이트맵에 넣었다는 사실만으로 모든 URL을 곧바로 수집하지 않으며, 검색 반영에는 시간이 걸릴 수 있다고 안내합니다.
실무 표에는 페이지 URL / 발견 문제 / 수정일 / 재검사 결과 / 다음 확인일 다섯 칸을 둡니다. 예를 들어 “진료시간 페이지: 모바일에서 홈으로 이동 → 대응 모바일 URL 연결 수정 → 공개 화면과 URL 검사 정상 → 1주 뒤 색인 상태 재확인”처럼 기록합니다. 이렇게 해야 다음 담당자가 색인 요청만 반복하지 않고 남은 원인을 이어서 해결할 수 있습니다.
상담 전에 가져갈 한 장 요약
검색에서 빠진 페이지 하나를 고른 다음 ① 공개 최종 URL ② 서버 응답과 로그인 여부 ③ robots.txt와 noindex ④ 사이트맵과 내부 링크 ⑤ 모바일 렌더링 ⑥ 검색 도구의 URL 검사 ⑦ 수정 후 재검사를 순서대로 확인하세요. “검색에 안 보인다”는 현상만으로 새 콘텐츠를 주문하지 말고, 어느 단계에서 막혔는지 먼저 밝혀야 합니다. 병원 홈페이지 운영팀, 개발자, 마케팅 담당자가 같은 URL 표를 공유하면 수정 책임과 검증 결과를 분명히 할 수 있습니다.