Perplexity cites you, often not because your articles are the best, but because at the moment a user submits a question, your page is the "latest and can be instantly confirmed not out of date" source. Content freshness is not a bonus in rankings at Perplexity, it is the threshold for inclusion in the candidate source list. You can have an excellent analysis written two years ago, but as long as it looks like an old page that no one maintains, the model will skip it when answering the timeliness question and move to a inferior piece of content with newer information and clearer server responses.
Where does Perplexity read your "freshness"?
Let’s distinguish two things first. Perplexity also maintains its own index, as well as the ability to crawl web pages on the fly when users ask questions - its crawler PerplexityBot is responsible for building the index, and another Perplexity-User agent is answering to confirm the page content. This means that the freshness signal is read at two points in time: when indexing, and when the question is answered. You want the "when this page was last updated" seen at these two points in time to be consistent and credible. Questions that are highly time-sensitive (price, version, regulations, annual figures) are particularly susceptible to this problem. The model will tend to select pages that have been recently moved and have been moved with evidence.
- HTTP response headers: Last-Modified and ETag, which are used by the crawler to make conditional requests to determine "whether there have been changes since the last crawl."
- lastmod of sitemap.xml: tells the crawler which URLs are worth revisiting first.
- Structured data in the page: dateModified and datePublished of Article/BlogPosting, allowing the model to know the update time of the content declaration.
- Visible date on the page: "Last updated" marked at the beginning or end of the article, both humans and models will read it.
- The timeliness signal of the content itself: whether the year, version number, and latest number mentioned in the article match the declared update date.
First correct the freshness signal at the server layer
Most teams put all their efforts into changing the content, but let the server return an incorrect or missing Last-Modified. This is the most common and easiest vulnerability to fix. Correct approach: Every time the actual content of the page changes, update the Last-Modified header to the current time; if the content does not change, maintain the original value. Paired with the ETag, this content fingerprint hash allows the crawler to issue conditional requests using If-Modified-Since or If-None-Match. If the page has not changed, your server will return 304 Not Modified without transmitting the entire HTML; if it has changed, it will return 200 with new content. Many sites that use front-end frameworks or CDNs by default return each request to 200, and Last-Modified also points to the deployment time, causing each page to look like "it has just been modified and yet it seems that it has not been modified." The signals are contradictory.
Why conditional requests affect how often you get caught
The crawler has an implicit crawl budget for each website, and it will not crawl you unlimited times. When your server can quickly reply "No change" with 304, the crawler can spend the saved resources on returning to the truly updated page, thus shortening the return cycle. On the other hand, if you are forced to download the entire page every time you crawl it, and cannot find a clear update time, the crawler will learn that "the signal at this site is unreliable" and the frequency of return visits will decrease. When we perform GEO audits for clients, one of the most common findings is that after repairing this layer, the interval between key pages being re-crawled is significantly shortened.
sitemap's lastmod must be honest
The lastmod of sitemap is an important basis for crawler prioritization, but it is only useful when it is "accurate". A common mistake is to refresh the lastmod of all URLs to today every time the entire site is deployed, which is equivalent to telling the crawler "my entire site changes every day." The crawler will soon discover that the content has not changed, and the credibility of the entire sitemap will decrease, including the pages that were actually updated. The correct approach is to let lastmod reflect the actual change time of the URL content, calculated page by page, rather than using the build time to apply it with one click. Only include URLs that are truly worth revisiting, and don’t dilute the signal by cramming in pagination, tab pages, and parameter pages.
dateModified must be consistent with the visible date of the page
DateModified in structured data, Last-Modified in HTTP, lastmod in sitemap, and "Last updated on" visible to the naked eye on the page, these four numbers should point to the same thing. When they contradict each other—the schema says updated today, but the page says last year, and the server header says another time—the model is getting noise and can only conservatively distrust your claims of freshness. In practice, the update time is centralized into a single source of data, such as the actual modification timestamp in the content management system, and all four outlets are rendered from it, so that everyone can avoid talking about it. datePublished retains the original publication date, dateModified reflects the last substantial modification, both are required.
Update frequency: Spend effort on pages that will expire
Not every page needs to be updated frequently, and forcing the entire site to be renovated regularly will only dilute your maintenance resources. First, divide the content into two categories: one type is expiring, such as pricing, product comparisons, integration lists, annual trends, regulations and versions; the other type is relatively constant, such as noun definitions and principle explanations. The expiring pages are scheduled for a fixed review cycle, updated as soon as the information changes, and four time signals are synchronized to keep up; the permanent pages are only updated when there is substantial additions. The criterion for judging "whether it should be updated" is whether there are substantial changes in the content, not the calendar. If you only change one word at a time but refresh the update date, the model will see it and will not trust you more.
Freshness is not about "how often it is changed", but "whether there is a reason for the change, and the four places agree on it." The crawler trusts a predictable maintenance rhythm, not frequent but empty changes.— Tenten GEO
Re-fetch: You can't command Perplexity, but you can increase the chance
- Make sure robots.txt does not block PerplexityBot and Perplexity-User. Both must be allowed, otherwise all subsequent efforts will be in vain.
- After updating the key page, refresh the Last-Modified, sitemap lastmod and schema dateModified of the URL simultaneously, so that the three parties are consistent.
- Reduce server response time and correctly respond with 304 to unchanged pages, giving up crawl budget to updated pages.
- Connect from a high-traffic, frequently visited page to a newly updated page, and use its frequency of return visits to drive the new page to be discovered faster.
- After the update, create a new crawl trigger in other channels (own e-newsletters, communities, externally referenced pages) to increase the chance of being caught immediately.
By doing this, you are not flattering an algorithm, but allowing every real update to be read quickly and correctly by Perplexity. The problem with most websites is not that the content is not good enough, but that the freshness signals are contradictory, causing good content to be ignored as old pages. If you want to know where your site is fighting with each other in the four areas of Last-Modified, sitemap, schema, and visible dates, you can schedule a 30-minute GEO diagnosis (/contact), and we will directly point out the signal gaps that are causing Perplexity to skip you.
