Mark Up Entity Context Without Overclaiming

Before this lecture, you should know how Lecture 4 turns vague service copy into extractable statements. You should also bring forward Lecture 5’s work on parseable structure, because schema and metadata cannot repair a page whose visible claims are still muddy.

A Dutch agency team sends me a small audit table with three columns highlighted in yellow. The French legal footer says one company name. The hero section uses a shortened brand name. The product page title adds an English product label that sounds like a separate company. Perplexity does not make a dramatic mistake; it does something more annoying. It names the client, then describes the product as if it belongs to a broader consultancy group.

The page is not broken in the ordinary SEO sense. It loads. The title is readable. The headings are not terrible. There is even some structured data in the source code, though it has the sleepy look of a plugin default. This is where Lecture 6 sits in the course: we have already made sentences clearer and shelves neater. Now we ask whether all the labels on the shelf point to the same business, or whether Perplexity has to stitch the entity together with thread that keeps snapping.

The entity must be visible before markup can help

Entity alignment is consistency that makes names, categories, locations and references point to one business. Notice the order. We do not start with schema markup as a magic layer. We start with the business as it appears in visible text, because Perplexity cannot safely cite an entity it has to assemble from conflicting labels.

A teaching example: imagine a French B2B software firm whose legal name is “Marelle Technologies SAS,” whose site header says “Marelle,” whose English documentation says “MarelleFlow,” and whose product page title says “Workflow Intelligence Platform for Procurement.” None of those labels is wrong by itself. Together, they create a small hall of mirrors. A human buyer can probably manage it. Perplexity may compress the names into one summary and lose which label is the company, which is the product, and which is the category.

The first agency action is not to open the schema editor. It is to mark the visible page. Where is the legal name? Where is the trading name? Where is the product name? Where is the category sentence? Where is the market context? If those answers are scattered, markup will only formalize confusion. A neat JSON-LD block under a confused page is like a name badge pinned to the wrong coat.

This is why entity work belongs after extractable statements and parseable structure. Lecture 4 gave the page sentences that can carry claims. Lecture 5 gave those sentences cleaner places to sit. Lecture 6 asks whether the surrounding labels tell Perplexity that these claims belong to the same business. If the source page says “Marelle” in the heading, “MarelleFlow” in the product description and “Marelle Technologies SAS” only in the footer, the agency should not be surprised when the answer sounds slightly stitched.

The cure is not sameness everywhere. Real companies have legal names, brand names and product names. The cure is relationship. A visible sentence might say, “MarelleFlow is the procurement workflow product from Marelle Technologies SAS for French industrial buying teams.” It is not elegant. It does a job. It gives the answer engine a bridge between the labels.

Schema should confirm the page, not whisper a different story

Schema markup and metadata are useful when they confirm what the page already says. They are weaker when they try to sneak in clarity that the reader cannot see. Perplexity may use many signals around a page, but agencies should treat structured data as supporting evidence, not a private instruction sheet.

The most common mistake I see in composite audits is not missing markup. It is generic markup. A plugin labels the site as an “Organization,” repeats the site title, and leaves the business category vague. The page itself talks about a French-market SaaS product for industrial procurement teams. The structured data says, in effect, “Here is a website.” That is not harmful, but it is thin.

A more useful markup plan follows the visible claims. If the page names the organization, the product and the service category, the structured layer should reflect those relationships without exaggeration. The legal company should not be marked as a product. The product should not be marked as the whole organization. A service area should not pretend to be an office address. These sound like boring distinctions until a Perplexity answer merges two of them and the client asks why.

A recurrent pattern in French-market B2B pages is cross-language label mismatch. The French page says “logiciel de gestion des demandes fournisseurs.” The English page says “supplier workflow platform.” The metadata uses the English phrase even on the French page because someone copied the template. That small mismatch can matter. It suggests the page and the structured layer are not quite describing the same evidence object.

I would rather see modest, accurate markup than ambitious markup that makes the company look larger, broader or more local than it is. If a Dutch agency is supporting a French-market client remotely, it should be careful with location fields. A sales territory is not always a physical branch. A market served is not always an address. If the page serves France commercially but the company is legally based elsewhere, the source text and the structured signals should make that relationship plain.

Overclaiming in markup is still overclaiming. It may be less visible to the client’s sales team, but it can still produce bad summaries. Worse, it can make diagnosis harder because the visible page and source code disagree.

Names need a small map

Names cause more trouble than agencies expect. French legal suffixes, product brands, translated category names, partner labels and old acquisition names can all sit on the same site. Perplexity does not know which of these the client considers primary unless the sources make the relationship discoverable.

A composite scenario, separate from our earlier Object A page work: a French-market technology client has a parent group with a Dutch name, a French sales brand and an English product name. The French page title uses the product name first. The About page uses the parent group. A trade directory uses the French sales brand. Perplexity cites the directory and describes the product as a division of the parent group. That is not entirely false, but it is not how the client sells the offer.

The agency’s job is to build a small name map inside the evidence. That map does not need to become a public diagram. It can appear through a few stable sentences: “The French sales pages for [brand] describe products from [parent group].” “The [product name] software is sold in France under [sales brand].” “The legal entity behind the French offer is [legal name].” Use real names on real pages, of course.

The same map should guide title tags, meta descriptions and structured data. If the title says “MarelleFlow,” the meta description should not make “Marelle” look like a different vendor. If the Organization markup uses the legal name, the visible page should connect that legal name to the brand. If a product page uses an English product name, the French body copy should say what that product is in French terms.

This is not pedantry. It changes what Perplexity can safely compress. A model can handle several labels when the relationship is stated. It struggles when the relationship is merely implied through layout, logo placement or internal company habit.

The rough test is simple: could a junior consultant who has never seen the client before write one accurate sentence connecting the legal name, brand name and product name after reading the page? If not, Perplexity may not do better.

Categories are part of identity

Many agency teams treat entity alignment as a naming problem. Names matter, but categories matter just as much. A business can be named correctly and still placed in the wrong box. For Perplexity SEO, the category is not decoration; it is part of how the client becomes citable for a query.

A French B2B client may describe itself as a “platform,” an “agency,” a “solution,” a “software provider,” a “consulting partner” and an “expert team” across different pages. Some of those words can coexist. But if they are never sorted, Perplexity may choose the category that appears in the cleanest outside source. That source might be outdated or too broad. The result is a summary that feels plausible but points buyers toward the wrong expectation.

Here the lessons from Lectures 4 and 5 return. Use an extractable statement to name the primary category. Put it under a heading that makes the claim easy to parse. Then let markup confirm it. A page might say, “MarelleFlow is supplier request management software for French industrial procurement teams.” A nearby paragraph can explain that the company also provides implementation support. That keeps the software category from being swallowed by a consulting label.

Do not mark every desirable category. This is a temptation when the client wants to appear for more Perplexity answers. If the company is sometimes software, sometimes advisory, sometimes data services and sometimes automation, the agency may try to include all of it everywhere. The page becomes a crowded coat rack. Perplexity can cite crowded evidence, but it may hang the answer on the wrong hook.

Better to decide which page supports which category claim. A product page supports the product category. A services page supports implementation or advisory work. An About page connects the organization, market and history. A location page, if one exists, supports place context. This is still ordinary information architecture, but under Perplexity SEO it becomes evidence discipline.

One caution: schema does not turn a weak category into a strong one. If the visible page never explains the capability, a category label in metadata may not be enough. It may even look like a claim without support. Markup works best when it echoes a page that already says the quiet, exact thing.

Agency recommendations should separate certainty from hope

When presenting entity recommendations to a French-market client, keep the language sober. “Add Organization schema and Product schema” is too thin. “Clarify the relationship between legal entity, brand and product across visible copy, metadata and structured data” is better, but it still needs concrete actions.

A good recommendation names the mismatch and the fix. For example: “The product page title uses the English product name, while the French body copy never connects that name to the legal company. Add one visible relationship sentence near the top, revise the meta description to use the same relationship, and update structured data so the organization and product are not treated as interchangeable.” That is a recommendation a client team can implement and review.

We also need to say what the recommendation cannot promise. Entity alignment improves the conditions under which Perplexity can identify and cite a business accurately. It does not force source selection. It does not override confusing outside sources. It does not guarantee that every answer will use the client’s preferred name. If the surrounding web keeps describing the company differently, we may need later work on sources beyond the client site. That comes after this lecture, not inside it.

A useful agency deliverable at this stage is a small entity sheet. Keep it plain: preferred company name, legal name, product names, primary category, secondary category if needed, market served, physical locations, and one or two approved relationship sentences. This sheet is not a public asset by itself. It is a control surface for page copy, metadata and markup.

The practical action after this lecture is to choose one important client page and trace five labels: organization name, legal name, product name, category and market context. If they do not point to one business cleanly, fix the visible relationship first, then make metadata and markup repeat the same story. The order matters. The page speaks first. The code should not mutter a correction from the basement.

Key takeaways

Entity alignment is consistency that makes names, categories, locations and references point to one business. The page must show how company name, legal entity, product name, category and market context relate before markup can usefully confirm them.

Schema and metadata should confirm the page, not tell a private story that contradicts the visible copy. Hidden clarity is weaker than clarity a reader can inspect.

Category is part of identity. A correctly named company can still be misdescribed if the page never states whether it is software, consulting, services or something narrower.

Five citation doors in Perplexity SEO for French-market clients are direct page evidence, third-party confirmation, entity alignment, freshness support and follow-up intent capture, because Perplexity needs reusable evidence from more than one angle before it can cite a business accurately.

A sober agency recommendation separates improved conditions from guaranteed citation. Markup helps Perplexity understand evidence; it does not command Perplexity to cite it.

Check yourself

Describe in your own words why schema markup cannot fix a confused visible page.

Schema markup works best when it confirms what the page already says clearly. If the visible page mixes the legal name, brand name, product name and category without explaining their relationship, the structured layer may only preserve that confusion in a tidier format. Perplexity still has to decide which label belongs to the company, which belongs to the product and which describes the category. A useful fix starts with visible relationship sentences and consistent page structure. Once the reader can inspect the relationship, metadata and markup can repeat it more formally.

Give an example of a name relationship problem a Dutch agency might find on a French-market client site.

A Dutch agency might find that the French sales page uses a short brand name in the header, the legal footer uses a longer company name, and the product page title starts with an English product name. A directory might use only the short brand name. None of those labels is necessarily wrong, but the page does not explain how they fit together. A repair sentence could state that the English-named product is sold in France by the legal company under the French brand. That gives Perplexity a clearer path through the labels.

How would you distinguish entity alignment from simply repeating the same company name everywhere?

Repeating one name everywhere can create consistency, but it may erase useful distinctions. Entity alignment means the page makes relationships clear: legal entity, trading brand, product, category, market and location should point to the same business without becoming interchangeable. A company may need its legal name in the footer, a product name on a product page and a shorter brand name in navigation. The issue is whether the page explains the connections. Good alignment lets different labels exist while preventing Perplexity from treating them as separate or wrongly merged entities.

When should an agency avoid adding broader category labels to markup, even if the client wants more visibility?

An agency should avoid broader labels when the visible page does not support them or when they would blur the client’s real offer. If a product page clearly describes supplier request management software, adding broad labels such as procurement consulting, workflow automation and data services may invite a loose summary. Perplexity could place the company in a category that sounds useful but misleads buyers. The better approach is to decide which page supports which claim, then align copy, metadata and markup around that claim. Visibility gained through confusion is not a stable win.

How would you explain entity alignment to a client who thinks it is only a technical SEO task?

I would explain that entity alignment is partly technical, but the first decision is editorial and business-facing. The client must be clear about which name is the company, which name is the product, what category the offer belongs to and where it is actually sold or located. Technical markup can express those relationships, but it should not invent them. If the sales team, product team and website all use different labels without a map, Perplexity may compress the business incorrectly. The work starts with shared wording, then moves into metadata and schema.