← 블로그 목록
INSIGHTS2026년 9월 19일1 VIEWS

메타 태그 확인 기준 · 넣은 것과 검색 결과가 다를 때

메타 태그를 규격대로 넣어도 검색 결과에는 다르게 나온다. 자사 블로그에서 제목은 13편 중 10편이 잘렸고 설명은 56편 중 23편이 문장 중간에서 끊겨 있었다. 길이만 검사하면 못 잡는 이유와 무엇을 어떤 순서로 확인해야 하는지 실측으로 적었다.

메타 태그를 넣는 방법은 어디서나 찾을 수 있다. 그런데 넣은 뒤에 검색 결과를 실제로 확인해 보면, 써 놓은 것과 다르게 나오는 경우가 많다.

우리는 자사 블로그를 운영하면서 이걸 두 번 겪었다. 한 번은 제목이 잘렸고, 한 번은 설명이 문장 중간에서 끊겼다. 둘 다 코드는 정상이었고 태그도 규격대로 들어가 있었다. 그래서 몇 달 동안 아무도 몰랐다.

이 글은 메타 태그 목록이 아니라, 넣은 뒤에 무엇이 어긋나는지를 우리 숫자와 함께 적는다. 규격을 지켰는데도 결과가 망가지는 경우가 있고, 그쪽이 훨씬 오래 방치된다.

검색 결과에 나오는 것은 내가 쓴 것과 다를 수 있다

먼저 전제를 하나 바꿔야 한다. 메타 태그는 요청이고, 검색 결과에 실제로 표시되는 것은 검색엔진이 정한다.

우리가 넣는 것검색 결과에 나오는 것
<title>대개 그대로, 다만 길면 잘린다
<meta name="description">그대로일 때도 있고, 본문에서 다른 문장을 뽑아 쓸 때도 있다
<meta property="og:*">검색이 아니라 공유 카드에 쓰인다

이 셋을 섞으면 진단이 안 된다. 공유 카드가 이상한데 검색 설명을 고치거나, 검색 결과 제목이 잘렸는데 og 태그를 손보는 일이 생긴다.

그리고 어느 쪽도 사이트 화면에서는 보이지 않는다. 이게 문제의 절반이다.

글을 쓰고 나면 보통 사이트에서 확인한다. 제목이 잘 나오고 본문이 제대로 보이면 끝난 것으로 여긴다. 그런데 검색 결과에 나가는 문자열은 그 화면에 없다. 사람이 그 글을 처음 만나는 자리가 정작 우리가 안 보는 자리다.

제목이 잘렸다 — 노출 있는 13편 중 10편

우리 글의 제목은 「주제 · 부제」 형태였다. 앞에 핵심, 가운데 구분 기호, 뒤에 보조 설명이다.

검색 결과에서 실제로 어떻게 보이는지 세어 보니 노출이 있던 13편 중 10편이 잘려 있었다. 잘린 자리는 대부분 구분 기호 뒤였다. 즉 앞의 핵심만 남고 뒤의 보조 설명이 사라졌다.

세는 방법은 단순했다. 노출이 있는 글의 주소를 하나씩 site: 검색에 넣고 제목이 로 끝나는지 봤다. 서치콘솔이나 분석 도구에는 이 정보가 없다 — 실제 검색 결과 화면에만 있다. 그래서 대시보드를 아무리 봐도 안 보였던 것이다.

고치기 전고친 뒤
잘리는 글10편1편
손댄 글9편
제목을 통째로 바꾼 글0편

남은 1편은 다른 글과 통합할 대상이라 거기서 같이 처리하기로 두었다. 고칠 수 있는 것을 다 고치고 나면 남는 것은 대개 이런 종류다 — 제목 문제가 아니라 글 자체를 어떻게 할지 정해야 하는 경우.

여기서 배운 것이 두 가지다.

하나, 글자 수 제한은 숫자가 아니라 폭이다. 한글은 글자당 폭이 넓어서, 영문 기준으로 알려진 글자 수를 그대로 적용하면 어긋난다. 같은 글자 수라도 어떤 제목은 살고 어떤 제목은 잘린다.

둘, 뒤쪽은 없어져도 되는 내용만 둔다. 어차피 잘릴 수 있는 자리이므로, 클릭을 결정하는 정보를 뒤에 두면 안 된다. 우리는 제목 9편을 고쳐서 잘리는 글을 10편에서 1편으로 줄였다.

무엇을 고쳤나

접미사를 없앨 수는 없었다. 브랜드 표기 규칙 같은 것은 우리가 정할 수 있는 부분이 아니었다. 그래서 앞쪽을 줄였다.

  • 같은 말을 두 번 하는 부분을 뺐다
  • 부제에서 검색어와 무관한 수식을 덜어냈다
  • 앞에 핵심 키워드가 오도록 순서를 바꿨다
  • 숫자와 연도처럼 폭을 많이 차지하면서 클릭에 기여하지 않는 부분을 정리했다

핵심은 제목 전체를 다시 쓰지 않은 것이다. 순위가 붙어 있는 제목을 통째로 바꾸면 그 순위를 잃을 수 있다. 잘리는 부분만 손대는 편이 안전하다.

설명이 문장 중간에서 끊겼다 — 56편 중 23편

두 번째는 더 나빴다. 메타 설명을 훑다가 56편 중 23편(41%)이 문장 한가운데서 끊기고 로 끝나 있는 것을 발견했다.

전부 같은 패턴이었다. 긴 설명을 쓴 다음 특정 글자 수에서 기계적으로 자른 것이다. 자르는 동작 자체는 정상이었다. 자를 위치를 고르지 않았을 뿐이다.

라이브에서 확인해 보니 그 잘린 문자열이 descriptionog:description 양쪽에 그대로 들어가 있었다. 검색 결과 스니펫과 메신저 공유 카드가 동시에 걸린다. 사람이 그 글을 열어 보기도 전에 만나는 첫 문장이 미완성 문장이었다.

41%가 이 상태로 몇 달을 있었는데 아무도 말하지 않았다. 당연하다. 자기 글의 메타 설명을 검색 결과 형태로 확인하는 사람은 거의 없다.

길이만 검사하면 이걸 못 잡는다

여기서 중요한 교훈이 나온다. 만약 우리에게 "설명은 160자 이하" 같은 검사가 있었다면 23편 전부 통과했을 것이다. 규칙은 만족했고 결과는 망가졌다.

검사해야 하는 것은 몇 자인가가 아니라 문장이 끝났는가다.

검사 항목무엇을 보나
종결 여부마침표나 종결어미로 끝나는가. 나 조사로 끝나면 잘린 것
제목 재진술설명이 제목을 그대로 반복하는가
어투 일치본문과 문체가 같은가
길이마지막에 본다

종결 검사는 도구가 없어도 할 수 있다. 글 목록을 뽑아 설명의 마지막 글자만 모아서 보면 된다. 마침표가 아닌 것이 걸리는 대로 잘린 것이다. 우리는 이 한 번의 확인으로 23편을 찾았다.

어투 일치는 의외로 자주 걸린다. 우리가 23편을 다시 쓸 때 한 건이 이것으로 걸렸다 — 본문은 "습니다"체인데 설명만 "한다"체였다. 사람이 쓴 글에 기계가 요약을 붙인 티가 난다.

제목 재진술도 흔하다. 설명이 제목과 거의 같은 문장이면 검색 결과에서 같은 말을 두 번 보여주는 셈이고, 클릭할 이유를 한 줄 더 주지 못한다. 제목이 "무엇"을 말한다면 설명은 "왜 이 글인지"를 말하는 편이 낫다.

그래서 최소한 무엇을 넣어야 하나

목록을 길게 만들 필요는 없다. 실제로 영향이 있는 것은 몇 개뿐이다.

<title> — 앞쪽에 핵심을, 뒤쪽에 없어져도 되는 것을. 잘린다고 가정하고 쓴다.

<meta name="description"> — 완결된 문장으로. 제목을 되풀이하지 말고, 클릭할 이유를 준다. 검색엔진이 이걸 무시하고 본문에서 뽑아 쓸 수도 있는데, 그건 이 문장이 그 검색어에 안 맞는다는 신호로 읽으면 된다.

<meta property="og:title"> / og:description / og:image — 공유 카드용이다. 설명을 자동으로 채우는 구조라면 description과 함께 망가지므로 둘 다 확인한다. 이미지 쪽이 안 뜨는 경우의 확인 순서는 OG 이미지 설정 기준에 따로 적었다.

<link rel="canonical"> — 같은 내용이 여러 주소로 열릴 때 대표 주소를 정한다. 이게 없으면 검색엔진이 다르게 고를 수 있다.

<meta name="robots"> — 필요할 때만. 사이트를 만들면서 켜 둔 차단 설정을 공개 후 끄지 않은 경우가 흔하다. 이건 실수로 들어가면 손해가 가장 큰 태그이므로, 다른 것보다 먼저 없는지 확인한다.

<link rel="alternate" hreflang> — 언어별 페이지가 실제로 있을 때만. 없는 주소를 가리키면 오히려 문제가 된다.

반대로 keywords는 넣지 않아도 된다. 오래전에 쓰이지 않게 됐고, 넣어도 아무 영향이 없다. 그 자리에 시간을 쓸 여유가 있다면 위의 다섯 개가 실제 값으로 채워져 있는지 확인하는 편이 낫다.

자동으로 채우는 구조라면 특히 두 곳을 본다

메타 값을 사람이 하나하나 쓰는 곳은 많지 않다. 대개 어딘가에서 자동으로 만든다. 우리 23편도 그랬다.

이 구조에서 문제가 생기는 지점은 거의 항상 두 곳이다.

하나, 자르는 지점. 긴 문장을 정해진 길이로 맞추는 부분이다. 여기서 "몇 자에서 자를까"만 정하고 "어디서 자를까"를 정하지 않으면 우리와 같은 결과가 된다. 문장 단위로 자르거나, 자른 뒤 완결되지 않으면 앞 문장까지만 쓰는 방식으로 바꿔야 한다.

둘, 기본값을 채우는 지점. 값이 없을 때 무엇으로 대신할지 정하는 부분이다. 본문 첫 문단을 그대로 가져오는 방식이 흔한데, 첫 문단이 도입부라면 글마다 비슷한 문장이 들어간다. 전 글의 설명이 서로 닮아 있다면 여기를 보면 된다.

자동 생성 구조에서 사람이 어디까지 봐야 하는지는 AI 블로그 자동 포스팅, 어디까지 맡기나에 따로 정리했다. 그리고 이 두 곳의 특징은 한 번 어긋나면 전 글에 퍼진다는 것이다. 사람이 쓰면 한 편만 틀리고 끝나지만, 자동 생성은 같은 규칙으로 계속 만든다. 우리가 23편을 손으로 고치는 동안에도 새 글은 같은 규칙으로 나오고 있었다. 고치는 것과 생기지 않게 하는 것은 다른 일이다.

확인하는 순서

넣고 끝내면 어긋난 것을 못 본다. 우리가 쓰는 순서다.

하나, 실제 HTML에 들어갔는지. 편집기에서 저장한 것과 배포된 문서는 다를 수 있다. 브라우저에서 페이지 소스를 열어 그 태그가 있는지 본다.

둘, 값이 완결됐는지. 위의 종결 검사다. 목록 전체를 한 번 훑는다.

셋, 검색 결과에서 어떻게 보이는지. 검색창에 site: 뒤에 주소를 넣으면 실제 표시 형태가 나온다. 여기서 잘림이 보인다. 제목과 설명 외에 별점이나 목차처럼 추가로 표시되는 것들은 리치 스니펫 표시 기준에서 다뤘다.

넷, 공유 카드는 따로. 메신저나 슬랙에 링크를 한 번 붙여 본다. og 값이 검색과 다르게 망가져 있을 수 있다.

넷 중 셋과 넷을 건너뛰는 경우가 대부분이고, 우리가 놓친 것도 정확히 거기였다.

한 가지 덧붙이면, 셋은 모바일에서도 봐야 한다. 표시되는 폭이 좁아서 잘리는 지점이 다르다. 데스크톱에서 멀쩡한 제목이 모바일에서 잘리는 경우가 우리 쪽에도 있었다.

언제 다시 봐야 하나

한 번 맞춰 두면 끝나는 일이 아니다. 우리 경험으로는 세 시점이다.

제품이나 서비스 내용이 바뀔 때. 설명에 적어 둔 기능이나 범위가 낡는다. 바뀐 것의 이름으로 기존 글을 훑는 일은 십 분이면 끝난다.

제목 규칙을 바꿀 때. 접미사 하나를 붙이거나 떼는 것으로 전체 글의 잘림 여부가 한꺼번에 달라진다.

자동으로 생성하는 구조를 손볼 때. 자르는 로직, 기본값 채우는 로직이 여기 있다. 한 줄이 바뀌면 전 글에 퍼진다.

주기적으로 돌리는 것보다 이 세 시점에 맞춰 돌리는 편이 효율이 좋다. 아무 일도 없었는데 매달 훑는 것은 대개 아무것도 찾지 못하고, 정작 바뀐 직후에는 안 보는 일이 생긴다.

그리고 새 글만 보지 않는다. 23편도 10편도 새 글을 검사해서 찾은 것이 아니라 전체 목록을 한 줄씩 내려보다가 나왔다.

정리하면

메타 태그에서 실제로 시간을 써야 하는 곳은 세 군데다.

넣은 값이 완결됐는지. 길이 검사는 이걸 못 잡는다. 마지막 글자만 봐도 잡히므로 가장 값싼 확인이다.

검색 결과와 공유 카드에서 실제로 어떻게 보이는지. 사이트 화면에는 없는 정보다. site: 검색과 링크 붙여 보기, 둘 다 한 번씩.

자동으로 만드는 구조의 두 지점. 자르는 곳과 기본값 채우는 곳. 한 번 어긋나면 전 글에 퍼지므로 개별 글을 고치는 것보다 여기를 먼저 본다.

나머지 태그 목록은 대부분 한 번 맞춰 두면 손댈 일이 없다. 반복해서 어긋나는 것은 위 세 군데다.

자주 묻는 질문

메타 설명이 순위에 영향을 주나요?

순위 요소로 쓰이지 않는다고 알려져 있다. 다만 검색 결과에서 클릭을 결정하는 문장이므로 노출이 클릭으로 바뀌는 비율에는 영향을 준다. 순위와 클릭은 나눠서 봐야 한다.

제목은 몇 자가 적당한가요?

글자 수보다 표시되는 폭이 기준이라 한글에서는 영문 기준을 그대로 쓸 수 없다. 숫자를 외우는 것보다 검색 결과에서 실제로 잘리는지 확인하는 편이 빠르다. 우리는 그렇게 해서 10편이 잘리고 있다는 것을 알았다.

설명을 비워 두면 어떻게 되나요?

검색엔진이 본문에서 적당한 문장을 뽑아 쓴다. 나쁘지 않은 선택일 때도 있지만 어느 문장이 뽑힐지 정할 수 없다. 잘린 문장을 넣는 것보다는 비워 두는 편이 낫다.

검색 결과 제목이 내가 쓴 것과 다르게 나옵니다

검색엔진이 본문의 큰 제목이나 다른 문구로 바꿔 쓰는 경우가 있다. 대개 <title>이 그 검색어와 잘 맞지 않거나, 지나치게 길거나, 사이트 이름이 반복될 때다. 바꿔 쓰이는 것 자체가 신호다.

og 태그와 메타 설명을 같은 값으로 써도 되나요?

되고, 실제로 많이 그렇게 한다. 다만 그러면 한쪽이 망가질 때 둘 다 망가진다. 우리 23편이 그랬다. 같은 값을 쓸 거라면 검사도 양쪽을 같이 해야 한다.

이미 나간 글의 제목을 고쳐도 되나요?

고쳐도 된다. 다만 순위가 붙어 있는 제목을 통째로 바꾸면 그 순위를 잃을 수 있으므로, 잘리는 부분만 손대는 편이 안전하다. 우리는 9편을 고치면서 제목을 처음부터 다시 쓴 것은 한 편도 없었다.

고친 뒤 검색 결과에 언제 반영되나요?

그 페이지가 다시 읽힌 뒤다. 며칠에서 몇 주까지 걸리고 고르지도 않다. 그래서 고친 직후에 검색 결과를 보고 "안 바뀌었다"고 판단하면 이르다. 바꾼 날짜를 적어 두고 일주일쯤 뒤에 확인하는 편이 낫다.

전부 확인하려면 시간이 얼마나 드나요?

전 글의 제목과 설명만 뽑아 종결 여부를 보는 일은 한 번에 십 분 정도다. 본문을 다시 읽는 것이 아니라 두 필드만 보기 때문이다. 어디를 볼지 정해 두는 것이 확인 시간을 줄이는 유일한 방법이다.

참고 자료

글 쓰는 팀 없이도, 콘텐츠는 계속 쌓여야 합니다

Trina는 검색 데이터로 주제를 고르고, 채널별 말투에 맞춰 글을 다시 쓰고, 발행 후 성과까지 기록합니다.

데모 체험하기