Check whether website code exposes an address hidden on your profile

Define the public information you actually approve

Create a short approved-public-details sheet: business name, contact methods, service areas, and any genuinely public customer location. Do not place the private street address in a public audit example. The website and profile can have different publication mechanisms, so verify both rather than assuming one setting controls the other.

Source checks: Google Search Central: LocalBusiness structured data · Google Search Central: Organization structured data · Google Search Central: Block indexing with noindex

Inspect more than the visible contact paragraph

Search the public homepage, contact page, footer, and service templates. Ask the editor to inspect page source and rendered JSON-LD for address and geographic-coordinate fields. Review embedded maps, downloadable documents, and widgets that may import old details. A hidden code block remains publicly retrievable even if no visitor sees it in the design.

Trace the address to its publishing source

Find whether the value comes from a theme, SEO plugin, CMS record, booking service, or map embed. Correct the approved public record there so the next publish does not restore it. Use a controlled account with the appropriate editing permissions. Keep a dated record of what component changed without redistributing the address through screenshots or shared notes.

Choose truthful markup instead of an invented substitute

Review the business-data format with the editor.

• Remove intentionally nonpublic address fields from public output where appropriate.
• Do not substitute a fake street, virtual office claim, or customer address.
• Check Google's LocalBusiness rich-result requirements rather than assuming incomplete output remains eligible.
• Consider accurate applicable Organization information where supported; it has different documented requirements.
• Retest rendered code, visible pages, and relevant embeds.
• Check other templates that share the same business record.

Keep privacy and feature eligibility separate

Google's LocalBusiness feature documentation requires a physical address for that feature's eligibility. That is not a reason to publish an address the business has chosen to keep nonpublic or fabricate one. General accurate organization information is a separate implementation decision. Noindex is an indexing instruction and does not make public code private.

Retest after account and template updates

Confirm the current public output no longer publishes the intended nonpublic details from the repaired sources. Previously copied third-party records may require separate review; do not promise that a website edit erases every historic copy. Add this public-output check to future migrations and plugin changes.

Ask anyone producing new contact PDFs, maps, or brand materials to use the approved public-details sheet. This prevents an old onboarding document from becoming the source of a new public embed. Record the asset owner and last reviewed date so the audit covers the website's actual publication paths, not only its primary contact page.

Illustrative hidden field in a theme's JSON-LD

An illustrative mobile repair business displays only its service areas, but an old theme setting emits a streetAddress in homepage JSON-LD. The editor removes that intentionally nonpublic field from the public generator and reviews truthful organization markup. No replacement office is invented, and no private address appears in the example or repair brief.

The public-output check includes a current contact page, homepage JSON-LD, and the old map embed. The owner records only whether each repaired source still exposes an intentionally nonpublic field, without putting its actual value into a publicly shared checklist.

Questions about this task