# Last verified or updated timestamp reflects actual verification date

- **Pattern:** `ab-001019` (`directory-listing-schema.structured-data.verification-timestamp`)
- **Severity:** high
- **Lifecycle:** active
- **Last modified:** 2026-04-18
- **Canonical URL:** https://auditbuffet.com/patterns/ab-001019
- **License:** CC-BY-4.0 — attribute to AuditBuffet Pattern Catalog (https://auditbuffet.com/patterns/ab-001019)

## Why it matters

A `dateModified` field populated only at creation time and never updated tells Google and AI crawlers that your listings are perpetually fresh — regardless of whether the underlying data is years stale. The schema-org `dateModified` property is used by search engines to prioritize recrawl frequency and by users to assess trustworthiness. Directories with static creation-time timestamps signal data decay: a business that closed 18 months ago still appears current. When users or LLMs consume your structured data and discover the timestamps are lies, the directory's authority collapses. Data freshness is a core data-integrity guarantee for any directory product.

## Severity rationale

High because a static or submitter-controlled timestamp deceives search engine recrawl heuristics and erodes user trust when listings display outdated information without any staleness signal.

## Remediation

Set `dateVerified` and `dateModified` server-side whenever listing data is updated or verified — never accept these timestamps from the submitter. Write the timestamp in the same transaction as the update.

```ts
// In your listing verification handler (e.g., src/app/api/listings/[id]/verify/route.ts)
await db.listing.update({
  where: { id: listingId },
  data: {
    // ... verified field values
    dateVerified: new Date(),
    dateModified: new Date(),
  },
});
```

Include `dateModified` in the JSON-LD block as an ISO 8601 string: `"dateModified": listing.dateModified.toISOString()`. Also update `dateModified` on any owner-initiated edit to the listing's content fields.

## Detection

- **ID:** `verification-timestamp`
- **Severity:** `high`
- **What to look for:** Enumerate every listing record. For each, check the listing schema for a `dateModified` or verification timestamp field. Verify this field is set only when the listing data is actually verified or updated, not at creation time. Check the business logic for when this timestamp is updated.
- **Pass criteria:** The `dateModified` or verification timestamp is set to the actual date the listing data was last verified or updated, not a static creation date — 100% of listings must include a verification or last-updated timestamp. Report: "X listings found, all Y have verification timestamps."
- **Fail criteria:** The timestamp is never set, or it's set to the creation date and never updated, or it's manually entered by the submitter without server validation.
- **Skip (N/A) when:** Never — data freshness is critical for directories.
- **Detail on fail:** Quote the actual timestamp handling code. Example: `"Verification timestamp set at creation and never updated"` or `"No dateModified field in JSON-LD"` or `"Submitter can manually set dateModified to any date without validation"`
- **Remediation:** Automatically set the verification timestamp when data is verified. Example:

  ```ts
  await db.listing.update({
    where: { id: listing.id },
    data: {
      dateVerified: new Date(),
      dateModified: new Date()
    }
  })

  const jsonLd = {
    "@type": "LocalBusiness",
    "dateModified": listing.dateModified.toISOString(),
  }
  ```

## External references

- schema-org dateModified

Taxons: findability, data-integrity

HTML version: https://auditbuffet.com/patterns/ab-001019