Recency and Authority — Two Fields AI Uses to Trust You

An AI accepts two judgments before it ever quotes you. First — is this still current? Second — who actually wrote this? Both happen in fractions of a second, both ride on machine-readable signals you either supplied or didn't.

Here's what's actually happening under the hood of the citation pipeline — and where you fit in it.

What does a model check before it quotes you?

When an LLM composes an answer and is looking for sources to cite, it runs candidates through two filters:

• Recency check — is the information current? A 2019 post about the Next.js App Router would be a strange thing to quote, and not only because it is old: the App Router did not exist until Next.js 13 in late 2022, so the date and the subject contradict each other outright.
• Authority check — does the author have weight in this niche? An anonymous Medium post and a senior engineer's post are very far from the same thing for weighted ranking.

A caveat on how hard to read that first filter. No engine publishes a recency rule, and "stale content gets dropped instantly" is something the industry repeats rather than something anyone has demonstrated. What is safe to say is weaker and still worth acting on: a page carrying no date at all gives a retriever nothing to weigh, and dating a page costs you one field. Supply the signal and let the engine decide what to do with it.

No signal — no trust. The AI doesn't guess. It reads what you gave it.

datePublished and author — the canonical fields

Inside the Article Schema.org type, these two fields carry the load. Here's the canonical pattern for embedding the JSON-LD via a <script> block in a Next.js server component:

import React from 'react';
 
interface PageProps {
  params: Promise<{ slug: string }>;
}
 
export default async function BlogPostPage({ params }: PageProps) {
  const { slug } = await params;
 
  const jsonLd = {
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "Recency and Authority in AI Citations",
    "datePublished": "2026-05-07T08:00:00Z",
    "dateModified": "2026-05-07T08:00:00Z",
    "author": {
      "@type": "Person",
      "name": "Oleksii Turovskyi",
      "url": "https://alexturik.com",
      "sameAs": [
        "https://github.com/turovskiy",
        "https://linkedin.com/in/alexturik",
        "https://x.com/alexturik"
      ]
    }
  };
 
  return (
    <article className="max-w-3xl mx-auto py-10 px-4">
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
      />
      <header className="mb-8 border-b pb-4">
        <h1 className="text-4xl font-bold text-gray-900">
          Recency and Authority in AI Citations
        </h1>
        <time dateTime="2026-05-07T08:00:00Z" className="text-sm text-gray-500 mt-2 block">
          May 7, 2026
        </time>
      </header>
      <div className="prose prose-blue lg:prose-lg">
        <p>Article body starts here…</p>
      </div>
    </article>
  );
}

Perplexity, ChatGPT browse, Google AI Overviews, Claude search — they all look at this structure first. Long before they start parsing your HTML.

Why doesn't a "1 hour ago" badge count?

This is where most sites quietly fail. You see "published an hour ago" on the rendered page and assume the date is there. To machines, it isn't.

A text badge is for human eyes only. The crawler ignores it, because the string "1 hour ago" cannot be safely resolved to an exact timestamp without deep context. What an algorithm actually needs:

1. Minimum — a semantic <time datetime="2026-05-07T08:00:00Z">May 7, 2026</time> in the HTML.
2. Better — a datePublished field in JSON-LD.
3. Gold standard — both, in HTML and JSON-LD. Duplicating the data here is a feature, not a bug.

Why is a bare author string not enough?

This is the single most common mistake. People write "author": "Oleksii Turovskyi" and move on. Technically valid. Authority — zero.

The right structure is a Person object with an identity graph through the sameAs array. sameAs is the glue that fuses you to your reputation across other ecosystems.

A GitHub account with a commit history, a LinkedIn with relevant experience, a Twitter with expert activity — the AI sees this whole graph and builds a model: who you are, what you're an expert in, whether it's worth quoting you specifically in this knowledge vertical. Without sameAs you're a text string. With it — a person with a reputation footprint.

Backup via meta tags

There are situations where embedding JSON-LD painlessly isn't an option. An old WordPress without access to header.php. A legacy build. A Jamstack with a stale theme. That's when meta tags in <head> step in. Second-tier signal, but AI crawlers do read them.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Recency and Authority in AI Citations</title>
 
  <meta property="article:published_time" content="2026-05-07T08:00:00Z">
  <meta property="article:modified_time" content="2026-05-07T08:00:00Z">
  <meta name="author" content="Oleksii Turovskyi">
</head>
<body>
  <article>
    <h1>Recency and Authority in AI Citations</h1>
  </article>
</body>
</html>

This is not a full replacement for the sameAs graph. But it's much better than naked HTML with no signal at all, and definitely better than leaving your authority an open question for a hallucinating model.

What does dateModified actually buy you?

This one gets overlooked all the time. You update an old article — add fresh benchmarks, rewrite a section on hooks, fix outdated CLI commands. Without dateModified, the only date any machine can read is still the original datePublished from 2023, so every consumer downstream is working from a number you know to be wrong.

Add dateModified and the record matches reality. Whether that converts into a citation is not something I can promise you, per the caveat above — but shipping an edit while leaving the markup asserting a stale date is a self-inflicted wound, and correcting it costs one field.

What is the most common date-format mistake?

"datePublished": "2026/05/07"          ✗ invalid
"datePublished": "May 7, 2026"         ✗ invalid
"datePublished": "07.05.2026"          ✗ invalid
"datePublished": "2026-05-07T08:00:00Z" ✓ ISO 8601, works

Schema.org requires ISO 8601. No exceptions. Plug your URL into validator.schema.org after every template change — it catches this in seconds.

Reusable author schema

Wrap the block once and you get authority signals on every publication, forever:

export function getAuthorSchema() {
  return {
    "@type": "Person",
    "name": "Oleksii Turovskyi",
    "url": "https://alexturik.com",
    "sameAs": [
      "https://github.com/turovskiy",
      "https://linkedin.com/in/alexturik",
      "https://x.com/alexturik"
    ]
  };
}

Call it inside every JSON-LD generator. Write it once — pays back across every post.

Field reference

What each field is for, and what breaks when it is missing or wrong.

The offset is the part people miss. 2026-08-09 parses, but Google's Rich Results Test reports it as an invalid date-time, because a date with no time zone is not a moment — it is a different instant in every country.

FAQ

What is the difference between datePublished and dateModified?

datePublished is when the page first went live and never changes. dateModified is when the content last meaningfully changed. Models weigh the second more heavily for anything time-sensitive, because it answers "is this still true" rather than "when was this written".

Should I update dateModified to look fresh?

No. Bumping the date without changing the content is the structured-data equivalent of a doorway page — the claim and the document disagree, and both Google and the crawlers that build citation indexes compare them. Update the field when you update the article, and the signal stays worth something.

Why isn't a visible "Updated 1 hour ago" enough?

Because it is prose. A machine reading the page sees a string that could be generated, templated, or relative to a build time it cannot resolve. The machine-readable field is what gets parsed; the visible badge is what reassures the human. Ship both, and make them agree.

Does author have to be a Person rather than a string?

author: "Oleksii Turovskyi" is technically valid and practically useless. A Person object with a url is an entity that can be linked to a profile, a body of other work, and a reputation — which is what an authority check is actually looking for. A string is just characters.

How do I see what a crawler makes of my dates?

Run the Rich Results Test for Google's reading, and check the raw JSON-LD for the offset. The AEO Checker extension surfaces whether the page carries JSON-LD at all, which is the failure mode that hides behind a green visual check.

Sources

• schema.org/datePublished · schema.org/dateModified · schema.org/author
• Google Search Central: Article structured data — which date fields Google reads and how
• RFC 3339, Date and Time on the Internet — the offset requirement that trips up date-only values

Part of the Answer Engine Optimization cluster — the full reading order in dependency sequence, plus a glossary of every term used across these articles.

Auditing your own site?

Open the Schema Markup Validator on a recently-published post. If datePublished is missing, malformed, or the author is a bare string — your recency and authority checks are silently failing on every AI citation pipeline that visits your domain.

Follow me on LinkedIn for more on AEO architecture. For a structured-data audit or schema implementation on your platform, get in touch.