Checking local-business NAP consistency in code

Citation Builder — Fri, 03 Jul 2026 12:00:49 +0000

If you have ever done local SEO, you have heard the acronym NAP: Name, Address, Phone. The folklore is that these three fields should be byte-for-byte identical everywhere your business is listed (Google, Yelp, Apple Maps, the long tail of directories), or your local rankings suffer.

"Just compare the strings" is the instinct. Then you actually try it, and every assumption falls apart. This is a writeup of the engineering problems I ran into building a free NAP checker, and how I ended up solving them. No framework, just plain JavaScript and a few HTTP calls.

The core problem: equality is the wrong operator

Here is the same real business as three directories store it:

Joe's Plumbing & Heating, LLC   | 123 N Main St Ste 4   | (415) 555-0199
Joe's Plumbing and Heating      | 123 North Main Street  | +1 415-555-0199
Joeβ€™s Plumbing & Heating LLC    | 123 N. Main St. #4     | 415.555.0199

A human reads those as one business. === reads three different businesses across all three fields. The whole job is closing that gap without being so fuzzy that two genuinely different businesses score as a match. Every field needs its own normalization pipeline before you can compare anything.

Phone is the easy win, so start there

Phone numbers feel messy but they are the most tractable field, because there is a real spec underneath. Strip everything to digits, drop the country code, and compare the national significant number. libphonenumber does this properly, but the 80% version is small:

function normalizePhone(raw, region = "US") {
  const digits = (raw || "").replace(/\D/g, "");
  if (!digits) return null;

  // US/CA: 11 digits starting with 1 -> drop the country code
  let nsn = digits;
  if (region === "US" && nsn.length === 11 && nsn.startsWith("1")) {
    nsn = nsn.slice(1);
  }
  // store last 10 as the comparable key
  return nsn.length >= 10 ? nsn.slice(-10) : nsn;
}

normalizePhone("(415) 555-0199");   // "4155550199"
normalizePhone("+1 415-555-0199");  // "4155550199"
normalizePhone("415.555.0199");     // "4155550199"

All three formats above collapse to 4155550199. Phone becomes a clean equality check on a normalized key. The one trap: extensions. 555-0199 x12 should match 555-0199 on the main number, so compare the leading NSN, not a naive "last 10 digits" that swallows the extension. For anything beyond US/CA, hand it to libphonenumber and trust the region metadata, because national-number length is not universal.

Names: strip the legal suffix, then match tokens

Business names break equality in two predictable ways:

Legal suffixes. LLC, Inc, Ltd, Co, GmbH, Corp, L.L.C. These are noise for matching. One directory keeps them, one drops them, one abbreviates.
Connectors and punctuation. & vs and, smart quotes (β€™ vs '), trailing commas, casing.

So the name pipeline is: lowercase, normalize unicode (β€™ β†’ '), expand/standardize &, strip a known list of legal suffixes, collapse whitespace. Then I don't do a raw string compare. I tokenize and measure token overlap, because word order and a stray extra word shouldn't tank the score:

const LEGAL = /\b(llc|l\.l\.c\.|inc|incorporated|ltd|co|corp|company|gmbh|kg|bv|sa|srl)\b/g;

function normalizeName(s) {
  return (s || "")
    .toLowerCase()
    .normalize("NFKC")
    .replace(/[β€™']/g, "")
    .replace(/&/g, " and ")
    .replace(LEGAL, "")
    .replace(/[^a-z0-9\s]/g, " ")
    .replace(/\s+/g, " ")
    .trim();
}

function tokenScore(a, b) {
  const A = new Set(normalizeName(a).split(" ").filter(Boolean));
  const B = new Set(normalizeName(b).split(" ").filter(Boolean));
  if (!A.size || !B.size) return 0;
  let shared = 0;
  for (const t of A) if (B.has(t)) shared++;
  return shared / Math.max(A.size, B.size); // Jaccard-ish, biased to the longer side
}

"Joe's Plumbing & Heating, LLC" vs "Joe's Plumbing and Heating" now scores 1.0 on shared tokens. Dividing by the longer token set (rather than the union) keeps a directory that bolts on a city name ("... Heating San Francisco") from scoring a perfect match against the clean version.

Addresses: the abbreviation swamp

Addresses are the worst field, and it is worth being honest about why. The variation isn't typos, it's a dictionary of equivalent forms that postal systems treat as identical:

In the wild	Canonical
`St`, `St.`	`Street`
`Ave`, `Av`	`Avenue`
`Blvd`	`Boulevard`
`N`, `N.`	`North`
`Ste`, `#`, `Unit`	(suite designator)
`Hwy`	`Highway`

The fix is an expansion map applied token by token, the same way you normalize the name. 123 N Main St Ste 4 and 123 North Main Street #4 both reduce to 123 north main street 4 and compare cleanly. Keep the map small and US/region-specific; an over-eager map will "correct" things that were never abbreviations.

Why reverse-geocoding lies to you

Here is the subtle one that cost me the most time. Some directories only give you a lat/long, not a clean street string. The tempting move is to reverse-geocode those coordinates back into an address and compare. Don't trust that comparison for a mismatch verdict.

Reverse geocoding snaps a point to the nearest known feature in the geocoder's database. A rooftop pin 12 meters off can resolve to the building next door, a different suite, or the road centerline. So you reverse-geocode 123 Main St and get back 125 Main St, and your checker screams "address mismatch!" when the listing is perfectly fine. The error is in your verification method, not in the data.

The rule I settled on: reverse-geocoded addresses are advisory. If the forward, text-based address agrees, great. If it disagrees, fall back to a coordinate-distance check (are the two points within ~50m?) before ever reporting a mismatch. A mismatch born from snapping is a false positive, and false positives in this tool are worse than gaps, because they send people editing listings that were already correct.

Scoring: per field, not one blob

Early on I concatenated N + A + P and computed one similarity number. Useless. A wrong phone and a wrong suite number are completely different problems, and an aggregate score hides which one you have.

So scoring is field-level. Each directory result returns a per-field verdict, and not_found is explicitly not a failure:

function scoreField(mine, theirs, kind) {
  if (theirs == null) return { status: "not_found" };   // coverage gap, not a mismatch
  const ok =
    kind === "phone" ? normalizePhone(mine) === normalizePhone(theirs)
    : kind === "name" ? tokenScore(mine, theirs) >= 0.8
    : normalizeAddress(mine) === normalizeAddress(theirs);
  return { status: ok ? "match" : "mismatch", theirs };
}

That not_found distinction matters more than it looks. If a directory simply doesn't list you, that is a coverage signal ("go claim this listing"), not a consistency signal ("you have conflicting data"). Folding them together makes a business with thin coverage look like a business with a data integrity problem. They need opposite fixes.

The data sources are the actual hard part

The algorithms above are a weekend. Getting clean field data to compare against, for free, at scale is the part that never ends.

What worked, server-side and free:

OpenStreetMap / Nominatim is the workhorse. Geocode the address, get structured address parts back. Critically, request extratags β€” that is where phone / contact:phone and website live, so you can compare more than just the address. Respect the usage policy: one request per second, a real User-Agent, and cache aggressively.
iBegin and Lacartes gave usable structured listings for US/CA/UK without a login wall.

What did not work, and why it's worth knowing before you waste an afternoon:

Yelp and Yellow Pages: hard 403 to anything from a datacenter IP. Their bot detection assumes residential traffic; your server is not that. Scraping them at scale means a residential proxy budget, which kills "free."
Hotfrog: same datacenter 403 story.
hub.biz: echoed my query back at me instead of returning its own stored record, which is worthless for a consistency check (you'd be comparing the input to itself).
A long tail of directories sit behind Cloudflare challenges or render NAP only after client-side JS, so a plain server fetch sees an empty shell.

The lesson is that "check across all directories" is marketing; "check across the directories that expose structured data to an anonymous server request" is the real, shippable scope. Be upfront about coverage instead of pretending a not_found from a bot-wall means the listing is absent.

Putting it together

The shape that worked:

Normalize the user's own NAP once.
For each reachable source, fetch, extract NAP (incl. extratags), normalize the same way.
Score per field, with match / mismatch / not_found as distinct states.
Treat reverse-geocoded addresses as advisory and gate mismatches behind a distance check.
Report coverage and consistency as two separate things.

I packaged this into a free checker I built if you want to see the normalization behavior on a real business without writing the code. But the genuinely portable lesson is the framing: NAP consistency is a per-field normalization-and-matching problem with a nasty data-acquisition tail, and the single biggest correctness bug is trusting a reverse-geocode to tell you two addresses disagree.

If you build your own, start with phone (real spec, clean wins), get your name and address normalizers right, and spend your remaining time on the data sources, because that is where the project actually lives.

DEV Community: Citation Builder