Keeping a content guide current: dated facts and recheck dates

A content guide stays current when every fact that can change is written down with its source, the date it was checked and the date it must be checked again. On top of that register sit three habits: change the visible "Last updated" date only when the content really changed, keep the sitemap's lastmod value accurate, and have a clear rule for when a page gets updated, rewritten or merged into another.

Facts go stale in two ways. Some changes are scheduled: a law takes effect on a known date, or a temporary rule is set to expire. Others arrive with little warning: Google stopped showing FAQ rich results for all sites on May 7, 2026, so any page still telling readers to add FAQ markup to win rich results became wrong. A register with recheck dates handles the first kind. A routine review handles the second.

Why guides go stale

A guide with 40 or 100 articles may repeat the same fact on a dozen pages. When the fact changes, every one of them has to change, and nobody remembers all twelve. Common sources of change:

• Laws and regulations with effective dates, sunset dates and phased rollouts.
• Platform policies. Google's documentation shows how often these move. In 2026 alone, FAQ rich results ended (the documentation was removed on June 15, 2026), the policy formerly called "site reputation abuse" was renamed "Site reputation policy" in August, and on May 15 Google clarified that its spam policies also apply to generative AI responses in Search.
• Vendor prices and plans, which change without notice.
• The business itself: new services, retired services, new locations, new prices, new staff.

The last one is the easiest to miss, because nobody announces it to the content team.

Build a dated-fact register

The register is a spreadsheet with one row per fact. It grows out of the research file you build before writing, which our guide to research files for YMYL content covers. The register adds the forward-looking columns.

The "pages that use it" column does most of the work. When a fact changes, you search one row instead of the whole site. Keep a separate list of claims that could not be verified; those stay out of the guide until someone confirms them.

Setting recheck dates

For scheduled changes, set the recheck date before the change happens, so the page can be updated on the day rather than weeks later. Two anonymized examples from guides we've built:

• On an adult ADHD guide for a psychiatry practice, a telehealth prescribing flexibility set to expire on December 31, 2026 was logged with a recheck date.
• On a window-replacement guide, a state law taking effect on January 1, 2027 was logged the same way.

Unscheduled changes need a routine instead of a date. The schedule below is house practice, a starting point rather than a rule.

Rechecks on medical, legal or financial pages go back through review when the facts change. Our guide to expert review before indexing covers how that review is logged.

Visible dates: what Google recommends

Google's page on byline dates says "Google doesn't depend on a single date factor." It recommends a prominent, user-visible date labeled "Published" or "Last updated," plus datePublished and dateModified in Article, BlogPosting or VideoObject structured data. Its other advice is short:

• "Make your dates and times consistent." The visible date and the structured data should agree.
• "Don't specify future dates."
• "Minimize the presence of other dates on the page."

Google doesn't guarantee that a byline date will show in results.

The date must also be honest. Google's helpful-content page lists "Are you changing the date of pages to make them seem fresh when the content has not substantially changed?" as a warning sign. It also asks whether you are "adding a lot of new content or removing a lot of older content primarily because you believe it will help your search rankings overall by somehow making your site seem "fresh?" (No, it won't)." Change "Last updated" when a fact, a recommendation or a section changed, not when you fixed a typo.

Sitemap lastmod: accurate or useless

The lastmod value in an XML sitemap tells search engines when a URL last changed. Google's sitemap documentation says: "Google uses the <lastmod> value if it's consistently and verifiably (for example by comparing to the last modification of the page) accurate." It defines the right value as "the date and time of the last significant update to the page," and says "an update to the main content, the structured data, or links on the page is generally considered significant, however an update to the copyright date is not."

Two practical consequences:

1. Don't stamp every URL with today's date on each build. If lastmod changes when the page doesn't, it stops being verifiably accurate, and Google says it uses the value only when it is.
2. Don't bother with priority or changefreq. "Google ignores <priority> and <changefreq> values."

One approach is a small ledger that records a page's content fingerprint and the date it last changed, so lastmod moves only when the content does. Submitting a sitemap remains, in Google's words, "merely a hint."

Update, rewrite, merge or retire

Not every stale page deserves the same treatment. This table is a decision aid, not a Google rule.

Google's canonicalization documentation calls redirects "A strong signal" and rel="canonical" "A strong signal," and says "We don't recommend using noindex to prevent selection of a canonical page within a single site." Overlap alone isn't a crisis: "Some duplicate content on a site is normal and it's not a violation of Google's spam policies." Choosing which page owns a question is covered in mapping every article to a money page, and rewriting older posts in how to update old blogs.

Refresh the money pages too

Articles exist to hand readers to a service or product page. If that page changes and the guide doesn't, the guide starts quoting old prices or describing services that no longer exist. It can also go the other way. On a custom awards company's guide, a planned comparison post would have competed with a product page that already had a comparison table and five FAQs on the same question. The plan went stale against its own money pages a second time later, so the plan is now re-checked before every batch, not just at the start.

Price and cost pages need the closest watch, because a stale number misleads the reader at the moment of decision. Our guide to pricing and cost pages covers how to date them.

A simple upkeep routine

1. Each month, sort the register by "Recheck by" and work through everything due.
2. For each changed fact, update every page in its "pages that use it" column, including FAQs, answer boxes and meta descriptions.
3. Send changed YMYL pages back to the reviewer before the change goes live, and keep the reviewer line only on a version the reviewer approved.
4. Update the visible date, dateModified and lastmod only on pages that changed substantially.
5. Each quarter, filter Search Console's Performance report to the guide's URLs, note articles that have lost impressions, and look for pages that now overlap.
6. Before each new batch, re-read the money pages the batch will link to.

The broader cycle of planning, publishing and refreshing is described in the GEO content lifecycle.

Conclusion

Keeping a guide current is mostly bookkeeping: a register of dated facts, recheck dates set ahead of known changes, honest visible dates, a lastmod that moves only when content does, and a clear rule for merging overlapping pages. It is unglamorous work, and it is what keeps a large guide trustworthy after launch. Recheck dates are step eight of the method in our TOFU, MOFU, BOFU content strategy (top, middle and bottom of funnel), and content refreshes are part of our content marketing services. More guides are in our GEO and AEO Guide.

Frequently asked questions