Last verified or updated timestamp reflects actual verification date

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.

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.

// 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.

• ID: directory-listing-schema.structured-data.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:

  await db.listing.update({
    where: { id: listing.id },
    data: {
      dateVerified: new Date(),
      dateModified: new Date()
    }
  })
  
  const jsonLd = {
    "@type": "LocalBusiness",
    "dateModified": listing.dateModified.toISOString(),
  }