엔티티 명확성: 출처를 식별하는 표기의 기준

엔티티 명확성은 이 문서를 누가 발행했고, 누가 작성했으며, 어느 시점의 정보인지 기계가 식별할 단서가 있는가를 확인하는 카테고리입니다. GEO 100점 중 15점을 차지하며, 발행 주체와 작성자, 날짜, 조직명 표기, 책임 주체로 이어지는 경로, 페이지 유형을 나타내는 JSON-LD를 차례로 봅니다.

여기서 “명확하다”는 말은 “믿을 만하다”와 같지 않습니다. 이름이 적혀 있다는 사실과 그 이름이 실제 조직이나 사람을 가리킨다는 사실은 별개의 문제입니다. 날짜가 있다고 해서 내용이 최신이라는 뜻도 아니고, Organization이나 Person 구조화 데이터가 있다고 해서 그 조직이나 사람의 전문성, 권위, 자격이 생기는 것도 아닙니다. 검사기가 관찰하는 것은 공개 HTML에 드러난 표기의 존재, 형식, 문자열 수준의 일관성입니다.

이 구분은 실무에서 중요합니다. 빈 작성자 칸을 채우려고 존재하지 않는 전문가 이름을 만들거나, 검토하지 않은 사람을 검토자로 표시하거나, 보유하지 않은 자격을 프로필에 추가하면 안 됩니다. 그런 표기는 이 검사기의 일부 항목을 통과시킬 수는 있어도 문서의 신뢰성을 높이지 않으며, 오히려 독자가 확인했을 때 더 큰 문제를 만듭니다. 확인 가능한 사실만 적고, 공개할 수 없는 정보는 억지로 꾸미지 않는 것이 이 카테고리를 해석하는 전제입니다.

왜 15점이며 왜 이 순서로 보는가

8개 규칙은 식별의 흐름을 따릅니다. 발행 주체와 작성자는 각각 3점, 날짜 표기는 2점으로 봅니다. 조직명 일관성, 책임 주체 경로, JSON-LD 유형은 각각 2점입니다. 날짜 표기의 기존 3점 중 1점을 게시·수정 날짜 정합성으로 옮겼고, 외부 프로필 연결은 0점 진단으로 추가했습니다. 합계는 15점 그대로입니다.

기본 귀속 정보는 출처 확인의 출발점입니다. 누가 발행했는지, 누가 썼는지, 언제 공개되거나 고쳐졌는지 모르면 추가 확인을 시작하기 어렵습니다. 명칭 일관성과 소개 링크, JSON-LD는 이 정보를 보강하지만 실제 주체나 내용의 진실성을 증명하지는 않습니다.

모든 경고가 0점이 되는 것은 아닙니다. GEO 공용 채점 규약에서 warning은 해당 항목 배점의 절반을 받습니다. 따라서 3점 항목의 경고는 1.5점, 2점 항목의 경고는 1점입니다. pass는 만점입니다. unknown과 not-applicable은 확인 실패를 곧바로 결함으로 간주하지 않고 계산 대상에서 제외하는 판정입니다. 이 카테고리에서는 특히 엔티티명 일관성이 비교 후보 부족으로 not-applicable이 될 수 있습니다.

이 15점과 항목별 비중은 Google, Schema.org 또는 특정 AI 검색 사업자의 공식 배점이 아닙니다. 공개 HTML에서 출처 단서를 확인하는 순서를 표현한 애드브랜치 검사기의 자체 우선순위입니다. 15점을 모두 받아도 검색 노출, AI 답변 인용, 풍부한 검색 결과 표시를 보장하지 않습니다.

1단계: 문서의 기본 귀속 정보를 찾는가

발행 조직/사이트명 (3점)

검사기는 발행 주체 후보를 두 경로에서 모읍니다. 첫째는 파싱에 성공한 JSON-LD 안의 publisher 이름과 @type이 Organization인 노드의 name입니다. 둘째는 초기 HTML에서 추출한 텍스트 표본에 있는 저작권 표기입니다. 저작권 표기는 ©, (c), copyright 뒤에 오는 문자열을 정규식으로 찾으며, 연도 또는 연도 범위가 사이에 있어도 후보로 수집합니다.

후보가 하나라도 있으면 이 항목은 통과합니다. 중요한 점은 후보의 진위를 확인하지 않는다는 것입니다. JSON-LD의 publisher.name이 실제 사업자명인지, 푸터의 저작권 이름이 현재 운영 주체인지, 두 주체가 법적으로 같은지는 판정하지 않습니다. 이름이 두 글자 이상이고 검사기가 읽을 수 있는 위치에 있는지가 핵심입니다.

화면 상단 로고의 픽셀이나 og:site_name만으로는 이 규칙을 통과하지 못할 수 있습니다. 반대로 공통 위젯이 넣은 제3자의 Organization 노드도 후보가 될 수 있으므로, 통과는 올바른 발행 주체를 찾았다는 인증이 아닙니다.

작성자 정보 (3점)

작성자 후보는 JSON-LD의 author, creator, reviewedBy, 두 글자 이상인 메타 작성자 값, rel 속성에 author가 포함된 링크에서 수집합니다. 작성자 링크는 링크 텍스트가 있으면 그 텍스트를, 없으면 주소를 후보로 사용합니다. 여기에 본문 텍스트 표본에서 작성자, 글쓴이, 기자, editor, written by 중 하나가 발견되는지도 봅니다.

이 규칙은 후보 이름을 수집하지 못해도 작성자 표기 문구만 발견하면 통과합니다. 그래서 “작성자 정보”라는 제목보다 실제 판정은 넓고 느슨합니다. 예를 들어 본문에 “작성자 정보를 확인하세요”라는 일반 문장이 있어도 작성자라는 단어 때문에 통과할 수 있습니다. 반대로 화면에 작성자 카드가 보여도 JavaScript 실행 뒤에만 나타나 초기 HTML 텍스트와 스냅샷 필드에 들어오지 않으면 경고가 날 수 있습니다.

reviewedBy도 작성자 후보로 함께 보는 점에 유의해야 합니다. 작성자와 검토자는 역할이 다르지만, 이 규칙은 문서에 책임 있는 사람이나 주체를 식별할 단서가 있는지 넓게 관찰합니다. 따라서 통과 여부만으로 실제 집필자와 검토자가 분리돼 있는지 알 수 없습니다. 역할을 공개할 때는 한 사람에게 하지 않은 검토 역할을 붙이거나 외부 전문가 감수처럼 오해하게 표현해서는 안 됩니다. 실제 역할과 범위를 있는 그대로 구분해야 합니다.

게시/수정 날짜 (2점)

날짜 규칙은 스냅샷의 게시일과 수정일 메타 값, JSON-LD의 datePublished, dateModified, dateCreated 문자열을 후보로 모읍니다. 그중 문자열이 YYYY-MM-DD로 시작하는 값이 하나라도 있으면 통과합니다. 시각과 시간대가 뒤에 이어지는 ISO 형식도 앞부분이 조건을 만족하므로 통과 대상입니다.

여기서 검사하는 것은 엄격한 달력 유효성 검증이 아닙니다. 정규식은 문자열 시작의 네 자리 연도, 두 자리 월, 두 자리 일을 확인할 뿐입니다. 실제로 존재하지 않는 날짜인지, 미래 날짜가 잘못 들어갔는지, 본문을 고친 날과 dateModified가 같은지는 확인하지 않습니다. 날짜가 하나만 있어도 통과하므로 게시일과 수정일을 모두 제공했는지도 구분하지 않습니다.

이 항목이 높은 점수를 받는다고 해서 최신성을 증명하지는 않습니다. 오래된 글에 최근 수정일만 바꿔 넣거나 내용을 검토하지 않고 날짜만 갱신해도 형식상 통과할 수 있습니다. 실제 최신성은 변경 이력, 근거 자료의 시점, 본문 내용까지 별도로 검토해야 합니다.

게시·수정 날짜 정합성 (1점)

게시·수정 날짜 정합성은 날짜의 존재 여부와 별도로 달력 유효성과 순서를 봅니다. meta의 게시일과 수정일, JSON-LD 각 노드의 datePublished, dateModified, dateCreated를 모아 확인합니다. 해석할 수 없는 날짜, 관측 시각보다 24시간을 초과한 미래 날짜, 같은 노드에서 수정일이 게시일보다 24시간 넘게 앞선 날짜는 개선 권장입니다. meta의 날짜 쌍도 같은 방식으로 비교하며, 후보가 없으면 해당 없음이고 문제가 없으면 통과합니다.

서로 다른 JSON-LD 노드의 날짜를 억지로 한 쌍으로 묶지는 않습니다. 한 페이지에 문서와 조직 등 여러 주체가 있을 수 있기 때문입니다. 날짜가 통과해도 실제 수정 시점이나 최신성이 입증되는 것은 아닙니다. Google은 보이는 날짜와 구조화 데이터의 날짜를 맞추고 미래 날짜를 피하라고 안내합니다. Google 게시 날짜 안내 또한 내용을 실질적으로 바꾸지 않고 날짜만 고쳐 최신처럼 보이게 하는지 경계하라고 묻습니다. Google 유용한 콘텐츠 안내

2단계: 발견한 주체를 혼동 없이 따라갈 수 있는가

엔티티명 일관성 (2점)

이 규칙은 발행 조직/사이트명 규칙과 같은 후보 목록을 다시 사용합니다. 즉 JSON-LD의 publisher, 모든 Organization 이름, 텍스트 표본의 저작권 표기에서 이름을 모읍니다. 그런 다음 소문자로 바꾸고 공백, 일부 문장 부호와 기호, 회사 형태를 나타내는 주식회사, ㈜, inc, llc, ltd, corp, co 등을 제거해 비교합니다.

판정 분기는 다소 독특합니다. 정규화한 고유 이름이 1개 이하이면 비교할 대상이 부족하다고 보고 not-applicable로 제외합니다. 서로 다른 정규화 이름이 정확히 2개이면 통과합니다. 3개 이상일 때만 경고합니다. 따라서 “일관성 통과”가 모든 표기가 완전히 동일하다는 뜻은 아닙니다. 두 이름의 차이는 약칭과 정식 명칭일 수도 있고, 실제로 서로 다른 조직일 수도 있습니다.

이 기준은 오탐을 줄이려는 보수적인 임계값입니다. 사이트 운영사, 브랜드, 서비스명이 함께 쓰이는 정상적인 페이지에서 이름이 둘이라는 이유만으로 경고하지 않습니다. 대신 세 종류 이상으로 분산되면 어느 이름이 발행 주체인지 모호할 가능성이 커졌다고 봅니다. 임계값은 경험적 우선순위이며 외부 표준의 요구사항이 아닙니다.

문자열 정규화에도 한계가 있습니다. “애드브랜치”와 “AD Branch”처럼 언어와 띄어쓰기가 함께 달라진 표기는 같은 주체여도 서로 다른 이름으로 남을 수 있습니다. 반대로 회사 형태와 기호를 제거한 뒤 우연히 같은 문자열이 되면 다른 법인을 같은 후보로 볼 수도 있습니다. 검사기는 별칭 사전, 사업자등록 정보, sameAs 관계를 사용해 실체를 대조하지 않습니다.

후보가 하나뿐이라 제외된 결과도 “문제가 전혀 없다”는 뜻은 아닙니다. 비교할 자료가 없다는 뜻에 가깝습니다. 발행 주체 이름을 여러 위치에 반복해야만 좋은 것도 아닙니다. 필요한 위치에 정확한 대표 표기를 두고, 반복한다면 같은 주체인지 독자가 혼동하지 않게 관리하는 것이 중요합니다.

연락/소개 경로 (2점)

검사기는 페이지에서 수집한 링크의 주소와 링크 텍스트를 합쳐 about, contact, 소개, 문의, privacy, 개인정보, 고객센터 중 하나가 포함되는지 찾습니다. 하나라도 발견하면 통과합니다. 링크가 내부 링크인지 외부 링크인지, 실제로 200 응답을 반환하는지, 연결된 페이지에 유효한 연락 수단이나 운영 주체 설명이 있는지는 확인하지 않습니다.

이 방식은 널리 쓰이는 경로 이름을 빠르게 찾는 휴리스틱입니다. 한국어와 영어 외의 표현, “회사 정보”, “운영자 안내”, “제휴 요청”처럼 목록에 없는 표현만 쓰는 사이트는 실제 경로가 있어도 놓칠 수 있습니다. 반대로 /articles/about-contact-patterns 같은 문서 주소나 링크 문장에 우연히 “문의”가 포함되면 책임 주체로 이어지는 링크가 아니어도 통과할 수 있습니다. 개인정보 처리방침 링크 하나만 있어도 조건을 만족하지만, 그 페이지가 독자가 찾는 소개나 연락 정보를 충분히 제공한다는 보장은 없습니다.

이 항목은 연락처를 본문마다 반복하라는 요구가 아닙니다. 사이트 공통 헤더나 푸터의 링크도 스냅샷에 수집되면 후보가 됩니다. 공개가 부적절한 개인 연락처를 억지로 노출할 필요도 없습니다. 실제 운영 주체가 관리하는 소개, 문의, 고객 지원, 개인정보 안내 중 사이트 성격에 맞는 경로가 명확하면 됩니다.

조직·작성자 외부 프로필 연결 (0점, 점수 미반영 진단)

조직·작성자 외부 프로필 연결은 Organization 계열이나 Person 노드의 sameAs를 확인합니다. 대상 노드가 없으면 해당 없음, 노드는 있지만 sameAs가 없으면 참고, 값이 있어도 절대 HTTP(S) URL이 하나도 없으면 개선 권장입니다. 유효한 URL이 하나 이상 있으면 통과하고 호스트와 @id 유무를 근거로 보여 줍니다.

Google은 Organization의 sameAs를 권장 속성으로 안내하지만 필수로 두지는 않습니다. 같은 안내에서 @id는 권장 속성으로 제시되지 않습니다. 검사기도 이 항목에 점수를 배정하지 않습니다. 링크가 공식 계정인지, 외부 프로필이 지금 열리는지, @id 참조가 올바른 대상에 연결되는지까지 확인하는 것은 아닙니다. 실제 운영하는 프로필만 연결하세요. Google Organization 안내

3단계: 기계가 읽을 페이지 유형이 있는가

페이지 적합 JSON-LD 유형 (2점)

검사기는 초기 HTML의 script[type="application/ld+json"] 블록을 파싱한 결과를 중첩해서 순회합니다. 파싱에 실패한 블록은 값 수집에서 제외되며, 중첩 순회는 깊이 8을 넘으면 멈춥니다. 먼저 문서 전체에서 모든 @type 문자열을 모은 뒤, 검사기가 인정하는 유형과 대소문자를 구분하지 않고 비교합니다.

인정 목록은 Article, BlogPosting, NewsArticle, Product, SoftwareApplication, Organization, Person, FAQPage, HowTo, WebPage, BreadcrumbList입니다. 이 가운데 기사 계열은 headline, 제품과 소프트웨어, 조직, 사람, HowTo는 name, FAQPage는 mainEntity가 있어야 합니다. WebPage와 BreadcrumbList는 이 규칙에서 별도 필수 속성을 요구하지 않습니다.

판정은 세 단계입니다. 수집한 유형이 하나도 없으면 JSON-LD 자체가 없었는지, 블록은 있으나 파싱에 실패했는지를 구분해 경고합니다. 유형은 있지만 인정 목록과 하나도 맞지 않으면 경고합니다. 인정 유형이 있더라도 그 유형에 지정된 필수 속성이 비어 있으면 경고하고, 조건을 모두 만족하면 통과합니다.

속성 확인 방식도 알아둘 필요가 있습니다. 필수 값은 비어 있지 않은 문자열이거나 원소가 하나 이상인 배열일 때만 존재한다고 봅니다. 객체 형태의 값이나 숫자 값은 이 검사에서 충족으로 인정되지 않습니다. 여러 인정 유형이 함께 있을 때 그중 필수 속성이 빠진 유형이 하나라도 있으면 경고할 수 있습니다. 예를 들어 완전한 WebPage가 있더라도 함께 선언한 Article에 headline이 없으면 누락 목록이 생깁니다.

규칙 이름에는 “페이지 적합”이 들어가지만, 검사기가 본문 내용을 분류해 @type과 대조하는 것은 아닙니다. 허용 목록 안의 유형과 요구 속성이 있는지를 확인합니다. 기사 페이지에 Organization만 있어도 이름 조건을 충족하면 이 규칙을 통과할 수 있고, 실제 제품이 아닌 페이지에 Product를 선언해도 사실 여부를 판정하지 못합니다. 통과 결과를 “Schema.org 의미가 정확하다”거나 “Google의 구조화 데이터 정책을 만족한다”는 인증으로 해석하면 안 됩니다.

JSON-LD는 화면에 보이는 정보와 일치해야 가치가 있습니다. 구조화 데이터만 그럴듯하게 채우고 본문에는 발행 주체나 작성자, 날짜가 없으면 사람에게는 확인 경로가 생기지 않습니다. 반대로 화면에 정확한 정보를 제공하더라도 JSON 문법 오류가 있으면 이 규칙은 유형을 읽지 못합니다. 두 표현은 서로를 대신하는 장식이 아니라 같은 사실을 서로 다른 독자에게 전달하는 층입니다.

신뢰 신호라는 표현을 조심해야 하는 이유

발행 주체, 작성자, 날짜, 소개 페이지, 구조화 데이터는 흔히 “신뢰 신호”라고 불립니다. 이 표현은 확인을 시작할 단서라는 뜻에서는 유용하지만, 신뢰를 자동으로 생성하는 장치처럼 이해하면 위험합니다. 익명의 허위 정보를 조직 이름 아래 게시한다고 사실이 되지 않으며, 자격이 없는 작성자에게 직함을 붙인다고 전문성이 생기지 않습니다.

검사기는 외부 명부나 자격 데이터베이스를 조회하지 않습니다. 따라서 높은 점수는 출처 표기를 따라가기 쉬운 구조에 가깝지, 출처가 신뢰할 만하다는 결론이 아닙니다. 경고를 없애려고 존재하지 않는 작성자, 검토자, 자격을 만들어서도 안 됩니다. 점수보다 사실성이 우선입니다.

이 검사가 확인하지 못하는 것

• 사실 여부를 검증하지 않습니다. 조직명, 사람 이름, 역할, 날짜, 연락 경로, JSON-LD 값이 실제 사실과 맞는지 외부 자료와 대조하지 않습니다.
• 전문성이나 권위를 평가하지 않습니다. 학력, 경력, 자격, 해당 주제의 전문 지식, 독립적인 검토 여부를 확인하지 않습니다. 표기를 추가해도 이런 속성이 만들어지지 않습니다.
• 단일 페이지의 초기 HTML을 봅니다. JavaScript 실행 뒤에 나타나는 작성자 카드나 링크, 렌더링 이후 바뀌는 구조화 데이터는 스냅샷에 없으면 관찰하지 못할 수 있습니다.
• 사이트 전체의 일관성을 보지 않습니다. 같은 조직이나 작성자가 다른 페이지에서 어떻게 표기되는지, 여러 언어 버전에서 이름과 역할이 일치하는지 비교하지 않습니다.
• 이름의 의미를 이해하지 않습니다. 약칭, 번역명, 브랜드명, 법인명이 같은 주체인지 판단하지 못하고, 정규화 뒤의 문자열 개수로만 엔티티명 일관성을 판정합니다.
• 링크 목적지를 검사하지 않습니다. 소개나 문의로 보이는 링크가 실제로 열리는지, 필요한 정보가 있는지, 제3자 페이지로 잘못 연결되는지 확인하지 않습니다.
• 날짜의 진실성과 최신성을 확인하지 않습니다. 형식과 달력 유효성, 미래 여부, 게시·수정일 순서는 검사하지만 실제 수정 시점과 본문 정보의 최신 상태는 검증하지 않습니다.
• JSON-LD의 전체 규격 준수를 보장하지 않습니다. 제한된 유형과 속성을 확인하며, Schema.org의 모든 유형과 관계, Google의 기능별 필수·권장 속성, 화면 내용과 구조화 데이터의 일치를 검증하지 않습니다.
• 모든 중첩을 무제한 탐색하지 않습니다. JSON-LD 순회는 깊이 제한이 있고, 파싱에 실패한 블록은 후보 수집에서 제외됩니다.
• 노출이나 인용을 예측하지 않습니다. 배점은 애드브랜치 자체 기준이며, Google이나 AI 검색 서비스가 페이지를 색인하거나 답변에 인용할지를 뜻하지 않습니다.

이어서 읽기

항목별 영향, 수정 지침, 코드 예시는 아래 자동 생성 표에서 확인할 수 있습니다. 구조화 데이터의 역할과 범위를 더 살펴보려면 구조화 데이터, 전체 GEO 점검 순서를 함께 보려면 GEO 점검 체크리스트, 검색 최적화와 생성형 검색 최적화의 관점 차이를 구분하려면 SEO와 GEO의 차이를 이어서 읽어 보세요.