First CH Apps / Business Name, Address & Phone Consistency Checker
Enter up to three URLs from the same site — the home page, the company profile, the access page and so on. For each page we read the visible text, the footer, tel: links and JSON-LD (Organization / LocalBusiness), pick out the business name, address, phone number and opening hours, and line up every place where they differ, page to page or page to structured data. Use it as groundwork before you tidy up the NAP (name, address, phone) details shown on maps and in search.
Only the pages you enter are compared. We do not check your Google Business Profile, directories or review sites, and we do not crawl links.
We look in four places: (1) the visible text (without script, style, comments or the footer), (2) the footer (the last footer element), (3) numbers in tel: links, and (4) the name, address, telephone and openingHours / openingHoursSpecification of JSON-LD Organization and LocalBusiness nodes, including subtypes such as Restaurant or Dentist.
From the text we take labelled values (company name, address, TEL, opening hours and their Japanese equivalents), addresses that start with 〒 or a prefecture, Japanese phone numbers separated by hyphens or brackets, and the name after ©. Fax numbers are not treated as phone numbers.
Normalisation only removes differences in how things are written, following Japanese conventions: full-width vs half-width characters, spaces, the various hyphen characters, the 〒 postcode mark and postcode format, brackets and hyphens in phone numbers, and +81 (+81-3-… equals 03-…). Japanese block addresses written as 1丁目2番3号 count as 1-2-3 only when the digits are exactly the same.
A missing prefecture, building name or floor is never filled in (渋谷区… vs 東京都渋谷区… is a possible mismatch). Kanji numerals, legal-entity suffixes (株式会社 vs (株)) and upper/lower case are not unified either.
Values are compared only when they clearly belong to the same business or shop. When one place holds several different values (head office and branch, main line and reservations), when a value is labelled as a reservation line, branch or recruiting contact, or when the JSON-LD lists more than one business, we leave it out and mark it as needing review.
For opening hours we compare only the time ranges (such as 9:00–18:00), not the days.
Before fetching, we read robots.txt once. Pages it disallows, and all pages when robots.txt cannot be fetched, are left unchecked. Redirects to another origin (including http vs https or with vs without www) are not followed.
Treat the results as pointers. Making the details consistent is not a promise of better rankings or map visibility; have someone confirm what is correct.
Sent: only the URLs you type (up to three). Our server (Cloudflare Workers) fetches the site's robots.txt and each URL once as a public page. Links are not followed.
Stored: nothing. The comparison lives entirely inside one request and writes neither the URLs, the fetched content nor the result to any database (no KV, no D1). It leaves memory when the request ends. To limit rapid repeat runs, a per-IP counter is kept in memory for up to 10 minutes (never stored).
Returned: the business names, addresses, phone numbers and opening hours we found, with short snippets of how they were written. We never re-serve the fetched HTML, so this app cannot be used to browse other sites through us.
Note: public GET only, with no cookies or credentials. URLs pointing at internal networks, localhost or private IPs are rejected.
POST /nap-check/api/check with JSON ({"urls": ["https://example.com/", "https://example.com/company/"]}; up to 3, same origin) or a form body and you get the same comparison back as JSON.
Keeping the business name, address and phone number written the same way across your pages, your structured data and outside listings saves everyone who checks them a step. If you would like us to unify the details across a site or set up its structured data, get in touch.
See First CH SEO support (local listings and structured data)