- Methodology
- Parameters
- Content Freshness
Content Freshness
stableCategory: authority · Methodology v4.5
This parameter checks how recent your content appears to AI systems.
Signal Source
- Source
https://{domain}- Kind
- http_response
Score Bands
| Verdict | Condition |
|---|---|
| Pass | the most recent strong freshness signal (Last-Modified header, JSON-LD dateModified, or visible date) is within 90 days |
| Partial | the most recent strong freshness signal is between 90 and 365 days old, OR only a server Date header within 365 days is available as a weak fallback |
| Fail | no freshness signals are found, or the most recent strong signal is older than 365 days |
Description
What this parameter measures
This parameter checks how recent your content appears to AI systems. friendly4AI collects dated signals from several sources (the Last-Modified HTTP header, JSON-LD dateModified, visible "Last updated" dates in the page text, and the server Date header), then selects the most recent strong signal and measures its age in days. Strong signals (Last-Modified, dateModified, visible dates) drive the score; the server Date header is treated only as a weak fallback when no strong signal exists, because it reflects when the page was served rather than when its content actually changed.
Why it matters for AI-readiness
AI engines favour current information and discount content that looks stale. Perplexity, ChatGPT search, and Gemini all weigh recency when choosing what to surface, so a page with no freshness markers, or one whose newest signal is a year old, is easy for them to pass over in favour of a dated competitor. Explicit, honest freshness metadata tells a model your content is maintained and worth citing today. The dates have to reflect real edits, though: stamping an old page with a fresh date without updating the content is the kind of signal AI systems learn to distrust.
How we score it
This Authority and Trust parameter uses an age-based classifier under the v4.4 methodology. With a strong signal present, a page passes (100) when the newest signal is within 90 days, earns a partial (50) when it is between 90 and 365 days old, and fails (0) when it is older than a year. When only the server Date header is available, the result caps at partial (within 365 days) or fail (older), and a complete absence of any signal fails. A newer v2.2 enhancement (config-gated, off by default) replaces the binary 90/365 split with a four-band classifier (fresh, recent, aging, at-risk) plus a Perplexity-staleness flag and a future-dated-signal guard; when that flag is disabled, the 90/365 bands documented here are the live behaviour.
How to fix common issues
- Send an accurate
Last-ModifiedHTTP header that updates whenever the page content genuinely changes. - Add
dateModifiedto your JSON-LD (Article,WebPage, or similar) and keep it aligned with the real edit date. - Show a visible "Last updated" date on substantive pages so both readers and crawlers see the recency.
- Do not back-date or fake freshness; keep every date tied to a real content update, since mismatched signals erode trust.
- Re-scan and check the
freshness_days,freshness_source,last_modified_header, andschema_date_modifiedevidence fields.
Version History
- Introduced
- v4.0
- Last changed
- v4.4
Key takeaways
- Signal: https://{domain}
- Category: Authority & Trust
- Passes when: the most recent strong freshness signal (Last-Modified header, JSON-LD dateMo…