ローカルディレクトリ全体でのNAP一貫性の監査

複数のディレクトリに古い電話番号や住所が掲載されているビジネスは、顧客や検索エンジンを混乱させます。NAPデータを監査し、重要な点を修正する方法。

ローカルビジネスは、自社が管理していない数十もの場所にオンライン上で存在しています。地図アプリ、レビューサイト、業界ディレクトリ、データアグリゲーター、SNSプロフィールなどです。それぞれが、ビジネスの名前、住所、電話番号の独自のコピーを保持しており、ローカルSEOではこれをNAPと呼びます。ビジネスが移転したり、電話番号を変更したり、ブランドを変更したりしても、これらのコピーの多くはそのままになっています。

その結果、顧客が繋がらない番号にかけたり、配達員が旧住所に向かったり、検索エンジンや地図アプリが同じビジネスについて矛盾した情報を保持したりすることになります。多くの小規模サイトは大手サイトからデータをコピーするため、一つの誤った掲載情報が広がりやすくなります。

NAP監査は、こうした不整合を体系的に見つけ出します。このガイドでは、何を収集すべきか、書式のノイズによって本当の問題が埋もれないように掲載情報をどう比較するか、それを行うためのコード、そして修正の優先順位の付け方について説明します。

NAP監査で確認する内容

ビジネスが掲載されている場所ごとに、監査では次の3つの質問に答えます。

名前: 店舗や自社サイトで使われている、余分なキーワードや旧ブランド名が付いていない、実際のビジネス名になっているか?
住所: 部屋番号や号室を含め、正しい郵便番号を伴った現在の住所になっているか?
電話番号: 誰も出ない旧回線やトラッキング番号ではなく、現在の主要な番号になっているか?

多くの監査では、ウェブサイトのURL、営業時間、主要カテゴリも確認します。これらも同じように古くなるためです。以下の手法はそれらにも容易に拡張できます。

ステップ1: 正規のレコードを書き出す

すべては一つのレコード、つまりどこにでも表示されるべきビジネスのNAPと比較されます。これはディレクトリからではなくビジネス自身から取得し、法人格の略称を外し、郵便局が保持している通りの住所をそのまま、主要な電話番号とともに、省略せずに書き出します。複数拠点を持つビジネスの場合は、拠点ごとに安定したIDを付けた正規レコードを1つずつ保持します。

当たり前のことに聞こえますが、ほとんどの監査がここで間違えます。正規レコード自体が古い場合、すべての比較が同じ方向に誤ったものになります。

ステップ2: 掲載情報を収集する

収集すべき掲載情報は3つのグループに分かれます。

ソース	例	収集方法
主要プラットフォーム	Google Business Profile、Apple Business Connect、Bing Places、Facebook	ビジネス自身のダッシュボードと公式API
レビュー・ディレクトリサイト	一般・業界ディレクトリ、レビュープラットフォーム	公式APIがある場合はそれ、なければ公開の掲載ページ
データアグリゲーター	多くの小規模ディレクトリにデータを供給する企業	各社のビジネス用ポータル

公式APIとビジネス自身のアカウントが存在する場合は、それらを利用してください。より信頼性が高く、許可されています。APIのないディレクトリについては掲載ページが公開されているため、ディレクトリごとにビジネスあたり1ページを収集するのは軽く、時折行う作業です。掲載情報は国や都市によって異なることもあるため、実際の地元顧客が見るのと同じように確認してください。ローカルビジネスデータの収集に関するガイドで、収集の側面を扱っています。

URLと日付とともに、生の値を掲載されたとおりに正確に記録してください。監査は正規化された値を比較しますが、修正にはどのサイトで何が間違っているかを正確に知る必要があります。

ステップ3: ノイズに埋もれずに比較する

単純な比較では、ほとんどすべてにフラグが立ってしまいます。「St」対「Street」、「(312) 555-0142」対「312-555-0142」、「LLC」の有無。これらはどれも本当の問題ではなく、こうしたもので埋め尽くされた監査結果は、昨年の電話番号がまだ残っている掲載情報を隠してしまいます。

解決策は、比較の前に各フィールドを正規化し、結果を分類することです。

ステータス	意味	優先度
match（一致）	正規レコードと同一	なし
format（書式差）	テキストは異なるが、正規化後は同じ値	低: 都合の良いときに整える
close（近似）	部屋番号の欠落や誤字など、ほぼ同じ	中: 確認して修正
mismatch（不一致）	異なる値: 別の住所、別の番号、別の名前	高: 最優先で修正
missing（欠落）	その掲載情報ではフィールドが空	中: 追加する

以下のコードは、それぞれのフィールドに適した方法で正規化します。名前は句読点、アクセント記号、先頭の「The」、法人格の略称を取り除きます。住所は標準的な略語に展開し（「Street」を「st」に、「Suite」を「ste」に）、ZIP+4の拡張部分を削除します。電話番号はphonenumbers、つまりGoogleの電話番号ライブラリのPython移植版で解析され、国際形式で比較されるため、同じ番号であればどのような書式でも一致します。

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を拡張してください。

監査の実行

あるビジネスを4つのディレクトリ掲載情報と比較した監査を見てみましょう（例示であり、実在の掲載情報ではありません）。

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の不整合の一般的な原因

移転や電話番号の変更がメインプロフィールでは更新されたが、それ以外では更新されなかった。
通話トラッキング番号が広告キャンペーンのために追加され、その後削除されなかった。
ブランド変更で、旧名称がロングテールのディレクトリに残り続けている。
部屋番号や号室がフィールドを持たないディレクトリによって削除されている。
重複した掲載情報。多くの場合自動的に作成され、それぞれわずかに異なるデータを持つ。
複数拠点のビジネスで、ある拠点のデータが別の拠点の掲載情報にコピーされている。

よくある質問

NAPの整合性とは何ですか?

NAPとは名前、住所、電話番号のことです。NAPの整合性とは、ビジネスのNAPが、地図アプリ、ディレクトリ、レビューサイト、自社ウェブサイトなど、オンライン上で掲載されているすべての場所で同一かつ正確であることを意味します。

「St」と「Street」のような書式の違いは重要ですか?

誤ったデータに比べればはるかに重要度は低いです。監査では比較の前に書式を正規化し、無害な違いに紛れて見失われるのではなく、古い住所や電話番号を持つ掲載情報が目立つようにすべきです。

どのくらいの頻度でビジネスの掲載情報を監査すべきですか?

主要プラットフォームは毎月、その他のディレクトリは四半期ごとというのが妥当なペースであり、それに加えて移転、電話番号の変更、ブランド変更があった際には追加で監査を行ってください。

ディレクトリの掲載情報にトラッキング電話番号を使うべきですか?

慎重に使用してください。キャンペーン終了後に削除されたトラッキング番号は、掲載情報に繋がらない番号を残してしまいます。使用する場合は、プラットフォームが許可している箇所では主要な番号も併せて掲載されるようにし、どの掲載情報がどの番号を持っているかを記録しておいてください。

まとめ

NAP監査はデータ品質の仕事です。一つの正規レコード、ソースと日付とともに収集されたすべての掲載情報、比較前に正規化された値、そして本当の問題が目立つように分類された結果。まず最大手のプラットフォームの不一致から修正し、そこから順に対応し、掲載情報は元に戻る傾向があるため定期的に再監査してください。上記のコードは比較を処理しますが、規律として重要なのは正規レコードを正しく保ち、監査結果に基づいて行動することです。