The date and time format in WordPress core settings affects far more than display. It dictates how publication dates render in archive pages, RSS feeds, Article structured data, and Google search results - and a misconfigured format breaks all of them.
Why this matters
When the format is empty or returns raw template strings instead of a real date, WordPress outputs literals like F j, Y instead of "May 7, 2026". Users lose trust instantly. Worse, structured data for Article or BlogPosting passes the raw text to Google, which rejects it as invalid instead of rendering a publication date in rich results.
Google uses dates in several critical surfaces: in the Article card on Google Discover, in the "Updated" line of search snippets, and in the Freshness algorithm that prefers recent content for newsy queries. If the date is malformed or missing, Google may pick a date itself from the body text (often wrong) or show the result without any date at all.
There is also a localization angle. A Hebrew site with US-style "May 7, 2026" looks foreign and unprofessional. An English site using d/m/Y confuses American readers expecting m/d/Y. The right choice depends on the audience.
How to detect
Open Settings > General and scroll to "Date Format" and "Time Format". If the fields are empty or display strange placeholders, you have a problem. Second, open a recent post in the browser and inspect the date below the title - if it shows %Y-%m-%d literally instead of a formatted date, the setting is broken.
Third check: visit the Google Rich Results Test, paste a post URL, and look for datePublished and dateModified in the structured data output. The value must be in the international date-format standard format (like 2026-05-07T10:00:00+02:00). An empty or non-conforming string triggers a warning and prevents the rich result from rendering.
How to fix
Go to Settings > General. Under "Date Format" pick one of the predefined options or enter a custom format. For an English site "F j, Y" ("May 7, 2026") or Y-m-d (ISO style) work well. For a Hebrew site d/m/Y or j בF Y ("7 במאי 2026") feel native.
Under "Time Format" choose between 24-hour (H:i, displays "14:30") or 12-hour (g:i a, displays "2:30 pm"). Save changes.
If the site is multilingual via Polylang or WPML, each language has its own format setting. Verify each one is configured - the plugin typically adds a field under the language settings page.
Common mistakes
First mistake: using non-PHP format strings. WordPress uses PHP's date() function so you must use its format codes. YYYY or MM do not work - it must be Y and m. The full reference is on php.net under date format characters.
Second mistake: ignoring themes that hardcode formats. Some themes (Astra and GeneratePress in certain configurations) bake a date format into functions.php or directly into a template file rather than calling get_the_date() with no arguments. In that case changes in the core settings have no visible effect on actual posts and you must edit the theme file.
Third mistake: showing publication date when modified date is more useful. For evergreen content (guides, reviews), users prefer "Updated May 7, 2026" over "Published March 12, 2019". Inspect the theme - if it uses get_the_date() only, swap in get_the_modified_date() or display both alongside.
Verifying the fix
After saving, open a post in the browser and confirm the date renders correctly. Run a post URL through Google Rich Results Test and verify datePublished and dateModified are valid the international date-format standard strings. Hit the RSS feed (/feed/) and confirm <pubDate> is in RFC 822 format. With everything valid, Google will reflect dates in search results within days.
dateModified updates automatically on every meaningful edit, not just publication.