Content-freshness policy — high-level pointers (local fallback)

celebi tells you which pages are stale and how old their content is. The detailed, current refresh policy — the exact cadence per content type, which pages to prioritise, and the house age thresholds — lives in the team wiki (set OUTLINE + OUTLINE_API_URL, scope with CELEBI_WIKI_COLLECTION, and the report links it directly). This file is the minimal high-level fallback for when the wiki isn’t configured: direction only, deliberately not step-by-step, so there’s nothing to drift out of sync.

• Prioritise by traffic × staleness — refresh the oldest pages that still earn visits first; a stale page nobody reads can wait.
• Cadence by content type — news is stale in months, blog/articles within a year, evergreen pages hold for years, legal/policy only when the facts change.
• Update the dates together — when you refresh, bump the visible “Last updated” date and the schema dateModified so the freshness signal is real, not cosmetic.
• Don’t churn evergreen pages — re-dating a page with no substantive change is noise; refresh the content, not just the timestamp.

Full playbook → the team wiki’s content-freshness reference (per-type cadence, prioritisation, refresh procedures).