Absent, not null: a response contract worth copying

When Google renders no knowledge panel, our response has no knowledgeGraph key. Not null. Not {}. Not an empty array. The key is simply not there.

This is deliberate, and it is the single most common source of integration bugs we see, so it is worth spelling out.

The failure it prevents

// wrong, and it will throw
if (body.knowledgeGraph.title) { … }

// wrong in a subtler way: null and {} are different states
if (body.knowledgeGraph !== null) { … }

// correct
if ('knowledgeGraph' in body) { … }

With 50.8% of queries carrying an AI Overview and the rest not, roughly half of all responses exercise the absent branch. A parser that only ever saw the present branch in testing will meet the other one in production, at volume, on the first day.

Why absent beats null

A null carries a claim: this field exists and its value is nothing. An absent key carries a weaker and more accurate claim: Google rendered no such block, and we are not going to invent a representation for something that did not happen. The distinction matters most when you start storing responses, because null and missing serialise differently, aggregate differently, and disagree exactly where your interesting cases are.

The full contract is on the documentation page.