회사 정보 일치 NAP 진단, 기준값 한 벌로 사이트별 대조하기

회사 정보 일치(NAP: Name·Address·Phone, 회사 이름·주소·전화번호) 진단은 공식 웹사이트에 기준값 한 벌을 정하는 데서 시작합니다. 각 사이트의 표시값을 그 기준값과 대조해 일치·표기 차이·불일치로 판정하고, 불일치에는 원인 후보를 함께 적어 재발을 막습니다.

실무에서는 AI 답변과 검색 결과가 공개된 여러 출처의 회사 정보를 함께 참고한다고 보고 이 진단을 합니다. 출처마다 값이 다르면 어느 값이 맞는지 밖에서 판단할 근거가 흐려지기 때문입니다. Google 문서도 정보가 완전하고 정확한 비즈니스가 지역 검색 결과에 표시될 가능성이 더 높다고 설명합니다. 다만 정보 일치는 회사 정보를 정확히 전달하기 위한 조건이며, 검색 노출이나 AI 답변 인용을 보장하지는 않습니다.

진단의 기준값은 어디에 정하나요?

대조를 시작하기 전에 자사 웹사이트에 기준값 한 벌을 정합니다. 외부 사이트끼리만 비교하면 어느 쪽이 맞는지 판정할 수 없기 때문입니다.

Google의 조직(Organization) 구조화 데이터 문서는 name과 alternateName을 사이트 이름과 같게 쓰도록 요구합니다. 등록된 법인명이 이와 다르면 legalName에 따로 적습니다. 전화번호에는 국가번호와 지역번호를 넣고, 주소에는 해당 국가에 적용되는 속성을 모두 넣는 것이 권장 사항입니다. 마크업 위치는 홈페이지나 회사를 설명하는 한 페이지면 되고, 모든 페이지에 넣을 필요는 없습니다.

매장이나 지점이 있는 회사라면 Google의 지역 비즈니스(LocalBusiness) 문서도 함께 봅니다. 이 문서에서 name과 address는 요구 속성, telephone과 url은 권장 속성입니다. 부서는 「매장 이름 부서 이름」 형태로 짓고, 부서에 자체 브랜드가 있으면 부서 이름만 씁니다.

일반 구조화 데이터 지침은 마크업이 페이지 내용을 실제로 나타내야 하며, 사용자에게 보이지 않는 내용은 마크업하지 않도록 정합니다. 사이트 이름 문서는 WebSite 구조화 데이터를 주된 지정 수단으로 둡니다. 여기에 og:site_name, title, 제목 요소 등 홈페이지의 다른 텍스트도 함께 고려하므로, 이 값들에 같은 이름을 쓰라고 요구합니다. 결국 기준값은 화면에 보이는 회사 소개 문구와 구조화 데이터가 같은 상태여야 합니다.

예를 들어 가상의 ○○테크 기업이라면 기준값을 다음처럼 한 장으로 정리합니다.

기준값 문서에는 확정일과 결정한 사람을 함께 적습니다. 이전이나 번호 변경이 생기면 이 문서부터 고치고 대조를 다시 시작합니다.

어떤 사이트를 어떤 순서로 대조하나요?

대조 대상은 영향이 큰 곳부터 정합니다. 실무에서는 다음 순서를 권합니다.

1. 자사 사이트 내부: 푸터, 회사 소개, 문의 페이지, 개인정보처리방침의 사업자 정보, 구조화 데이터를 서로 대조합니다. 내부가 어긋나 있으면 외부를 고쳐도 값이 다시 흔들립니다.
2. 직접 관리하는 지도·업체 프로필: Google 비즈니스 프로필처럼 소유권을 확인한 곳입니다. 관리자 화면 값과 공개 화면 값을 따로 봅니다.
3. 위키데이터 항목: 항목이 있으면 공식 웹사이트(P856) 같은 속성이 기준값과 같은지 확인합니다.
4. sameAs로 연결한 프로필: SNS와 리뷰 프로필 소개란의 이름·주소·전화번호를 봅니다.
5. 업종 디렉터리·보도자료·채용 공고: 직접 고칠 수 없는 곳이 많으므로 수정 요청 대상으로 분류합니다.

Google 비즈니스 프로필 도움말은 사용자 신고, 라이선스 콘텐츠 같은 여러 출처에서 정보를 모아 프로필을 업데이트할 수 있다고 밝힙니다. 그러므로 관리자 화면에 입력한 값만 보고 끝내지 않습니다. 로그아웃한 상태에서 공개 화면도 함께 확인합니다.

무엇을 일치로, 무엇을 불일치로 판정하나요?

모든 차이를 오류로 보면 수정 목록이 불필요하게 길어집니다. 뜻이 같은 표기 차이와 실제로 다른 정보를 구분합니다.

판정 근거는 공식 지침에서 찾습니다. Google 비즈니스 프로필 지침은 실제 세계에서 일관되게 쓰이고 알려진 이름, 곧 간판에 쓰는 실제 이름을 프로필 이름으로 정합니다. 실제 이름에 없는 홍보 문구, 매장 코드, 영업시간, 전화번호, URL, 위치 정보를 덧붙이는 것은 허용되지 않습니다. 실무에서는 정식 상호에 지역명이 원래 들어 있으면 그 이름을 기준값으로 보고 불일치로 처리하지 않습니다.

법인 접미어와 특수문자는 기준이 다릅니다. 지침은 간판·명함·청구서처럼 그 표기를 일관되게 보여 주는 실제 증빙이 있을 때만 이를 허용합니다. 그래서 자사 사이트와 디렉터리에서는 (주) 표기 유무를 표기 차이로 기록하고, 지도 프로필에서는 간판 표기와 다르면 불일치로 처리합니다.

주소와 전화번호 기준도 같은 지침에 있습니다. 우편 주소만 빌리고 실제로 영업하지 않는 가상 오피스와 원격지의 사서함·우편함은 등록 대상이 아닙니다. 공유 오피스는 간판이 있고 영업시간에 고객을 받으며 자사 인력이 상주하면 등록할 수 있습니다. 전화번호는 사업자가 직접 관리해야 하고, 가능하면 중앙 콜센터 번호 대신 지역 번호를 쓰도록 권합니다.

이상 신호마다 어떤 원인을 의심해야 하나요?

불일치를 고쳐도 몇 주 뒤 같은 값이 되돌아오기도 합니다. 증상과 원인 후보를 짝지어 기록하면 재발 지점을 좁힐 수 있습니다.

두 번째 신호는 공식 설명과 연결됩니다. Google 도움말에 따르면 사용자가 제안한 수정은 4일 안에 수락하거나 거절할 수 있습니다. 응답이 없으면 비즈니스 웹사이트 같은 다른 공개 정보가 뒷받침할 때 Google이 그 수정을 자동으로 게시할 수 있습니다. 실무에서는 자사 사이트에 남은 옛 주소가 잘못된 제안의 근거가 될 수 있다고 보고, 사이트 내부부터 정리합니다.

같은 도움말은 일괄 업로드에서 항목을 빈 칸으로 두면 자동 업데이트가 적용될 수 있다고 안내합니다. 위키데이터의 공식 웹사이트(P856) 속성 문서는 홈페이지가 바뀌어도 옛 주소를 지우지 않도록 합니다. 새 주소는 별도 진술로 추가해 우선(preferred) 순위를 주고, 옛 주소에는 종료 시점(P582) 한정자를 붙이는 방식입니다.

대조 결과는 어떤 양식으로 기록하고 요청하나요?

사이트 하나를 한 행으로 적습니다. 열은 다음과 같이 둡니다.

직접 고칠 수 없는 사이트에는 수정 요청을 보냅니다. 요청 문안에는 근거 위치를 함께 적습니다.

「안녕하십니까. ○○테크 웹 담당자입니다. 귀 사이트에 실린 자사 정보 중 주소가 이전 주소로 표시되어 있습니다. 현재 주소는 서울특별시 ○○구 ○○로 00, 0층입니다. 공식 웹사이트 회사 소개 페이지에서 같은 내용을 확인하실 수 있습니다. 수정을 요청드립니다.」

재확인도 같은 양식으로 합니다. 이전 기록과 나란히 놓으면 되돌아온 값과 새로 생긴 불일치를 바로 구분할 수 있습니다.

정리

1. 회사 소개 페이지의 화면 문구와 Organization 구조화 데이터를 같은 값으로 맞추고 기준값 문서를 확정합니다.
2. 자사 사이트의 푸터, 문의 페이지, title, og:site_name, 제목 요소를 기준값과 대조해 내부 불일치부터 고칩니다.
3. 지도 프로필은 관리자 화면과 공개 화면을 함께 보고, 파란색 글자로 표시된 Google 변경 정보와 상단 알림을 검토합니다.
4. 위키데이터, sameAs 프로필, 외부 디렉터리를 한 행씩 기록하고 판정과 원인 후보를 적습니다.
5. 직접 고칠 수 없는 곳에는 근거 위치를 담은 수정 요청을 보내고, 재확인일을 정해 같은 양식으로 다시 대조합니다.