Schema Markup and Entity Linking: @id, sameAs, @graph

Structured data — schema markup — means repeating in machine-readable form what your page already says in prose. From a semantic SEO point of view its main value is not the star rating in the search results: markup lets you name your entities, declare their types and connect them to one another.

Google's structured data guidelines accept three formats — JSON-LD (recommended), Microdata and RDFa. This article uses JSON-LD only, because it is written separately from the HTML and is by far the easiest to maintain.

What structured data does and does not do

What it does: it classifies the information on a page unambiguously. The word "Baku" in running text could be a city, a restaurant name or a surname; the moment you write "@type": "Place" that ambiguity disappears. This is the machine-side half of the "disambiguation" job described in the entity SEO article.

What it does not do: it does not guarantee rankings and it does not make weak content strong. Google's own documentation is explicit that even correct markup does not guarantee a rich result — the algorithm prioritises user experience and may choose to show a plain text result instead.

@id and @graph: connecting entities

On most sites schema is written like this: an Organization on the home page, a separate Article on a blog post, each unaware of the other. As far as Google is concerned those are unconnected objects.

The correct approach is to use @id: give every entity a unique, stable, URL-shaped identifier and then reference it.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Agency",
      "url": "https://example.com/",
      "logo": {
        "@type": "ImageObject",
        "@id": "https://example.com/#logo",
        "url": "https://example.com/storage/logo.png"
      },
      "sameAs": [
        "https://www.linkedin.com/company/example",
        "https://www.facebook.com/example"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "name": "Example Agency",
      "publisher": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "Article",
      "@id": "https://example.com/blog/semantic-seo#article",
      "headline": "What is semantic SEO",
      "isPartOf": { "@id": "https://example.com/#website" },
      "publisher": { "@id": "https://example.com/#organization" },
      "author": { "@id": "https://example.com/about#person" }
    }
  ]
}

Note that the publisher field does not repeat the company details; it references them by @id. That brings three benefits — shorter code, a single source of truth, and, most importantly, every page tying back to the same entity as far as Google is concerned.

sameAs: external corroboration

sameAs is a simple but powerful field. It says: "this entity is also over there". Google's Organization documentation recommends it for links to your profiles on social media and review sites.

"sameAs": [
  "https://www.linkedin.com/company/example-agency",
  "https://www.facebook.com/exampleagency",
  "https://www.instagram.com/exampleagency",
  "https://www.youtube.com/@exampleagency"
]

Two practical rules:

• List only official, active profiles. An empty or abandoned profile adds no corroborating weight.
• Link back to your site from those profiles. Corroboration is more credible when it runs both ways.

The same logic applies to authors: an author's Person entity can carry a sameAs array pointing at their professional profiles.

The Organization schema: which fields

Per Google's Organization documentation no properties are required — you add the ones relevant to your organisation. The markup belongs on the home page or on a dedicated page such as About us.

For a local business, choose the more specific LocalBusiness type over Organization — Google's general guidelines recommend using the most specific schema.org type available. That is standard practice in local SEO work.

Article and BreadcrumbList for a cluster

When building a content cluster it makes sense to add two schemas to every article: Article (the content itself) and BreadcrumbList (its position on the site).

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Home",
      "item": "https://example.com/" },
    { "@type": "ListItem", "position": 2, "name": "Blog",
      "item": "https://example.com/blog" },
    { "@type": "ListItem", "position": 3, "name": "What is semantic SEO" }
  ]
}

The final element carries no item — the reader is already on that page.

If the article has a genuine question and answer section, a FAQPage schema can be added too. The condition is that the questions and answers must be visible text on the page — a direct requirement of the guidelines below.

Rules and prohibitions

Google's structured data guidelines come in three blocks: technical, quality and content. The most important prohibitions:

• Do not mark up hidden information. Content a user cannot see on the page must not appear in the markup.
• Do not mark up irrelevant content. The documentation's own example is blunt: woodworking instructions must not be labelled as a recipe.
• Do not provide false or misleading information. Fake reviews, impersonating others and misrepresenting affiliations are prohibited.
• Do not block the page carrying the markup. If a page is blocked by robots.txt or noindex, the markup is not processed.
• Pick the most specific type and fill the fields. Without the required properties there is no eligibility for the feature; recommended properties improve the result.

Testing and fixing errors

The most common technical problem is this: the markup is injected by JavaScript and disappears during rendering. If you can see the JSON-LD block in the "rendered HTML" section of URL Inspection, you are fine.

Common mistakes

1. Repeating the whole Organization block on every page. Referencing it by @id is the better pattern.

2. Using a random string as @id. It must be stable and URL-shaped so that other blocks can reference it.

3. Marking up an FAQ that is not on the page. This is the single most frequently violated rule.

4. Supplying a logo that is too small or blocked. There is a minimum size requirement and the file must be crawlable.

5. Forgetting to update the markup. When an address or phone number changes and the schema stays behind, your entity signals start contradicting each other.