SEO Semantic Graph: The Ontological Engineering Engine for WordPress
SEO Semantic Graph builds a unified Knowledge Graph that tells Google and AI models exactly how your content is structured: what is a container, what is content, what belongs to what, and what is connected to what. No scattered code fragments, no “Ontological Chimeras”.
Above all, it solves the main content cannibalization problems: every URL gets one clear role in the graph, with no overlapping signals. See how it prevents cannibalization →
Traditional plugins focus on syntax (the green light). We focus on ontology: the actual structure and meaning of your site.
The Problem: Validators check grammar, not logic
A JSON-LD document can pass every automated test and still be ontologically wrong. The Schema.org Validator and Google’s Rich Results Test verify that the markup is well formed. They do not verify that the graph makes logical sense.
What validators accept (without flinching)
- A
WebPagedeclaring itself as anArticle(container confused with content). - A
hasPartused to list pages that are not physically part of the document. - A
Reviewattached to a type Google does not accept (for example anArticle). - An
@idpointing to a node that exists nowhere else (an orphan node). - An
aboutproperty that is free text instead of a resolvable reference. - A legacy microformat (
hentry) that validators read as an extraCreativeWork, unconnected to your graph and filled with whatever comes first in the page.
The Solution: No Ontological Chimeras
An Ontological Chimera is structured data that is syntactically valid but logically incoherent: a page that declares two incompatible things at the same time.
SEO Semantic was built to prevent exactly this.
The plugin decides where each property lives, which node owns it, and how nodes reference each other through exact @ids. It works at the ontological level, not just the semantic one.
Note on hentry: what it is and why it appears
You may see an hentry node in your graph that does not come from our plugin. hentry is a microformat from the blog era (hAtom) that WordPress and many themes add to every post through post_class(). Google documents JSON-LD, Microdata and RDFa — not hAtom. The validator reads it as an extra CreativeWork, disconnected from the graph, and fills it with whatever comes first on the page. It is, in effect, an ontological chimera.
SEO Semantic removes it by default. There is a “Replacement CSS class” field: if your theme styles .hentry, enter for example ssg-entry and it will be added in its place.
Limitation: if the theme hard-codes hentry in its templates, or prints its own Microdata (itemscope, itemtype), the plugin cannot remove it — it does not clean the HTML after the fact. If a hentry CreativeWork still appears after the test, search itemtype in the page source: it comes from the theme and must be fixed in a child theme.
How SEO Semantic Prevents Content Cannibalization
Traditional WordPress sites suffer from cannibalization because categories, tags, and poorly structured archives create overlapping signals. Search engines and AI models get confused about which page is the actual authority.
The Old Way: The Ambiguous Tree
In standard setups, multiple pages fight for the same keywords because categories and overlapping archives group them loosely. Google’s crawler has to guess the hierarchy, often leading to internal cannibalization and diluted ranking power.
The Semantic Way: Zero Guesswork
SEO Semantic completely prevents cannibalization by design. By enforcing strict ontological rules—such as explicit isPartOf vertical parent links and targeted significantLink bridges—every URL has a unique, non-overlapping role in the Knowledge Graph.
When AI models and search engines crawl your site, they don’t have to “guess” relationships. They mathematically read who the master Hub (Pillar) is and who the child nodes are. Total clarity, zero cannibalization.
The Entity SEO Rules, Applied by Default
The plugin applies the Semantic Audit Guide so that the correct configuration is the default one.
Container ≠ Content
A URL is never declared an “Article”. It is a WebPage that hosts a mainEntity (the logical content).
Linking vs Containment
On Pillar Pages the plugin never uses a fake hasPart. It uses significantLink (as strings) combined with a structured ItemList.
Pure Reference Nodes
Nodes are stitched together with exact @ids (#webpage, #article, #organization). Every reference inside a page resolves inside the same graph; references to other pages point only to their containers (#webpage).
Entity Disambiguation
One strong about (for example a Wikipedia URL) and an array of secondary mentions.
Breadcrumb on the WebPage
The BreadcrumbList belongs to the page, not to the content, and follows the parent chain you declare.
Data Parity by Design
FAQs, reviews, aggregate ratings, prices and availability are generated from the same data as the visible HTML, so what the JSON-LD declares is what the visitor sees.
Single Source of Truth
By default SEO Semantic silences the JSON-LD of Yoast SEO, Rank Math and All in One SEO (you can switch this off in the settings). Schema printed by other plugins or by your theme, for example WooCommerce product data, is not touched.
Legacy hentry Removed
The hentry microformat added by WordPress and many themes is removed by default, because validators read it as an extra, unconnected CreativeWork. If your theme styles .hentry, choose a neutral replacement class in the settings.
To see how these rules are applied in practice, read the full Schema.org Audit guide.
Relations, not categories
Categories and tags belong to the old, tree-shaped web: they give a machine a label, not a meaning. To understand what a category contains, a search engine or an LLM has to read the titles inside it and guess.
SEO Semantic replaces labels with declared relations
- Vertical: this page belongs to that pillar (
isPartOf). Pages with the same parent are siblings. - Horizontal: this page connects to a page of another collection (
significantLink). Pages linked across different parents are cousins. - Topical: this article is part of collection X but has points of contact with an article of collection Y — you declare it with
aboutormentions.
Declared, never inferred
The plugin declares these relations. It never infers them, and it does not use WordPress categories or tags. For this reason archive, category, tag, author and search pages receive only the Organization and WebSite nodes: they are listing pages, not entities.
If your site already earns traffic from category archives, turn them into pillar pages or keep them out of the index.
Who it’s for (and who it’s not for)
This plugin is a surgical tool for those who need ontological control.
✅ It’s for you if:
- You are an SEO consultant or webmaster working on Entity SEO.
- You need a coherent Knowledge Graph for pillar pages, silos, service or product catalogs.
- You have used a validator, seen the green light, and suspected the graph made no logical sense.
- You want a single source of truth for JSON-LD, with no conflicts from other plugins.
❌ It’s NOT for you if:
- You are looking for an all-in-one SEO suite (meta tags, sitemaps, redirects, analytics). This plugin does not do that.
- You only need basic meta tags and do not care about structured data.
- You expect the plugin to fix SEO automatically without configuring the ontology.
- You want several plugins printing JSON-LD at the same time. By default SEO Semantic silences the JSON-LD of Yoast SEO, Rank Math and All in One SEO (you can switch this off in the settings). Schema printed by other plugins or by your theme, for example WooCommerce product data, is not touched.
Use Cases & Practical Guides
Two specific guides show you exactly how the plugin behaves on different types of WordPress content.
Configuring Articles (Content)
How the plugin handles the Article entity: why reviews are blocked on posts, how author and date are extracted, and how type errors are prevented.
Configuring Pages (Container)
How to declare a Service, a Product, an App, a CollectionPage, an About or Contact page. How siloing works and how to prevent cannibalization.
How to Get Started
The plugin will be available on WordPress.org. In the meantime you can install it manually.
1. Global E-E-A-T configuration
Go to SEO Semantic in the sidebar. Enter your company details (name, VAT number, founder), your sameAs links (for example LinkedIn or Wikipedia) and choose your About Us page, which is typed AboutPage automatically. The Organization is printed on every page, so every reference to it resolves inside the page’s own graph.
2. Single page or article
Open any post or page. In the SEO Semantic Graph box choose what the page hosts (Service, Product, App, Collection, About, Contact). Posts are Articles automatically. For Products and Apps enter price, currency and availability: they are declared in the JSON-LD and shown in a small visible details box.
3. The Relationship Builder (siloing)
Use Belongs to for the vertical relation (parent). Use Links to for horizontal relations between collections. Tick the Pillar option on a hub page to generate its ItemList; every child page declares the hub as its parent by default.
4. Ontology and disambiguation
Use About for the main topic (a Wikipedia URL or an internal pillar) and Mentions for secondary concepts or pages of other collections.
5. Styling FAQs and reviews
The blocks inherit your theme’s fonts and colours and use three CSS variables (--ssg-accent, --ssg-radius, --ssg-border) that you can set in Additional CSS. Stable class names and HTML filters are documented in the readme. You can also switch the default stylesheet off. Never hide the blocks with display:none: the structured data would describe content visitors cannot see.
6. Languages
The interface is in English and is translated through WordPress language packs. The Italian translation is included as a downloadable file: copy seo-semantic-graph-it_IT.mo into wp-content/languages/plugins/ and set the site language to Italiano. Once the plugin is on WordPress.org, translations are managed on translate.wordpress.org and delivered automatically.
7. Legacy hentry
The hentry microformat that WordPress and many themes add to posts is removed by default, because validators read it as an extra, unconnected CreativeWork. If your theme styles .hentry you can choose a neutral replacement class in the settings. Limitation: if the theme hard-codes hentry in its templates or prints its own Microdata (itemscope, itemtype), the plugin cannot remove it. Search itemtype in the page source: it comes from the theme and must be fixed in a child theme.
Download the .zip file, go to WordPress > Plugins > Add New > Upload Plugin, upload the file and click Activate.
Good to know
A few practical notes before you configure your graph.
FAQ rich results are over
Since May 2026 Google no longer shows FAQ rich results. FAQPage is still valid Schema.org markup and describes your content to other consumers, but do not expect a visual snippet in Google.
Empty results are normal
A Service or CollectionPage returns No items detected in the Rich Results Test. The Schema.org Validator is where you check the graph.
Theme limits
If a theme hard-codes hentry or prints its own Microdata, the plugin cannot remove it: use a child theme.
Reviews
Use only genuine ratings. Google does not accept self-serving reviews on organizations.
Do you have a WordPress site and want to know if your graph is coherent?
Don’t stop at the green light. Find out if your site has Ontological Chimeras or orphan nodes.