All legal pages display last-updated or effective date

GDPR Art. 13(1) requires that privacy notices state when they were last updated so users can determine whether they have seen the current version of the policy. CCPA §1798.130(a)(5)(B) requires the privacy policy to include the date it was last updated. A date-free legal page gives users and regulators no way to verify whether the policy reflects current data practices — which is itself a compliance gap. Placeholder dates (Last updated: [DATE], Month DD, YEAR) are evidence that the page was deployed without review and have been used by regulators as evidence of systematic non-compliance in enforcement proceedings.

Add a hardcoded LAST_UPDATED constant near the top of every legal page component and render it prominently. Update this constant whenever you make a substantive change to the page.

// app/terms/page.tsx — same pattern for /privacy, /refund-policy, etc.
const LAST_UPDATED = 'February 15, 2026'  // Update when content changes

export default function TermsPage() {
  return (
    <main className="max-w-3xl mx-auto px-4 py-12 prose">
      <h1>Terms of Service</h1>
      <p className="text-sm text-muted-foreground mt-1">
        Last updated: {LAST_UPDATED}
      </p>
    </main>
  )
}

For MDX-based legal pages, use frontmatter: lastUpdated: 2026-02-15 and render {frontmatter.lastUpdated} in the page header. Search all legal page files for [DATE], YYYY-MM-DD, and Month DD, YEAR to catch any remaining placeholders.

• ID: legal-pages-compliance.accessibility-currency.last-updated-date

• Severity: low

• What to look for: Enumerate every relevant item. Read each legal page that exists and check for a last-updated or effective date near the top of the page — typically in the heading, subheading, or first paragraph. The date should be a real, specific date in an unambiguous format (e.g., "February 15, 2026" or "2026-02-15") — not a placeholder like "[DATE]," "YYYY-MM-DD," "Insert date here," or "Month DD, YEAR." Check whether the date is hardcoded in the content or rendered dynamically from a frontmatter field or CMS field. A date that appears to be the initial publication date and has never been updated despite other content changes on the site is still technically passing this check — the check evaluates presence of a date, not freshness. Freshness is covered by the material-change-notification check.

• Pass criteria: At least 1 of the following conditions is met. All legal pages that exist display a specific, non-placeholder last-updated or effective date near the top of the page.

• Fail criteria: One or more legal pages have no date. One or more pages have a placeholder date (e.g., "Last updated: [DATE]"). Date format is ambiguous (e.g., "01/02/03" which is unclear across locales).

• Skip (N/A) when: No legal pages exist (flagged by existence checks above).

• Detail on fail: Specify which pages are missing dates. Example: "Terms of Service has no last-updated date. Privacy Policy shows 'Last updated: [DATE]' — placeholder not replaced." or "Refund Policy has no effective date or last-updated date anywhere on the page.".

• Remediation: Add a last-updated constant to each legal page and display it prominently:

  // Consistent pattern for all legal pages
  // app/terms/page.tsx
  const LAST_UPDATED = 'February 15, 2026'  // Update this when content changes
  
  export default function TermsPage() {
    return (
      <main className="max-w-3xl mx-auto px-4 py-12 prose">
        <h1>Terms of Service</h1>
        <p className="text-sm text-muted-foreground mt-1">
          Last updated: {LAST_UPDATED}
        </p>
        {/* content */}
      </main>
    )
  }
  

  For MDX-based legal pages, use frontmatter:

  ---
  title: Terms of Service
  lastUpdated: 2026-02-15
  ---
  
  # Terms of Service
  
  Last updated: {frontmatter.lastUpdated}
  

  Update this date whenever you make a substantive change to the legal page content. Cosmetic or formatting changes do not require a date bump, but any change to rights, obligations, or policies does.