치과 홈페이지가 검색에 닿고 있는지 — 도구 없이 확인하는 법

치과 홈페이지를 새로 만들고 글을 올리기 시작했는데 검색에서 보이지 않는다는 말을 자주 듣습니다. 이럴 때 대개 글을 더 씁니다. 그런데 글이 검색 엔진에 닿지 않는 상태라면 몇 편을 더 올려도 같은 자리에 머뭅니다. 페이지를 만드는 일과 검색 엔진이 그 페이지를 읽어 가는 일은 서로 다른 일입니다. 앞의 일은 제작 업체가 합니다. 뒤의 일은 확인하는 사람이 없으면 아무도 하지 않습니다. 이 글은 순위를 올리는 방법이 아닙니다. 막힌 곳을 찾는 방법입니다. 도구를 사거나 개발자를 부르기 전에 브라우저 하나로 할 수 있는 점검만 모았습니다. 순서대로 따라가시면 됩니다.

만드는 것과 닿는 것은 다른 일입니다

홈페이지 제작 계약서의 검수 항목을 떠올려 보십시오. 디자인, 사진, 진료 과목 소개, 전화 연결 버튼이 적혀 있습니다. 「구글이 이 페이지를 읽어 갈 수 있는가」는 대개 적혀 있지 않습니다. 그래서 그 항목은 아무도 보지 않은 채로 공개됩니다.

검색 엔진이 페이지를 보여 주기까지는 단계가 있습니다. 구글 Search Central 문서는 이 과정을 크롤링, 색인, 검색 결과 제공의 세 단계로 나눠 설명합니다. 앞 단계가 막히면 뒤 단계는 오지 않습니다. 글을 더 쓰는 일은 관에 물을 더 붓는 일입니다. 관이 잠겨 있으면 물의 양은 문제가 아닙니다.

세 번째 단계에서 밀리는 것은 경쟁입니다. 시간과 내용으로 다뤄야 합니다. 첫 번째와 두 번째 단계에서 막히는 것은 설정입니다. 대개 몇 줄을 고치면 풀립니다. 그런데 설정 문제를 경쟁 문제로 오해하면 글만 계속 쓰게 됩니다. 그래서 순서가 중요합니다. 배관을 먼저 봅니다.

제작 업체 탓만도 아닙니다. 공개 전에는 미완성 화면이 검색에 나오지 않도록 일부러 막아 둡니다. 그 설정을 공개 시점에 푸는 작업이 따로 있습니다. 그 작업을 확인하는 사람이 없으면 막아 둔 상태가 그대로 남습니다. 이 글의 점검 항목 절반이 그 종류입니다.

준비물과 점검 순서

필요한 것은 네 가지입니다. 브라우저, 우리 도메인 주소, 메모할 곳, 휴대폰입니다. 계정도 결제도 설치도 없습니다.

도메인 주소는 정확히 적어 두십시오. www 가 붙는지, 끝이 kr 인지 co.kr 인지, 병원 이름이 영문으로 어떻게 들어가 있는지까지 적습니다. 이 글 뒤쪽에서 www 유무 때문에 생기는 문제를 다루는데, 그때 이 메모가 기준이 됩니다.

같이 적어 둘 숫자가 하나 더 있습니다. 지금 홈페이지에 만들어 둔 페이지 수입니다. 홈 하나, 진료 과목 소개 몇 개, 의료진 소개 몇 개, 오시는 길 하나, 그리고 올린 글 몇 편입니다. 대략의 수여도 됩니다. 이 수와 검색 엔진이 알고 있는 수를 비교하는 것이 첫 점검입니다.

순서를 바꾸지 않으시는 편이 좋습니다. 1번이 한 건도 없는 상태로 나오면 뒤 항목들의 뜻이 달라집니다. 7번만 하고 끝내면 느린 것은 알아도 막힌 것은 모릅니다.

site: 로 색인된 양을 세어 봅니다

구글 검색창에 site: 를 쓰고 바로 뒤에 도메인을 붙여 넣습니다. 띄어쓰기를 넣지 않습니다. 예를 들면 site:example.co.kr 입니다. 그러면 그 도메인에 속한 주소만 나옵니다.

여기서 보이는 결과 개수는 정확한 수가 아닙니다. 구글은 색인 상태를 확인하는 공식 창구로 Search Console 의 「페이지」 보고서를 안내합니다. 그래서 이 방법으로는 자릿수만 봅니다. 32건인지 37건인지는 중요하지 않습니다. 40건쯤인지 3건인지가 중요합니다.

범위를 좁혀 가며 여러 번 세어 보십시오. site:example.co.kr/blog 처럼 경로를 붙이면 그 아래만 나옵니다. 글 목록은 나오는데 개별 글이 하나도 안 나오는 경우가 자주 있습니다. 그러면 목록까지는 길이 있고 글로 들어가는 길이 없다는 뜻입니다. 뒤의 목록 점검에서 그 길을 확인합니다.

글 하나를 지목해서 보는 방법도 있습니다. 그 글의 주소를 복사해 검색창에 그대로 붙여 넣습니다. 아무것도 나오지 않으면 그 주소는 아직 색인되지 않았습니다. 제목의 특이한 문구를 따옴표로 묶어 검색해도 됩니다. 병원 이름처럼 흔한 말보다 그 글에만 있는 표현을 고르시면 됩니다.

한 가지 유보할 점이 있습니다. 공개한 지 얼마 되지 않았다면 아직 안 나오는 것이 정상일 수 있습니다. 구글 Search Central 은 사이트맵에 올린 주소가 모두 크롤링되고 색인된다고 보장하지 않는다고 적습니다. 즉 기다려야 하는 구간이 있습니다. 공개 후 몇 주가 지났는데도 홈조차 없다면 그때는 기다리는 문제가 아닙니다.

sitemap.xml 을 직접 열어 봅니다

주소창에 도메인을 치고 뒤에 /sitemap.xml 을 붙여 엔터를 누릅니다. 글자가 빽빽한 목록이 나오면 정상입니다. 보기 좋게 표로 정리된 화면이 나오는 경우도 있습니다. 둘 다 괜찮습니다.

사이트맵은 사이트의 주소 목록입니다. sitemaps.org 가 공개한 프로토콜 0.9 가 그 형식을 정합니다. sitemaps.org 의 같은 문서는 한 파일에 주소 50,000개까지, 압축하지 않은 상태로 50MB 까지 담을 수 있다고 적습니다. 치과 홈페이지는 이 상한에 걸리는 일이 거의 없습니다. 그래서 이 숫자는 「파일이 커서 다 담지 못했다」는 설명이 왔을 때 되물을 근거로 쓰시면 됩니다.

열린 뒤에는 Ctrl+F 로 찾습니다. 맥에서는 Cmd+F 입니다. 가장 최근에 올린 글의 주소 일부를 넣어 봅니다. 없으면 그 글은 사이트맵에 올라가지 않았습니다. 사이트맵이 글을 발행할 때마다 자동으로 갱신되지 않는 구조일 수 있습니다. 이 경우 처음 만들 때의 주소 몇 개만 영원히 들어 있습니다.

주소의 앞부분도 봅니다. 목록에 적힌 주소가 www 로 시작하는데 사람들이 쓰는 주소에는 www 가 없다면 두 주소가 어긋난 것입니다. http 로 적혀 있는데 실제로는 https 로 열리는 경우도 같습니다. sitemaps.org 프로토콜은 사이트맵 파일이 놓인 위치가 그 안에 담을 수 있는 주소의 범위를 정한다고 적습니다. 그래서 위치와 내용이 어긋나면 그 목록은 무시될 수 있습니다.

lastmod 날짜도 봅니다. 모든 주소가 똑같은 날짜로 찍혀 있으면 그 값은 실제 수정 시점이 아닙니다. 구글 Search Central 은 이 값이 일관되게 정확할 때 참고한다고 적습니다. 값이 늘 같으면 참고할 것이 없는 상태입니다.

마지막으로 robots.txt 안에 사이트맵 위치가 적혀 있는지도 봅니다. sitemaps.org 는 robots.txt 에 Sitemap: 으로 시작하는 줄을 넣어 위치를 알릴 수 있다고 안내합니다. 다음 항목에서 그 파일을 엽니다.

robots.txt 를 직접 열어 봅니다

주소창에 도메인을 치고 뒤에 /robots.txt 를 넣습니다. 몇 줄짜리 글자만 나옵니다. 이 파일은 크롤러에게 어디를 읽어 가도 되는지 알리는 쪽지입니다. RFC 9309 가 2022년에 이 형식을 표준으로 정리했습니다. 같은 문서는 이 파일이 사이트 루트의 /robots.txt 에 있어야 한다고 적습니다. 다른 경로에 둔 파일은 효력이 없습니다.

여기서 가장 흔한 사고가 하나 있습니다. 제작 중에 전체를 막아 둔 설정이 공개 후까지 남아 있는 경우입니다. 두 줄로 생겼습니다. User-agent: 별표 아래에 Disallow: 슬래시 하나가 붙어 있으면 모든 크롤러에게 사이트 전체를 읽지 말라고 말하는 중입니다. 슬래시 하나 차이입니다. Disallow: 뒤가 비어 있으면 아무것도 막지 않는다는 뜻이고, 슬래시가 하나 붙으면 전부 막는다는 뜻입니다.

읽을 때 섞이기 쉬운 두 가지를 구분해 두십시오. robots.txt 는 읽어 가지 말라는 쪽지이고, 검색 결과에 띄우지 말라는 쪽지가 아닙니다. 구글 Search Central 은 robots.txt 로 막은 주소도 다른 곳의 링크를 통해 검색 결과에 나올 수 있다고 적습니다. 반대 방향의 함정도 있습니다. 어떤 페이지를 색인에서 빼려고 noindex 를 넣었다면 그 페이지는 robots.txt 로 막혀 있으면 안 됩니다. 막혀 있으면 크롤러가 그 페이지를 열지 못해 noindex 를 읽지 못합니다. 같은 문서가 이 점을 명시합니다.

파일 자체가 열리지 않는 경우도 봐 두십시오. RFC 9309 는 robots.txt 요청에 서버 오류가 돌아오면 크롤러가 전면 차단으로 간주할 수 있다고 적습니다. 즉 파일이 없는 것보다 파일 요청이 오류로 실패하는 것이 더 나쁜 상태일 수 있습니다. RFC 9309 는 크롤러가 적어도 500KiB 까지는 이 파일을 해석해야 한다고도 적습니다.

AI 크롤러를 허용할지 막을지는 원장님이 결정할 일입니다. 이 글에서 권하지는 않겠습니다. 다만 내 파일에 무엇이 적혀 있는지 모르는 상태는 피하셔야 합니다. 제작 업체가 쓰는 기본 설정이 그대로 들어가 있는 경우가 있고, 그 기본값이 우리 뜻과 다를 수 있습니다. 구글 Search Central 의 크롤러 문서는 Google-Extended 를 막는 것이 구글 검색의 색인에는 영향을 주지 않는다고 적습니다. OpenAI 는 자사 문서에서 크롤러 토큰을 용도별로 나눠 안내합니다. 전부 한 줄로 막으면 검색 성격의 접근도 같이 막힙니다.

목록의 링크가 진짜 링크인지 확인합니다

글 목록 페이지를 엽니다. 글 제목 위에 마우스를 올립니다. 브라우저 창 왼쪽 아래에 주소가 잠깐 뜨는지 봅니다. 뜨면 그 제목은 링크입니다. 아무것도 뜨지 않으면 링크가 아닐 수 있습니다.

세 가지를 더 해 봅니다. 첫째, 제목을 우클릭합니다. 「새 탭에서 열기」가 메뉴에 있으면 링크입니다. 둘째, Ctrl 을 누른 채 클릭합니다. 맥에서는 Cmd 입니다. 새 탭이 열리면 링크입니다. 셋째, 키보드 Tab 키를 눌러 가며 초점이 제목으로 옮겨 가는지 봅니다.

세 가지가 다 안 되면 그 제목은 자바스크립트로 화면을 바꾸는 버튼입니다. 사람은 누를 수 있습니다. 크롤러가 따라갈 주소가 그 자리에 적혀 있지 않습니다. 이럴 때 목록 페이지는 색인되고 개별 글은 색인되지 않는 모습이 나타납니다. 앞에서 세어 본 결과와 맞춰 보십시오.

목록의 아래쪽도 봅니다. 「더 보기」를 눌러야 다음 글이 나오는 구조라면 첫 화면에 없는 글은 목록을 통해서는 길이 없습니다. 페이지 번호를 누를 때 주소창이 바뀌는지 확인하십시오. 뒤에 page 같은 글자가 붙어 주소가 새로 생기면 그 화면에는 길이 있습니다. 주소가 그대로이거나 샵 기호 뒤만 바뀌면 길이 없을 수 있습니다. 스크롤을 내릴 때마다 글이 늘어나는 구조도 같은 성격입니다.

길이 하나뿐일 필요는 없습니다. 목록에서 가는 길이 약해도 사이트맵에 그 주소가 있고 다른 글에서 링크가 걸려 있으면 길이 있는 셈입니다. 그래서 이 항목은 사이트맵 점검과 묶어서 보셔야 합니다. 둘 다 없으면 그 글은 주소를 아는 사람만 찾아오는 글입니다.

같은 글이 여러 주소로 열리는지 확인합니다

글 하나를 고릅니다. 그 주소를 메모장에 붙여 넣고 조금씩 바꿔 가며 주소창에 넣어 봅니다. 모두 같은 글이 열린다면 그 글은 주소를 여러 개 갖고 있는 상태입니다.

바람직한 모습은 하나만 남고 나머지는 대표 주소로 넘어가는 것입니다. 넘어갈 때 주소창의 글자가 바뀌므로 눈으로 확인할 수 있습니다. 서버가 301 응답으로 안내하면 그렇게 됩니다.

주소가 여러 개 남아 있을 때 쓰는 신호가 canonical 입니다. 페이지 소스에 link rel="canonical" 로 시작하는 한 줄이 들어가고, 거기에 대표 주소를 적습니다. 구글 Search Central 은 중복된 주소들 가운데 하나를 대표로 고른다고 설명하고, canonical 을 그 판단에 쓰는 신호 가운데 하나로 안내합니다. 같은 문서는 이것이 지시가 아니라 신호이고 구글이 다른 주소를 고를 수 있다고 적습니다. 그래서 canonical 을 넣었다고 해서 끝난 것은 아닙니다. 주소를 하나로 정리하는 쪽이 먼저입니다.

확인하실 것은 간단합니다. 변형 주소마다 페이지 소스를 열어 canonical 값을 봅니다. 모두 같은 하나를 가리켜야 합니다. 변형 주소가 각자 자기 자신을 가리키고 있으면 대표가 여러 개라는 뜻이 됩니다.

noindex 가 남아 있는지 찾습니다

페이지 소스를 엽니다. 화면 빈 곳을 우클릭하고 「페이지 소스 보기」를 고릅니다. 단축키는 Ctrl+U 이고 맥에서는 Cmd+Option+U 입니다. 글자가 가득한 화면이 나옵니다. 읽지 않아도 됩니다. Ctrl+F 로 noindex 를 찾습니다.

하나도 없으면 그 항목은 넘어갑니다. 있으면 그 줄을 봅니다. meta name="robots" 로 시작하는 줄에 들어 있으면 그 페이지를 색인에서 빼라는 표시입니다. 구글 Search Central 은 이 표시가 페이지의 head 영역에 있을 때 유효하다고 적습니다. none 이라는 값도 같이 찾아보십시오. 같은 문서가 none 은 noindex 와 nofollow 를 함께 쓴 것과 같다고 적습니다.

소스에 안 보이는 경우도 있습니다. 같은 표시를 HTTP 응답 헤더로 보낼 수 있습니다. 확인하려면 브라우저 개발자 도구를 엽니다. F12 를 누르거나 우클릭 후 「검사」를 고릅니다. Network 탭을 열고 페이지를 새로고침합니다. 맨 위의 문서 요청을 클릭하고 Response Headers 를 봅니다. x-robots-tag 라는 항목이 있으면 그 값을 확인합니다. 이 방법 말고는 소스에 안 보이는 noindex 를 찾을 길이 없습니다.

한 가지 더 구분해 두십시오. 「페이지 소스 보기」는 서버가 처음 보낸 글자입니다. 개발자 도구의 Elements 탭은 자바스크립트가 바꾼 뒤의 상태입니다. 둘이 다를 수 있습니다. 소스에는 noindex 가 있는데 화면에서는 지워지는 경우, 또는 그 반대도 생깁니다. 둘 다 보시는 편이 안전합니다.

이 점검은 템플릿별로 하셔야 합니다. 홈, 진료 과목 페이지, 의료진 페이지, 글 목록, 글 상세를 각각 봅니다. 공개 전 설정이 한 템플릿에만 남는 일이 흔합니다. 홈은 검색에 나오는데 글만 한 편도 안 나오는 사이트를 보면 글 상세 템플릿에 이 표시가 남아 있는 경우가 있습니다.

휴대폰으로 열어 봅니다

구글 Search Central 은 색인을 스마트폰 크롤러가 수집한 내용을 기준으로 만든다고 안내합니다. 그래서 휴대폰에서 보이는 모습이 기준에 가깝습니다. PC 에서만 확인하고 끝내면 기준과 다른 것을 보고 있을 수 있습니다.

와이파이를 끄고 이동통신으로 열어 보십시오. 그리고 다음을 봅니다. 첫 화면이 뜨기까지 체감이 어느 정도인가. 좌우로 밀리는 부분이 있는가. 글자를 확대하지 않고 읽히는가. 전화 버튼이나 띠배너가 본문을 가리는가. 팝업이 본문을 덮고 닫기 버튼이 손에 닿는가.

내용도 봅니다. PC 에서 보이던 문단이 휴대폰에서 빠져 있지 않은지 확인합니다. 모바일 화면을 간결하게 만들려고 본문 일부를 숨기는 경우가 있습니다. 색인이 모바일 기준이면 숨긴 부분은 없는 것으로 다뤄질 수 있습니다. 진료 설명이나 리뷰 영역이 그렇게 빠져 있는지 보십시오.

속도의 공개 기준은 web.dev 의 Core Web Vitals 문서에 있습니다. web.dev 의 같은 문서는 가장 큰 콘텐츠가 그려지는 시간인 LCP 는 2.5초 이내, 상호작용 반응인 INP 는 200밀리초 이내, 화면이 흔들리는 정도인 CLS 는 0.1 이내를 「좋음」 구간으로 적습니다. 도구 없이 이 값을 측정할 수는 없습니다. 다만 휴대폰에서 열어 보고 한참 기다리셨다면 그 자리를 적어 두시면 됩니다. 뒤에 Search Console 을 붙이면 같은 지표를 실제 방문자 기준으로 확인하실 수 있습니다.

느린 것과 막힌 것은 다른 문제입니다. 느려도 색인은 됩니다. 그래서 이 항목을 마지막에 두었습니다. 배관이 막혀 있는데 속도를 먼저 손보면 비용은 쓰고 결과는 그대로입니다.

Search Console 이 첫 단추입니다

여기까지는 밖에서 들여다본 것입니다. 구글이 실제로 무엇을 보고 무엇을 뺐는지는 Search Console 에서 알 수 있습니다. 아직 붙이지 않았다면 다른 어떤 작업보다 이것이 먼저입니다. 무료이고 설치할 프로그램이 없습니다.

붙이면 세 가지가 생깁니다. 「페이지」 보고서가 색인된 주소 수와 색인되지 않은 주소를 사유별로 나눠 보여 줍니다. 「URL 검사」 도구가 주소 하나를 넣으면 구글이 그 주소에 대해 아는 것을 보여 줍니다. 「실적」 보고서가 어떤 질문으로 우리 페이지가 노출됐는지 보여 주고, 구글 Search Console 도움말에 따르면 이 데이터는 16개월치를 보관합니다.

등록 절차는 짧습니다. 구글 계정으로 Search Console 에 들어가 속성을 추가합니다. 속성 종류가 두 가지입니다. 도메인 속성은 www 유무와 http, https 를 한 묶음으로 다룹니다. URL 접두어 속성은 적은 주소 모양 그대로만 다룹니다. 앞에서 www 어긋남을 확인하셨다면 도메인 속성이 편합니다.

붙인 뒤 할 일은 두 가지입니다. 사이트맵 주소를 제출합니다. 그리고 제작 업체를 사용자로 추가해 권한을 줍니다. 계정은 반드시 병원 쪽 이름으로 만드십시오. 업체 계정에만 있으면 계약이 끝날 때 데이터도 같이 갑니다. 지난 데이터는 옮길 수 없습니다.

네이버에도 같은 성격의 창구가 따로 있습니다. 네이버 서치어드바이저입니다. 등록과 소유 확인 절차가 비슷하고 사이트맵도 따로 제출합니다. 구글 쪽을 먼저 붙이고 같은 날 이어서 하시면 됩니다.

증상에서 짚어 볼 곳으로

점검을 마치면 메모에 증상이 남습니다. 증상별로 어디를 먼저 보는지 정리했습니다. 원인을 단정하는 표가 아닙니다. 순서를 정하는 표입니다.

이 표로 범위를 좁힌 다음 업체에 물으십시오. 「검색이 안 됩니다」로 보내면 답이 돌아오기까지 몇 번을 더 주고받습니다. 「글 상세 페이지 소스에 noindex 가 있습니다」로 보내면 한 번에 끝납니다.

업체에 그대로 보낼 문장

아래 문장을 그대로 복사해 쓰시면 됩니다. 한 번에 전부 보내지 말고 점검에서 걸린 항목만 고르십시오. 그리고 「고쳐 주세요」보다 「지금 어떻게 되어 있는지 알려 주세요」를 먼저 보내시는 편이 좋습니다. 고치는 비용이 들지 않는 확인 요청은 거절하기 어렵습니다.

고쳤다는 답을 받으면 같은 방법으로 다시 확인하십시오. 작업 전후를 같은 자리에서 보시면 됩니다. 사이트맵은 새로고침하면 바로 바뀝니다. robots.txt 도 그렇습니다. 색인 수는 바로 바뀌지 않습니다. 구글이 다시 읽어 갈 시간이 필요합니다. Search Console 의 URL 검사에서 색인 요청을 넣어 두고 기다리시면 됩니다.

자주 묻는 질문

Q: 글을 더 쓰는 것이 왜 답이 아닌가요

글을 쓰는 일이 틀렸다는 뜻은 아닙니다. 순서의 문제입니다. 글이 검색 엔진에 닿지 않는 상태라면 쓴 글이 쌓이기만 합니다. 배관이 통한 뒤에 쓰면 같은 글이 일을 합니다. 이 글의 점검은 대부분 몇 분이면 끝납니다. 글 한 편 쓰는 시간보다 짧습니다.

Q: site: 결과 수가 만든 페이지 수와 정확히 같아야 하나요

아닙니다. 구글은 색인 상태의 공식 창구로 Search Console 의 「페이지」 보고서를 안내합니다. 검색 화면의 결과 개수는 그 용도로 만든 숫자가 아닙니다. 그래서 자릿수만 보십시오. 만든 페이지가 40개인데 결과가 3건이면 짚어 볼 일이 있습니다. 37건이면 넘어가셔도 됩니다.

Q: robots.txt 에서 AI 크롤러를 막아야 하나요

정해 드릴 일이 아닙니다. 다만 두 가지는 알고 결정하셔야 합니다. 구글 Search Central 의 크롤러 문서는 Google-Extended 를 막는 것이 구글 검색의 색인에 영향을 주지 않는다고 적습니다. 그리고 OpenAI 는 자사 문서에서 크롤러 토큰을 용도별로 나눠 안내합니다. 전부 한 줄로 막으면 검색 성격의 접근도 같이 막힙니다. 지금 파일에 무엇이 적혀 있는지부터 확인하십시오.

Q: 사이트맵을 제출하면 색인이 되나요

보장되지 않습니다. 구글 Search Central 은 사이트맵에 올린 주소가 모두 크롤링되고 색인된다고 보장하지 않는다고 적습니다. 사이트맵은 주소를 알리는 목록입니다. 알려야 찾아올 수 있지만 알렸다고 반드시 저장되는 것은 아닙니다. 그래서 사이트맵과 링크 구조를 같이 보셔야 합니다.

Q: 이 점검을 얼마나 자주 하면 되나요

평소에는 분기에 한 번으로 충분합니다. 그리고 다음 세 가지 일이 있은 다음에는 바로 하십시오. 홈페이지를 새로 만들거나 크게 바꿨을 때, 도메인이나 서버를 옮겼을 때, 제작 업체를 바꿨을 때입니다. 이 세 경우에 설정이 되돌아가는 일이 가장 많습니다. Search Console 을 붙여 두셨으면 색인된 주소 수가 크게 줄었을 때 알림이 오므로 그때 보시면 됩니다.