An entity is just a thing the system is trying to identify
An entity is a distinct thing: a business, person, place, service, product or policy.
A relationship connects two things. A founder runs a company. A company offers a service. A clinician works at a practice. A product has a price and return policy.
A knowledge graph is one way to store those things and relationships. That is a useful technical definition. It does not prove that Google has created a specific record for your business, that the record is correct or that an answer product will name you.
For an owner, the practical questions are simpler:
- Is the business named clearly?
- Can a buyer tell what it actually offers?
- Are the people and locations real?
- Do the website, profiles and feeds agree on material facts?
- Is there a clear page where each fact can be checked?
- Is the next step obvious?
Mindflow Marketing uses entity work to remove factual confusion. We do not sell a secret switch into a Knowledge Graph.
The AI Search Guide explains the wider system. How AI Search Works explains why access, retrieval and synthesis remain separate from factual clarity.
Start with one governed business record
Before correcting ten public pages, decide which internal record owns each fact. That record should be factual, approved and maintained. It is not a block of marketing copy to paste everywhere.
| Fact | Primary owner | Public page or system | Do not invent |
|---|---|---|---|
| Legal business name | Official registration and company records | Legal/footer details where relevant | A marketing alias presented as the legal name |
| Public brand name | Approved brand record | Homepage and About page | A keyword-stuffed business name |
| Website and contact | Operating record | Contact page and governed profiles | Tracking numbers presented as the only permanent identity |
| Physical location | Real operating record | Contact/location page and eligible profiles | A virtual office or city address the business does not occupy |
| Service area | Delivery/operations record | Service-area or market pages | Cities the business cannot actually serve |
| People and roles | HR/professional record | Team, founder or provider pages | Credentials, dates or responsibilities without support |
| Services or products | Commercial catalogue | Dedicated service/product pages and feeds | An offer the business does not provide |
| Price and availability | Sales, scheduling or commerce system | Offer page, booking system or product feed | A price or availability that the buyer cannot receive |
| Policy | Approved operating/legal policy | Governed policy page | Terms copied from another company |
Use stable identifiers inside the record where they genuinely exist: product ID, professional licence number, location code or internal person ID. A stable identifier can help avoid confusing two similar names. It should not expose private data or imply a credential the owner cannot verify.
The record also needs an owner. Marketing cannot confirm a clinician’s status, a lawyer’s jurisdiction or a warehouse’s current inventory alone. The person closest to the source approves the fact; the website and profile owners publish it.
Mindflow Marketing uses that governed record as the correction baseline. If no one can verify a claim, we do not turn it into public copy or markup.
Put visible facts before markup
Structured data is machine-readable code that describes a page. Google says it provides explicit clues about page meaning.
For a business, Organization markup can describe applicable administrative details such as the name, URL, logo, contact information and address. Google recommends the most specific type that fits. A real local business may use an appropriate LocalBusiness subtype. An online store may use OnlineStore.
Markup comes after the visible page.
| Sequence | Owner check |
|---|---|
| 1. Verify | Is the fact true, current and approved? |
| 2. Publish | Can a buyer find it on the correct page? |
| 3. Mark up | Does the structured data describe that visible fact accurately? |
| 4. Validate | Is the code syntactically valid and accessible to the relevant crawler? |
| 5. Recheck | Did the platform process the page, and did the visible result change? |
Google’s structured-data rules say markup should be current, relevant and representative of visible content. Correct markup can make a page eligible for certain search features. It does not guarantee that Google will show the feature.
The same limit applies here. No official source reviewed for this chapter says Organization schema guarantees a Knowledge Panel, an AI citation or a recommendation. Google also says its generative Search features do not require a special AI schema.
Do not create an invisible list of cities, people or services in JSON-LD that the page never explains. Do not mark a person as a lawyer, clinician or founder without a governed factual basis. Code makes a claim easier to parse; it does not make the claim true.
Google explains applicable organization properties in its Organization structured-data guide. Its general guidelines require markup to represent visible, current content and state that valid structured data does not guarantee a Search feature.
Connect the real people, places, services and products
One business can contain several different objects. Give each important object a clear page and a truthful relationship to the organization.
| Object | Suitable public owner | Relationship to state clearly |
|---|---|---|
| Organization | Homepage or About page | Public name, purpose, contact and accountable people |
| Founder or professional | Focused person/profile page | Role, supported experience, credentials and organization |
| Location | Real location page | Address, contact, hours and services available there |
| Service | Dedicated service page | Who provides it, for whom, where and what happens next |
| Product | Product page and governed feed | Brand, variant, price, availability and applicable policies |
| Policy | Dedicated policy page | Which organization, service, product or transaction it governs |
Google’s ProfilePage documentation has a narrow use: the page must focus on one affiliated person or organization. A general company homepage is not automatically a profile page. The visible page should do the human job first: tell the reader who the person is, what they are responsible for and why that role matters.
Mindflow provides a real example. The About Mindflow Marketing page owns the company explanation. The Youssef Hodaigui page owns the scoped founder role. One page should not pretend to be both objects at once.
sameAs can point to a page that unambiguously identifies the same person or organization. Use it only when the identity match is real. A trade directory category, an unrelated article or a profile you do not control is not automatically a valid identity reference.
Use relationships to clarify reality, not to create it. A service page can say the company provides the service in a defined market. Markup can describe that page. Neither should claim a location, employee, integration or product that does not exist.
Google defines the valid scope of a ProfilePage and recommends clear creator information in its people-first content guidance. Schema.org defines sameAs as an unambiguous identity reference.
Your public profiles and feeds can disagree with your site
A website is not the only source a platform may use.
Google says Business Profile information can come from:
- the business’s official website and other public web content;
- licensed third-party data;
- owners and other users who contribute facts, photos and reviews;
- Google’s interactions with the place or business.
That explains why fixing the homepage may not immediately fix a map profile. It also explains why an old directory address can keep returning after a move.
| Conflict | Check first | Correct at | Verify after |
|---|---|---|---|
| Wrong brand or site name in Search | Homepage name, WebSite markup and visible references | Homepage/source that carries the wrong name | Recrawl and later Search display |
| Wrong local phone, address or hours | Business Profile and real-world operating record | Profile plus incorrect governed/public source | Profile update status and live listing |
| Wrong service area | Operations record, site and eligible local profile | Site/profile source that overstates coverage | Market page, profile and buyer route |
| Wrong person role | HR/professional record and person page | Person/About page and governed profiles | Visible page and platform profile |
| Wrong product price or availability | Commerce system, feed and landing page | Source system/feed and page | Merchant diagnostics and live product page |
| Wrong shipping or return statement | Approved policy and product/feed fields | Policy owner, site and feed | Checkout path and governed listing |
Google can apply profile updates from other sources. Owners can review some updates and suggest edits when information is wrong. That is not a reason to keep editing the profile blindly. Find the conflicting source and correct the authoritative record.
Ecommerce has an additional data layer. Merchant Center uses defined attributes for product identity, price, availability and other facts. Google also requires basic, verifiable merchant and customer-service information. Feed values and landing pages should agree because the buyer needs the same product after the click.
Mindflow Marketing maps the source, owner and correction path before changing copy. “Make every mention identical” is too simplistic. A legal name and public brand can differ legitimately. A mailing address and service area can differ. The material meaning must be accurate and the relationship must be clear.
Google lists the inputs to Business Profiles in Business Profile Help and explains external profile updates. Merchant Center documents required product attributes and verifiable merchant information.
Reviews corroborate experience, not every business fact
A real review can describe what a customer experienced. A collection of current reviews can help a buyer understand service, communication, product fit or recurring problems.
A review does not establish every fact about the business. It may use an old name. It may describe a former location. It cannot by itself verify a professional licence, current inventory, legal jurisdiction or medical claim.
Reviews also have rules. The FTC’s Consumer Reviews and Testimonials Rule addresses specified fake, false and deceptive practices. Buying fabricated reviews, conditioning an incentive on positive sentiment or rewriting a customer’s experience creates a trust and compliance problem rather than an entity foundation.
Ask for honest feedback through a compliant process. Keep the reviewer’s words and disclose incentives where required. Correct factual profile errors through the proper edit path instead of trying to bury them under more reviews.
No official provider source reviewed here establishes “more reviews makes AI recommend the business” as a universal rule. Treat reviews as evidence of experience, not a citation lever or identity shortcut.
The FTC’s Consumer Reviews and Testimonials Rule Q&A explains the distinction between reviews and testimonials and the rule’s deceptive-practice boundaries.
The important facts change across five industries
Every industry needs clear identity. The objects and consequences are different.
| Industry | Objects and facts to govern | High-consequence conflict | Business action |
|---|---|---|---|
| Home Services | Business, real location or service area, trade/service, hours, phone and licence where relevant | Wrong phone, fake or old location, unavailable service or mismatched hours | Qualified call, estimate and booked job |
| Legal | Firm, attorney, jurisdiction, office, practice area and supported credentials | Wrong attorney status, jurisdiction, office or unsupported specialty | Qualified consultation and accepted matter |
| Healthcare | Organization, clinician, specialty, location, service and appointment path | Wrong provider/location, outdated service or unsafe medical statement | Appropriate appointment and patient-acquisition record |
| B2B SaaS | Company, product, use case, integration, plan, support and policy | Deprecated integration, wrong price path or unclear company/product relationship | Qualified demo, trial and opportunity |
| eCommerce | Merchant, brand, product, variant, price, availability, shipping and returns | Feed/page mismatch, unavailable product or wrong policy | Product visit, completed order and repeat purchase |
An online-only SaaS company does not need invented local offices. A service-area contractor should not hide behind a national “digital business” description. A healthcare practice needs a clear relationship between the organization, clinician and reviewed information. A law firm needs jurisdiction and attorney facts that survive professional verification. A store needs the same variant and price in the feed, page and checkout.
The public record should answer the buyer’s real question. Who provides this? Is it available to me? Is this the right location, professional, plan or product? What happens next?
The answer products may change. Those questions remain useful.
Reconcile conflicts with a fact ledger
Do not fix identity problems from memory. Create a dated record.
| Ledger field | What to enter |
|---|---|
| Fact or object | The exact name, role, location, service, product, price or policy being checked |
| Authoritative owner | The operating, legal, professional, sales or commerce system that can verify it |
| Canonical public record | The primary page, profile or feed where a buyer should confirm it |
| Other observed sources | Profiles, directories, results or answers showing the fact |
| Conflict | The exact difference, not “inconsistent online” |
| Buyer consequence | Wrong call, lost trust, unsafe advice, failed checkout or other risk |
| Correction | The specific edit or request required at the source |
| Responsible owner | The person authorized to approve and publish it |
| Correction date | When the source changed |
| Verification date | When the public result was rechecked |
Prioritize by consequence, not by how easy the edit is.
An old logo is usually less urgent than a wrong clinic phone. A stale SaaS integration can waste a sales call. A wrong service area can send a homeowner to a company that will not travel there. A mismatched product price can stop a purchase. A false professional credential may carry legal and reputational risk.
Preserve a screenshot or export before the correction. That gives you a clean before-and-after record and makes rollback possible when an integration or feed overwrites the change.
Mindflow Marketing uses the ledger to decide what gets corrected first, who owns the approval and when to verify it. We do not create profiles or claims simply to fill a graph.
Measure the correction before claiming visibility changed
A factual correction has a short evidence chain:
source corrected → platform processed change → public display changed → answer or result changed → buyer visited → qualified action recorded
One step does not prove the next.
If the Business Profile now shows the correct phone, record the correction. Do not claim better rankings until the relevant search observations change. If ChatGPT names the correct product, record the mention. Do not call it pipeline until a qualified demo reaches the CRM.
Allow time for crawling, feed processing, profile review and interface updates. Keep the correction and verification dates separate. If the fact changes again, inspect the source that may be overwriting it.
Use AI Citation Surfaces to classify what a product showed. Use How to Measure AI Search Visibility Honestly for a fixed-question protocol. For Google-specific answer reporting, use the AI Overviews chapter.
The record can show that the foundation is cleaner. Search and answer products still decide how they use it.
Fix the highest-consequence verified conflict first
You can publish accurate facts, correct governed profiles, maintain product feeds and describe visible information with valid markup.
You cannot force a Knowledge Panel, citation, ranking or recommendation.
For a first fact review, share:
- the business and website;
- the primary market and industry;
- the governed profiles or feeds;
- the facts you already know are wrong or inconsistent;
- the call, consultation, appointment, demo or order that matters.
Mindflow Marketing will locate the source, identify the owner, prioritize the correction and set a verification date. If the problem is local-result eligibility or distance rather than identity, the 2026 local-pack guide explains that separate diagnosis. The AI Visibility service explains the wider engagement.
The platform chooses the display. Mindflow Marketing remains responsible for the evidence, correction priority and recommendation.
Provider and standards documentation was checked on 21 August 2026. Platform fields, markup guidance and processing behavior can change. Recheck the current source before a consequential correction or implementation.