로컬 디렉토리 전반의 NAP 일관성 감사하기

여러 디렉토리에 오래된 전화번호나 주소로 등록된 비즈니스는 고객과 검색 엔진에게 혼란을 줍니다. NAP 데이터를 감사하고 중요한 부분을 수정하는 방법.

로컬 비즈니스는 자신이 통제하지 못하는 수십 곳의 온라인 장소에 존재한다. 지도 앱, 리뷰 사이트, 업종별 디렉토리, 데이터 애그리게이터, 소셜 프로필 등이다. 이 각각의 장소는 비즈니스의 이름, 주소, 전화번호(로컬 SEO에서는 NAP라고 부른다) 사본을 저장하고 있다. 비즈니스가 이전하거나 전화번호를 바꾸거나 브랜드를 변경해도, 이 사본 대부분은 예전 그대로 남아있다.

그 결과 고객은 끊긴 전화번호로 전화를 걸고, 배달 기사는 예전 주소로 찾아가며, 검색 엔진과 지도 앱은 같은 비즈니스에 대해 서로 모순되는 정보를 갖게 된다. 많은 소규모 사이트들은 더 큰 사이트에서 데이터를 가져오기 때문에, 잘못된 리스팅 하나가 퍼져나가는 경향이 있다.

NAP 감사(audit)는 이런 불일치를 체계적으로 찾아낸다. 이 가이드는 무엇을 수집해야 하는지, 형식 차이가 실제 문제를 가리지 않도록 리스팅을 비교하는 방법, 이를 수행하는 코드, 그리고 수정 우선순위를 정하는 방법을 다룬다.

NAP 감사가 확인하는 것

비즈니스가 등재된 각 장소에 대해, 감사는 세 가지 질문에 답한다:

이름(Name): 매장 간판이나 웹사이트에서 사용하는 실제 비즈니스명이며, 추가된 키워드나 예전 브랜드명이 없는가?
주소(Address): 스위트 또는 유닛 번호를 포함해 올바른 우편번호와 함께 현재 주소인가?
전화번호(Phone): 아무도 받지 않는 예전 회선이나 추적용 번호가 아니라 현재 대표 번호인가?

많은 감사는 웹사이트 URL, 영업시간, 주요 카테고리도 함께 확인하는데, 이들 역시 같은 방식으로 오래된 정보가 되기 때문이다. 아래 방법은 이런 항목들로도 쉽게 확장할 수 있다.

1단계: 정본 레코드 작성

모든 것은 하나의 레코드, 즉 모든 곳에 나타나야 할 비즈니스의 NAP와 비교된다. 이는 디렉토리가 아니라 비즈니스 자체에서 가져와야 하며, 전체를 정확히 기록한다: 법인 접미사는 제외하고, 우체국에 등록된 그대로의 거리 주소, 대표 전화번호. 여러 지점을 가진 비즈니스라면 지점마다 안정적인 ID와 함께 정본 레코드를 하나씩 유지한다.

당연해 보이지만, 대부분의 감사가 바로 여기서 틀어진다. 정본 레코드 자체가 오래된 것이라면, 모든 비교가 같은 방향으로 잘못되게 된다.

2단계: 리스팅 수집

수집해야 할 리스팅은 세 그룹으로 나뉜다:

출처	예시	수집 방법
주요 플랫폼	Google Business Profile, Apple Business Connect, Bing Places, Facebook	비즈니스 자체 대시보드와 공식 API
리뷰 및 디렉토리 사이트	일반 및 업종별 디렉토리, 리뷰 플랫폼	존재하는 경우 공식 API, 없으면 공개 리스팅 페이지
데이터 애그리게이터	수많은 소규모 디렉토리에 데이터를 공급하는 업체	해당 업체의 비즈니스 포털

공식 API와 비즈니스 자체 계정이 존재하는 곳이면 어디든 활용한다. 더 신뢰할 수 있고 허용된 방식이기 때문이다. API가 없는 디렉토리의 경우 리스팅 페이지는 공개되어 있으며, 디렉토리별로 비즈니스당 페이지 하나를 수집하는 것은 가볍고 가끔씩만 수행하면 되는 작업이다. 리스팅은 국가와 도시에 따라서도 다를 수 있으므로, 실제 현지 고객이 보는 방식으로 확인해야 한다. 로컬 비즈니스 데이터 수집에 관한 가이드에서 수집 측면을 다루고 있다.

URL과 날짜와 함께 등재된 원본 값을 그대로 기록한다. 감사는 정규화된 값을 비교하지만, 수정 작업은 각 사이트에서 정확히 무엇이 잘못됐는지 알아야 한다.

3단계: 노이즈에 묻히지 않도록 비교하기

단순한 비교는 거의 모든 것을 문제로 표시한다. “St”와 “Street”, “(312) 555-0142”와 “312-555-0142”, “LLC”가 있거나 없는 경우 등은 실제 문제가 아니며, 이런 것들로 가득한 감사는 작년 전화번호가 아직 남아있는 리스팅을 숨겨버린다.

해결책은 비교 전에 각 필드를 정규화하고, 결과를 분류하는 것이다:

상태	의미	우선순위
match(일치)	정본 레코드와 동일함	없음
format(형식 차이)	텍스트는 다르지만 정규화 후 값이 같음	낮음: 편할 때 정리
close(근접)	스위트 번호 누락이나 오타처럼 거의 같음	중간: 확인 후 수정
mismatch(불일치)	다른 값: 다른 주소, 다른 번호, 다른 이름	높음: 먼저 수정
missing(누락)	해당 리스팅에 필드가 비어있음	중간: 추가

아래 코드는 각 필드에 맞는 방식으로 정규화한다. 이름은 구두점, 악센트, 앞에 붙은 “The”, 법인 접미사를 제거한다. 주소는 표준 약어로 확장되고(“Street”를 “st”로, “Suite”를 “ste”로), ZIP+4 확장 번호는 제거된다. 전화번호는 Google의 전화번호 라이브러리의 Python 포트인 phonenumbers로 파싱되고 국제 형식으로 비교되므로, 같은 번호의 어떤 표기 방식이든 일치하게 된다.

import re
import unicodedata
from difflib import SequenceMatcher

import phonenumbers

LEGAL_SUFFIXES = {"llc", "inc", "ltd", "co", "corp", "gmbh", "plc", "sl", "srl"}
ADDRESS_WORDS = {
    "street": "st", "avenue": "ave", "boulevard": "blvd", "road": "rd", "drive": "dr",
    "lane": "ln", "court": "ct", "place": "pl", "suite": "ste", "floor": "fl",
    "north": "n", "south": "s", "east": "e", "west": "w", "apartment": "apt", "unit": "ste",
}


def _words(text):
    text = unicodedata.normalize("NFKD", text).encode("ascii", "ignore").decode().lower()
    text = text.replace("&", " and ").replace("#", " ste ")
    return re.sub(r"[^a-z0-9 ]+", " ", text).split()


def norm_name(name):
    words = [w for w in _words(name) if w not in LEGAL_SUFFIXES]
    return " ".join(words[1:] if words[:1] == ["the"] else words)


def norm_address(address):
    # Drop the ZIP+4 extension, so "60607-1234" matches "60607".
    address = re.sub(r"\b(\d{5})-\d{4}\b", r"\1", address)
    return " ".join(ADDRESS_WORDS.get(w, w) for w in _words(address))


def norm_phone(phone, region="US"):
    try:
        number = phonenumbers.parse(phone, region)
    except phonenumbers.NumberParseException:
        return None
    if not phonenumbers.is_valid_number(number):
        return None
    return phonenumbers.format_number(number, phonenumbers.PhoneNumberFormat.E164)


def compare(field, canonical, listed, region="US"):
    """'match', 'format' (same after normalising), 'close', 'mismatch' or 'missing'."""
    if not listed:
        return "missing"
    if listed.strip() == canonical.strip():
        return "match"
    if field == "phone":
        a, b = norm_phone(canonical, region), norm_phone(listed, region)
        return "format" if a and a == b else "mismatch"
    normalise = norm_name if field == "name" else norm_address
    a, b = normalise(canonical), normalise(listed)
    if a == b:
        return "format"
    return "close" if SequenceMatcher(None, a, b).ratio() >= 0.9 else "mismatch"


def audit(canonical, listings, region="US"):
    """One row per directory: the status of name, address and phone."""
    rows = []
    for source, listing in listings.items():
        row = {"source": source}
        for field in ("name", "address", "phone"):
            row[field] = compare(field, canonical[field], listing.get(field), region)
        rows.append(row)
    return rows

region 인자는 국가 코드 없이 작성된 번호에 대해 전화번호 파서가 어떤 국가를 가정할지 알려주며, 덕분에 같은 코드를 region="DE"나 region="BR"로 독일이나 브라질 비즈니스에도 동일하게 사용할 수 있다. 주소 약어는 영어권 기준이므로, 다른 시장을 위해서는 ADDRESS_WORDS를 확장해야 한다.

감사 실행하기

다음은 한 비즈니스를 네 개의 디렉토리 리스팅과 비교한 감사 예시이다(실제 리스팅이 아닌 설명용 예시):

from nap import audit

canonical = {
    "name": "Corner Bakery",
    "address": "123 North Main Street, Suite 4, Chicago, IL 60607",
    "phone": "(312) 555-0142",
}
listings = {
    "Directory A": {"name": "Corner Bakery", "address": "123 N Main St #4, Chicago IL 60607",
                    "phone": "312-555-0142"},
    "Directory B": {"name": "The Corner Bakery LLC", "address": "123 North Main Street, Suite 4, Chicago, IL 60607",
                    "phone": "(312) 555-0142"},
    "Directory C": {"name": "Corner Bakery", "address": "88 West Lake Street, Chicago, IL 60601",
                    "phone": "(312) 555-0199"},
    "Directory D": {"name": "Corner Bakery & Cafe", "address": "123 N Main St, Chicago, IL 60607"},
}

print(f"{'source':<12} {'name':<9} {'address':<9} phone")
for row in audit(canonical, listings):
    print(f"{row['source']:<12} {row['name']:<9} {row['address']:<9} {row['phone']}")

source       name      address   phone
Directory A  match     format    format
Directory B  format    match     match
Directory C  match     mismatch  mismatch
Directory D  mismatch  close     missing

한 줄씩 읽어보면:

Directory A는 주소와 전화번호의 형식이 다르지만, 모든 값은 올바르다. 수정할 필요 없음.
Directory B는 이름에 “The”와 “LLC”를 덧붙였다. 이 역시 문제없지만, 정리해둘 가치는 있다.
Directory C는 이름은 올바르지만 예전 주소와 예전 전화번호를 갖고 있다. 이것이 고객을 엉뚱한 곳으로 보내는 리스팅이며, 가장 먼저 고쳐야 할 대상이다.
Directory D는 이름이 다르고(“Corner Bakery & Cafe”), 스위트 번호가 빠져있으며, 전화번호가 아예 없다.

4단계: 올바른 순서로 수정하기

주요 플랫폼의 불일치를 먼저 처리한다. 이 리스팅들이 가장 많은 사람에게 도달하며, 많은 소규모 사이트가 여기서 데이터를 가져온다.
나머지 모든 곳의 불일치를 처리하되, 해당 비즈니스 업종과 가장 관련 있는 디렉토리와 비즈니스명 검색에서 상위에 노출되는 디렉토리부터 시작한다.
누락된 필드, 특히 전화번호.
근접 일치, 예를 들어 스위트 번호 누락 같은 경우.
형식 차이는 수정한다면 가장 마지막에.

일부 리스팅은 비즈니스 자체 계정을 통해 직접 수정할 수 있다. 다른 것들은 클레임 절차나 지원 요청이 필요하며, 데이터 애그리게이터는 종종 자체 포털을 통해 수정 사항을 제출해야 하고, 그 후 변경 사항이 해당 업체가 공급하는 사이트들로 전파된다. 일부 디렉토리에서는 수정 사항이 반영되기까지 몇 주가 걸릴 수 있다는 점을 염두에 둔다.

5단계: 일정에 맞춰 재감사하기

리스팅은 다시 원래대로 돌아가는 경향이 있다. 애그리게이터가 수정 사항을 덮어쓸 수 있고, 일부 플랫폼에서는 사용자가 수정 제안을 할 수 있으며, 아무도 기억하지 못하는 출처에서 예전 데이터가 다시 나타나기도 한다. 주요 플랫폼은 매월, 롱테일 디렉토리는 분기마다 감사를 다시 실행하고, 이전, 전화번호 변경, 리브랜딩 후에는 항상 재감사한다.

각 감사 결과를 날짜와 함께 보관한다. 단일 실행 결과보다 추세가 더 중요하다. 매번 수정해도 예전 주소로 되돌아가는 리스팅은 아직 잘못된 데이터를 갖고 있는 상류 출처를 가리킨다.

지도 순위가 중요한 비즈니스라면, 감사와 함께 비즈니스가 서비스하는 지역 전체에 걸친 순위 측정을 병행한다. 지오그리드 순위 추적에 관한 가이드에서 이를 측정하는 방법과 리스팅을 정리한 후 가시성이 개선되는지 확인하는 방법을 다루고 있다.

NAP 불일치의 흔한 원인

이전과 전화번호 변경이 메인 프로필에만 반영되고 다른 곳에는 반영되지 않은 경우.
광고 캠페인을 위해 추가된 콜 트래킹 번호가 제거되지 않고 남아있는 경우.
리브랜딩 이후 예전 이름이 롱테일 디렉토리에 그대로 남아있는 경우.
해당 필드가 없는 디렉토리에서 스위트 및 유닛 번호가 누락되는 경우.
종종 자동으로 생성되며 각각 조금씩 다른 데이터를 가진 중복 리스팅.
한 지점의 데이터가 다른 지점의 리스팅에 복사된 여러 지점을 가진 비즈니스.

FAQ

NAP 일관성이란 무엇인가?

NAP는 이름(name), 주소(address), 전화번호(phone number)의 약자다. NAP 일관성이란 지도 앱, 디렉토리, 리뷰 사이트, 자사 웹사이트 등 온라인에 등재된 모든 곳에서 비즈니스의 NAP가 동일하고 정확한 것을 의미한다.

“St”와 “Street” 같은 형식 차이가 중요한가?

잘못된 데이터에 비하면 훨씬 덜 중요하다. 감사는 비교 전에 형식을 정규화해야 하며, 그래야 예전 주소나 전화번호를 가진 리스팅이 무해한 차이들 속에 묻히지 않고 눈에 띄게 된다.

비즈니스 리스팅은 얼마나 자주 감사해야 하는가?

주요 플랫폼은 매월, 다른 디렉토리는 분기마다 감사하는 것이 합리적인 주기이며, 여기에 더해 이전, 전화번호 변경, 리브랜딩 후에는 추가로 감사한다.

디렉토리 리스팅에 추적용 전화번호를 사용해야 하는가?

주의해서 사용해야 한다. 캠페인 종료 후 제거된 추적 번호는 리스팅에 죽은 번호를 남긴다. 추적 번호를 사용한다면, 플랫폼이 허용하는 경우 대표 번호도 함께 등재되도록 하고, 어떤 리스팅에 어떤 번호가 쓰였는지 기록해둬야 한다.

결론

NAP 감사는 데이터 품질 작업이다: 하나의 정본 레코드, 출처와 날짜와 함께 수집된 모든 리스팅, 비교 전에 정규화된 값, 그리고 실제 문제가 드러나도록 분류된 결과. 가장 큰 플랫폼의 불일치부터 먼저 고치고, 그 다음으로 내려가며, 리스팅은 다시 어긋나기 마련이므로 일정에 맞춰 재감사한다. 위의 코드는 비교 작업을 처리해주지만, 정본 레코드를 정확하게 유지하고 감사 결과에 따라 행동하는 것은 꾸준한 노력의 문제다.