워드프레스 구독형 플랜으로 만든 사이트에서 카카오톡에 링크를 붙였는데, 제목도 이미지도 없이 주소만 덩그러니 남고 미리보기가 비어 나왔습니다.
OG 태그는 정상이었습니다. og:title, og:description, og:image가 전부 들어 있었고 이미지도 1200×630으로 맞춰 둔 상태였으며, 카카오 캐시 초기화까지 돌려 본 뒤였기 때문에 검색하면 나오는 방법은 거의 다 해 본 셈이었습니다.
그런데도 안 됐습니다.
원인은 제가 건드릴 수 있는 자리에 있지 않았습니다. 호스팅 엣지 단의 보안 정책이었고, 이건 호스팅사 고객지원에 문의해서 받은 답변이며 지금도 고쳐지지 않은 상태입니다.
이 글은 그 과정에서 확인한 것과, 홈페이지를 만들 때 이런 것을 왜 미리 봐야 하는지에 대한 이야기입니다.
검색 결과 상위에 있는 글들은 대체로 세 가지를 답으로 내놓습니다.
og:image 규격이 안 맞는다 (1200×630, 용량 제한)세 가지 다 실제로 흔한 원인이라 먼저 확인하는 것이 맞고, 카카오 디벨로퍼스의 캐시 초기화 도구를 쓰면 몇 분이면 끝나기 때문에 굳이 건너뛸 이유도 없습니다.
다만 셋을 다 통과했는데도 비어 나온다면, 그때부터는 원인이 다른 층에 있습니다.
판별하는 방법은 어렵지 않은데, 브라우저에서 페이지 소스를 열었을 때 OG 태그가 멀쩡히 보이는데도 미리보기만 안 뜬다면 태그를 빠뜨린 쪽이 아니라 크롤러가 그 태그까지 도달하지 못하고 있는 쪽으로 봐야 합니다.
사람이 보는 화면과 크롤러가 받는 응답은 얼마든지 다를 수 있는데, 이 둘을 같은 것으로 놓고 보면 원인을 영영 못 찾습니다. 그럼 크롤러는 어디에서 막히고 있을까요?
호스팅사 고객지원에서 받은 답변이고, 원문은 영문이라 옮기면 이렇습니다.
“이건 저희 쪽 문제이지 고객님 쪽 문제가 아닙니다. 이미 알려진 이슈이고 저희 팀이 작업 중입니다. 저희 플랫폼의 엣지 보안이 현재 일부 링크 미리보기 크롤러에게 자바스크립트 챌린지를 띄우는데, 그 크롤러들은 자바스크립트를 실행하지 못합니다. 그러면 크롤러는 Open Graph 태그를 아예 읽지 못하고, 미리보기가 비어 나오거나 403 오류가 납니다.”
정리하면 순서가 이렇습니다.
증상은 똑같이 “미리보기가 안 뜬다”로 보이지만 원인이 앉아 있는 층이 다른데, 태그를 안 써서 못 읽는 상황과 태그가 멀쩡히 있는데 그 문서까지 못 가는 상황은 손댈 곳이 완전히 다르기 때문에 같은 증상으로 묶어 두면 계속 헛돌게 됩니다.
그리고 답변에서 눈여겨볼 표현이 하나 있습니다. “일부 링크 미리보기 크롤러”라고 했는데, 카카오톡 하나만 걸린 문제가 아니라는 뜻으로 읽힙니다.
여기서부터는 제가 답변을 보고 해석한 부분입니다.
링크 미리보기 크롤러는 검색엔진 크롤러와 목적이 다릅니다. 검색엔진은 문서를 색인해야 하니 자바스크립트를 실행해서라도 최종 화면을 확인하지만, 미리보기 크롤러는 메시지 창에 카드 하나 그리려고 페이지를 한 번 긁고 끝냅니다.
그 한 번을 위해 브라우저 엔진을 띄우는 비용을 쓰지 않는 쪽이 자연스럽고, HTML을 받아서 <head> 안의 메타 태그만 읽는 구조라면 자바스크립트 챌린지 앞에서 할 수 있는 일이 없습니다. 그래서 같은 사이트인데도 결과가 갈리고, 구글 검색에는 멀쩡히 잡히는데 카카오톡 미리보기만 비어 나오는 상황이 여기서 나옵니다.
우리 사이트가 검색에 잘 잡힌다는 사실이 모든 크롤러에게 잘 열려 있다는 뜻은 아닙니다.
(어떤 크롤러가 자바스크립트를 실행하고 어떤 크롤러가 못 하는지는 각 서비스가 공식적으로 다 밝히지는 않아서, 이 문단은 단정이 아니라 추정으로 두겠습니다. 다만 고객지원 답변의 “자바스크립트를 실행하지 못하는 크롤러”라는 표현과는 맞아떨어지죠.)
지금 고칠 수 있느냐고 물었고, 받은 답변은 이렇습니다.
“고객님의 리포트를 저희 팀이 이미 트래킹하고 있는 이슈에 연결했습니다. 영향을 받는 다른 사이트들도 함께 있습니다. 이 이슈가 열려 있는 동안에는 개별 도메인 예외를 적용할 수 없습니다. 영향받는 크롤러 전체를 한 번에 처리하려면 플랫폼 단위로 수정해야 하고, 공유드릴 일정은 아직 없습니다.”
세 가지를 확인할 수 있는 답변입니다.
솔직하게 적자면, 지금 단계에서 이용자가 할 수 있는 최선은 리포트를 남기고 개선을 기다리는 것입니다. 다만 같은 증상을 겪고 있다면 고객지원에 문의해 같은 이슈로 묶어 달라고 요청해두는 편이 낫습니다. 당장 고쳐지지는 않아도 영향받는 사이트 수는 플랫폼이 우선순위를 정할 때 실제로 보는 숫자이기 때문입니다. (이런 답을 받으면 답답하지만, 원인을 모르는 상태보다는 낫습니다.)
오히려 여기서 더 중요한 질문은 따로 있다고 봅니다. 이런 이슈를 홈페이지를 만들기 전에 알 수 있었는가입니다.
SEO를 위해 홈페이지를 만들 때 챙기는 목록은 대체로 비슷합니다. robots.txt, 사이트맵, 메타 태그, 구조화 데이터, 내부링크, 페이지 속도 정도가 들어갑니다.
전부 필요한 항목인데, 이 목록에는 공통점이 하나 있습니다. 전부 “사이트 안”의 이야기라는 점입니다.
robots.txt는 크롤러에게 “여기는 긁어도 된다”고 알려 주는 파일인데, 크롤러가 그 파일까지 오지도 못하면 어떻게 될까요? 읽으려면 일단 서버까지 도달해야 하고, 엣지에서 막히면 robots.txt에 뭐라고 썼는지는 아무 의미가 없습니다.
사이트맵도 마찬가지라서, 주소 목록을 아무리 정확하게 만들어도 그 주소로 들어온 요청이 챌린지 페이지를 받으면 거기서 끝납니다.
| 다루는 층 | 막히면 | |
|---|---|---|
| robots.txt · 사이트맵 · 메타 태그 | 사이트 안 | 앞단을 통과한 뒤에야 작동 |
| WAF · 봇 차단 · 엣지 보안 | 사이트 앞 | 여기서 막히면 뒤는 열어 볼 수도 없음 |
순서로 보면 앞단이 먼저인데, 점검 목록에서는 대체로 빠져 있거나 아예 다른 사람 담당으로 넘어가 있는 경우가 많습니다.
AI 검색까지 생각하면 이 자리는 더 중요해집니다. AI 크롤러도 결국 서버에 요청을 보내는 쪽이고 봇 차단 정책이 어디까지 걸려 있는지에 따라 읽히는 범위가 달라지는데, 콘텐츠를 아무리 잘 써도 앞단에서 끊기면 인용될 재료가 되지 못합니다.
이 글을 쓰면서 구글에서 카카오톡 미리보기 og태그, 카카오톡 링크 미리보기 안됨, og태그 적용 안됨, 워드프레스 카카오톡 미리보기 네 가지를 직접 검색해 봤는데 네 개 전부 AI 개요가 떴습니다.
이런 질문은 이미 AI가 요약해서 답하는 영역이라는 뜻인데, 그 요약에 우리 문서가 들어가려면 크롤러가 먼저 문서를 읽을 수 있어야 하고, 앞단에서 막히는 사이트는 그 자리에 아예 후보로도 오르지 못합니다.
구독형 호스팅과 구축형 중에 어느 쪽이 우리 사업 또는 산업군과 맞을까요?
차이가 아래 4가지에서 나뉘게 되는데, 생각보다 이 중요한 요소가 기능 비교표에는 잘 안 나오는 항목입니다.
(가격과 기능만 나란히 놓고 비교하면 이 줄은 아예 보이지 않죠.)
구독형은 보안과 속도, 백업을 플랫폼이 알아서 처리해 주기 때문에 운영하는 입장에서는 확실히 편합니다.
대신 그 설정을 사이트 쪽에서 직접 건드릴 수 없습니다. 이번 사례가 정확히 그 경우라, 개별 도메인 예외를 요청할 수도 없고 직접 규칙을 풀 수도 없었습니다.
구축형은 반대로 손이 더 가는 대신 앞단 정책을 직접 조정할 수 있는데, 어느 쪽이 낫다기보다 어느 쪽이 우리 사업에 맞는지의 문제이고 그 판단을 하려면 애초에 이런 항목이 비교표에 올라와 있어야 합니다.
구독형에서 문제가 생기면 고치는 주체도 일정도 플랫폼이 정합니다. 이번처럼 “일정은 아직 없습니다”라는 답을 받으면 기다리는 것 말고 할 수 있는 일이 많지 않습니다.
그래서 계약 전에 물어볼 만한 질문이 생깁니다. 봇 차단 정책을 도메인 단위로 조정할 수 있는지, 이슈가 생겼을 때 예외 처리가 가능한지 두 가지인데, 기능 목록에는 안 나와도 물어보면 답은 대체로 있습니다.
검색엔진 크롤러는 통과시키면서 미리보기 크롤러만 막는 상황이 실제로 생기는데, 이번 사례가 바로 그렇게 갈린 경우입니다.
허용 목록을 크롤러 단위로 관리할 수 있는 구조인지 미리 보면, 나중에 AI 크롤러를 어디까지 열지 정할 때도 같은 자리에서 판단할 수 있습니다.
로그를 볼 수 있는지가 큰데, 어떤 요청이 몇 번 막혔는지 보이지 않으면 “미리보기가 안 뜬다”에서 “엣지에서 막히고 있다”까지 가는 데 시간이 한참 걸리기 때문입니다.
이번과 마찬가지로 고객지원 답변을 받기 전까지는 원인은 알았으나 해결하긴 어렵죠.
이번 건에서 다시 확인한 것은, 콘텐츠와 전략이 아무리 잘 짜여 있어도 서버 앞단에서 끊기면 거기서 끝난다는 점입니다. 글을 잘 쓰는 일과 그 글이 읽히는 경로를 확보하는 일은 서로 다른 작업이고, 뒤쪽은 대체로 기획 단계에서 정해집니다.
서치나인은 홈페이지 기획을 콘텐츠부터 시작하지 않습니다. 크롤링과 색인이 되는 구조인지, 앞단 정책이 무엇을 막고 있는지, 그 사이트가 속한 업종에서 어떤 경로로 고객이 들어오는지를 먼저 보고 그다음에 콘텐츠와 페이지 역할을 설계합니다.
업종마다 기획을 다르게 잡는 것도 같은 이유입니다. 병의원과 이커머스와 B2B SaaS는 고객이 묻는 질문도 급한 항목의 순서도 달라서, 같은 점검표를 돌리면 어느 한쪽은 반드시 헛돕니다.
지금 쓰고 있는 홈페이지가 어느 쪽인지, 앞단에서 막히는 것이 있는지 확인이 필요하다면 서치나인 상담에서 사이트 진단부터 같이 볼 수 있습니다. 진단 결과를 보고 무엇부터 손댈지 순서를 정하는 것까지가 시작점입니다.
