Structured data does not make a dental page true, and it does not replace a clear author or a careful text. It is a machine-readable restatement of facts on the page: who publishes it, how the page sits in the site, whether a block is a real FAQ, and what kind of document it is. That restatement should stay modest. The page is usually an explanation for the public, not a clinic visit and not a diagnosis.

We are Dentalog, an independent French dental information site. This article looks at schema.org types that fit, then describes what we publish today and the lessons we keep in mind when we add types. The observations below are based on the homepage, legal and contact pages, category hubs, glossary entries, price pages, and a sample of 100 sitemap URLs, checked on 10 November 2026.

Types that usually fit an information site

MedicalWebPage is the schema.org type for a page whose main content is medical information. It can sit on a guide or a condition page when the visible text is health information. It is a poor fit for a marketing landing page, and it should not imply that the publisher provides treatment if the site only publishes information.

FAQPage is appropriate when the page shows a real question and answer list. Each Question needs an acceptedAnswer that matches the visible text. A heading is not enough if the answers are missing from JSON-LD, and JSON-LD answers should not exist if the reader cannot see them.

Article or BlogPosting describes a dated editorial piece, with a headline, an author, and preferably datePublished / dateModified. Either type can work. If the HTML presents a guide as an article, the JSON-LD should not call it a product or a local business.

Organization names the publisher: legal name, logo, and a canonical site URL. A standalone Organization (or a WebSite that points at it) helps every page share the same entity, rather than repeating a slightly different publisher block on a few articles only.

BreadcrumbList describes the path that places the page in the tree: home, category, current document. It is simple and easy to keep in sync with the visible breadcrumb.

Person, often nested on the article as author, attaches a named writer. It supports experience and expertise signals only if the same identity is visible on the page and the profile is not inflated.

A small, honest Organization example looks like this:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Dentalog",
  "url": "https://dentalog.fr/",
  "logo": "https://dentalog.fr/dentalog-favicon.png"
}

A compact BreadcrumbList can be as short as home, category, and the current URL. A FAQPage should include only questions that appear on the page.

How we mark up dentalog.fr today

On the public site, JSON-LD is the structured data format we use. We have not added microdata or RDFa.

A BreadcrumbList is present on almost every page in the 100-URL sample, including category hubs, glossary entries, many guides, and the legal pages. FAQPage appears on some articles. One example is https://dentalog.fr/carie-dentaire-causes-symptomes-traitements, which includes both BreadcrumbList and FAQPage. Some guides use BlogPosting or Article, with a nested Person author (name, image, and a profile URL) and a nested Organization publisher.

That is the current layer: a site-wide breadcrumb, FAQ markup where a visible question and answer list is already on the page, and a richer article object on some guides. We add a medical page type only where the page is medical information.

Lessons we apply as we extend the graph

The first lesson is simple: a visible FAQ and a FAQPage object should describe the same questions and the same answers. On a price page such as the implant fee guide at https://dentalog.fr/implant-dentaire-prix, the structured data should restate the document, and a FAQ block should appear only when that FAQ is on the page.

Other lessons we keep in mind when we add types:

• We describe ourselves as an information publisher, not as a Dentist or LocalBusiness, because we do not run a practice and we do not offer appointments.
• We would add MedicalWebPage only where the page is medical information, and we would not invent medical codes the text never mentions.
• FAQPage answers must match the visible answers.
• Dates in a BlogPosting or Article block should match dates that a reader can also see in the HTML.
• The publisher name should be the same wherever an organization is declared.

None of this requires a dramatic rewrite. It requires the JSON-LD to describe the page that already exists, and types to be added only where the visible content already supports them.

Trust signals in the E-E-A-T sense

Google's quality rater guidance talks about experience, expertise, authoritativeness, and trust. Structured data can repeat those signals. It cannot create them.

For a dental information site, the visible signals matter first: a named author, a publisher with legal pages, dates that can be checked, a clear statement that the text is information rather than a treatment plan, and no invented reviews. On dentalog.fr, article pages already show a named byline and photograph, and, on guides that include a BlogPosting or Article object, that block repeats the person and an organization publisher.

We would not claim that adding MedicalWebPage everywhere would change how the site is understood. As we extend the graph, we do it where the page already supports the type: a stable Organization on the site, FAQPage only where the FAQ is complete and visible, and an article type with dates that match the HTML. We treat structured data as documentation, not as decoration.