I stopped using SEO Plugins like a year ago or so.
SEOPress Premium was the last one I used
I did it due to four main reasons:
- I am obsessed with having the least amount of plugins possible.
- I want to challenge myself and see If I could create mu-plugins who could take of SEO Basics.
- I didn’t want to pay for premium plugins for a tiny premium feature here and there.
- SEO Plugins tend to get bloated as they become popular.
When I started creating mu-plugins for my websites, I chose to included published and modified date since that was a common practice.
Lots of publishers did that after listening influential people in the industry telling everyone that Google rewarded fresh content.
For instance, one of my mu-plugins outputted this into the head section of my HTML
<meta name="published-date" content="2022-12-20">
<meta name="modified-date" content="2024-10-23">
I also added “published on” and “updated on” to the hero section of my posts and pages.
The related-posts section also displayed the last modified date under the post title
And now that I think about the last modified date used to be part of the list of posts shown using WordPress Query Loop.
Table of Contents
Removing or Not Removing the Dates from Source Code?
When Google hit most of my sites. I removed the dates from the posts lists and related post sections.
I didn’t remove the dates from the head section of my site’s HTML or from the hero section of my posts and pages.
Why didn’t I remove traces of published and modified dates from my sites?
- Simply because having a last updated or last modified date is not a terrible idea for some searches.
- There are some instance in which I truly care when the article was published and or if it was recently updated.
- Sometimes seeing that an article has been recently updated makes you trust what you read even more.
Having said, I knew that lots of people were recommending to update posts to get a boost in rankings.
This is probably the reason why Google asks:
Are you changing the date of pages to make them seem fresh when the content has not substantially changed?
Creating helpful, reliable, people-first content
Let’s say you are not one of those guys who is trying to game the system and you are genuinely adding bits of information to your posts and pages.
You will probably get hit in the cross fire, since we don’t know what “substantially changed” means for Google.
Freezing Modified Dates
When reading about the impact that modified dates can have on SEO, I found out that some plugins are locking or freezing modified dates and published dates.
- Rank Math provides a guide on How to Lock the Modified Date of Your Posts.
- All in One SEO also has the option to prevent the “post modified” date from being changed.
There are also plugins that let’s you have control over the modified date of your post.
Mu-Plugin to Freeze or Lock Modified Dates
If you are not a big fan of using SEO Plugin or adding a specific plugin to have this feature, you probably want to do this via a mu-plugin.
To use this mu-plugin, you just have to create a custom field:
Field Type | True or False |
Field Name | freeze_modified_date |
This plugin will lock the modified date by default and you will have to choose Unfreeze from the custom fields to make sure changes in the modified date are visible on the source code or on your pages.
<?php
/*
Plugin Name: Custom Modified Date Management
Description: Prevent updates to modified dates unless a specific custom field condition is met.
Version: 1.2
Author: TicoLibre
*/
if ( ! defined( 'ABSPATH' ) ) {
exit;
}
add_filter( 'wp_insert_post_data', 'modified_date_freezer', 10, 2 );
function modified_date_freezer( $data, $postarr ) {
// Return if post ID is zero, indicating that a new post is being processed.
if ( (int) $postarr['ID'] === 0 || !$postarr['ID'] ) return $data;
// Get the post before the update.
$post_before_update = get_post($postarr['ID']);
// Return if the modified date is not set.
if ( !isset($data['post_modified']) ||
!isset($data['post_modified_gmt']) ||
!isset($post_before_update->post_modified) ||
!isset($post_before_update->post_modified_gmt) ) {
return $data;
}
// Get the value of the custom field.
$freeze_modified = get_post_meta( $postarr['ID'], 'freeze_modified_date', true );
// Check if the custom field has value '1' to allow modification.
if ( $freeze_modified === '1' ) {
// Allow the modified date to be updated if the custom field is '1'.
return $data; // The modified date can change normally.
} else {
// Lock the modified date by reverting to the original modified date.
$data['post_modified'] = $post_before_update->post_modified;
$data['post_modified_gmt'] = $post_before_update->post_modified_gmt;
}
return $data;
}
The primary functionality is to lock the modified date from being updated unless certain conditions are met.
- The plugin checks a custom field (freeze_modified_date) associated with each post to determine whether the modified date should be locked or allowed to update.
- If the custom field is not set (empty) or has a value of 0: The modified date is locked, meaning it will remain unchanged even when content is modified.
- If the custom field has a value of 1: The modified date can be updated normally. This allows authors or editors to control when they want the modified date to reflect changes in the post.
Issues with the Mu-Plugin
By default, the plugin locks/freezes the modified date since there is no value stored in the post_meta table for the freeze_modified_date field linked to an specific post.
When you changed the value to Unfreeze, the value for that field will be “1” and if you switch back to freeze , the value will be “0”
The only issue present in the plugin is that Custom Fields are not auto-saved, so changing from Freeze to Unfreeze requires that you click the update or save button twice for the plugin to behave the way you expected.
Another issue that you will find while using the mu-plugin is that revision won’t get the right date so that might be a bit confusing if you for some reason has to restore a revision.
Using Custom Date (ACF + Mu Plugins)
What I am doing today is to create a custom modified date using Advanced Custom Fields (ACF) and use that custom date for:
meta settings, hero sections, and schema code and core sitemaps.
So WordPress keeps keeping track of the many times I have updated a post or page but that’s not visible on the source code.
I created a custom plugin that I ran only once to populate the custom field for every existing post if there was no value in them.
<?php
/*
Plugin Name: Update Locked Modified Date
Description: Populate the custom field with post_modified_gmt if it is not already set.
Version: 1.1
Author: TicoLibre
*/
function populate_locked_modified_date() {
// Retrieve all public post types
$post_types = get_post_types(array('public' => true));
// Set up query args to include all public post types
$args = array(
'post_type' => $post_types,
'post_status' => 'publish',
'numberposts' => -1 // Retrieve all posts
);
// Retrieve all posts of the specified types
$posts = get_posts($args);
foreach ($posts as $post) {
// Check if the custom field is already set
$locked_modified_date = get_post_meta($post->ID, 'locked_modified_date', true);
// Only update if the custom field is empty
if (empty($locked_modified_date)) {
// Get the post modified GMT value
$modified_date_gmt = get_post_field('post_modified_gmt', $post->ID);
// Update the custom field with the modified GMT value
update_post_meta($post->ID, 'locked_modified_date', $modified_date_gmt);
}
}
}
// Run the function only once to avoid multiple executions
add_action('init', 'populate_locked_modified_date');
After that I modified the different mu-plugin that display the modified date and changed to start using the custom modified date from the locked_modified_date field.
So no matter how much information I add this post, the last time this was updated was Nov 3rd, 2024