Structured data and schema

Structured data gives search engines a machine-readable description of the entities and page types on a website.

We use schema to clarify, not decorate

Organization schema can identify the company. Article schema can describe a published article. Breadcrumb schema can describe the path to a page. The markup should match what the page actually contains.

Shared helpers reduce mistakes

We use reusable components for JSON-LD so escaping and rendering behavior stay consistent across page types.

Dynamic values come from content

A documentation page can use its title, description, URL, and last-modified date to generate its own TechArticle markup. This avoids copying stale schema between pages.

Schema is not a shortcut

Adding markup does not make thin content authoritative. It helps search engines interpret information that is already present.

Validation is part of QA

Malformed JSON-LD can silently undermine the work. Structured data should be checked after changes to templates or content models.

We generate schema from the same objects that render the page

Several of our codebases expose helper functions for breadcrumbs, services, articles, FAQs, and the organization itself. A service page passes its actual title, description, path, provider, and service area into the schema helper. An article passes its publication date, modified date, image, and author information.

This reduces the chance that the invisible structured data drifts away from the visible document. If the page title changes, the content object changes. The schema reads from that object rather than from a copied JSON block that somebody may forget to update.

Schema type should follow the page, not the SEO wish list

A service page can reasonably describe a Service. An article can describe an Article or BlogPosting. Technical documentation can use TechArticle. BreadcrumbList can describe the route hierarchy. We do not add unrelated schema types simply because a validator recognizes them. Structured data should make the page easier to interpret, not tell search engines that the page contains entities or features that are not actually present.

JSON-LD is code and can break like code

Malformed JSON, wrong URLs, stale IDs, or inconsistent page data can make structured data useless. That is why the connectrader post-build audit parses every JSON-LD block it finds instead of merely checking that a script tag exists. The audit also verifies expected schema types for route families. Blog pages need article and breadcrumb data. Service pages need service and breadcrumb data. Documentation pages need TechArticle and breadcrumbs.

This turns schema coverage into a release rule.

Stable identifiers help entities connect

Organization and business schema can expose a stable @id. Service, article, and page schema can refer back to that identifier as publisher or provider. This is cleaner than repeating slightly different organization objects on every route. The same principle applies to canonical URLs. Structured data should describe the production page identity, not the temporary preview hostname.

FAQ schema requires restraint

If a page has genuine frequently asked questions that are visible to the user, FAQ structure can be a sensible representation. It should not be generated from hidden keyword text or invented questions that exist only for markup. The structured data is strongest when it is a faithful machine-readable view of the page people can already see.

That is why schema belongs inside the content and routing architecture rather than as a plugin checkbox added at the end.