You rewrote the page, added a Direct Answer block, and marked it up with schema. ChatGPT and Perplexity still cite a competitor's page that has not been touched in three years. The reason is usually not the content itself. It is that nothing on your page actually told the crawler the content changed.
Content freshness signals are the machine-readable and visible cues, HTTP headers, sitemap timestamps, structured data, and on-page dates, that tell an AI crawler how recently a page was verified as accurate. AEO Excellence runs audits that catch exactly this gap: sites with genuinely current content that never tells a crawler so, and sites that fake freshness with a cron job instead of a real edit. Both get skipped for citation in favor of a page that proves it was checked.
The cost of missing this is not obvious until you compare two pages side by side. A page updated last week with no freshness signals looks, to a crawler deciding what to recrawl, identical to a page that has not been touched since it was published. The crawler has no reason to spend a fetch on it, so the update never gets seen, and the citation keeps going to whichever competitor page happens to send the right headers.
What Counts as a Content Freshness Signal?
A content freshness signal is any data point a crawler can read without rendering the full page that indicates when the content last changed for real. Four signals do almost all of the work: the HTTP Last-Modified response header, the sitemap's lastmod element, a dateModified property in JSON-LD schema, and a visible "Updated on" date near the headline.
Crawlers weight these differently. A header or sitemap value is cheap to check before a full crawl, so it often decides whether the page gets recrawled at all. Schema and visible dates matter once the page is actually fetched and parsed, because they confirm what the header already implied.
A common mistake is treating these four signals as interchangeable. A site that only updates the visible date while the HTTP header and sitemap stay static is telling a human reader one story and a crawler a different one, and the crawler's version is the one that decides whether the page gets revisited at all.
How Often Do AI Crawlers Actually Recheck a Page?
GPTBot typically revisits a mid-size site every 2 to 7 days, and Perplexity refreshes its index faster for pages tied to trending topics. Google-Extended, the crawler that feeds Gemini and AI Overviews, runs on Google's standard organic crawl schedule rather than its own cycle.
None of these crawlers re-read every page on every pass. They prioritize pages whose freshness signals suggest something changed since the last visit. A page with a static Last-Modified header from eight months ago gets deprioritized even if you rewrote three paragraphs yesterday, because the header never told the crawler to look again.
This matters most on sites behind a CDN or a static site generator, where the Last-Modified header often reflects the last full deploy rather than the last content edit. A single copy fix pushed through a build pipeline can carry the same header as a change made six months earlier, which erases the exact signal you are trying to send.
Which Freshness Signal Should You Fix First?
Fix the HTTP Last-Modified header first, because it is checked before the crawler downloads anything else on the page. The table below ranks all four signals by how early a crawler reads them and how much effort each one takes to maintain correctly.
| Signal | Where It Lives | When a Crawler Reads It | Effort to Maintain |
|---|---|---|---|
| Last-Modified header | HTTP response headers | Before the page body downloads | Low, server config |
| Sitemap lastmod | sitemap.xml | During sitemap crawl, before the page visit | Low if tied to publish workflow |
| dateModified schema | JSON-LD in the page head | After the page is parsed | Medium, must match a real edit |
| Visible updated date | Near the H1, on the page | After the page is parsed | Medium, easy to forget |
Notice that the two cheapest signals to maintain, the header and the sitemap, are also the two a crawler reads earliest. Fixing those first gets you the biggest change in recrawl priority for the least engineering effort, and the schema and visible date can follow once the pipeline is in place.
How Do You Set Up Real Freshness Signals?
Setting up real freshness signals takes five changes, most of them one-time server or template work rather than ongoing manual effort.
- Configure your server or CMS to send a true Last-Modified header tied to the actual last content edit, not the last deploy.
- Update the sitemap's lastmod value only when the page content changes, driven by your CMS save event rather than a nightly cron job, following the format defined in the sitemaps.org protocol.
- Set dateModified in your Article or FAQPage JSON-LD to the same timestamp as the Last-Modified header, using the schema.org dateModified property.
- Add a visible "Updated on" date near the H1 so a human and an AI agent parsing the rendered page see the same date the header claims.
- Log what changed in a short changelog note if the edit is substantive, since a one-word edit and a rewritten section should not carry the same freshness weight.
The step teams skip most often is the second one. A sitemap generated once at build time and never touched again quietly freezes every lastmod value at the deploy date, which means every future content edit is invisible to a crawler reading the sitemap first.
Why Most Teams Fake Freshness Instead of Building It
The fastest way to fail this is a script that rewrites dateModified to today's date on every deploy, whether or not the content changed. Crawlers that cross-reference the claimed date against the actual rendered text catch this quickly, and a page caught faking freshness loses trust for future crawls too, not just the current one.
This is the exact failure mode AEO Excellence's audits flag most often on existing clients: schema that claims a page was updated today while the visible text has not changed in months. Our FAQ walks through how the Monitor stage of an AEO engagement tracks freshness signals against real content diffs instead of trusting a timestamp on its own.
Isn't This Just Extra Engineering Work for a Small Ranking Bump?
For a single page, yes, it is a small change. Across a site with a real content calendar, it is the difference between a crawler treating your whole domain as actively maintained or stale. The work is mostly configuration, not ongoing labor: once the Last-Modified header and sitemap lastmod are wired to your CMS's real save event, they update themselves correctly for every future edit with no extra step.
The honest tradeoff is that dateModified and the visible date still need a human to confirm the edit was substantive, not cosmetic. That five-minute check per publish is the only recurring cost, and it is the same discipline the four-stage Audit, Architect, Implement, and Monitor methodology is built to enforce.
What's the Next Step?
Pick your five most important pages and check whether the Last-Modified header, sitemap lastmod, and dateModified schema on each one actually agree with the last real edit date. Where they do not, you have found the freshness gap a crawler is already seeing. If you want a second set of eyes on all four signals across your full site rather than five pages, contact AEO Excellence for an audit and you will get a prioritized list of exactly which pages are sending stale signals first.