Keep one business identity across conflicting structured-data blocks

Inventory every source of the business description

Inspect the public homepage and two representative service pages. List each JSON-LD or other structured-data block, the entity type, identifier, name, URL, telephone, and publisher source when you know it. Themes, SEO plugins, and custom snippets can all emit overlapping descriptions. Do not delete everything because a test shows several items; some legitimately describe different objects.

Source checks: W3C: JSON-LD 1.1 node identifiers · Google Search Central: Organization structured data · Google Search Central: LocalBusiness structured data

Distinguish the business from its pages

An Organization describes the organization; a WebPage describes a specific page. A real separately represented business location can also need its own identity. Write this distinction in the brief before selecting identifiers. A service page should not redefine the business as a new organization just because its title or city differs from the homepage.

Choose stable identifiers for the real entities

In JSON-LD, @id identifies or references a node. Agree on a consistent business identifier, such as the illustrative https://example.com/#business, and separate page identifiers where used. This is a site-data convention, not an instruction that Google must display a feature. Use identifiers consistently through supported plugin or code settings rather than inserting keywords into each one.

Resolve conflicting facts and emitters

Review the inventory with the website editor.

• Identify whether overlapping blocks describe the same entity or legitimately different ones.
• Select the controlled source for the business name, URL, and public contact details.
• Align references to the agreed business identifier where the implementation supports it.
• Remove redundant conflicting custom output rather than masking it with another block.
• Retest public markup on the homepage and service templates.
• Keep distinct real locations separately described when appropriate.

Avoid imaginary location entities

Do not create a separate LocalBusiness for every city the business serves or invent addresses to populate required fields. Likewise, a plugin's validator does not confirm that facts are true or that a knowledge feature will appear. If an address is intentionally not public, review the specific markup eligibility and privacy decision instead of importing a sample address.

Maintain a small entity map

Store entity, identifier, emitting component, approved fields, and last checked date. Use this map when changing a plugin, template, domain, or contact number. The direct result is coherent machine-readable identity and fewer contradictions, not a guaranteed knowledge panel or ranking improvement.

For a domain change, review identifiers and references as a planned migration task. Do not automatically keep an unreachable old identity URL or create a second business without documenting the relationship. Ask the technical owner to verify the generated graph alongside ordinary customer-facing contact information so both forms remain consistent.

Illustrative theme and plugin disagreement

An illustrative site has a theme Organization at https://example.com/#company and a custom LocalBusiness at https://example.com/repair#business, both describing the same company but with different phone numbers. The editor establishes one approved business identity and aligns the supported references, while the repair page retains its own page identity. The fix corrects a contradiction; it does not manufacture a new location.

The approved entity map distinguishes business identity from the repair page even when both are described in one graph. Future contact-number edits update the controlled facts rather than adding a third competing business block.

Questions about this task