메타데이터를 점검하며 발견한 문제(+제목·설명·대표 주소가 뒤섞인 사이트의 경우)
메타데이터는 웹페이지에 붙는 ‘이름표’입니다.
사람이 페이지를 열어 보기 전, 검색엔진과 AI는 이 이름표를 먼저 읽습니다. 페이지 제목, 짧은 설명, 대표 주소, 사용 언어, 공유할 때 보이는 이미지와 문구가 모두 메타데이터에 포함됩니다.
방문자는 보통 이 정보를 직접 보지 못합니다. 그래서 사이트를 운영하면서도 놓치기 쉽습니다. 하지만 검색 결과에 어떤 제목이 보일지, 어떤 페이지가 검색에 등록될지, 링크를 공유했을 때 어떤 이미지와 설명이 나올지를 결정하는 중요한 정보입니다.
1,200개 페이지를 열어보니
작업은 사이트 안의 모든 페이지에서 메타데이터를 꺼내 표로 정리하는 일부터 시작했습니다.
점검한 페이지는 모두 1,200개였습니다. 정보를 뽑는 데 걸린 시간은 한 시간도 되지 않았습니다. 더 오래 걸린 일은 결과를 읽고, 무엇이 문제인지 구분하는 일이었습니다.
설명문 항목을 같은 내용끼리 정렬했을 때 놀라운 결과가 나왔습니다.
1,200개 페이지의 설명문이 모두 같았습니다.
내용은 회사 소개 문구 두 줄이었습니다. 홈페이지를 처음 만들 때 넣어 둔 문장이었고, 그 뒤 만들어진 모든 페이지에 그대로 복사되어 있었습니다.
제목도 비슷한 상태였습니다. 게시판 글 380개는 모두 같은 제목을 쓰고 있었습니다. 실제 글 제목은 들어가지 않았고, 회사명 뒤에 게시판 이름만 붙어 있었습니다.
예를 들면 이런 식입니다.
실제 글 제목: “2026년 하반기 지원사업 신청 안내”
검색 결과 제목: “OO회사 | 공지사항”
사람이 검색 결과를 보면 이 글이 무엇에 관한 글인지 알기 어렵습니다.
점검 결과를 본 담당자는 한동안 말을 잇지 못했습니다. 그러고는 이렇게 물었습니다.
“이게 다 템플릿 때문에 생긴 문제인가요?”
출처 입력
답은 “그렇다”입니다.
누군가 제목이나 설명문을 잘못 입력한 것이 아니었습니다. 글을 작성하는 화면에 제목과 설명문을 따로 입력할 수 있는 칸 자체가 없었습니다. 입력할 자리가 없으니 모든 값이 처음 설정된 기본값으로 남아 있었던 것입니다.
메타데이터를 꺼내 보는 일 자체는 어렵지 않습니다. 사이트를 돌아다니며 각 페이지의 정보를 표로 정리해 주는 도구는 여러 가지가 있습니다. 중요한 것은 도구가 아니라, 결과를 보고 어떤 문제부터 고칠지 결정하는 일입니다.
메타데이터 문제는 사람이 잘못 입력해서 생기는 경우보다, 템플릿의 기본값이 모든 페이지에 복사되면서 생기는 경우가 많습니다. 입력할 칸이 없으면 값은 계속 기본값으로 남습니다.
출처 입력
왜 모든 페이지가 같아졌을까
원인을 따라가 보니, 많은 사이트에서 볼 수 있는 익숙한 과정이 나왔습니다.
처음 홈페이지를 만들었을 때는 대문 페이지 하나만 있었습니다. 개발자는 페이지의 공통 영역에 회사 소개 문구를 설명문으로 넣었습니다. 대문 페이지 하나만 놓고 보면 자연스러운 설정이었습니다.
문제는 그 뒤였습니다.
사이트에 게시판 기능이 추가되면서, 게시판의 모든 글이 대문 페이지의 설정을 그대로 물려받았습니다. 게시판 글마다 설명문을 따로 입력하는 칸은 없었습니다.
편집자가 글을 올릴 때 볼 수 있는 항목은 보통 아래 정도였습니다.
글 제목
본문
첨부 파일
대표 이미지
페이지 제목, 설명문, 대표 주소 같은 메타데이터는 화면에 보이지 않았습니다. 따라서 편집자는 그것이 존재하는지도, 바꿔야 하는지도 알기 어려웠습니다.
대표 주소는 더 큰 문제였습니다
대표 주소는 같은 내용의 페이지가 여러 개 있을 때 “이 주소가 원본입니다”라고 검색엔진에 알려 주는 정보입니다. 영어로는 canonical URL이라고 합니다.
이 사이트의 게시판에는 목록 정렬과 필터 기능이 있었습니다. 예를 들어 최신순, 인기순, 카테고리별 보기처럼 같은 목록을 여러 주소로 열 수 있는 구조였습니다.
개발자는 이런 중복 주소를 정리하려고 대표 주소를 게시판 첫 페이지로 지정했습니다. 문제는 그 설정이 게시판 목록에만 적용된 것이 아니라, 게시판의 개별 글에도 함께 적용된 점입니다.
그 결과 게시글 900개가 모두 이렇게 말하고 있는 상태가 됐습니다.
“나는 독립된 글이 아닙니다. 게시판 첫 페이지의 복사본입니다.”
출처 입력
검색엔진 입장에서는 900개의 글을 각각 검색에 올릴 이유가 줄어듭니다. 원본이라고 지정된 게시판 첫 페이지 하나만 중요하다고 판단할 수 있기 때문입니다.
언어 설정도 잘못되어 있었습니다. 해외에서 만든 템플릿을 사용하면서 페이지 언어가 영어로 남아 있었습니다. 실제 화면은 한국어였기 때문에 방문자는 전혀 알아차리지 못했습니다.
결국 특정 한 사람의 실수라고 보기 어려웠습니다.
개발자는 당시 필요한 기능을 만들었습니다.
편집자는 입력할 수 있는 내용을 작성했습니다.
디자이너는 화면을 관리했습니다.
하지만 화면 뒤에서 작동하는 메타데이터를 책임질 사람은 정해져 있지 않았습니다. 이것이 가장 근본적인 문제였습니다.
대문 페이지 하나에는 맞았던 기본값이 게시판과 새 기능을 거치며 모든 페이지에 퍼졌습니다. 문제는 개인의 실수보다, 화면 뒤의 정보를 관리할 담당자가 없었던 구조에 있었습니다.
출처 입력
무엇이 가장 큰 문제였나
점검 결과, 문제가 된 항목은 여러 개였습니다. 하지만 모든 문제가 같은 정도로 심각한 것은 아니었습니다.
무엇부터 고칠지 정하려면 “보기 싫은 문제”와 “검색에 실제 피해를 주는 문제”를 구분해야 합니다.
항목 | 발견한 문제 | 영향도 | 먼저 해야 할 일 |
대표 주소 | 900개 글이 게시판 첫 페이지를 원본으로 지정 | 매우 높음 | 각 글이 자기 주소를 대표 주소로 갖도록 수정 |
페이지 제목 | 380개 글이 같은 제목 사용 | 높음 | 글 제목이 제목 태그에 자동으로 들어가게 수정 |
설명문 | 1,200개 페이지가 같은 회사 소개 문구 사용 | 중간 | 페이지별 설명문 또는 자동 생성 규칙 마련 |
언어 선언 | 한국어 페이지가 영어로 설정됨 | 중간 | 페이지 언어를 한국어로 수정 |
공유 미리보기 | 모든 글이 같은 이미지와 문구 사용 | 중간 | 글별 대표 이미지·설명 설정 기능 추가 |
가장 큰 문제는 대표 주소였습니다
대표 주소 오류가 가장 심각했습니다.
900개 글이 각자 자기 주소를 원본으로 말하지 않고, 모두 게시판 첫 페이지를 원본이라고 말하고 있었습니다. 좋은 글이 수백 편 있어도 검색엔진에는 게시판 첫 페이지 하나만 중요한 문서처럼 보일 수 있는 상태였습니다.
이 문제는 방문자가 알아차리기 어렵습니다.
사이트 안에서 글을 클릭하면 정상적으로 열립니다. 화면도 깨지지 않습니다. 게시물도 잘 보입니다. 하지만 검색엔진이 보는 정보는 화면 뒤에 숨어 있기 때문에, 검색 도구의 색인 보고서를 확인하지 않으면 문제를 발견하기 어렵습니다.
실제 점검 과정에서 담당자는 검색 관리 도구 계정이 있다는 사실도 이번에 처음 확인했습니다. 사이트는 오래전부터 운영되고 있었지만, 색인 상태를 정기적으로 보는 업무는 없었던 것입니다.
설명문은 중요하지만, 가장 급한 문제는 아니었습니다
모든 설명문이 같은 것도 분명 문제입니다. 하지만 대표 주소 오류만큼 치명적이지는 않았습니다.
검색엔진은 설명문이 부족하거나 부적절하면, 본문에서 적절한 문장을 골라 검색 결과에 보여 주기도 합니다. AI도 보통 설명문만 읽는 것이 아니라 본문 내용을 함께 참고합니다.
그렇다고 설명문을 무시해도 된다는 뜻은 아닙니다.
1,200개 페이지가 같은 설명문을 쓰면 페이지끼리 구별이 잘되지 않습니다. 검색 결과에서 어떤 글을 눌러야 할지 알기 어렵고, 링크를 공유했을 때도 모든 글이 비슷하게 보입니다.
제목은 사람이 클릭할 이유를 만드는 정보입니다
페이지 제목은 검색 결과에서 가장 눈에 잘 띄는 문장입니다.
게시판 이름만 보이고 글 제목이 보이지 않으면, 이용자는 그 글이 자신이 찾는 내용인지 알기 어렵습니다. 검색엔진과 AI도 이 페이지가 무엇에 관한 문서인지 판단하는 데 필요한 중요한 단서를 놓치게 됩니다.
페이지 제목은 책 표지의 제목과 비슷합니다. 책 제목이 모두 “공지사항”이라면 어떤 책을 읽어야 할지 알 수 없는 것과 같습니다.
대표 주소 오류는 글 자체가 검색에 등록되지 못하게 만들 수 있습니다.
설명문 중복도 고쳐야 하지만, 먼저 막힌 길부터 뚫는 것이 맞습니다.
어떤 순서로 고쳤을까
정비는 영향이 큰 문제부터 진행했습니다. 전체 작업에는 약 6주가 걸렸고, 그중 절반 정도는 게시판 기능과 템플릿을 수정하는 개발 작업이었습니다.
1. 대표 주소부터 바로잡았습니다
모든 게시글이 자기 자신의 주소를 대표 주소로 갖도록 바꿨습니다.
목록 페이지에서 중복 주소를 막는 기능은 유지했습니다. 다만 그 기능이 목록에만 적용되고, 개별 글에는 영향을 주지 않도록 범위를 분리했습니다.
2. 페이지 언어를 한국어로 바꿨습니다
언어 선언은 공통 영역 한 곳만 고치면 됐습니다. 작업 자체는 반나절도 걸리지 않았습니다.
작은 수정이지만, 검색엔진과 브라우저, 번역 도구, 보조기기 등이 페이지 언어를 이해하는 데 도움이 됩니다.
3. 제목 생성 규칙을 바꿨습니다
제목은 아래 방식으로 자동 생성되도록 수정했습니다.
글 제목 | 회사명
예를 들어 “2026년 하반기 지원사업 신청 안내 | OO회사”처럼 표시되도록 바꿨습니다.
이제 게시글마다 고유한 제목을 갖게 됐고, 검색 결과에서 무엇에 관한 글인지 더 쉽게 알 수 있게 됐습니다.
4. 설명문을 입력할 수 있는 칸을 만들었습니다
게시판 글을 작성할 때 설명문을 따로 입력할 수 있도록 칸을 추가했습니다.
다만 설명문을 꼭 입력해야 하는 필수 항목으로 만들지는 않았습니다. 필수로 만들면 편집자가 의미 없는 문장을 억지로 넣을 수 있기 때문입니다.
대신 설명문을 비워 두면 본문의 첫 문단에서 내용을 가져와 자동으로 만들도록 했습니다.
즉, 편집자는 중요한 글에만 직접 설명문을 작성하고, 나머지 글은 자동 생성 문구를 사용할 수 있게 했습니다.
5. 공유 미리보기 이미지를 글마다 정할 수 있게 했습니다
링크를 카카오톡, 페이스북, 링크드인 같은 서비스에 공유하면 제목·설명·이미지가 함께 표시됩니다. 이를 공유 미리보기라고 합니다.
이전에는 모든 글이 같은 회사 이미지와 문구를 사용했습니다. 정비 후에는 글마다 대표 이미지를 지정할 수 있게 했고, 이미지를 지정하지 않았을 때는 본문 첫 이미지를 자동으로 사용하도록 했습니다.
6. 모든 글을 손으로 고치지는 않았습니다
기존 글 1,200개를 모두 사람이 직접 수정하면 시간과 비용이 많이 듭니다. 그래서 검색 유입이 이미 있는 상위 150개 글부터 사람이 직접 설명문을 작성했습니다.
나머지 글은 자동 생성 설명문을 적용했습니다.
이 방식은 중요한 글에 시간을 먼저 쓰고, 전체 사이트의 기본 품질도 함께 올릴 수 있다는 장점이 있습니다.
설명문을 작성할 때는 간단한 규칙도 만들었습니다.
글의 가장 중요한 결론을 한 문장으로 씁니다.
이 글에서만 얻을 수 있는 구체적인 정보 하나를 덧붙입니다.
회사 소개나 광고 문구는 넣지 않습니다.
읽는 사람이 “왜 이 글을 열어야 하는지” 알 수 있게 씁니다.
예를 들어 아래처럼 쓸 수 있습니다.
나쁜 예: “OO회사는 고객 만족을 위해 최선을 다합니다.”
좋은 예: “2026년 하반기 지원사업의 신청 기간, 대상, 제출 서류를 한눈에 정리했습니다.”
대표 주소, 언어, 제목 규칙처럼 구조 문제부터 고쳤습니다. 설명문은 모든 글에 억지로 입력하게 하기보다, 자동 생성 규칙을 만들고 중요한 글부터 사람이 직접 다듬었습니다.
석 달 뒤에 달라진 점
가장 먼저 달라진 것은 검색엔진에 등록된 페이지 수였습니다.
대표 주소를 고친 뒤 약 3주가 지나자, 검색 관리 도구에서 등록된 페이지 수가 늘기 시작했습니다. 약 두 달 뒤에는 기존에 문제가 있던 900개 글 대부분이 각각 독립된 페이지로 검색에 등록됐습니다.
새 글을 하나도 추가하지 않았는데도 검색에 존재하는 문서 수가 약 8배 가까이 늘어난 셈입니다.
그다음에는 검색 결과의 클릭률이 달라졌습니다. 제목에 실제 글 제목이 표시되고, 설명문도 글마다 달라지면서 이용자가 내용을 더 쉽게 판단할 수 있게 됐습니다.
특히 사람이 직접 설명문을 작성한 상위 150개 글에서 변화가 더 뚜렷하게 나타났습니다.
AI 답변이나 검색 결과에 언급되는 글도 조금씩 늘었습니다. 하지만 정확히 말하면, 메타데이터를 고쳐서 갑자기 글이 좋아진 것은 아니었습니다.
원래 좋은 글이었지만 검색엔진에 제대로 등록되지 못했던 글이 다시 발견된 것입니다.
메타데이터 정비는 무언가 새로운 내용을 더하는 작업이라기보다, 좋은 콘텐츠가 검색과 AI에 전달되는 길을 막고 있던 장애물을 치우는 작업에 가깝습니다.
마지막으로 남은 일, 담당자를 정하는 것
구조를 고쳤다고 해서 문제가 영원히 사라지는 것은 아닙니다.
새 게시판 기능이 추가되거나, 홈페이지 디자인이 바뀌거나, 다른 업체가 사이트를 개편하면 같은 문제가 다시 생길 수 있습니다. 그래서 이 사이트는 메타데이터 점검을 분기마다 한 번 하는 정기 업무로 정했습니다.
전체 페이지의 메타데이터를 추출하는 데는 약 한 시간 정도면 충분합니다. 분기마다 제목 중복, 설명문 누락, 대표 주소 오류, 언어 선언, 공유 미리보기 상태를 확인하면 큰 문제로 번지기 전에 발견할 수 있습니다.
점검을 마친 뒤 담당자가 한 말이 기억에 남습니다.
“우리는 글을 잘 쓰는 데만 신경 썼는데, 그 글에 이름표를 붙이는 일은 모르고 있었네요.”
메타데이터를 가장 쉽게 설명하면 바로 이것입니다. 메타데이터는 웹 문서에 붙는 이름표이자, 검색엔진과 AI에게 이 페이지가 무엇인지 알려 주는 안내문입니다.
새 글을 쓰지 않아도 검색에 등록되는 문서 수가 크게 늘 수 있습니다. 좋은 글이 검색에 발견되지 못하게 막고 있던 설정을 고쳤기 때문입니다.
메타데이터 전수 점검과 정비 문의
지오세오 geoseonow.net은 사이트 전체 페이지의 메타데이터를 확인해 중복, 누락, 잘못된 대표 주소 지정을 찾아냅니다.
단순히 문제 목록만 제공하지 않습니다. 템플릿과 게시판 기능이 어떤 방식으로 제목, 설명문, 대표 주소를 만들고 있는지 확인해 근본 원인을 찾습니다. 정비 후에는 같은 문제가 다시 생기지 않도록 분기 점검 절차까지 운영 업무에 포함할 수 있도록 지원합니다.
지오세오는 서울 종로구 새문안로에 있습니다. 출판 편집에서 문서마다 제목, 저자, 발행 정보 같은 서지 정보를 정확히 붙이는 원칙을 웹 문서에도 적용합니다.
메타데이터는 웹페이지의 서지 정보입니다. GEO와 SEO 콘텐츠 전략 설계부터 실행까지 함께 진행합니다.
출처 및 참고 자료
Google Search Central, 검색 결과의 제목 링크 관리
Google Search Central, 검색 결과 스니펫 관리
Google Search Central, 중복 URL 통합 및 표준 URL 지정
Google Search Central, 페이지 색인 생성 보고서 안내
The Open Graph Protocol 명세
댓글