Markup ownership and template conflicts
Resolve the identity, then fix the generator that repeats it.
Two valid JSON blocks can disagree about one organization. Identify each emitter, compare the entity evidence and give shared facts a maintained owner before merging or suppressing output.
Inventory all emitters and their responsibility.
Inspect representative pages for schema from the theme, SEO plugin, commerce plugin, page builder, custom template, reusable block and inserted scripts. Record the emitting system, version, page family, node IDs, type, URL, supported facts and maintainer. A single JSON-LD block is not the whole page graph.
Choose a clear owner for common organization and website identity, then assign page-specific facts to the generator best placed to maintain them. This does not mean disabling every plugin. A commerce plugin may correctly own product data while an SEO plugin owns the website node. Document who changes each setting or filter so the defect does not return on the next request.
Decide if the nodes describe the same thing.
Compare IDs, names, identifiers, URLs, type, location, source records and relationships. A repeated name is not proof of duplicate identity. A brand, legal organization, branch, person, webpage and product may share words but need separate nodes. A page about a company is not the company itself.
Use a compact signature for review: ID, type, URL, supported identifiers and relevant relationships. Treat this as an editorial comparison method, not a unique truth fingerprint. Resolve identity before merging fields. A coincidentally matching address or a differently formatted ID cannot settle the question alone.
Separate repetition, complementary description and conflict.
Repeated references to the same accepted ID can connect a graph without creating a new entity. Complementary facts may be compatible if they describe that same entity and have evidence. Conflicting address, legal identity, author or product-version assertions require resolution; do not merge them into an unexplained array.
Schema.org permits properties to have more than one entry in general. That flexibility does not prove that two competing addresses are both appropriate current facts. A headquarters and a genuine branch can both exist, but their roles and evidence must be explained. Preserve genuinely distinct entities and connect them with supported relationships.
Worked example: two organization nodes disagree on an address.
In this fictional case, a theme emits https://example.test/#organization for Northbank Studio with 12 River Lane. A plugin emits https://example.test/#/organization for the same business with 8 Quay Road. The current visible contact page and approved organization record identify 8 Quay Road as its sole current office; the old address is a retired location, not an active branch.
Do not choose an address because its plugin is newer or its node appears first. Confirm the business identity and effective date with the record owner. Retain one stable accepted organization ID, update the theme’s stale source, and configure the plugin to reference that ID or suppress its duplicate organization output. Preserve unrelated useful plugin markup.
In the proposed repaired graph, retain https://example.test/#organization for Northbank Studio and use the approved current address, 8 Quay Road. Article publisher references point to that same ID. Remove the retired-address assertion and the duplicate ID from current output after reconnecting references. If an archive needs to discuss the former office, label it historically in visible content rather than quietly keep both as current addresses.
| Emitter/record | Observed assertion | Decision and owner |
|---|---|---|
| Theme Organization | /#organization, 12 River Lane | Site identity maintainer corrects source to approved current office |
| SEO plugin Organization | /#/organization, 8 Quay Road | Plugin maintainer references surviving ID or suppresses redundant node |
| Approved contact record | One current office at 8 Quay Road | Factual owner confirms effective date and visible contact wording |
| Article publisher reference | May point to retired duplicate ID | Template maintainer reconnects to retained organization ID |
Keep the graph internally consistent.
After choosing surviving IDs, find every reference to the retired IDs. Review publisher, author, mainEntity and page relationships where applicable, without treating those roles as interchangeable. Check that the surviving nodes still describe the visible content and that no unsupported fields were added during the merge.
Keep the old-to-new identity map and reasons. A change to an entity ID can affect templates far beyond the page first inspected. Do not delete a distinct Person node merely because it shares a business address, or merge a product family with a version-specific product because their titles match. Reference, merge, split, retain and suppress are different decisions.
Test page families and their allowed differences.
Select representative pages from every affected template: home, article, product, listing, profile, location and exceptions actually used on the site. Shared organization identity should agree where the same entity is intended. Page-specific title, price, author, local evidence or lifecycle may legitimately differ. Never copy those varying facts into a universal template.
Include a page with missing optional data and one with a local override. A family rule should define required inputs, allowed overrides, source precedence and behavior when evidence conflicts. Suppress unsupported facts instead of filling missing record data with a site-wide default that looks plausible.
Run change tests at the emitter and assembled-page levels.
Save the prior graph and configuration, apply the proposed generator change in a safe test environment, and compare the full output. Check node counts and identities, references, visible facts, page canonical and the relevant feature tests. Repeat after caches and performance layers assemble the page.
Test the same representative pages before and after a theme/plugin update. Confirm that a disabled duplicate does not reappear and that supported product, breadcrumb or article data still exists. A parser pass does not establish that the address is correct; a correct address does not prove that every emitted block parses.
Maintain the decision and a bounded rollback plan.
Store source evidence, accepted IDs, emitter ownership, suppressed output, configuration version, affected page families and reviewer. Define a trigger for rechecking: a move, rebrand, new plugin, template override or source withdrawal. Keep the repair reproducible rather than manually editing generated HTML after every response.
Rollback should restore an accurate accepted configuration. If the old version itself publishes false facts, do not reactivate that known error as a blanket remedy. Hold or suppress the affected assertion while the responsible owner resolves it. Coherence is a maintenance outcome; it is not a promise of search appearance or rankings.
Sources and related learning
Schema.org data model. Google structured data policies.
The worked scenarios are fictional teaching records. They do not report live tests, client work or measured search outcomes.
Continue with semantic SEO learning and schema and entity identity. Check markup and content together. Separate entities with similar names.