Fixing the Wrong Schema Type in AI-Generated Markup

Why a model picks the wrong type

A language model chooses a type by recognising patterns in the wording. It has seen a great many pages, and it associates tone and layout with types: a chatty, first-person opening looks like a blog post; a list of prices looks like a product; a name and phone number look like an organisation. Most of the time that works. It fails when a page's style and its purpose point in different directions.

• Style over substance. A recipe preceded by six paragraphs about a family holiday reads like a BlogPosting for most of its length. The ingredients and method, which make it a Recipe, are a minority of the text.
• Nouns over intent. A page titled "The best cordless drills for 2026" mentions many products, so Product is an easy guess, even though the page sells nothing and reviews several things.
• Generic over specific. Models often fall back on broad types, Organization instead of Dentist, Article instead of NewsArticle, because broad types are safe and common in their training data.
• One type per page. Some pages genuinely contain two things, such as an article with an embedded event. A generator asked for one block has to pick, and it may pick the less important one.

None of these produce invalid markup. A BlogPosting with a headline and author is perfectly valid. The cost is quieter: the page loses eligibility for the rich result it could have had, and search engines receive a less accurate description of what the page is.

Common mislabels and what they should be

These are the swaps that come up most often when reviewing generated markup. The right answer depends on the page, so treat the table as a first guess to confirm, not a rule.

Two further points about FAQ and HowTo types, which generators still produce often. Google removed HowTo rich results in 2023, and FAQ rich results are now limited to well-known, authoritative government and health sites. The types still exist in schema.org and can still describe a page accurately, but choosing them in the hope of a rich result on an ordinary business site will not work.

The main-entity test for choosing a type

The quickest way to settle a disputed type is to ask one question: if this page could only be about one thing, what would it be? Write the answer as a single sentence starting "This page is a…" or "This page is for…". Then check it against these prompts.

1. What would a visitor come here to do? Cook, buy, book, attend, apply, read, contact. The verb usually points at the type: cook suggests Recipe, attend suggests Event, apply suggests JobPosting.
2. What would be wrong if it were missing? Remove the ingredients from a recipe post and it stops being useful; remove the holiday story and nothing important is lost. The part you cannot remove is the main entity.
3. Does the page sell or describe? Product and Offer describe something the reader can buy from this page or from a named seller. A page that describes products it does not sell is usually an article or a review.
4. Is there a more specific type that is still true? Once you have a broad answer, look down the schema.org hierarchy. LocalBusiness has dozens of subtypes; Article has NewsArticle, BlogPosting, TechArticle and others. Pick the deepest one that fits without stretching.

A small fictional example: Greenfield Garden Services publishes a page called "Hedge trimming in Exampleton". It has a paragraph about the service, a price guide and a contact form. The generator returned Product, because of the prices. The one-sentence answer is "This page is for booking hedge trimming from a local gardener", which makes it a Service offered by the business, with the business itself as a LocalBusiness described once, site-wide.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",
  "@id": "https://www.example.co.uk/hedge-trimming#service",
  "name": "Hedge trimming",
  "serviceType": "Hedge trimming",
  "areaServed": "Exampleton",
  "provider": { "@id": "https://www.example.co.uk/#business" },
  "offers": {
    "@type": "Offer",
    "price": "45.00",
    "priceCurrency": "GBP",
    "description": "Hedges up to 10 metres, one visit"
  },
  "url": "https://www.example.co.uk/hedge-trimming"
}
</script>

The provider reference assumes the site already publishes the business as an entity with that @id. If it does not, the Organization and Person references guide explains how to set one up.

Overriding the type: before or after generation

There are two places to correct the type, and one is much better than the other.

Before generation (preferred)

When a page is ambiguous, set the type yourself before running the generator, rather than letting it infer one. The model then reads the page looking for the properties of the type you chose, so it looks for ingredients and cooking times on a recipe, or dates and a venue on an event. The output is shaped correctly from the start, and required fields for that type are more likely to be found.

After generation (only for small changes)

Editing the @type value by hand is fine when moving between closely related types that share their properties, such as Article to NewsArticle, or LocalBusiness to Plumber. It is risky when the types are unrelated. Changing Product to Service in one line leaves behind properties like sku, gtin or brand in a form that makes little sense for a service, and leaves out provider and serviceType, which the original never looked for. For a jump between unrelated types, regenerate.

The fix, step by step

Pages that are genuinely two things

Some pages have a real second subject. A news article about a festival also announces the festival; a blog post about a trip includes a recipe; a shop's product page includes a how-to video. You have three sensible options, and the right one depends on what each part is worth.

1. Describe only the main entity. If the second subject is incidental, leave it out. A passing embed of a video does not need VideoObject markup.
2. Nest the second thing inside the first. Use a property that links them, such as about, mentions, subjectOf or video. The page keeps one main type, and the relationship is explicit.
3. Use two linked top-level entities. Output the page as a WebPage with mainEntity pointing at the thing it is mainly about, and give each entity its own @id. This suits a recipe post, where the WebPage or BlogPosting wraps the Recipe as its main entity.

What to avoid is two unconnected blocks that each claim to be the page, such as a BlogPosting and a Recipe with the same headline and no link between them. That reads as two competing descriptions. If another system, such as your SEO plugin, already outputs the article type, see the duplicate schema guide before adding a second main entity.

Multiple types on one entity

JSON-LD allows an array of types, such as ["Product", "Car"] or ["LocalBusiness", "Restaurant"], where an entity really is both. Use it sparingly. Where one type is a subtype of the other, as with LocalBusiness and Restaurant, the subtype alone already says both things, and the array adds nothing.

Harder calls

Article, BlogPosting or NewsArticle

All three are fine for Google's article features, which do not require the subtype. Use NewsArticle for reporting on current events, BlogPosting for posts on a blog, and Article when neither fits. The difference is descriptive rather than a switch for special treatment, so a generator choosing BlogPosting for a news story is a small correction, not an urgent one.

Organization or LocalBusiness

If customers visit a physical location, or you serve a defined local area and show an address, LocalBusiness or a subtype is usually right. Online-only businesses and head-office sites for larger companies are usually Organization, sometimes with separate LocalBusiness entities for each branch page.

Product or Offer-only

A page selling one item is a Product with offers. A page listing a single deal on someone else's product, such as a voucher site, is harder; the product is not yours, so be careful about claiming ratings or identifiers for it.

Review or Article

A genuine review of one thing, with a verdict, suits Review with itemReviewed. Google limits self-serving reviews, so a business marking up reviews of itself on its own site will not get review stars for its LocalBusiness or Organization.

Stopping the same mislabel across a site

• Decide types per template. Most sites have a handful of page kinds. Write a one-line table: blog post is BlogPosting, recipe is Recipe with a WebPage wrapper, location page is the relevant LocalBusiness subtype, and so on.
• Set the type for ambiguous templates every time. Leave detection on only for templates where it reliably gets the answer right.
• Review a sample after bulk runs. A type mistake repeats on every page with the same layout, so checking three pages per template catches most of them.
• Watch Search Console. If a report for the feature you expected, such as Recipes or Events, never appears for a section, the pages may be typed as something else.

For choosing types in hand-written markup, rather than correcting generated output, see the schema type choice guide.