Bing이 "설명이 너무 짧다"고 해서 고쳤더니, 본문 오류가 줄줄이 나왔습니다

안녕하세요. Jay입니다!

검색 최적화라고 하면 대부분 구글부터 떠올리실 겁니다. 저도 그랬습니다. 그런데 직접 운영하는 도구 사이트의 Bing 웹마스터 도구 데이터를 1년 치 내려받아 보니, 지난 12개월 검색 클릭 약 1만 1천 회가 거의 전부 Bing에서 왔더군요. 같은 기간 구글에서 온 클릭은 손에 꼽을 정도였습니다.

그래서 Bing이 보내는 경고를 처음으로 진지하게 읽었습니다. 가장 많이 걸린 항목이 「meta description이 너무 짧음」 50건이었고, 오늘은 그걸 고치다 생긴 일을 정리해 보겠습니다. 결론부터 말하면, 설명문을 고치다가 본문의 사실 오류를 열 건 넘게 찾았습니다.

📏 먼저 잰다 — 몇 자가 "짧은" 걸까

경고를 받으면 일단 "길게 늘리자"로 가기 쉽습니다. 그 전에 Bing이 짚은 50개 페이지의 description 길이를 전부 재 봤습니다.

• 50개 전부 100자 이하였습니다
• 101자 이상인데 걸린 페이지는 0개

흔히 말하는 권장 길이 150160자는 영문 기준입니다. 한글은 한 글자가 더 넓게 렌더링돼서, 검색 결과에서 대략 8090자 근처에서 잘립니다. 그래서 저는 기준을 이렇게 잡았습니다.

항목	기준
한글 description	130~170자
핵심 문장 위치	앞 80자 안에 (잘려도 의미가 남게)
영문 description	150~160자

🔭 경고 목록만 고치면 안 되는 이유

Bing 목록은 크롤러가 그때까지 본 일부입니다. 목록에 있는 50개만 고치면 다음 보고서에 나머지가 또 올라옵니다.

그래서 사이트 전체를 직접 쟀습니다. 사이트맵의 URL을 전부 받아서 description 길이를 세는 짧은 스크립트면 충분합니다.

import re, requests

sitemap = requests.get("https://example.com/sitemap.xml").text
urls = re.findall(r"<loc>(.*?)</loc>", sitemap)

for url in urls:
    html = requests.get(url).text
    m = re.search(r'<meta name="description" content="([^"]*)"', html)
    desc = m.group(1) if m else ""
    if len(desc) <= 100:
        print(len(desc), url)

이렇게 돌려 보니 Bing 목록 밖에서 35개가 더 나왔습니다. 그중 8개는 짧은 게 아니라 description 자체가 없었습니다. 초창기에 쓴 블로그 글들이었죠. 같은 파일의 짧은 영문판도 20개 정도 함께 고쳤습니다.

🔴 진짜 수확 — 본문을 읽고 쓰니 오류가 보였다

description을 130자로 늘리려면 그 페이지가 무슨 말을 하는지 알아야 합니다. 그래서 페이지마다 본문을 다시 읽고 요약했는데, 여기서 문제가 쏟아졌습니다.

① 확률 계산이 틀린 글이 4편

글	적혀 있던 값	다시 계산한 값
이월수가 나올 확률	66%	약 60%
연속 번호가 나올 확률	49.5%	약 52.9%
로또 5등 확률	22분의 1	45분의 1
해외 복권 확률	퍼센트 전부	전 등수 오류

② 법이 바뀌었는데 글은 그대로

연말정산 글이 옛 세액공제 한도를 쓰고 있었습니다. 연금저축·IRP 한도가 이미 늘어난 뒤였죠. 게다가 성격이 다른 소득공제와 세액공제를 한 표에서 더하고 있었습니다.

③ 없는 기능을 광고하는 설명

이게 제일 뜨끔했습니다.

• 칼로리 계산기 설명: "수백 가지 음식, 자동 저장" → 실제로는 26개, 저장 기능 없음
• 꿈해몽 도구 설명: "AI 꿈해몽" → 외부 AI를 쓰지 않음
• 별자리 궁합 페이지: 설명 전체가 띠 궁합 이야기 → 도구는 서양 별자리
• 메트로놈 설명: "30 BPM부터" → 실제 최저 40 BPM

처음부터 거짓말을 쓴 건 아닙니다. 기능을 바꾸거나, 초안을 쓸 때 계획만 보고 적었거나, 다른 페이지를 복사해 왔거나 — 이유는 제각각이었지만 결과는 같았습니다. 페이지 문구가 실제 기능에서 조금씩 멀어져 있었던 겁니다.

🧰 덤으로 고친 것들

전체를 훑다 보니 description 말고도 걸리는 게 있었습니다.

• 소개·카탈로그·카테고리 페이지 등 12곳의 공유 이미지(og:image)가 실제로는 404 — 이미지 생성 대상 목록에서 빠져 있었습니다
• 목록 페이지 제목에 브랜드명이 두 번 들어가 있었습니다 (| Jay-Project | JAY Project)
• 소개 페이지의 앱 개수가 몇 달 전 숫자 그대로였습니다

모두 고친 뒤 다시 쟀더니 ko/en 326페이지에서 100자 이하 0, 누락 0, 중복 0, Bing이 짚었던 페이지들은 132~168자가 됐습니다.

💡 Jay의 정리 — 설명문은 사실 확인 장치였다

이번 작업에서 가장 크게 배운 건 이겁니다. description을 "짧은 문구 늘리기"로 하면 그냥 SEO 작업이지만, "본문을 읽고 요약하기"로 하면 사실 확인 작업이 됩니다.

특히 도구 사이트라면 코드를 정답으로 두는 게 효과적이었습니다. 설명문에 "자동 저장"이라고 쓰기 전에 그 컴포넌트에 저장 코드가 있는지 한 번 열어 보는 겁니다. 그 한 번이 위의 "없는 기능" 네 건을 전부 잡아냈습니다.

그리고 확률·세금처럼 숫자가 들어간 글은 다시 계산하거나 1차 출처와 대조해야 합니다. 원래 글을 믿고 요약만 하면 틀린 숫자가 description에까지 복사돼, 검색 결과에서 가장 잘 보이는 자리에 오류를 올려놓게 됩니다.

결론

검색엔진 경고는 귀찮은 숙제처럼 보이지만, 이번엔 사이트 전체를 다시 읽을 계기가 됐습니다. 경고 목록만 고치지 말고 전체를 재 보고, 설명문을 쓸 때는 본문을 다시 읽어 보세요. 생각보다 많은 것이 그사이에 낡아 있을 겁니다.

혹시 사이트를 고쳤는데 검색 결과나 화면에 옛 내용이 계속 보인다면, 예전에 정리한 Cloudflare 캐시의 함정 글도 함께 참고해 보세요.

다음에도 유익한 포스팅으로 찾아오겠습니다. 감사합니다!