Date triangulation: How Google Determines When a Page Was Really Published
The patent that reveals six different date sources Google uses — and why faking a byline date doesn't work
What is Date triangulation?
Date triangulation is Google's system for determining when a page was actually published or last updated. It does not rely on a single date source — instead, it triangulates from multiple signals, comparing them to detect inconsistencies and establish the most reliable date.
The Google API leak reveals three date fields: bylineDate (the visible date in the article — easy to fake), syntacticDate (the date from URL structure, structured data, or server timestamp — also manipulable), and lastSignificantUpdate (the date Google determined the content was last meaningfully changed — the hardest to fake because it is derived from content analysis).
The triangulation approach is specifically designed to resist date manipulation. A publisher can change the visible date on a page (bylineDate), but they cannot easily change when Google first crawled the page, when the domain was registered, or when the page was first referenced by other documents. By comparing multiple date sources, Google can detect when a byline date doesn't match the other evidence.
The patent: six inception date sources
US7346839B2 describes the inception date determination mechanism in Claims 2-5. The patent lists six different sources Google can use to determine a document's inception date, each with different reliability characteristics.
The first source is the crawl or index date: when Google's search engine first discovers or indexes the document. This is reliable but biased — a page may have existed for years before Google discovered it. The second is the first link date: when Google first discovers a link pointing to the document. This can predate the crawl date if the linking page was crawled before the target.
The third source is the domain registration date: when the domain was registered. This provides a hard lower bound — the page cannot have been created before the domain existed. The fourth is the first reference date: the first time the document is referenced in a news article, newsgroup, or mailing list. The fifth is the page count threshold: the date when the document first reaches a minimum number of pages. The sixth is the server timestamp: a time stamp set by the server hosting the document.
The patent explicitly notes that some of these techniques are 'biased' (can be influenced by third parties) while others are not. The inception date is determined from the combination of these sources, not from any single one. This multi-source approach is the essence of triangulation: each source provides an independent data point, and the system reconciles them to find the most likely true date.
Date triangulation in the ranking architecture
Date triangulation feeds into FreshnessTwiddler (System 24) — it provides the date information that FreshnessTwiddler needs to assess content freshness. This dependency chain is the architectural reason why date manipulation matters: if a publisher fakes a byline date, Date triangulation may still detect the true date through other sources, and FreshnessTwiddler will use the corrected date for its freshness assessment.
Date triangulation is a primary Trust signal (T: primary). Date manipulation is a direct trust violation — it deceives both Google and users about when content was published. A page that claims to be 'updated today' but was actually last modified three years ago is breaking the implicit trust contract.
The system has no upstream dependencies (fedBy is empty) — it is a primary signal derived directly from Google's crawl data, domain registration records, and content analysis. It is a source, not a transformer: it produces date information that other systems consume.
Implications for SEO practitioners
The patent's multi-source approach means that faking a single date source is not enough. A publisher can change the visible byline date, but Google will cross-check it against the crawl date, the domain registration date, the first reference date, and the server timestamp. If these don't match, the system will discount the faked date.
For content that genuinely needs to signal freshness, the strategy is to update substantively. The system tracks not just when the date changed, but when the content itself changed — through the lastSignificantUpdate field. A genuine content update that adds new information will produce a consistent signal across all date sources: the byline date matches the crawl date, which matches the content change.
For domain migrations and rebrands, the date triangulation can work against you: a new domain will have a new domain registration date, a new first-crawl date, and no historical reference data. This is the date-level equivalent of the hostAge-Sandbox effect — the new domain's content will appear 'newer' than it actually is, which can be good for freshness queries but bad for authority signals that reward age.
Google has officially communicated about date determination, which is unusual — most ranking systems are not discussed publicly. This gives Date triangulation an [O] evidence code, stronger than systems known only from the leak.