Pick one publication date field and stick with it
Most CMS platforms offer several date fields: created date, published date, modified date, scheduled date. Some let you add custom date fields. This abundance creates a problem—which date actually controls when content appears on your site?
The field that controls visibility wins
Your publication date should be the field that determines whether content is publicly visible. Not the date you started drafting. Not the date you last edited metadata. The date that flips content from hidden to live.
In WordPress, that's the publish date. In static site generators, it's usually the date in your front matter that the build process checks. In headless CMSs, it's whichever timestamp field your API query filters against. Find that field in your system and treat it as the source of truth.
Stop using creation date as publication date
Creation date records when someone first saved a draft. That's useful for internal tracking, but it's not a publication date. If you draft a post in January and publish it in March, the publication date is March.
Some systems default to showing creation date in URLs or archives. Override this. Your URL structure should reflect when content went live, not when someone started working on it.
Modified date is for updates, not launches
Modified date tracks the last time anyone touched the content. That includes typo fixes, tag adjustments, or image swaps. It's valuable for revision tracking, but it's not your publication date.
If you display "last updated" on pages, that's fine. Just don't let it replace or confuse the original publication date. Readers and search engines need both pieces of information, clearly labeled.
Scheduled date should set publication date
If you schedule content to publish later, the scheduled date should become the publication date when that moment arrives. Not the date you configured the schedule. Not the date the cron job ran. The date you intended the content to go live.
Some systems create a gap here—the scheduled date lives in one field, and publication date gets set to whenever the system processed the queue. Fix this in your CMS settings or workflow. Scheduled date and publication date should be the same value once content is live.
One field, one label, one purpose
Once you've identified your publication date field, name it clearly. Not "date." Not "timestamp." Call it "Publication Date" or "Published On." Make sure everyone creating content knows this is the field that matters.
Then stop adding alternative date fields that might compete with it. If you need internal tracking dates, keep them in a separate admin section where they won't create confusion.
When you log publication activity, reference this single authoritative date field. When you sort archives, filter by it. When you generate feeds, pull from it. One field, doing one job, consistently.