sameAs and Official Social Profile Links

Identity is a narrower claim than relevance

Schema.org defines sameAs as a reference page that unambiguously identifies the entity. An official business profile can qualify. A news story discussing the company, a supplier website, or an interesting industry resource does not become the company itself. Related pages can use ordinary editorial links without being asserted as identity equivalents.

Think about the subject of each node. A company social account should not be attached to an author Person just because the founder controls both accounts. A personal professional profile should not be presented as the company identity. Keep the relationships truthful and use separate entities where the subjects differ.

Verify each profile before publishing it

1. Open the exact profile URL and confirm that it resolves to the intended entity, not a platform homepage, search result, expired account, or renamed handle.
2. Compare the displayed name, official website, branding, and business context. Similar names alone are weak evidence of ownership.
3. Confirm the destination with the account owner or another reliable business record when ownership is uncertain. Do not infer control from a matching logo.
4. Check whether the URL points to a person, organization, branch, product, or community. Match it to the correct node.
5. Record the verified profile URL and verification date in an internal register. Avoid sharing account credentials or private account details in the public markup.

Visible links and structured references serve different uses

A visible link helps a visitor reach a useful official account. A sameAs value is a machine-readable identity assertion. One does not automatically create the other, and neither should be filled with guesses merely to satisfy a count. Use descriptive accessible names for visible icon links so a keyboard or screen-reader user can understand the destination.

If the website already provides useful profile links, keep them current and verify that they belong to the same business. A genuine business without public social accounts does not need fabricated ones. An unresolved official-profile set should remain an internal decision rather than appearing as placeholder URLs in active structured data.

An illustrative identity reference

The domains and profile path are illustrative. Replace them only with independently verified identity pages in a real implementation. This escaped example is not active JSON-LD and does not establish that an official N8 profile has been approved.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Studio",
  "url": "https://example.com/",
  "sameAs": ["https://example.org/official-profile"]
}

Repair the reference set

1. Inventory the existing sameAs values and visible official-profile links. Keep a copy of the current entity output before editing.
2. Remove malformed or unrelated identity assertions. Retain ordinary editorial links where they remain useful and accurately described.
3. Update renamed or moved profile URLs to their verified final destinations. Check that the platform still represents the same entity.
4. Separate person and company references. Link a real founder relationship through suitable properties instead of merging identities.
5. Update the actual structured-data owner and any visible icon module separately when both need correction.
6. Validate the public entity graph and test each visible destination. Record unresolved ownership questions without inventing replacement accounts.

Joomla and WordPress checks

Joomla

Inspect the organization markup owner and the module or particle that renders social icons. They may use different configuration fields. Verify that the same profile set is attached to the correct entity without assuming that a theme icon automatically populates JSON-LD. Keep menu and article routing unchanged while repairing identity references.

WordPress

Review the active SEO plugin entity settings, author profile data, theme icons, and any schema plugin. A user-profile social field may describe an author rather than the business. Test public output after updating the responsible field; a saved URL in a settings form is not evidence that the intended graph uses it.

Common mistakes worth catching

An organization node containing the founder personal account is a subject mismatch. A sameAs value pointing to a social-network homepage does not identify the company. A review article about your service is useful coverage but is not automatically an official identity page. A broken old handle can point to another owner after reassignment.

Do not inflate the array with dozens of loosely related accounts. Keep a small, defensible set and document why each reference identifies the entity. If a multi-location business maintains genuine location-specific accounts, attach them to the correct branch records rather than indiscriminately repeating every account on every location.

Verify accuracy over time

Inspect the final public JSON-LD and confirm that the correct node carries the intended URLs. Open each URL while signed out where practical and check its final destination. Test accessible names and keyboard focus on visible links. Schema validation can catch structural problems, but it cannot establish who owns an account.

Rescan the representative pages and compare the observed reference set. Recheck after rebranding, ownership transitions, account renames, or platform changes. Keep the internal register useful for future maintenance. If identity information remains inconsistent, review business entity markup and visible authorship and business information together.

Primary references

Use these first-party references for the technical definitions and platform behavior discussed in this guide.

• Schema.org: sameAs
• Google Search Central: Organization
• Schema.org: Person
• Schema.org: Organization