---
name: ensure-nap-consistency-across-platforms
description: "Check your name, place and phone on the web. Fix old facts so people can reach you."
category: Digital Plumbing
stage: —
definitive_article: /digital-plumbing
status: needs-work
---

# Ensure NAP Consistency Across Platforms

Old phone numbers can send people to the wrong place. This guide helps you keep your name, place and phone right on the web. Start with the facts for each shop you own.

**The path:** Trusted facts → Profile list → Scoped fixes → Public comparison.

**Use this when:** a business changes its name, location or phone, takes over old profiles, or finds conflicting public facts.

## Inputs
- An owner-backed identity record for each branch: public trading name, address or service-area policy, phone, website and supporting evidence.
- The in-scope website and profile URLs, with actual editing access or a responsible owner for each.
- Known legitimate differences such as branch numbers, approved call tracking, character limits and hidden service-area addresses.

## First-run prompt

> Compare the supplied public profiles with the business fact record. Fix true conflicts within scope and record legitimate platform differences. Keep private addresses private. Do not force every branch or tracking number to match one universal string.

## Steps
1. Write the trusted name, address and phone record. These facts are often called NAP. Use current business evidence and the owner’s confirmed public details; an outdated Google listing is not automatically the truth.
2. Separate distinct locations, brands and people before comparing. A second real branch may need a different phone or address. Identify the canonical website and proper profile for each entity.
3. List the actual surfaces in scope: website header/footer/contact/schema, Business Profile, social Pages and other important maintained listings. Record public URLs and who can edit them; missing access is a specific dependency.
4. Compare facts, not just characters. “Street” and “St” can describe the same address, while a wrong suite or disconnected phone is a real defect. Record acceptable formatting differences instead of generating cosmetic change work.
5. Preserve privacy and eligibility rules. A service-area business may hide its address on Google; do not publish a home address across the web just to make fields look identical. Apply the appropriate public facts on each platform.
6. Update true mismatches through each supported source within current authority. Preserve legitimate dynamic call-tracking behavior and record its relation to the stable business number. Do not change an authentication or recovery contact because a public phone changed.
7. Read back the public fields after save. Some platform edits are reviewed before going live; record submitted, pending and publicly visible states separately. Check structured facts and contact links alongside visible text on the website.
8. Save a platform-by-field comparison with evidence dates and next owners. Route the remaining exact mismatches, not a vague request to fix all listings. Keep old evidence for the run record while updating the maintained identity source.

## Definition of done (QA checklist)

- [ ] A trusted fact record exists for each real business or branch in scope.
- [ ] All scoped surfaces were compared, with legitimate formatting and privacy differences explained.
- [ ] Incorrect facts were fixed and read back, or carry exact pending state and owner.
- [ ] Tracking and private account contacts were not confused with public business identity.
- [ ] The record links to current public proof without claiming universal web-wide consistency.

## Example(s)

**Fictional teaching example.** Oak Repair’s owner confirms its new shop at 14 Cedar Street. The website says “14 Cedar St,” which is the same address. Facebook still says “41 Cedar Street,” a true conflict. The guide changes the transposed number and keeps the harmless abbreviation. A service-area sister business has a hidden home address, so its blank public street field is marked intentional. The comparison teaches factual consistency rather than a character-matching score.

## Handoff and Content Factory context

Give the maintained identity record to the profile and site owners. Use [add schema markup person localbusiness](https://local-service-spotlight.github.io/task-library/?task=add-schema-markup-person-localbusiness#task-add-schema-markup-person-localbusiness) if machine-readable facts still conflict, or [verify google business profile](https://local-service-spotlight.github.io/task-library/?task=verify-google-business-profile#task-verify-google-business-profile) when Google ownership or verification needs work.

This setup supports the [Content Factory](https://blitzmetrics.com/content-factory/). Produce gathers real source material; Process makes useful assets; Post places and checks them; Promote distributes suitable work within its own scope. This check does not automatically execute all four stages. Use the actual next step above; catalog neighbors are not prerequisites.

## When this runs

Run after a real identity change and when a discrepancy appears. Optional periodic reviews should use the approved profile list and a real schedule; no automatic edits to unrelated accounts follow.

## First-run setup and continuity

Open the supplied task file and its linked source. Verify the project’s real inputs, account, access and output folder before work. This Markdown file is a guide; it does not install an app, connect an account, supply a subscription or create a schedule. Carry out work already authorized; do not ask for the same approval again. Keep any unsupplied destination or new action outside that scope clearly pending.

Save source IDs, versions, decisions, checked outputs and next owner in the project tracker. Before a retry, check the saved state and other workers’ changes. A model name does not guarantee memory or a running timer. Repeated work needs an actual configured trigger and durable state; one-off work can be started by the prompt above.

Keep agent media muted with volume zero before playback. If mute cannot be verified, use captions, metadata or still frames. State the limit: silent visual checks do not prove spoken-word accuracy or audio quality. Do not start sound through the user’s speakers unless explicitly asked.

## Write up the real run

For every actual attempt, [write its meta article](https://blitzmetrics.com/meta-article-prompt/) with this recipe and revision, trigger, steps performed, output evidence, measured result, gaps and next owner. Failed, blocked and partial attempts also get a written record. A draft can satisfy writing; publishing it follows the existing job scope.

Keep one stable execution ID across retries and edits. A separately scoped child task may have its own ID linked to its parent. Writing the parent’s meta record is part of that run, not an endless new chain. The [recipe and meta-article guide](https://localservicespotlight.com/meta-articles/) explains this distinction. Teaching examples are not real executions and must not enter the run count.


<!-- factory-layer:start -->

## Factory chain (do not treat this as isolated)

- **Phase:** Gate
- **Importance:** 2/5 `●●○○○` — frequency 2, revenue 2, gating 2 (supporting)
- **Suggested previous station:** —
- **Suggested next station:** —
These stations are generated neighbors, not verified prerequisites or handoffs. Follow the task’s actual Inputs and Handoff sections.
- **Handoff:** Record only the property IDs, access and checks required by this task in the client register. Pass the verified result to the task that needs it.

## Model routing (same factory, any engine)

- **This task's lane:** `any` — Any capable chat model (Claude, ChatGPT, Grok, Gemini). SOP following, drafts, checklists.
- **Single-engine path:** Use the capable AI app you already have. Check its required tools and access before starting. Pass the actual result and proof to the next task.
- **Optional multi-engine:** A tested local model may draft; a stronger model may review facts and voice. Use supported tools for approved actions. Pick models from observed quality and cost; a model name does not prove it can run this task.
- **Never** store the working state in one vendor's memory. Files in the Content Library are the bridge.

<!-- factory-layer:end -->
## Definitive article & links

- Canonical article: https://blitzmetrics.com/digital-plumbing
- Exact task: [Ensure NAP Consistency Across Platforms](https://local-service-spotlight.github.io/task-library/?task=ensure-nap-consistency-across-platforms#task-ensure-nap-consistency-across-platforms)
- Writing standard: [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Digital Plumbing training](https://blitzmetrics.com/digital-plumbing/)
- [Entity linking](https://blitzmetrics.com/entity-linking/)
- [Google business representation rules](https://support.google.com/business/answer/3038177?hl=en)

## Review and evidence still needed

The source contributor status is preserved. It is not certification of this draft or proof of account access, completed work or a live outcome. The worked example teaches the method and is explicitly fictional.
- The owner-backed facts and complete in-scope profile list are required. This draft does not claim a web-wide citation cleanup.