Which structured data types to use on a corporate website, how to connect them with JSON-LD, and which mistakes to avoid for a safe Schema.org implementation.
Schema describes; it does not invent relevance
Structured data provides explicit clues about a page's meaning. It does not fix an ambiguous proposition, an empty biography, or a product without an explanation. Before writing JSON-LD, check that the information exists on screen and matches the title, description, and links. If a page presents Wiwo.Lab as a creative intelligence product, the markup must describe that same offering, rather than a list of capabilities the user cannot find. The editorial rule is simple: every important property must have a visible, verifiable equivalent.
Schema.org works when it accurately describes visible content and connects entities through stable identifiers. For a brand like Wiwo, the priority is not adding every possible type, but building a coherent graph across Organization, WebSite, Service or Product, Article, Person and BreadcrumbList.
Start with a base graph for the entire organization
The homepage can declare Organization and WebSite with stable identifiers using @id. The organization brings together its name, URL, logo, description, locations, and official profiles when confirmed. WebSite identifies the domain and its publisher. Inner pages can refer to those same @id values in author, publisher, provider, or isPartOf, avoiding the recreation of slightly different entities. This continuity helps products, articles, people, and studies belong to a single semantic architecture.
Use the most specific type the page genuinely supports
Wiwo.Lab, Wiwo.Ops and Wiwo.Talk pages can be evaluated as Product or Service according to their business model and available information; the decision must be consistent. Articles use Article or BlogPosting with headline, description, image, author, publisher, datePublished and dateModified. Leadership can use Person when biographies are substantive. BreadcrumbList explains hierarchy and ItemList can organize editorial archives, although not every type produces a special search-result appearance. Specificity serves description, rather than promises of a rich result.
FAQs must exist for people
An FAQ section can be modeled as FAQPage when its questions and answers are visible and reflect the actual content of that URL. Hidden questions should not be generated just to fill out Schema. Nor should FAQPage, where the publisher supplies answers, be confused with QAPage, which is intended for pages where users can contribute answers. Even with valid markup, a search engine may choose not to display a rich result. The main benefit remains a clearer page and a faithful semantic description.
Validate the graph with every publication
Review must check syntax, absolute URLs, ISO dates, crawlable images, stable identifiers and parity with content. It must also detect duplicate nodes, empty properties and entities changing names between templates. The Rich Results Test helps review Google-supported features; the Schema.org validator inspects general vocabulary. No automatic validation replaces editorial review: JSON-LD can be syntactically correct while still misrepresenting the page.
