The Ad Firm published a guide titled “JSON-LD for AI Retrieval: Best Practices.” It is an agency article. The page does not give a byline this desk will treat as confirmed, so the piece is cited as the firm’s.
The practical advice is ordinary and checkable. Start from the main thing the page is about. An article should connect an Article to a Person for the author and an Organization for the publisher. Give those nodes a stable @id, a URI reused everywhere that same organization, author, or location appears, so a model does not mint a second entity because the name string drifted. Prefer a specific Schema.org type, filled with the properties that type actually has. An author property that points at a Person node says more than an author field that is only a string of text.
“Before anything ships, every claim in the JSON-LD needs a visible match on the page it describes.”
— The Ad Firm, JSON-LD for AI Retrieval
The guide says the comparison should cover names, dates, offers, ratings, and authorship, by hand or by script, before publish. Padding the block with optional fields that are not on the page does not strengthen the record. It adds places for the markup and the visible page to disagree. The firm also says the step people skip is written governance: one @id per organization, author, and location, used everywhere, with the syntax validated against the current schema before it ships.
What structured data still is not
JSON-LD is a machine-readable copy of claims the page already makes. If the page names the wrong company, the markup will too, only faster. A correct Organization node is useful. It is not a third-party record, and it is not proof that the publisher controls the domain. AI Verified is not endorsing the firm’s other services.
An earlier automated note quoted a Marketpath headline under this title. That sentence belongs to a different article. It has been removed.
Read the source: JSON-LD for AI Retrieval: Best Practices (The Ad Firm).