---
title: "Schema Relationship Candidates: What Mentions, About, And IsPartOf Mean In Legible — Legible"
date: 2026-04-04
author: "Legible"
description: "Learn what Schema Relationship Candidates do in Legible, what happens when you accept one, and how relationships like mentions, about, and isPartOf enrich your JSON-LD without changing the page's main schema identity."
thumbnail: "https://getlegible.com/docs/schema-relationship-candidates/opengraph-image"
canonical: "https://getlegible.com/docs/schema-relationship-candidates/"
ai_use: allow
ai_training: allow
ai_summary: allow
ai_citation: required
content_license: "All Rights Reserved"
source: html-extraction
note: "Content extracted from public HTML. Install the Legible plugin for structured metadata, real-time sync, and AI permission controls."
---

# Schema Relationship Candidates: What Mentions, About, And IsPartOf Mean In Legible — Legible

Why this matters
Relationship Candidates are Legible's way of asking whether one page on your site should be structurally connected to another page in the schema graph. They help the engine move from isolated page markup toward a richer same-site knowledge graph.

Accepting a relationship does not rewrite the page, change its category, or replace its primary entity. It approves a semantic connection that Legible can use in schema evidence and, for safe relationship types, in published JSON-LD.

## What relationship candidates are

A Relationship Candidate is a reviewable suggestion that one content item on your site is meaningfully connected to another. Legible generates these suggestions from same-site content only, then asks a human reviewer to confirm whether the relationship is real.

This is useful because many pages are related in ways that plain page-level schema cannot express on its own. A docs article may mention a terminology reference page. A guide may be part of a larger documentation hub. A product page may be about a specific concept explained elsewhere on the site.

- Candidates are always same-site, not cross-domain.
- They are suggestions, not automatic publishing decisions.
- They are reviewed page by page in the Schema tab.
## Why Legible suggests them

The purpose is to make your schema graph more connected and more semantically useful. Instead of describing each page as a disconnected island, Legible can show that one page mentions, is about, or is part of another same-site resource when that connection is clearly grounded in the page content.

This helps machines understand how your content fits together. It is usually a subtler improvement than changing a page from `WebPage` to `TechArticle`, but it can still strengthen how AI systems and search engines interpret the shape of your site.

## What the relationship types mean

These types are intentionally narrow. Legible is not trying to infer every possible link on your site. It is trying to capture a small set of relationships that are understandable, reviewable, and semantically safe.

- `mentions`: the current page refers to the other page's topic or concept in a meaningful way.
- `about`: the current page is substantially about the topic represented by the other page.
- `isPartOf`: the current page belongs inside a broader same-site section or parent resource.
- `mainEntityOfPage`: the relationship is useful as a reviewer hint, but it currently stays in preview and evidence instead of being wired into published JSON-LD.
## What happens when you accept one

Accepting a Relationship Candidate confirms that the connection is real for the current page. Legible stores that relationship as an accepted relationship, removes it from the pending review list, and keeps it available in schema evidence for future previews and graph generation.

For relationship types that are already wired conservatively, acceptance can also enrich the published JSON-LD. In the current version of the Schema Engine, that applies to `mentions`, `about`, and `isPartOf` when the target page is valid and the mapping is semantically safe.

- The accepted relationship is saved on the current page.
- It no longer appears as a pending suggestion.
- It can enrich the page's schema graph when the relationship type is safely supported.
- It does not change the page category, manual label, or main primary entity.
- It does not edit page copy or create a visible front-end link on its own.
## What happens when you reject or restore one

Rejecting tells Legible that the suggested relationship is not useful or not correct for this page. The rejection is kept as review state so the same low-quality suggestion does not immediately return on the next AI generation pass.

Restoring moves the relationship back to pending if you want to reconsider it later. This is useful when the content changed or the earlier decision was too strict.

## Example: accepting a mentions relationship

Imagine a docs page about AI content permissions that talks about terms such as `ai-train`, `ai-input`, and `ai-input=yes`. If Legible suggests a `mentions` relationship to your AI Content Terminology Reference page and you accept it, the page can keep its existing main schema identity while also publishing a small semantic reference to that terminology page.

```
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebPage",
      "url": "https://example.com/docs/ai-content-permissions/",
      "name": "AI content permissions"
    },
    {
      "@type": "TechArticle",
      "headline": "AI content permissions",
      "mentions": [
        {
          "@id": "https://example.com/docs/ai-content-terminology/",
          "url": "https://example.com/docs/ai-content-terminology/",
          "name": "AI Content Terminology Reference",
          "@type": "TechArticle"
        }
      ]
    }
  ]
}
```

## What accepting does not do

That distinction matters. Relationship review is about approving semantic graph edges, not reclassifying the whole page.

- It does not turn a docs page into an FAQ page.
- It does not swap the page's primary entity from `TechArticle` to something else by itself.
- It does not create relationships to pages outside the current site.
- It does not publish ambiguous relationships just because the model suggested them.
## How to decide whether to accept

- Accept `mentions` when the page clearly refers to the target topic or concept.
- Accept `about` when the target represents what the page is largely about, not just a side reference.
- Accept `isPartOf` when the target is a real parent section, hub, or larger same-site resource.
- Reject a suggestion if it feels incidental, forced, circular, or too weak to explain confidently to another human.
- Restore only when you want the candidate back in the pending queue for a fresh decision.
## Why some pages have no relationship candidates

Many pages genuinely will not have any relationship suggestions. The current relationship model is deliberately conservative. It only works with same-site content, and it favors explicit or well-supported semantic links over broad assumptions that every page is related to every other page.

That means empty states are often normal, especially on smaller marketing sites or pages that stand alone. A zero state does not mean the page has no schema. It only means Legible did not find a high-confidence relationship worth asking a human to review.

## Best practices

- Keep page titles and section structure clear so the relationship model has stronger signals.
- Use descriptive docs hubs, glossary pages, and architecture references when you want same-site relationships to be easier to detect.
- Review high-value content first: docs hubs, major guides, pricing pages, service pages, and terminology references.
- Treat accepted relationships as graph quality improvements, not as a shortcut for fixing a misclassified page.
## Troubleshooting

- No relationship suggestions appear anywhere: Make sure AI analysis has been generated for the site, not only for pages you opened manually.
- A relationship keeps returning after rejection: Re-check whether the target page or the source content changed enough to justify a new suggestion.
- Accepting did not visibly change the page: That is normal. Relationship acceptance usually changes schema evidence and graph references, not the on-page UI.
- The wrong relationship type was suggested: Reject it and let the deterministic page identity stay as-is. Relationship review should not be used to force category changes.

---
*Content delivery by [Legible](https://getlegible.com)*