Context
Documentation is known to get stale. SEO rewards content with metadata that is newer, rather than older. However, changing the original publish date can affect this and is not a great solution. Many large content producers have added metadata that specifies the date of publication, as well as the last time the content was updated, and last time the content was verified. While this isn't necessary for blogs, it greatly helps reader confidence in technical content such as tutorials and documentation.
Currently, the blog plugin supports a published date that is automatically added to the blog post when built. This date field in the metadata currently benefits from being automatically converted to the set date format specified in the configuration file. However, if any other dates are added to the metadata file they do not get converted.
I'm proposing adding a date_verified and date_updated field to the metadata that also get the benefit of date formatting and are applied to the blog post, similar to the date metadata option if set.
Description
Add a date format normalization for two new metadata fields date_updated and date_verified (naming convention up to you) to allow for these fields to be set properly in the metadata and automatically show up in the blog if set.
Related links
Use Cases
An author of the content would add the date_verified and date_updated keys to their metadata specifying when the content was last verified for correctness and updated respectively. Mkdocs-material would then format the dates similarly to how it does for the date field here and make that variable available for the templates. There could also be additions made to the plugin to allow for this information to be automatically added to the metadata sidebar as shown in the image below.
As a user, I would see that the documentation, tutorial, or blog that I'm reading is actively being maintained and have more confidence in its viability before continuing with it.
This change would greatly impact the quality of the documentation for all who chose to use it, not only from a user experience standpoint but also from an SEO vantage as newer content tends to be ranked higher.
Visuals
Before submitting
Context
Documentation is known to get stale. SEO rewards content with metadata that is newer, rather than older. However, changing the original publish date can affect this and is not a great solution. Many large content producers have added metadata that specifies the date of publication, as well as the last time the content was updated, and last time the content was verified. While this isn't necessary for blogs, it greatly helps reader confidence in technical content such as tutorials and documentation.
Currently, the blog plugin supports a published
datethat is automatically added to the blog post when built. This date field in the metadata currently benefits from being automatically converted to the set date format specified in the configuration file. However, if any other dates are added to the metadata file they do not get converted.I'm proposing adding a
date_verifiedanddate_updatedfield to the metadata that also get the benefit of date formatting and are applied to the blog post, similar to thedatemetadata option if set.Description
Add a date format normalization for two new metadata fields
date_updatedanddate_verified(naming convention up to you) to allow for these fields to be set properly in the metadata and automatically show up in the blog if set.Related links
Use Cases
An author of the content would add the
date_verifiedanddate_updatedkeys to their metadata specifying when the content was last verified for correctness and updated respectively. Mkdocs-material would then format the dates similarly to how it does for thedatefield here and make that variable available for the templates. There could also be additions made to the plugin to allow for this information to be automatically added to the metadata sidebar as shown in the image below.As a user, I would see that the documentation, tutorial, or blog that I'm reading is actively being maintained and have more confidence in its viability before continuing with it.
This change would greatly impact the quality of the documentation for all who chose to use it, not only from a user experience standpoint but also from an SEO vantage as newer content tends to be ranked higher.
Visuals
Before submitting