A WordPress date audit checks whether each article’s visible publication and update dates agree with WordPress, Article structured data, and the XML sitemap. Accurate dates help readers judge freshness and give search systems consistent evidence. They do not guarantee rankings or AI citations, and changing a date without improving the page is not a genuine refresh.
What you need before a WordPress date audit
Choose five to ten published posts, including one new article, one substantially updated article, and one page that has only received minor edits. You need WordPress administrator access, the public URLs, the rendered page source or a structured-data testing tool, and the post sitemap. Record the site timezone under Settings and note whether a theme or SEO plugin controls the visible dates and Article markup.
If your team does not yet define what qualifies as a meaningful update, create that rule first. The site’s WordPress editorial policy should distinguish substantive changes from typo fixes, template changes, and automated saves.
Use this WordPress date audit checklist
| Surface | Pass condition | Common problem |
|---|---|---|
| Visible article | Clearly labels Published and, when useful, Last updated | Date is missing, vague, or buried |
| WordPress record | Original publish time is preserved | Publication date is overwritten during a refresh |
| Article markup | Uses accurate ISO 8601 values and timezone | Plugin and theme output conflicting values |
| XML sitemap | Last modification reflects a significant page change | Every save resets the value |
| Editorial evidence | Update notes explain the substantive revision | Fresh date appears without changed content |
How to audit WordPress publish and modified dates
1. Record the source dates in WordPress
Open each post and record its published and last modified timestamps. Do not change them during the audit. Confirm the site timezone so a UTC value in markup is not mistaken for a one-day error. Keep the original publication date even after a major refresh; the modification date should carry the new update time.
2. Check the dates readers can see
Open the public article in a private browser window. Look near the title, byline, or introduction for an unambiguous label such as “Published” or “Last updated.” Google recommends a prominent user-visible date and says equivalent visible and structured values should be consistent in its byline date guidance.
WordPress supports a Post Date block and a Modified Date variation in block themes. The official Post Date block documentation explains that the block can be added to the single-post template for a consistent layout. A classic theme may instead require a theme setting or a developer-reviewed template change.
3. Inspect Article structured data
View the rendered source and find the BlogPosting, Article, or NewsArticle object. Compare datePublished and dateModified with the WordPress record. Values should use ISO 8601 format, ideally with the correct timezone offset. If multiple Article objects disagree, identify whether the theme, SEO plugin, or another schema plugin created each one before disabling or editing anything.
Google lists both properties as recommended Article fields and advises adding timezone information. Its Article structured data documentation also recommends validating markup before release. Schema should describe what a reader can verify on the page, not manufacture freshness.
4. Decide whether the modified date is deserved
Review the revision, not just the timestamp. A new example, corrected process, refreshed source, rewritten recommendation, or material link change can justify a new modified date. Fixing punctuation, changing a button color, or opening and saving a post usually does not. Use the content refresh workflow to document what changed and why it improves the reader’s task.
5. Compare the sitemap last modification value
Open the post sitemap and find the canonical URL. Compare its lastmod value with the significant update. Google says it uses this value when it is consistently and verifiably accurate; changes to main content, structured data, or links can be significant, while a copyright-date change is not. Check the exact rules in Google’s sitemap documentation.
6. Resolve the date owner
Choose one component to own each output. For example, let the theme display the dates, the SEO plugin create one Article object, and the sitemap plugin supply lastmod. Remove duplicate output only after confirming its source and taking a backup. Then clear caches and repeat the public-page, markup, and sitemap checks.
Illustrative worked example
Suppose a guide was published on March 5 and substantially revised on September 12 with new screenshots, corrected steps, and a primary-source reference. WordPress still shows March 5 as published and September 12 as modified. The public page says “Published March 5” and “Last updated September 12.” Article markup carries both timestamps with the site timezone, and the sitemap shows September 12.
That row passes. If the same post instead received one spelling correction on October 2, changing every modified value to October 2 would overstate the update. Record the minor edit internally, keep the public update date tied to the September revision, and verify the site’s automation does not force a false October freshness signal.
How to troubleshoot failed date checks
- Visible date differs by one day: compare the WordPress timezone with the offset in structured data.
- Two modified dates appear: inspect the theme template, block template, and plugin settings for duplicate output.
- Schema changes but the page does not: make the visible label consistent or stop emitting an unsupported modified value.
- Sitemap updates after every save: document the behavior and ask the plugin developer whether significant-update filtering is supported.
- Search shows another date: reduce distracting dates where practical, but remember Google estimates dates from several signals and does not guarantee a chosen byline date.
Limitations of a date audit
This audit verifies consistency and editorial honesty; it cannot show whether an AI system cited the page or why Google selected a particular search-result date. Search systems may use several signals, and interfaces can change. Do not backdate posts, replace publication dates with update dates, or bulk-refresh timestamps to imply work that did not happen. Pair accurate dates with useful content, verifiable sources, and appropriate schema markup.
Frequently Asked Questions
Should a WordPress post show both published and updated dates?
Show both when the original publication history matters and the article has received a meaningful revision. A new post only needs its publication date. Clear labels help readers understand what each date represents.
Does changing a WordPress post date improve rankings?
No. A new timestamp alone does not make content more useful or guarantee better rankings. Update the date only when the page has changed enough to justify telling readers it was revised.
What should count as a significant content update?
A significant update changes the page’s substance, accuracy, or usefulness. Examples include corrected instructions, new evidence, a rewritten recommendation, an important example, or material changes to structured data and links.
Should dateModified match the sitemap last modification date?
They should normally describe the same significant revision, although their formats or precision may differ. Investigate large differences because they can indicate caching, timezone, plugin, or automated-save problems.
Can accurate dates guarantee visibility in AI search?
No. Accurate dates make freshness claims easier to verify, but no date field guarantees inclusion, citation, or ranking in an AI search experience. Content quality and technical accessibility still matter.
How often should I repeat a WordPress date audit?
Repeat it after theme or SEO plugin changes and during scheduled content reviews. A small sample every quarter is often enough to reveal systemic problems without repeatedly editing stable posts.
Conclusion
A reliable WordPress date audit reconciles the database record, visible labels, Article markup, sitemap, and actual editorial work. Preserve the original publication date, update modification signals only after substantive changes, and fix conflicting outputs at their source. The result is a clearer history for readers and cleaner evidence for search systems without pretending that timestamps guarantee visibility.