Profile and Organization Structured Data: Keep Identity Facts Visible, Factual and Owned

What counts as a profile page?

A profile page is a page whose primary subject is one person or one organization associated with the wider website. That sounds simple, but many sites mix an author byline, an about paragraph, a company logo, a service offer and a contact route in the same template. The first review question is therefore not “which schema type can the plugin add?” It is “what does a visitor believe this page is about?” Google describes ProfilePage markup for pages focused on a person or organization, including an author page, an employee page, an about-me page or a user profile. The visible purpose should lead the representation, not the other way around.

This distinction matters because an article can name an author without being a profile page. The article’s main subject remains the article, while the author identity is a relationship that may point to a separate, genuine profile page. A homepage can identify a business without being a personal profile. A contact page can contain organization details without becoming a separate branch location. A short “about our team” section can be useful visible copy without supporting a ProfilePage object. Treating every identity mention as a profile creates a less defensible model and makes future corrections harder.

Google’s ProfilePage documentation says the primary focus must be a single person or organization affiliated with the overall website. It gives user profiles, author pages, about-me pages and employee pages as examples, while warning against pages whose main focus is something else. [1] The practical test is to remove the markup mentally and read the page as a person would: is there one subject, a coherent identity, supporting facts and a stable public URL? If the answer is no, improve the page purpose or leave the specialized representation out.

Choose the page’s main subject

The Organization documentation approaches the same problem from the organization side. It recommends placing organization information on the homepage or a single page that describes the organization, rather than repeating a full identity record on every article. It also recommends choosing the most specific subtype that actually matches the organization and including only properties that apply. [2] “More fields” is not the same as “better information.” A business should publish the name, URL, logo, contact details or address it can verify and maintain, not every field available in a plugin interface.

A reliable review begins with page purpose. Put the public URL in a worksheet, write one sentence describing what a visitor should learn there, and identify the entity that sentence names. Then classify the page as a person profile, organization page, article, service page, contact route, or mixed section requiring clarification. This is a content decision before it is a markup decision. If a page contains two equally prominent people, a company and several offers, it may need clearer information architecture rather than an ambitious identity graph.

The primary entity is the subject the page is about, not necessarily the website owner or the person who edited the template. On a genuine author page, the mainEntity can be a Person. On an organization description page, it can be an Organization or an applicable subtype. On an article, the Article remains the principal content object and an author relationship can identify the contributor when the page visibly supports it. This distinction prevents an organization from being silently attached as the main subject of every unrelated page.

Apply the visible-page test

Use the visible-page test for each identity fact. A public reader should be able to find the meaningful name, role, image, profile relationship or organization detail in the page experience. Google’s structured-data guidance warns against marking up information that is not visible to users or creating empty pages merely to hold markup. [1] The test does not require showing raw JSON-LD terminology. It requires that the underlying fact—such as a person’s name or an organization’s public logo—has a visible, supportable home and is not only present in a hidden field.

The source-and-owner ledger is intentionally small. For every property, record the plain-language fact, the visible support, the approved source, the person or team allowed to confirm it, the markup property, the last review date and the trigger that requires another check. This is different from a broad plugin checklist. It gives an editor a reason to omit a field when its source is uncertain and gives a maintainer a clear path when a name, role, image, URL or contact route changes.

Build the identity ledger

Names deserve special care. Use the public name by which the person or organization is actually identified, and keep spelling, capitalization and punctuation consistent with the visible page. An alternateName or handle can be useful when it is a genuine public identifier, but it should not be a keyword list. For an organization, the public name should correspond with the site identity and approved business record. Do not add a legal name, trade name or abbreviation merely because it may sound authoritative. If two names are both used, explain the relationship visibly before modeling it.

Identifiers are optional facts, not decorations. A profile platform may use an internal identifier that remains stable when a handle changes. A business may have an applicable public identifier, but a private account number or guessed registry code is not suitable page content. Record the source and purpose before including one. If the identifier cannot be explained to a reviewer and tied to the subject of the page, leaving it out is safer than publishing a mysterious value that future editors cannot maintain.

Images connect identity and representation. A profile image should represent the person or organization named by the page, be publicly reachable and be served from a durable URL. Google’s guidance also describes image quality and crawlability considerations. [1] A logo should be the organization’s representative mark and should remain legible on a plain background. Do not use a generic stock image as a person’s portrait, a decorative hero as a logo or an image whose ownership and subject cannot be confirmed. The visible image and the structured image property should describe the same thing.

Review sameAs, images and dates

sameAs links are relationships, not a place to collect every mention of a brand or person. Include an external profile or home page only when it is genuinely associated with the subject and can be reviewed. Confirm that the destination identifies the same person or organization, uses the intended public URL and does not redirect to an unrelated campaign, directory entry or temporary page. A shorter list of verified relationships is more useful than a long list assembled from guesses. The owner should know who can remove a link when an external profile changes.

Dates on a profile page need a clear meaning. ProfilePage guidance describes dateCreated and dateModified as applicable properties, with dateModified ideally representing human-edited profile information. [1] Do not use a recent template deployment, an automated cache timestamp or a date on an unrelated article as the person’s profile modification date. If the site cannot distinguish a meaningful identity update from a system event, omit the date or document the limitation rather than presenting false precision.

An author relationship should be visible and honest. If an article displays “By Alex Morgan,” the site should be able to identify Alex as a real contributor and, where applicable, link the byline to a stable profile page. The profile should not claim credentials, employment or first-hand experience that the business cannot verify. A generic editorial label such as “SEO team” should not be turned into a fictional person. When an article has multiple contributors, keep the visible attribution and the underlying relationships aligned instead of assigning one convenient name to every page.

Connect people to articles honestly

A profile page can include recent activity, but activity does not replace identity. Google’s examples show how articles or other objects can reference a profile entity, while the profile itself remains about the person or organization. [1] Keep the full article content on its article URL and let the profile summarize the person’s real public role. Do not copy entire articles into a profile only to create more markup. The page should be useful to a reader who wants to understand the subject, not merely to a crawler looking for a larger graph.

Organization pages require the same discipline. Start with the visible organization name and public URL, then review applicable logo, contactPoint, email, telephone, address, description and other administrative properties. Google says there are no required Organization properties in its general documentation; properties should be included when they apply. [2] That boundary is valuable for a small business operating globally or remotely: do not invent a storefront, local address, opening hours or service area. If a detail is not applicable or cannot be maintained, it should not be represented as though it were.

Contact information is operational information. A public email address should be monitored or intentionally described; a phone number should include the appropriate country and area context; an address should reflect an applicable physical or mailing location. If the organization does not receive visitors at an address, do not imply that it does. If a contact point is only for a particular purpose, make that purpose visible. Structured data should clarify the page’s public facts, not silently expand the business’s claims.

Keep organization facts applicable

Logo consistency is a small but important identity check. Compare the visible header or organization page with the image used in the delivered representation. Confirm that the URL is public, the file is supported, the image is not blocked and the mark is recognizable on a light background. Google’s Organization guidance includes a minimum logo size recommendation and cautions that the image should look as intended on white. [2] Those are review conditions, not a promise about a knowledge panel or a particular visual treatment. Record what was observed rather than predicting what Google might display.

The delivered-page inspection is the final technical layer. View the public HTML, locate the JSON-LD or other markup, parse it, and compare its primary entity, URLs and values with the visible page. Check that a template or plugin has not added a second organization with conflicting names, logos or URLs. Check that a profile URL is canonical and that sameAs destinations are not stale. A green syntax test cannot prove that the page’s facts are true, current or appropriate for its subject.

When a conflict appears, correct the source of truth before adding another schema block. If the visible name is current but the markup is stale, identify the component that owns the markup and update it through the site’s controlled workflow. If the markup is accurate but the visible page is vague, clarify the page copy. If two systems describe the same organization differently, choose one accountable owner and remove the contradiction. Do not conceal a content or identity problem by layering a third representation over the first two.

Inspect the delivered representation

A profile-page review also needs an exclusion list. Do not make a profile page from an empty author archive, a generic staff grid with no individual pages, a company review page about an unrelated organization, a homepage whose main purpose is selling products, or a page whose only identity fact is a logo in the header. Do not use interaction statistics unless they are genuine, attributable to the hosted platform and appropriate for the subject. Do not add sameAs links simply because a search result mentions a similar name.

The maintenance trigger is often more important than the first implementation. Review a profile when a person changes role, an author stops contributing, a business changes its public name, a logo is replaced, a contact route moves, an external profile is removed, a template changes or a page is migrated. Record the date and the public evidence. A profile that was accurate at launch can become misleading later without any code error. Ownership turns identity data into a maintained editorial responsibility rather than a one-time technical task.

A compact handoff can be completed in six questions: what is the page’s main subject; where is the visible supporting fact; which Person or Organization type applies; who owns the source; which public URLs and images were checked; and what changed after delivery? If any answer is unknown, pause the specialized markup. The correct next action may be to improve the page, repair a source record, remove a stale property or retain ordinary article markup. A smaller truthful representation is preferable to an elaborate unsupported one.

Know what not to model

The final review should separate observation from interpretation. “The page contains one visible organization name and a public logo URL” is an observation. “Google may independently select a logo representation” is a prediction and should not be written as a deliverable. “The profile page has a valid mainEntity property” is a technical observation. “The page has a certain rich-result treatment” is not a defensible conclusion. This separation keeps editorial work honest and gives future maintainers a record they can reproduce without relying on assumptions about Search behavior.

ProfilePage and Organization markup can be useful when the page genuinely describes a person or organization and the representation matches visible, maintained facts. It is not a substitute for a clear page, a verifiable identity or an accountable content owner. Start with the reader’s understanding, use only applicable properties, link real relationships, inspect the delivered output and record what was checked. Those habits produce a more durable public identity record while respecting the boundary between what a site controls and what Google independently decides.

A useful failure diagnosis starts with the public page rather than the markup panel. If the page title names a person but the body contains only a generic company pitch, the page purpose is unresolved. If the profile image is broken, the first fix is the public asset path, not another image property. If a sameAs destination identifies a different person, remove or correct the relationship. If the organization name differs between the header, about page and delivered data, choose the approved source and make the visible record coherent before testing syntax again.

The handoff should leave enough context for someone who was not present at launch. Store the reviewed URL, the page-purpose sentence, the primary entity type, the properties accepted or omitted, the sources checked, the owner and the next review trigger. Note whether a change was visible to readers, whether the delivered markup matched it and whether any uncertainty remains. This record prevents a later editor from treating an old implementation as an instruction to repeat every property forever.

A profile-specific review is also a useful restraint on automation. Templates can repeat a logo, author reference or organization object across many pages, but repetition does not make a fact applicable to each page. The owner should understand which values are global, which belong only to a profile and which must be supplied by an individual contributor. When a system cannot express that distinction cleanly, ordinary visible links and honest page copy may be the better implementation.

The distinction between a page being technically accessible and a fact being appropriate is important. A crawler may be able to fetch an image or JSON-LD block, yet the page may still lack a visible explanation of who the subject is. Conversely, a page may clearly identify a person while a template omits the relationship from the delivered markup. Treat these as separate observations and document the correction that addresses the actual problem.

Before closing the review, ask another editor to read the page without opening its source. Ask who the page is about, what relationship the person or organization has to the site and which facts seem current. Then compare those answers with the ledger and the delivered representation. A second reader can surface ambiguity that a property-by-property technical inspection misses, especially when a page has accumulated old names, multiple logos or inherited author labels.

Keep the release record readable to a future editor. Include the final public URL, the page purpose, the accepted entity type, the visible evidence for each material property, the external destinations reviewed, the date of the inspection and the owner responsible for follow-up. If a property was intentionally omitted, record that decision and its reason. A clear omission is easier to maintain than a silent field that later appears authoritative only because a plugin preserved it.