Establish which organisation the website represents
Organisation structured data should identify the actual publishing or operating organisation, not create a fictional business entity around a personal website. Start by establishing the public trading identity, any distinct legal identity and the relationship between the business and named professionals. A sole practitioner’s name and a registered company are not automatically interchangeable.
The Schema.org type is spelled Organization, even in a British English implementation guide. Select a more specific subtype only when it accurately describes the entity. A remote consultancy does not become a physical local business simply because local search presentation appears attractive. Business reality should determine the type and properties.
Google recommends placing organisation information on the homepage or a single page describing the organisation, rather than requiring a full definition on every page. Use the structured data planning framework to establish the purpose and owner first. The objective is a coherent public identity, not a graph made impressive by unsupported administrative detail.
Build a verified public identity checklist
Collect the approved public name, canonical website URL, public logo, relevant contact details and confirmed identity links. Where a legal name differs from the trading name, record the distinction and its source. Check each proposed administrative identifier against an authoritative record before publication. Omit information that is unknown, private or irrelevant to the page.
The evidence checklist should include the visible supporting page, business record owner, review date and update trigger for each mutable value. A contact number needs an operational owner; a logo needs an approved asset location. Copying a previous site’s markup is not verification, especially after a rebrand, acquisition or change of legal structure.
Keep the scope proportional. Google’s general Organization guide has no universally required properties; it recommends including applicable information. More specialised features can introduce their own requirements. Do not invent a founding date, registration identifier or postal address to fill a generic template. A smaller verified record is easier to maintain than a comprehensive-looking but unreliable one.
Separate the business, the website and its people
Model the organisation independently from the WebSite and from the people associated with it. The business can publish an article; a person can author it. A profile page can describe the person rather than the business. Explicit relationships are clearer than assigning every role to a single node with one overloaded identifier.
Use a stable absolute organisation identifier and reference it consistently where the organisation genuinely has that role. Define a convention that survives ordinary page-title changes. Decide which record owns the full public definition and which templates only need a relationship. Repeating accurate data is possible, but uncontrolled duplication makes drift harder to diagnose.
The Person structured data guide explains how to handle authors and professional profiles separately. Do not assert employment, founder status or membership without evidence. A person writing on a website does not alone establish a legal employment relationship with its publisher, and shared branding does not make a person and organisation the same entity.
Select meaningful names, URLs, logos and contact fields
Use name for the recognisable public organisation name. Add legalName when an applicable legal name differs and is appropriate to publish. Use url for the organisation’s public website, and sameAs only for destinations that identify that same organisation. A directory category, partner website or article mentioning the business is not automatically an identity link.
A logo value should identify the approved organisation logo, not a staff portrait or a decorative banner. Check the current Google guide for image requirements and ensure the resource is available at the supplied address. A correct URL string is insufficient if the asset is blocked, redirects unexpectedly or has been replaced by an unrelated file.
Publish contact and address information only when it is relevant, accurate and approved for public use. Distinguish customer contact from internal administrative details. If several departments have different contact points, model those roles deliberately rather than duplicating numbers without explanation. Review ownership whenever operations or public contact arrangements change.
Keep generation deterministic and business records current
For a static PHP implementation, generate the organisation block from one approved public record. Avoid embedding old names and contact details directly into many template files. Use a proper JSON encoder and check the HTML embedding boundary. The JSON-LD guide explains why ordinary punctuation and closing-tag-like values need reliable serialisation rules.
Inventory other output sources before deployment. A plugin or tag manager can emit an older organisation definition after the server has already supplied the new one. Compare raw response and rendered output so duplicated ownership becomes visible. Do not remove an entire plugin until its other responsibilities have been identified.
Define update propagation. A rebrand should update the visible homepage, about page, organisation record and logo reference through an agreed release. Retain an audit note explaining which public facts changed. Deterministic generation cannot establish that business information is true, but it can prevent separately maintained versions from diverging after the approved record changes.
Illustrative worked example: a trading name changes
Consider a fictional consultancy, Northbridge Search Studio, whose approved trading name changes while the legal entity remains the same. This example illustrates a release decision and does not describe a real company or search outcome. The evidence pack contains the approved new public name, unchanged legal name, current website and new logo location.
The organisation record keeps its stable identifier. The name changes to the approved trading name; legalName retains the verified legal name where applicable. Existing author references continue to point to separate Person nodes. The team does not create a second organisation merely because the display name has changed, nor claim a merger that did not occur.
The reviewer checks the homepage, about page and representative article output for consistent identity. A plugin still emitting the old name is identified and corrected. Acceptance requires factual consistency and reachable public assets. It does not require a knowledge panel to appear, a displayed logo to change immediately or any measured improvement in ranking, indexing or AI citations.
Investigate identity conflicts and missing logo presentations
If a displayed business identity appears wrong, keep competing hypotheses open: the website publishes inconsistent facts, an old crawl reflects the previous name, another source describes a different organisation or Google has chosen a presentation outside the markup’s direct control. Begin with your own delivered output, because that boundary is inspectable and correctable.
For a missing logo, check the supplied resource, ownership, accessibility and current feature guidance. A staff portrait used as logo is a modelling problem; an unavailable asset is a delivery problem. A valid, accessible logo still does not guarantee a particular search display. Do not repeatedly alter identity details simply to provoke a visual change.
Use structured data validation to compare extraction and supported feature requirements. If tools disagree, preserve their inputs and scope. Schema.org validity, factual accuracy and Google presentation are separate observations. A consistent website can reduce its own ambiguity without controlling how every external system reconciles organisation information.
Specify factual and technical acceptance criteria
Require the approved public name, intended identifier and website URL to match the identity brief. Every emitted property needs a verified source and correct vocabulary meaning. Optional fields may be omitted when information is unavailable. Applicable subtype or feature requirements must be checked separately rather than imported from a generic checklist for every organisation.
Test the homepage or chosen organisation page, a representative article and any template with another generator. Confirm no obsolete name, contact point or logo survives in rendered output. Check public asset responses and compare visible attribution with graph relationships. A code-only test leaves deployment and resource accessibility unverified.
Assign an operational owner for future changes and record the accepted omissions. Include multilingual or regional variants where they actually exist, preserving the same entity identity when appropriate. Release acceptance should be a reviewable set of facts and outputs, not a promise that a search interface will display a particular name, badge or logo after deployment.
Recover safely after rebrands and identity releases
Archive the previous generator and approved record before changing public identity output. If deployment breaks the JSON or introduces unsupported claims, restore or disable the responsible output and verify the response. Distinguish code rollback from business-data rollback: an old encoder may still be usable, while an old phone number or legal name may no longer be correct.
Cache invalidation and external tag containers can leave mixed versions visible after recovery. Check the actual public HTML and assets rather than assuming a successful deployment restored consistency. The schema deployment guide provides a broader release process and evidence standard.
Organisation markup does not establish legal status, verify every affiliation or guarantee a knowledge panel. It cannot promise rankings, indexing or AI citations. Maintain it as an accurate public description with clear review triggers: rebrands, contact changes, entity restructuring and asset migrations. The practical acceptance test remains whether the website expresses the intended current organisation coherently and truthfully.
Frequently asked questions
Is an address required for every organisation graph?
Not under Google’s general Organization guide, which lists applicable recommended properties rather than universal required fields. A specific subtype or feature may have additional requirements. Do not publish a private or invented address to complete a generic template; review what the actual entity and intended feature need.
Should a consultant always use LocalBusiness?
No. Choose a type that accurately represents the business. A professional providing remote services should not invent a public premises or local operation to fit a feature. If a genuine local business model applies, review the relevant subtype and its separate current Google requirements.
Can name and legalName be different?
Yes, when the public trading name differs from the verified legal name. Keep the distinction intentional and supported by approved records. Do not use legalName for an old brand simply to preserve keywords or imply a legal identity that the organisation does not have.
Should the organisation block appear on every page?
Google recommends the homepage or a single page describing the organisation, such as an about page. Other content can reference the same organisation where appropriate. The implementation should preserve coherent identity without creating multiple independently maintained definitions that drift after business changes.
Does valid organisation markup guarantee a knowledge panel?
No. It supplies explicit information but does not control Google’s presentation or establish external recognition. Verify the public facts and technical delivery independently. Treat changes in displayed business identity as observations to investigate, rather than a guaranteed response to adding more properties.