Invalid object type for field "creator": the one-line fix

On 20 October 2026 Search Console sent this site a structured-data warning about its one video. In the French interface it read « Type d'objet non valide pour le champ "creator" ». In English it's "Invalid object type for field 'creator'". It was flagged as non-critical, which mostly means "not yet".

The cause was one line of JSON-LD, and it's a mistake I'd made deliberately, because it looked like good practice.

What the markup looked like

This site describes its owner once, as a Person with a stable @id, and then points at that @id from everything else. The video's creator was one of those pointers.

{
  "@type": "VideoObject",
  "name": "Why we built TheQuizMaster",
  "creator": { "@id": "https://yassirhalaoui.com/#person" }
}

Linking entities by @id is how JSON-LD is supposed to work. Define a thing once, reference it everywhere, and parsers merge the references into one entity. So why would Google call it the wrong type?

Why it passed on one page and failed on another

Google validates structured data per page. On the homepage, the Person node is in the same @graph as everything that points at it, so the reference resolves to a typed Person and validation is happy.

The video doesn't live on the homepage. It lives on a case study page, and that page's graph contained the VideoObject, the software application and the breadcrumbs, but not the Person. From the validator's point of view, creator was an object with an @id and nothing else: no @type, no name. An untyped object isn't a Person or an Organization, which is all creator accepts. So: invalid object type.

It's an easy trap because the markup is correct in the abstract. It's only wrong in the context it's checked in, and that context is one page at a time.

The fix

Carry the type and the name on the reference itself. The @id stays, so the reference still merges with the full entity wherever both appear.

{
  "@type": "VideoObject",
  "name": "Why we built TheQuizMaster",
  "creator": {
    "@type": "Person",
    "@id": "https://yassirhalaoui.com/#person",
    "name": "Yassir Halaoui",
    "url": "https://yassirhalaoui.com"
  }
}

In code, that meant changing the one helper every page used to build the reference, rather than patching the video:

// A bare { "@id" } only resolves when the Person node is in the same graph.
function personRef() {
  return {
    "@type": "Person",
    "@id": `${site.url}/#person`,
    name: site.name,
    url: site.url,
  } as const;
}

Check the references Google hasn't complained about yet

The video was the first thing Google flagged, not the only thing affected. Every article on this site had the same bare reference in author and publisher, and the article pages didn't carry the Person node either. Google's article guidance expects the author to be a Person or Organization with a name, so those would have been next.

Search the generated JSON-LD, not the source, for references that are only an @id:

curl -s https://yoursite.com/some-page \
  | grep -o '"@id":"[^"]*"}' \
  | sort -u

Anything that comes back is an object with an @id and nothing else. On a page where that id isn't defined, it's untyped.

A bare @id is fine where the node it points to is defined on the same page, for example a ProfilePage whose mainEntity is the Person sitting next to it. The rule of thumb: if you can't see the full node in the same script tag, give the reference a type and a name.

Confirming the fix

1. Run the affected URL through Google's Rich Results Test and the Schema Markup Validator. Both should show creator as a Person.
2. Deploy, then open the report in Search Console and choose Validate fix. Validation takes days, sometimes a couple of weeks, and the email arrives when it's done.
3. Spot-check two or three other templates by hand. The bug lives in a helper, so every template that uses the helper had it.

The broader lesson is about where structured data gets judged. You design it as a graph across the whole site. Google reads it one page at a time. Writing each page's JSON-LD so it validates on its own, while still pointing at the shared entity, satisfies both. The rest of how this site was set up to rank for its owner's name is in a new domain to page one for my name in six weeks.