Directories and search engines match business details on exact strings. Suite and Ste are treated as different addresses. This compares the name, address and phone in your structured data against what is actually written on the page.
A human reading Suite 4 and Ste 4 sees one address. A matching algorithm building a business entity across dozens of directories sees two. When those records disagree, the entity fragments — and a fragmented entity ranks worse than a single consistent one.
Most inconsistency does not begin at a directory. It begins with markup that says one thing and page text that says another.
Abbreviations, punctuation in phone numbers, a missing postcode. Each is enough to make two records look like two businesses.
There is no warning and no error. The listing simply performs worse than it should, and the cause is invisible.
Whether a LocalBusiness or Organization node exists at all. Without one, everything else is inferred from page text.
The schema number stripped to digits and matched against every number on the page. Formatting is ignored; the digits must agree.
The schema address normalised and compared token by token against the page text, reported as a percentage.
Several distinct numbers on one page makes it ambiguous which is your main line.
Whether hours are declared in markup rather than only as text. Declared hours can surface in the map pack.
Coordinates remove ambiguity when a street name repeats. sameAs is what ties your site to your Business Profile.
Point it at your contact or location page, where your details should be most complete. We read the structured data, extract every phone number and address fragment from the visible text, then compare them.
Reads one page. It does not query third-party directories — see the honest version below.
Strong agreement. Your markup and your page are describing the same address in compatible terms.
Partial. Usually an abbreviation difference or a missing element such as the postcode. Worth aligning.
Your markup and your page are effectively describing different addresses. Fix this before touching any directory listing.
Matching is token-based after normalising common abbreviations, so a high percentage means strong agreement rather than character-identical formatting.
Getting your own markup and page to agree is necessary and it is where most inconsistency starts. It is not the same as auditing your presence across the web, and we would rather say so than imply otherwise.
That needs live SERP data. This checks your own page and markup.
Verifying Yelp, Justdial or Apple Maps means asking each one. This compares your schema against your own page.
If your details differ between your contact page and your footer, run it against both.
Review velocity, profile completeness and proximity move the map pack. Consistency stops you losing ground you already hold.
For entity matching, yes. Different systems normalise differently, and the safest position is that your details are written identically everywhere you control.
Each location needs its own page and its own LocalBusiness node. One node listing several addresses is ambiguous.
No. Use your real primary line in markup. Call tracking numbers that appear only in schema are a common source of mismatch.
It is the clearest way to state which profiles belong to you. Most local sites omit it, which leaves the connection to be inferred.
Once your own details agree, the work that actually moves the map pack begins: citations, profile completeness, review velocity and the pages that support each location.